Отрицательная длительность в "Проблемах"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Отрицательная длительность в "Проблемах"

    Сегодня вижу странное: сработал триггер, у которого длительность существования проблемы показывается как отрицательная: -2сек.

    Проблема создана: 26.12.2018 09:17:24
    Проблема решена: 26.12.2018 09:17:22

    Это как? Со временем и синхронизацией всё в порядке (более того, хост, на котором возникала проблема, сам является ntpd-сервером).

    Zabbix-сервер v4.0.3, хост с отрицательным временем - FreeBSD 11.1-RELEASE-p11, zabbix_agentd (daemon) (Zabbix) 3.4.8.

    #2
    https://www.zabbix.com/documentation...роблемы

    Comment


      #3
      Описанные в документации варианты возникновения отрицательной длительности проблемы не подходят к моему случаю. Упрощённое выражение проблемы (в реале у меня разные пороги для рабочего и нерабочего времени):

      {Template BIND:bind.stats.query[SERVFAIL].avg(5m)}>={$BIND_SERVFAIL_MAX} Тип: Zabbix агент (активный)

      Интервал обновления 1m, триггер срабатывает, если среднее за 5мин >= порога. Как тут может -2 секунды появиться - не понимаю.

      Может это и не относится к этой странности, но, полазив по "Проблемам", обнаружил, что сегодня же, в районе 3 ночи (точное время 03:06:50, сработало на всех узлах в одну и ту же секунду, так что проблемы, скорее всего, были со стороны сервера) у меня была массовая проблема практически на всех узлах, включая сам Zabbix сервер: "Zabbix agent on Zabbix server is unreachable for 5 minutes", и при этом почти у всех проблем (но НЕ у всех!) "Длительность" отрицательная, порядка 4 - 5 мин! Что за чудеса?
      Last edited by DSV12; 26-12-2018, 10:09.

      Comment


        #4
        NVPS и history write cache при этом проседали? Прокси использутете?

        Comment


          #5
          Originally posted by astrix89 View Post
          NVPS и history write cache при этом проседали? Прокси использутете?
          Ответ на оба вопроса - нет. Не проседали, прокси не использую.

          UPD: просто для справки, может кому пригодится: чаще всего BIND мониторят или используя утилиту rndc или, более предпочтительный вариант, используя statistics-channels, снимая данные в формате xml. Начиная с версии BIND 9.10 формат xml оставлен только версии 3 (это внутренняя версия xml-формата статистики bind-а). Под эти варианты можно найти хорошего качества готовые подборки конфигов/скриптов/шаблонов, н-р, Zabbix-Bind9-Statistics-Collection. Но как-то совершенно незамеченной осталась возможность снимать статистику с BIND-а в JSON-формате. Мне не попадался ни один пример, использующий этот формат, я и сам узнал об этом случайно, ткнувшись в документацию по BIND-у: https://ftp.isc.org/isc/bind9/9.12.2...stics_channels

          Может кому-то эта информация окажется полезной и человек сваяет новую версию Zabbix-BIND9 Statistics Collection, используя JSON-формат статистики.
          Last edited by DSV12; 26-12-2018, 10:57.

          Comment


            #6
            Originally posted by DSV12 View Post

            Может это и не относится к этой странности, но, полазив по "Проблемам", обнаружил, что сегодня же, в районе 3 ночи (точное время 03:06:50, сработало на всех узлах в одну и ту же секунду, так что проблемы, скорее всего, были со стороны сервера) у меня была массовая проблема практически на всех узлах, включая сам Zabbix сервер: "Zabbix agent on Zabbix server is unreachable for 5 minutes", и при этом почти у всех проблем (но НЕ у всех!) "Длительность" отрицательная, порядка 4 - 5 мин! Что за чудеса?
            Так, с "Zabbix agent on ... is unreachable for 5 minutes" в 03:06:50 кое-что прояснилось:
            Code:
            [[email protected] backups]# crontab -l
            0 3 * * 3,6 /root/backups/backup-db.sh
            [[email protected] backups]# cat backup-db.sh
            #!/bin/bash
            now=$(date +"%d-%m-%Y-%H-%M")
            mysqldump -u root zabbix | gzip -9 > /root/backups/mysql/zabbix-bak-$now.sql.gz
            [[email protected] backups]#
            Судя по тому, что
            Code:
            [[email protected] backups]# time mysqldump -u root zabbix > 1.dmp
            
            real    0m59.235s - дамп работает почти точно одну минуту
            user    0m18.589s
            sys     0m4.066s
            а проблемы возникают позже, в 03:06:50, виноват в "Zabbix agent on ... is unreachable" 'gzip -9'. Мда, хорошая многозадачность у centos 7 А ведь
            Code:
            cat /proc/cpuinfo | grep -E 'processor|model name'
            processor       : 0
            model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
            processor       : 1
            model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
            processor       : 2
            model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
            processor       : 3
            model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
            не совсем ведь слабенько. Диски - 1Tb, зеркало (mdadm), iostat проблем с производительностью не выявил. Ладно, сделаю дефолтные '-6' для gzip-а или приоритет ему понижу, посмотрим, будут агенты отваливаться или нет. Кстати, 'time cat 1.dmp | gzip -9 > 9.gz' выдал 'real 6m50.984s'. Точно оно...

            UPD: От же...
            Code:
            time cat 1.dmp | gzip -6 > 6.gz
            
            real    1m30.587s
            user    1m28.989s
            sys     0m1.875s
            
            ls -lah *.gz
            -rw-r--r-- 1 root root 295M Dec 26 16:38 6.gz
            -rw-r--r-- 1 root root 293M Dec 26 16:30 9.gz
            И зачем я этот '-9' использовал

            Last edited by DSV12; 26-12-2018, 11:42.

            Comment


              #7
              У меня подобная проблема, обсуждали в посте https://www.zabbix.com/forum/in-russ...решения

              Comment

              Announcement

              Collapse
              No announcement yet.
              Working...
              X