ubuntu 10.04 LTS

There should be no additional restrictions like these in Zabbix 1.8.4, so we would appreciate more information on the issue. For instance, how is your item configured? Is it a trapper item that has a non-empty "Allowed hosts"? Is the item's host monitored by Zabbix proxy?

The item monitors a shell script that monitors my proxies (checks if zabbix_proxy runs etc):

#!/bin/bash
CONFIGFILE=/usr/local/etc/ftim/customers-enabled/$1
test -r $CONFIGFILE || (echo "Config not found"; exit 1)
. $CONFIGFILE

#Pingcheck
if ! (ping -c 1 $CUSTOMERHOSTNAME > /dev/null); then
zabbix_sender -z $ZABBIXSERVER - $ZABBIXHOST -k $FTIMKEY -o 1 > /dev/null;
exit
fi

...

#report ok
zabbix_sender -z $ZABBIXSERVER -s $ZABBIXHOST -k $FTIMKEY -o 0 > /dev/null

In 1.8.3 this worked flawless, since 1.8.4rc2 it doesn't work anymore!

Thank you for sharing the script. However, we would still like to know more about item and host configuration. In addition to the questions above, what do you mean by "Sending ... on my zabbix server to check something on a proxy fails"? Do you mean that if you send values using zabbix_sender from Zabbix server's machine to Zabbix server, it fails, but if you send values from Zabbix proxy's machine to Zabbix server, it works?

Example:

I execute this command on my Zabbix Server:

zabbix_sender -z MYZABBIXSERVERIP -s MONITOREDHOSTNAME -k ftim[proxy] -o 1

Then it returns

zabbix_sender [32324]: DEBUG: Answer [

]
Info from server: "Processed 0 Failed 1 Total 1 Seconds spent 0.000257"
sent: 1; skipped: 0; total: 1

I also get that output in my zabbix server log.

If I execute that command on the monitored zabbix proxy, it works flawlessy.

The item is configured as following:

Host: empty
Description: name
Type: zabbix trapper
key: ftim[proxy]
Type: Numeric (unsigned)
Data Type: Decimal
Units: empty
Use Custom Multiplier: no
Keep history & trends: 365/1095
Status: Active
Store Value: As is
show value: my value mapping
allowed hosts: empty
new application: empty
applications: empty

The host works...

Unsure. Could not reproduce the problem so far. Any additional details will be appreciated.

Can you give me a hint what information you need?
Thanks for your help!

Let us start by summarizing the information we already have at this point.

You have host P. Zabbix proxy is running on host P, but host P itself is monitored by Zabbix server. Zabbix server is running on host S. Host P and host S are different.

There is a trapper item T on host P. If you send values for item T using zabbix_sender from host P to Zabbix server, it works. If you send values for item T using zabbix_sender from any host other than P, including host S, it fails.

Is this correct?

This is correct, exactly!

(1) You wrote that it worked in 1.8.3, but not in 1.8.4rc2. Do you know whether it worked in 1.8.4rc1?
(2) Could you please execute the following SQL query on Zabbix server's database: "select * from items i, hosts h where itemid=<ITEMID> and i.hostid=h.hostid;", where <ITEMID> is the itemid of that trapper item. You can find out itemid from the URL of the item configuration page: http://localhost/zabbix/items.php?form=update&itemid=163845. If it contains sensitive informative, please send it to support_at_zabbix_dot_com.

(1) No, i am not sure whether it worked in 1.8.4rc1 or not
(2) See Attachment zabbix.txt

Output of select * from items i, hosts h where itemid=22787 and i.hostid=h.hostid;

the comments here seem to contradict each other.

this fails on the zabbix server :
zabbix_sender -z MYZABBIXSERVERIP -s MONITOREDHOSTNAME -k ftim[proxy] -o 1

"If I execute that command on the monitored zabbix proxy, it works flawlessy."

and from the summary by asaveljevs :

"Zabbix proxy is running on host P... There is a trapper item T on host P"

also, if the previously given information about which commands succeed and which fail was correct, the following from the summary actually is not correct :
"If you send values for item T using zabbix_sender from host P to Zabbix server, it works. If you send values for item T using zabbix_sender from any host other than P, including host S, it fails."
actually commands succeed when sent to zabbix proxy. which is "works as expected" for me.

one question which i don't see answered (sorry if i missed that) - is the proxy host set to be monitored by the proxy ? as in, is it prefixed by a proxy name in the host configuration list ?

richiv: Yes, the proxy itself is monitored by the proxy

well, then it fully works as expected. if a host is monitored by a proxy, all zabbix_sender communication should be through the proxy as well.

if so, this one can be closed

