Ad Widget

Collapse

Proxy problems

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • dhl
    Junior Member
    • Mar 2014
    • 9

    #1

    Proxy problems

    Hello,

    I've set up my Zabbix environment with one server and two proxies, all running version 2.2.3. I got few problems with proxies, so I hope someone could help me a bit.

    1) Queue: All 3 hosts (server and proxies) show the same number for the internal item with key zabbix[queue,10m]. Queue is actually on one proxy, because there are some network devices down from time to time, but as the item shows the same number for each host, I have 3 different triggers showing like the problem is appearing on server and other proxy too. So how to avoid this item showing overall queue and just to show the number of queued items on the current host (server or one of the proxies etc)?

    2) Events when a proxy is down
    Maybe a pseudoproblem, but.. Problem starts when the server loses contact with a proxy, then proxy continues collecting data and saving that til connection is restored (or for the configured number of hours in parameter ProxyOfflineBuffer). The problem is that as we cannot see the realtime events collected by the proxy, we are not taking any actions until the connection is restored. Now when the connection is restored, all the collected data is sent from proxy to server. This causes lots of triggers being activated at once showing all the triggers that had problems during the downtime. As some/all of the things may have been repaired already, we get the info with a delay. How to avoid triggers to light up when the problem is already fixed before connection between proxy and server is restored?


    Raido
  • elvar
    Senior Member
    • Feb 2008
    • 226

    #2
    Assuming you have (nodata) triggers in use for those hosts behind the remote proxy, you should at least be notified when those hosts are down due to the proxy losing contact with the parent server. When this happens you could then throw the hosts at that location into a maintenance period so when everything comes back up you don't receive alerts as you normally would. Another option is to ensure the hosts have dependencies linked to your (nodata) triggers and make sure your (nodata) triggers are configured to stay in a problem state until you have had 30-60 minutes of connectivity before returning to OK status.

    Does this all make sense? If not I'll try and respond with better detail tomorrow.

    Regards,

    Comment

    • dhl
      Junior Member
      • Mar 2014
      • 9

      #3
      Hey,

      Thank you for your reply. Yes, it might do the trick, I haven't thought about it that way. Ofcourse it means that hundreds of triggers are dependent of one (nodata) trigger, so it's lot of manual configuring trigger dependencies.

      Now I need to know what to do about the problem number 1 - items showing same queues everywhere..

      Raido

      Comment

      Working...