Ad Widget

Collapse

[3.4.8] net.tcp.service in simple check gives false positive result

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • wapplersystems
    Junior Member
    • Apr 2018
    • 3

    #1

    [3.4.8] net.tcp.service in simple check gives false positive result

    Hi, I have a problem with the simple check for HTTP and HTTPS Service. Both give me positive feedback, but I stopped the HTTP Server Apache.
    zabbix-get -s 127.0.0.1 -k net.tcp.service[tcp,<ip>,80]
    1
    I checked the result with nmap:
    PORT STATE SERVICE
    80/tcp closed http
    The port 80 ist open in the firewall, but the service is not running.

    I'm expecting a negative result or do I have a understanding problem? Maybe the default method is not the correct method?

    Just for sure I tested a real closed tcp port, like 81 and it gives a negative result.

    Zabbix version 3.4.8
    Last edited by wapplersystems; 29-04-2018, 19:13.
  • sicko
    Junior Member
    • Apr 2018
    • 5

    #2
    I believe the port is closed because there is nothing LISTENING on that port, and it should be considered as closed.

    Comment

    • wapplersystems
      Junior Member
      • Apr 2018
      • 3

      #3
      Originally posted by sicko
      I believe the port is closed because there is nothing LISTENING on that port, and it should be considered as closed.
      If closed or not. I think the simple test should discover if the HTTP Server is running or not. In this case the Apache server was not running, but the test said it was available.

      Comment

      • wapplersystems
        Junior Member
        • Apr 2018
        • 3

        #4
        The problem is, that the server is behind a "floating ip". This leads to a wrong measurement result of zabbix agent. Unfortunately, I do not know if you can solve the problem.

        Comment

        • Ilya Evseev
          Junior Member
          • Feb 2019
          • 7

          #5
          The same problem with Zabbix-agent 4.0.15.

          "net.tcp.service[http,hostname]" causes periodic trigger alerts while http://hostname is actually available (accessed by users and checked by external monitoring).
          Last edited by Ilya Evseev; 28-12-2019, 22:24.

          Comment

          Working...