Was it a bug in previous versions that it in fact did work then? Or is there a possibility to make this work again?

it was sort of a minor bug, i guess. in general, only the entity monitoring a host should care about that host - in this case, a proxy monitoring some host should be the only one taking care about what trapper items the host has, thus it's not something that should be brought back

In the attached SQL query output, we see that proxy_hostid=0, which means that the host is monitored by Zabbix server, not Zabbix proxy.

Is this issue listed here? Maybe i could apply some patches to re-enable this "bug", because we have built ourselves a strategy to monitor some basic things outside zabbix (just to make sure zabbix is running on our server and proxies)

Aleksandrs: this is strange, because the host itself looks as in the attached screenshot

Screenshot of host configuration with proxy monitoring itself

Reformatted the SQL query output so that is more readable.

sql output is for a host "basic-services-proxy", screenshot one ends with "-monitoring".

i think two basic rules of #bash apply

please, give some summary as to server, proxy, monitored host, item and operations performed details. all the way we had server + proxy monitoring itself, suddenly 3rd host enters the scene...

basic-services-proxy is an item, not a host... It is the item that this is all about...

See item-and-host.png. According to it, "basic-services-proxy" is the host name of the host that the trapper item "ftim[proxy]" is attached to.

that is very strange...
Sorry i was wrong, "basic-services-proxy" is a template that contains the item "ftim[proxy]". That is the correct way round. Now i don't fully understand why it is listed as a host?!?

ok, so that's not the item on the host that you attached the output for - it's the item from the template.
while there's no 100% proof, i'd say the situation is as described before - server + proxy, proxy monitored by proxy, trapper item on proxy that accepts data through the proxy only.

i'd suggest monitoring proxies using the internal item, not custom scripts. see zabbix manual on items for more detail.

I have checked out the source code and found something suspicious:

file \src\libs\zbxdbhigh\proxy.c

Line 1284 ff

if (item.type == ITEM_TYPE_TRAPPER && 0 == proxy_hostid &&
FAIL == zbx_tcp_check_security(sock, item.trapper_hosts, 1))

If I comment this out, maybe it will work?

No, commenting it out will not make your scenario work, because these lines check whether the value is coming from allowed hosts - the "Allowed hosts" field in trapper item configuration that we asked you about earlier and you said it is empty.

In order to make it work, you would probably have to change DCconfig_get_item_by_key() and a significant part of indexing mechanism in src/libs/zbxdbcache/dbconfig.c, so that DCconfig_get_item_by_key() can find an item, regardless of proxy_hostid.

If you wish to check whether proxy is running, you can use internal check zabbix[proxy,XXX-monitoring,lastaccess], as suggested by Rich (see http://www.zabbix.com/documentation/1.8/manual/config/items#internal_checks for more information).

so works as expected -> closing

There must be someone who fixed this behaviour, maybe we can get him to help us? We don't want to use the internal checks because we have a much more efficient way to check a lot more than that with less data, that's why we want this bug back!

i'm sure breaking something fixed before counts more as a support request, not a bugreport
also, what's much more efficient about the way you do it ?

Can I open a support request then

As we are developing stuff for our company's own use, I can not post it in public, but we are going to contribute to zabbix soon, as we are in negotiations with zabbix SIA regarding a support contract and direct contact to you developers for exactly such things!

support requests on how to best approach a given problem would be best posted as part of the support contract

We finally found a solution for our problem. See dbconfig.c attached.
Starting with line 397, changed "static ZBX_DC_HOST"

I don´t know, if our solution is "best-practice"; it just works and gives us again the possibility to use zabbix_sender from a differnt server than the corresponding proxy-server of a host to send values to the host.

Would be fantastic to see a conf-settings for this security-related change.
Maybe in zabbix_server something like
"zabbix_sender_security = 0 | 1".

1. if patches are to be attached, svn diff (unified diff) format should be used;
2. what is the purpose for the changes attached ? is it to revert the fix that was committed to zabbix tree ?

1) sorry, will do this later
2) yes, this is the fix for our "problem" with zabbix_trapper as described here by Aleksandrs:
https://support.zabbix.com/browse/ZBX-3429?focusedCommentId=37931&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_37931

SVN patch for dbconfig.c

Since Zabbix works as expected, we will not be integrating the patch. However, I do not see any big problems with the patch, so if it works for you with the limitations it has (hosts named the same as proxies and only active proxies), please continue using it.

In general, the problem of redirecting traffic from proxy to server if the latter is down should be solved in terms of high availability on a more global level. So we will not be introducing a configuration parameter like ZabbixSenderSecurity at this point either, because that would be more of a hack than a real solution. Hopefully someday we will have a high availability solution that will solve your problem.