8 Что нового в Zabbix 2.2.3

8.1 Массовые SNMP запросы

Производительность SNMP мониторинга существенно улучшена введением массовых запросов до 128 элементов данных одновременно. Нагрузка на сервер Zabbix и опрашиваемые SNMP устройства должна значительно уменьшиться:

обычные SNMP элементы данных имеют эффект от GetRequest-PDU с большим количеством переменных значений;
низкоуровневые правила обнаружения SNMP (версий SNMPc2 и SNMPv3) имеют эффект от GetBulkRequest-PDU c большим значением поля "количество повторений";
элементы данных SNMP с динамическими индексами имеют эффект от обоих этих улучшений: в первом случае от проверки индексов, во втором для построения кэша;

Смотрите дополнительную информацию об обработке массовых SNMP запросов.

8.2 Изменения в веб-интерфейсe

8.2.1 Обновленные переводы

Португальский (Бразильский)
Итальянский
Японский
Словацкий
Турецкий

8.3 Улучшения демонов

Существенно улучшена производительность обработки графиков в процессе низкоуровневого обнаружения. Тестирование с 2048 графиками показало, что количество SQL запросов стало в 600 раз меньше, чем ранее. Последующие запуски без каких-либо изменений показали что количество SQL запросов стало в 2500 раз меньше, и если необходимо изменить только название графика, количество SQL запросов стало 1500 раз меньше. Общее количество SQL запросов было меньше в 3.7 раза первоначального обнаружения, в 3000 раз меньше для следующих обнаружений без изменений и в 1500 раз меньше когда необходимо изменение названия графика.
Графики, созданные низкоуровневым обнаружением, не будут удалены и будут продолжать работать если соответстующие элементы данных более не обнаруживаются (до тех пор, пока эти элементы данных будут удалены).
Была добавлена групповая обработка услуг IT. Это устраняет возможные блокировки и улучшает производительность при обработке больших деревьев услуг IT. Тестирование с 800 услугами IT при глубине дерева равной 4 уровням показало улучшение производительности на 300%.
Значительно улучшен мониторинг лог файлов (элементы данных log[] и logrt[]):
- более эффективное чтение лог файлов и поиск строк согласно регулярным выражениям.
- более эффективный выбор лог файлов при проверке элементов данных logrt[].
- если длина строки лог файла превышает 256КБ, только первые 256КБ проверяются на соответствие регулярному выражению, оставшаяся часть строки игнорируется. Тем не менее, если Zabbix агент был остановлен во время его работы с длинной строкой и позиция где он работал утеряна, то длинная строка может быть проанализирована повторно после того как агент будет запущен снова.
- для элементов данных типа log[]: при возникновении проблем с лог файлом (файл отсутствует или не доступен для чтения) элемент данных log[] меняет статус на НЕ ПОДДЕРЖИВАЕТСЯ. До этого изменения (в версии 2.2.2) из-за ошибки в агенте переход в статус НЕ ПОДДЕРЖИВАЕТСЯ не происходил.
- для элементов данных logrt[]:

      * На UNIX платформах элемент данных ''logrt[]'' становится НЕ ПОДДЕРЖИВАЕМЫМ, если директория, где должны находится лог файлы, не существует.
             * Однако, на Microsoft Windows, если директория не существует, элемент данных не станет НЕ ПОДДЕРЖИВАЕМЫМ (например, если в имени директории допущена опечатка). На данный момент это ограничение агента.
             * Отсутствие лог файлов не делает элемент данных ''logrt[]'' НЕ ПОДДЕРЖИВАЕМЫМ. 
             * Ошибки чтения лог файлов элементом данных ''logrt[]'' журналируются как предупреждения в лог файле Zabbix агента, но не делает элемент данных НЕ ПОДДЕРЖИВАЕМЫМ.
         * Лог файл Zabbix агента может быть полезен, чтобы определить почему элемент данных ''log[]'' или ''logrt[]'' стал НЕ ПОДДЕРЖИВАЕМЫМ. Zabbix может осуществлять мониторинг лог файла агента, кроме случая когда  DebugLevel=4.
         * Пожалуйста обратите внимание, что хотя производительность проверок элементов данных ''log[]'' и ''logrt[]'' была улучшена, лимиты на максимальное количество анализируемых строк лог файла и число совпавших строк отправляемых серверу за одну проверку не были изменены. К примеру, если элемент данных 'log[]'' или ''logrt[]'' имеет //Интервал обновления// 1 секунда, по умолчанию агент не анализирует более чем 400 записей лог файла и не отправляет более чем 100 совпавших строк Zabbix серверу за одну проверку. Увеличением параметра **MaxLinesPerSecond** в конфигурационном файле агента или установка параметра **maxlines** в ключе элемента данных лимит может быть увеличен до 4000 анализируемых строк лог файла и до 1000 совпавших срок отправляемых Zabbix серверу в одну проверку. Если //Интервал обновления// 2 секунды, лимиты для одной проверки может бы быть установлен в 2 раза больше чем для //Интервала обновления// 1 секунда.
       * Скрипты запуска и остановки Java gateway более не скрывают сообщения об ошибках при запуске/остановке. Сейчас они также обнаруживают устаревшие PID файлы и должны работать в /bin/sh.
       * Исправлено коректное отображение Кэша значений (сободный кэш был больше чем доступного) 
       * Исправлена ошибка, при которой сообщалось  больше свободного места в кэше значений, чем было реально доступно. 
       * Улучшено сообщение об ошибках элементов данных VMware. Теперь вместо общего сообщения "Простая проверка не поддерживается" отображается подробное сообщение об ошибке. 
       * Максимальный размер отправляемых данных был увеличен с 64МВ до 128МВ для обратной совместимости с предыдущими версиями Zabbix. В случае если один процесс с лимитом отправляемых данных 128МВ отправляет данные другому с лимитом 64МВ, процесс получатель сбросит данные из-за превышения лимита размера.
       * Максимальный размер конфигурационного кэша (configuration cache) увеличен с 2GB до 8GB.
       * Для ДБ Oracle для групповых вставок теперь используется биндинг переменных, что дало значительное улучшение производительности.

8.4 Другие доработки

Страница руководства (manpage) по демону Zabbix агента описывает значение типов вывода параметров -p или -t.

Documentation