Использование системы мониторинга zabbix с 1с для мониторинга ключевых показателей бизнеса

Введение

В своей инструкции по установке и настройке zabbix я вообще не затрагиваю вопрос базы данных mysql или производительности сервера в целом. Я просто беру дефолтные настройки mariadb, которые идут с установкой и использую их. Когда у вас не очень большая инфраструктура на мониторинге этого вполне достаточно, чтобы нормально пользоваться системой.

Если вы активно используете zabbix и внедряете его повсеместно во все используемые системы (а я рекомендую так делать), то вы рано или поздно столкнетесь с вопросом производительности системы мониторинга и размера базы данных zabbix.

Тема производительности zabbix очень индивидуальная. Она напрямую зависит от того, как вы его используете, а схемы мониторинга могут быть очень разные. Одно дело мониторить несколько серверов, а другое дело нагруженные свичи на 48 портов со съемом метрик с каждого порта раз в 30 секунд.

Чтобы помочь вам разобраться в этой теме и прикинуть, к чему готовиться, я поделюсь с вами своим опытом эксплуатации заббикса, его нагрузки, производительности и обслуживания базы данных mysql. Расскажу, как можно уменьшить размер базы.

Проверка работы триггеров

Попробуем нарушить работу репликации mysql и проверим работу триггеров. Для этого я просто отключу vpn соединение, по которому доступны сервера. После разрыва связи на slave сервере следующая картинка статуса репликации:

Проверяем данные мониторинга репликации:

Значение Slave_IO_Running сменилось с Yes на Connecting и скрипт проверки вернул значение 0 вместо 1. Этого достаточно, чтобы сработал триггер и пришло оповещение о том, что репликация mysql сервера нарушена:

На почту пришло оповещение:

Восстанавливаем связь между серверами и ждем новой работы триггера и уведомления:

Проверяем Latest Data:

Все в порядке, мониторинг нормально отработал нарушение mysql репликации. Больше тут настраивать нечего, графики и экраны не нужны, в них нет необходимости. На этом работа по настройке мониторинга окончена.

Триггеры

Это логические выражения со значениями FALSE, TRUE и UNKNOWN, которые используются для обработки данных. Их можно создать вручную. Перед использованием триггеры возможно протестировать на произвольных значениях.

У каждого триггера существует уровень серьезности угрозы, который маркируется цветом и передается звуковым оповещением в веб-интерфейсе.

Не классифицировано (Not classified) — серый.
Информация (Information) — светло-синий.
Предупреждение (Warning) — жёлтый.
Средняя (Average) — оранжевый.
Высокая (High) — светло-красный.
Чрезвычайная (Disaster) — красный.

Некоторые функции триггеров

abschange — абсолютная разница между последним и предпоследним значением (0 — значения равны, 1 — не равны).
avg — среднее значение за определенный интервал в секундах или количество отсчетов.
delta — разность между максимумом и минимумом с определенным интервалом или количеством отсчетов.
change — разница между последним и предпоследним значением.
count — количество отсчетов, удовлетворяющих критерию.
date — дата.
dayofweek — день недели от 1 до 7.
diff — у параметра есть значения, где 0 — последнее и предпоследнее значения равны, 1 — различаются.
last — любое (с конца) значение элемента данных.
max\min — максимум и минимум значений за указанные интервалы или отсчеты.
now — время в формате UNIX.
prev — предпоследнее значение.
sum — сумма значений за указанный интервал или количество отсчетов.
time — текущее время в формате HHMMSS.

Прогнозирование

Триггеры обладают еще одной важной функцией для мониторинга — прогнозированием. Она предугадывает возможные значения и время их возникновения

Прогноз составляется на основе ранее собранных данных.

Анализируя их, триггер выявляет будущие проблемы, предупреждает администратора о возникшей вероятности. Это дает возможность предотвратить пики нагрузки на оборудование или заканчивающееся место на жестком диске.

Функционал прогнозирования добавили с обновлением системы 3.0, вышедшим в феврале 2016 года.

Настройка Zabbix

Основная наша идея заключалась в том, чтобы сделать в 1С HTTP-сервис, через который Zabbix будет забирать информацию из базы данных и строить на ее основании метрики, триггеры и оповещения.

Для начала разберемся, что такое узлы сети.

В обычном понимании мониторинга Zabbix узлы сети – это элементы инфраструктуры (такие как сетевое оборудование, физические и виртуальные сервера, базы данных, источники бесперебойного питания и прочее), с которых Zabbix постоянно считывает информацию.

В нашем случае, узлы сети – это торговые точки, производства, города и даже базы 1С. Это то, по чему мы хотим получать информацию.

На слайде показан узел сети – торговая точка сети СушиВок Санкт-Петербурга:

она принадлежит к нескольким группам, чтобы в дальнейшем удобно настраивать права доступа.
узел имеет IP адрес – это адрес базы, где находится данная торговая точка.

В Zabbix узлам сети можно добавлять пользовательские макросы. По сути, это реквизиты, которые в дальнейшем можно использовать в элементах данных, в триггерах и оповещениях.

На примере, показанном на слайде, макросы узла сети – это:

адрес URL базы, где находится торговая точка;
GUID данной точки.

Таким образом узлы сети — это элементы бизнеса, которые необходимо мониторить.

Переходим к элементам данных.

По сути, элемент данных – это и есть метрика. Даже в инструкции на сайте Zabbix написано, что элемент данных – это метрика, поэтому прошу не путаться, если я буду называть оба варианта.

Итак, метрика – это конкретный фрагмент данных, получаемый от узла сети.

Мы подразделяем метрики на «родительские» и зависимые.

«Родительские» метрики с некоторой периодичностью отправляют в 1С JSON с нужными ключами метрик, а в ответ получают из 1С JSON с такой же структурой, но уже с полученными данными.

В примере мы отсылаем ключи метрик:

MaxTimeKitchen – максимальное время отдачи кухни;
CountOrdersInKitchen – количество заказов на кухне и т.д.

И вместе с каждым ключом метрик отправляем $STOREGUID – это тот самый пользовательский макрос из узла сети.

На следующем слайде представлен пример JSON-структуры, полученной из базы 1С. Здесь мы видим результаты запрошенных метрик – например, максимальное время отдачи кухни равно 9 минутам, а активных заказов сейчас 2.

Получается, что родительская метрика хранит весь JSON с полученными данными из 1С, а зависимые метрики разбирают данный JSON и хранят уже конкретные значения.

В примере на слайде мы видим зависимую метрику «Совокупное время доставки», которая обновилась в 22:29 и получила информацию, что данный параметр равен 35 минутам.

Разбор JSON в Zabbix стал возможен с версии 4.0, которая вышла в 2018 году.

Установка и запуск службы zabbix

9. После того, как сохранили конфигурационный файл, открываем командную строку с административными правами. Для установки и запуска службы Zabbix agent в командной строке набираем:

«C:\Program Files\Zabbix_agent\bin\zabbix_agentd.exe» — config «C:\Program Files\Zabbix_agent\conf\zabbix_agentd.win.conf» — install

где:

C:\Program Files\Zabbix_agent\bin\zabbix_agentd.exe — путь до программы;

C:\Program Files\Zabbix_agent\conf\zabbix_agentd.win.conf — путь до конфигурационного файла.

После успешного применения команды появится вывод:

zabbix_agent.exe : service installed successfully

zabbix_agent.exe : event source installed successfully

Если командную строку запустить не с правами администратора, то получим ошибку:

zabbix_agentd.exe : ERROR: cannot connect to Service Manager: ….

Для запуска службы «Zabbix Agent» выполняем следующую команду:

net start «Zabbix agent»

После успешного выполнения команды в командной строке появится:

Служба «Zabbix Agent» успешно запущена.

Прописываем правила соединения в брандмауэре Защитника Windows

10. Для того, чтобы обеспечить передачу данных с клиента на сервер, необходимо разрешить zabbix агенту связываться с сервером. Пропишем необходимые правила для сетевого соединения в брандмауэре Windows. Открываем «Панель управления» далее «Брандмауэр Защитника Windows».

11. Далее выбираем «Дополнительные параметры».

12. В следующем окне выбираем «Правила для входящих подключений» — «Создать правило».

13. В открывшемся окне делаем выбор «Для программы», нажимаем «Далее».

14. Указываем с помощью кнопки «Обзор…» путь до программы, например %ProgramFiles%\Zabbix_agent\bin\zabbix_agentd.exe, нажимаем «Далее».

15. Выбираем «Разрешить подключение» — «Далее».

16. В новом окне задаем «Имя», например: «Zabbix_agent_in» — «Готово».

17. Затем открываем вновь созданное соединение Zabbix_agent_in, затем выбираем вкладку «Протоколы и порты»

Тип протокола: TCP

Специальные порты:

10050

Затем нажимаем «ОК».

Добавление узла сети на сервере Zabbix

18. Для добавления узла сети на сервере Zabbix заходим в веб-панель сервера с помощью логина и пароля, далее выбираем: «Настройка» — «Узлы сети» — «Создать узел сети».

19. В новом окне указываем:

Имя узла сети: например, Int

Группы: выбираем из списка с помощью кнопки «Выбрать» или пишем новое имя группы

Интерфейсы агента: задаем IP адреса клиента (в командной строке клиента надо набрать ipconfig /all)

20. Переходим на вкладку «Шаблоны», нажимаем «Выбрать» и из списка шаблонов, выбираем нужный, в данном случае «Template OS Windows», нажимаем «Выбрать».

21. Далее выбираем «Добавить» для присоединения выбранного шаблона, затем ниже нажимаем «Добавить» для добавления нового узла сети.

22. В списке появится новый узел сети, и через некоторое время узел сети станет зеленым. Это значит, что все настроено правильно и связь с клиентом установлена.

23. Если узел сети остается красным, то необходимо разбираться, в чем дело. Для этого наводим на значок в графе «Доступность» и читаем диагностическое объявление.

24. Далее переходим к клиенту и открываем лог файл zabbix агента (C:\Program Files\Zabbix_agent\conf\zabbix_agentd.win.conf).

Смотрим проблему, в данном случае:

failed to accept an incoming connection: connection from «192.168.11.49» rejected, allowed hosts: «192.168.20.158»

25. Для решения проблемы прописываем IP адрес клиента в конфигурационный файл zabbix агента:

Option: Server

Server=192.168.11.69, 192.168.20.158

26. Для применения измененных настроек перезапускаем службу Zabbix agent:

net stop «Zabbix agent»

net start «Zabbix agent»

27. Проверяем лог файл.

28. Если нет проблем, на сервере появится зеленый значок клиента.

Удаление zabbix агента

29. Для удаления zabbix агента, удаляем узел сети на сервере.

30. Останавливаем службу «Zabbix agent» на клиенте.

net stop «Zabbix Agent»

31. Удаляем папку с компонентами zabbix агента.

32. Удаляем правило для входящих подключений для zabbix агента.

Посмотреть видео как произвести установку, настройку и удаление zabbix агента можно здесь:

https://youtube.com/watch?v=uC14OHZSXUQ

Немного опечатались

Иногда бывает так, что порты и все доступы настроены, агент установлен, ошибок в логах нет, но метрики не приходят или приходят не полностью. В самом Zabbix хост “горит зеленым” и непонятно, что вообще происходит.

Можно потратить много времени на разбор ситуации, а причина окажется очень проста — ошибка в файле конфигурации из-за “копипасты”. То есть конфигурацию скопировали, но в файле не поменяли параметр “Hostname”. В итоге сервер Zabbix говорит, что агент доступен, но сам агент присылает данные для другого хоста. Вот так выглядит список дисков для проблемной машины. Нет никакой информации о дисках, но при этом общие показатели агент все же передал.

Как только мы исправим в файле конфигурации параметр “Hostname” на нужный (в нашем случае это “SRV-SQL-01-VM”), то картина сразу же изменится. В списке появятся все диски сервера.

Данные могут появиться не сразу, т.к. правила обнаружения выполняются не так часто, как получение обычных метрик, но Вы можете запустить их вручную в настройках хоста.

Копипаст — зло! Будьте осторожны!

Как это работает

Zabbix-сервер получает через zabbix-агенты информацию о пакетах и об операционной системе всех серверов в инфраструктуре.
Плагин (с помощью Zabbix API) получает ранее собранный Zabbix-сервером отчет об ОС. Непосредственно с серверов плагин ничего не получает. И на данном этапе не треует с ними прямого контакта.
Обработав полученную от Zabbix информацию плагин передает её в Vulners. От которого в ответ получает список найденных уязвимостей, их критичность и способ устранения.
Плагин обрабатывает полученные данные, агрегирует их для формирования статистики и формирует пакеты данных для передачи в Zabbix.
Плагин пушит в Zabbix данные в необходимом системе мониторинга формате. Делает он это с помощью утилиты zabbix-sender. После этого вы уже имеете в мониторинге все о найденных уязвимостях, которые отображаются на показанном ранее дашборде.
После подтверждения проблемы выполняется удаленная команда, которая передает плагину:
- Имя того, кто её инициировал
- Fix-команду исправления уязвимости
- Cписок серверов
Получив все это Zabbix Threat Control:
- Проверяет что команда на исправление инициирована тем, кем нужно. От того, кого не нужно — он команду не принимает
- Выполняет переданную ему команду на нужном количестве серверов.

По умолчанию плагин передает fix-команду на уязвимые сервера с помощью утилиты zabbix-get, обращаясь к Zabbix-агенту на целевом сервере с параметром . Такой способ подключения позволяет процессу обновления пакетов выполняться в фоне не быть привязанным к процессам zabbix-агента. Также есть возможность выполнять команду на целевом сервере через простое SSH-подключение. Способ выполнения fix-команд выбирается опцией в конфигурацоинном файле плагина.

И как результат работы — отсутствие уязвимых серверов, ваш спокойный сон и отличное настроение

Сжатие и оптимизация таблиц InnoDB

Файлы ibdata1 и ib_log

Большинство проектов с таблицами InnoDB имеют проблемы с большими файлами ibdata1 и ib_log. В большинстве случаев это связано с неправильной конфигурацией MySQL/MariaDB или архитектурой БД. Вся информация из таблиц InnoDB хранится в файле ibdata1, пространство которого само не используется. Я предпочитаю хранить данные таблицы в отдельных файлах ibd*. Для этого добавьте в my.cnf следующую строку:

innodb_file_per_table

или

innodb_file_per_table = 1

Если ваш сервер настроен и у вас есть продуктивные базы данных с таблицами InnoDB, сделайте следующее:

Сделайте резервную копию всех баз данных на вашем сервере (кроме mysql и performance_schema). Вы можете получить дамп базы данных с помощью этой команды:
После создания резервной копии базы данных остановите сервер mysql/mariadb;
Измените настройки в my.cfg;
Удалите файлы ibdata1 и ib_log;
Запустите демон mysql/mariadb;
Восстановить все базы из резервной копии:

После этого все таблицы InnoDB будут храниться в отдельных файлах, и ibdata1 перестанет экспоненциально расти.

Сжатие таблиц InnoDB

Вы можете сжимать таблицы с текстовыми данными / данными BLOB и экономить довольно много места на диске.

У меня есть база данных innodb_test, содержащая таблицы, которые потенциально могут быть сжаты, и поэтому я могу освободить место на диске. Прежде чем что-либо делать, я рекомендую сделать резервную копию всех баз данных. Подключитесь к серверу mysql:

# mysql -u root -p

Выберите нужную базу данных в консоли mysql:

# use innodb_test;

Чтобы отобразить список таблиц и их размеры, используйте следующий запрос:

SELECT table_name AS "Table",
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size in (MB)"
FROM information_schema.TABLES
WHERE table_schema = "innodb_test"
ORDER BY (data_length + index_length) DESC;

Где innodb_test — имя вашей базы данных.

Некоторые таблицы могут быть сжаты. Возьмем для примера таблицу b_crm_event_relations. Запустите этот запрос:

mysql> ALTER TABLE b_crm_event_relations ROW_FORMAT=COMPRESSED;

После его запуска вы можете увидеть, что размер таблицы уменьшился с 26 МБ до 11 МБ из-за сжатия.

Сжимая таблицы, вы можете сэкономить много дискового пространства на вашем хосте. Однако при работе со сжатыми таблицами нагрузка на процессор возрастает. Используйте сжатие для таблиц db, если у вас нет проблем с ресурсами процессора, но есть проблема с дисковым пространством.

Подготовка сервера к мониторингу процессов

Первым делом идем на целевой сервер и изменяем конфигурацию zabbix-agent. Нам надо активировать следующую опцию:

EnableRemoteCommands=1

Не забудьте после этого перезапустить агента.

# systemctl restart zabbix-agent

Предупреждаю, что подобная настройка — огромная дыра в безопасности сервера. Используйте на свой страх и риск. Чтобы у вас не было проблем с этим, настоятельно рекомендую ограничивать доступ к порту агента на сервере на уровне firewall только с сервера мониторинга. Так же в обязательном порядке использовать шифрованное соединение между сервером и агентом. Вообще, это универсальное правило при настройке мониторинга. В идеале, так надо делать всегда. Я стараюсь все это настраивать при работе мониторинга через интернет. Если проигнорировать данное предупреждение и оставить все в открытом доступе, то через разрешенные удаленные команды вам могут залить на сервер зловред.

Далее проверим команду, которая будет формировать список процессов для отправки на сервер мониторинга. Я предлагаю использовать вот такую конструкцию, но вы можете придумать что-то свое.

# ps aux --sort=-pcpu,+pmem | awk 'NR<=10'

Получаем список запущенных процессов, отсортированный по потреблению cpu и ограниченный первыми десятью строками. В данный момент на сервере с агентом нам делать нечего. Перемещаемся в web интерфейс Zabbix Server.

Установка обновления zabbix 5.0 до 5.2

Centos 7, 8

Для начала проверим список установленных пакетов zabbix в системе. Их название может быть разным в зависимости от используемых репозиториев. К примеру, в centos 7 у пакетов может быть дополнение в виде scl к названию пакета.

Centos 7:

# rpm -qa | grep zabbix
zabbix-web-5.0.5-1.el7.noarch
zabbix-web-mysql-scl-5.0.5-1.el7.noarch
zabbix-agent-5.0.5-1.el7.x86_64
zabbix-web-deps-scl-5.0.5-1.el7.noarch
zabbix-apache-conf-scl-5.0.5-1.el7.noarch
zabbix-release-5.2-1.el7.noarch
zabbix-server-mysql-5.0.5-1.el7.x86_64

Centos 8:

# rpm -qa | grep zabbix
zabbix-server-mysql-5.0.5-1.el8.x86_64
zabbix-web-5.0.5-1.el8.noarch
zabbix-web-mysql-5.0.5-1.el8.noarch
zabbix-web-deps-5.0.5-1.el8.x86_64
zabbix-release-5.0-1.el8.noarch
zabbix-agent-5.0.5-1.el8.x86_64

Устанавливаем обновление zabbix на сервер Centos 8, выбирая установленные у вас пакеты:

# yum upgrade zabbix-web zabbix-web-mysql zabbix-server-mysql zabbix-agent

Для centos 7 будет такой список:

# yum upgrade zabbix-web zabbix-web-mysql-scl zabbix-agent zabbix-server-mysql

Обращаю внимание, что на момент написания данной статья, пакетов 5.2 для Centos 7 в репозиториях нет. В официальных инструкциях их тоже нет и не понятно, будут ли

Как только появятся, я дополню статью.

После завершения обновления, запускаем zabbix-server.

# systemctl start zabbix-server

Проверяем лог сервера. Необходимо дождаться обновления базы данных

Важно не трогать в этот момент сервер, не прерывать обновление, не пытаться его перезапустить. Если база большая, обновление может длиться очень долго

Рекомендую сначала где-то протестировать этот процесс, прежде чем обновлять прод.

# tail -f /var/log/zabbix/zabbix_server.log

В конце должны получить сообщение:

2860543:20201029:173036.441 completed 100% of database upgrade
2860543:20201029:173036.441 database upgrade fully completed

Есть ненулевой шанс, что будет какая-то ошибка с базой. Чаще всего возникают проблемы с какой-то нестандартной записью в таблице. Туда может попасть какой-то необычный символ, или с кодировкой проблемы. В этих случаях удаляйте проблемные записи, меняйте кодировку базы zabbix.

После обновления переходите в web интерфейс и проверяйте версию Zabbix. Должна быть 5.2.

На этом обновления Zabbix до 5.2 на Centos завершено.

Debian / Ubuntu

Устанавливаем само обновление zabbix на сервер с Debian или Ubuntu следующей командой:

# apt upgrade zabbix-agent zabbix-frontend-php zabbix-nginx-conf zabbix-server-mysql

После завершения обновления, запускаем сервер:

# systemctl start zabbix-server

В момент запуска произойдет обновление базы данных. Для маленькой базы (1-2 гб) это не займет много времени. Вы можете даже не заметить процесса. Если база больше, то надо подождать, пока не закончится обновление. Следить за ним можно с помощью просмотра лог файла zabbix сервера.

# tail -f /var/log/zabbix/zabbix_server.log

После завершения обновления базы, сервер запустится. После этого можно запустить и агент.

# systemctl start zabbix-agent

В логах агента и сервера можно посмотреть версию запущенных сервисов.

Starting Zabbix Agent . Zabbix 5.2.0 (revision bcf99fb248).
Starting Zabbix Server. Zabbix 5.2.0 (revision bcf99fb248).

Теперь можно идти в веб интерфейс и смотреть на обновленную версию zabbix server. Перед этим почистите кэш браузера и удалите куки от страницы заббикса. Если этого не сделать, то могут быть проблемы и ошибки, с чем я не раз сталкивался. Если у вас в качестве веб сервера используется nginx, не забудьте поменять владельца директории /etc/zabbix/web на nginx, в том случае, если веб сервер работает от него. После обновления он будет принадлежать apache, а web интерфейс не заработает.

# chown -R nginx:nginx /etc/zabbix/web

Теперь можете лицезреть обновленную версию web интерфейса в браузере.

Подготовка к обновлению

Важная информация перед обновлением. Версия 5.4 без длительной поддержки. Через пол года к ней перестанут выходить обновления, так что вам обязательно придется обновляться на следующую версию. Если для вас не критичны нововведения этого релиза, пропускайте его и ждите новой LTS версии.

Если у вас версия ниже 5.2, то предварительно обновите ее до указанной. У меня есть цикл статей на тему обновления Zabbix:

2.4 до 3.0
3.0 до 3.2
3.2 до 3.4
3.4 до 4.0
4.0 до 4.2
4.2 до 4.4
4.4 до 5.0
5.0 до 5.2

Перед обновлением, сделаем на всякий случай бэкап базы данных. Для этого предварительно остановим сервер с агентом.

У меня что-то активно писалось в базу, поэтому сервер выключался долго. Я проверил лог zabbix-server, чтобы убедиться в корректном выключении. Там все нормально было, сервер штатно завершил работу, дописав то, что у него там накопилось. Так что бэкапим.

zabbix	название базы данных заббикса
-uzabbix	ключ -u и дальше имя пользователя базы данных
-p’password’	ключ -p и дальше пароль пользователя бд, если в пароле есть спецсимволы, экранируйте их одиночными кавычками

На всякий случай сохраним php скрипты админки, чтобы можно было оперативно запустить старую версию в случае нештатной ситуации. Хотя лично я сделал снепшот виртуалки перед обновлением, чтобы откатиться назад в случае проблем.

Centos 8

Подключаем репозиторий версии zabbix 5.4:

# rpm -Uvh https://repo.zabbix.com/zabbix/5.4/rhel/8/x86_64/zabbix-release-5.4-1.el8.noarch.rpm

Старый репозиторий от версии 5.2 будет автоматически удален.

Очищаем и пересоздаем кэш dnf:

Удаляем пакет текущего репозитория:

Подключаем новый:

Обновляем информацию о репозиториях:

Ubuntu 20

Удаляем пакет текущего репозитория:

Подключаем новый:

Обновляем информацию о репозиториях:

Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/5.4/ Дальнейшее обновление не будет отличаться от текущего.

К обновлению подготовились, можно приступать.

Вопросы

В последней версии Zabbix они не обещают решить проблему «девяти метрик»?
Когда я смотрел выступление разработчиков, которые рассказывали про возможности, которые они собираются включить в Zabbix версии 5.0, там ничего такого не было
Если не секрет, расскажите какие-нибудь кейсы с использованием интересных метрик и реакцию на них?
У нас, если при обмене данными накапливается большая очередь, и не отправляются данные больше 30 минут, всем программистам из Zabbix на почту рассылается сообщение, что очередь встала.
Расскажите про структуру сети Zabbix, сколько у вас серверов, есть ли прокси?
У нас используется один сервер Zabbix. На сервере 1С никакие вспомогательные прокси-серверы не разворачиваются – у нас центральный Zabbix сам запрашивает все данные, и этот обмен происходит с помощью веб-сервисов.
Метрики считывает 1С регламентным заданием или Zabbix периодически JSON запрашивает?
Когда вы настраиваете метрику в Zabbix, там очень гибко настраивается время опрашивания, вплоть до того, что ты можешь запрашивать эту метрику только по будням с 9 до 10, чтобы лишний раз не дергать 1С. И Zabbix каждый раз отправляет родительский JSON со списком метрик и GUID-ами узлов, которые хочет получить. И в ответ получает полный JSON с данными. А уже зависимые метрики разбирают этот JSON и получают из него элементы данных. Поэтому, отвечая на вопрос – никаких регламентных заданий. Это зло.
По поводу множества запросов в разные 1С. Вы говорите, что они легко подключаются. Как реализовано внедрение вашей подсистемы в эти базы?
Мы делали расширение 1С, чтобы можно было его подключать в несколько конфигураций.
Будет ли выложена эта публикация?
Собирались опубликовать. Выложу с инструкцией.
При онлайн-мониторинге и большом количестве метрик есть ли деградация производительности 1С?
Да, один раз было такое. Архитектурно немного некорректно сделано то, что в одной базе может быть 100 точек. И по сути, если метрика запрашивается каждую минуту, то каждую минуту запрашивается сто раз по количеству узлов. Но по-другому в той архитектуре, которую мы задумали, не сделать. Но даже при больших нагрузках все равно отрабатывало. Бывало, что, если метрика раз в минуту запрашивается, бывают пропуски, а потом все нормально идет подряд. Поэтому некритично. Когда мы все это архитектурно задумывали, мы сначала под этот проект хотели сделать отдельную базу SQL, но нам это не понадобилось
А вы не думали про такую модель, как выгрузка этой информации из 1С? Это как раз к этим регламентных заданиям. Когда вы архитектурное решение проектировали, вы не думали о том, что пусть 1С куда-нибудь «плюет» в RabbitMQ или еще какую-нибудь очередь, а Zabbix уже из нее получает?
По поводу RabbitMQ я пока не понял до конца всех плюсов – наверное, у нас нет таких объемов. Честно говоря, я против регламентов. У нас получилось очень гибко, и за счет этой гибкости очень легко настраиваются все эти метрики, триггеры без доработки конфигурации. Не хочется делать какие-то регламенты, потому что их потом придется дописывать дополнительно.
В PRTG есть карты (maps) – это такое поле x на y в графическом виде, куда можно вытащить любые сенсоры. Очень удобно – все разноцветное. Есть ли такое в Zabbix?
Это скорее вопрос к Grafana. В Zabbix есть графики, но они слишком упрощенные. Grafana в этом плане гораздо интереснее. Там есть различное представление отображаемой информации – не только графики. Там есть спидометры, индикаторы и т.д. Очень большое количество дашбордов, на любой вкус можно найти.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online. Больше статей можно прочитать здесь.

Решение:

1 этап — собственно получаем нужные нам данные.

Создаем регламентное задание в любой информационной базе.
Если все находятся на поддержке, то можно создать пустую или добавить регламентное задание в расширение.
Регламентное запускаем раз в минуту.
Я настроил чтобы во время обслуживания базы — регламентное не запускалось и не мешало обновлению или выгрузке
В регламентном задании собираем нужные нам показатели.
Мой пример такого сбора:

2 этап — отправляем полученные данные zabbix

Из полученных данных формируем файл и отправляем его zabbix серверу через zabbix sender.
Формат строк файла: <hostname> <key> <value>.
Пример моего кода:

Поясняю: zabbix со всеми вспомогательными файлами находится в папке «C:/zabbix/».
Если у вас другая папка, то указываем ее.

3 этап — сохраняем и анализируем полученные данные в zabbix

Тут все относительно просто для тех кто работал с zabbix.
Создаем элементы данных с именами из файла и нужные нам тригеры.
Единственный нюанс: элементы данных должны иметь тип «zabbix траппер».
Суть этого типа в том что не zabbix запрашивает данные, а данные ему отправляются через zabbix_sender.

Для простоты я прикрепил свой шаблон.
В шаблоне помимо описанных элементов еще есть:

стандартное отслеживание состояния службы сервера 1С 8.3
тригер на доступность службы (с 8 утра до 12 ночи)
тригер на отсутствие ответа от 1с больше 2х минут (с 8 утра до 12 ночи)
тригер на долгий запрос к БД (Захвачено СУБД из консоли больше 300с.) (с 8 утра до 12 ночи)
пара элементарных графиков (сессии и активность).

Создаём элемент данных.

Для начала необходимо выбрать наш шаблон, к которому привязан интересующий нас узел сети, если его нет создаём, о том как создать шаблон можете прочитать тут: ZABBIX — Новый шаблон. В нашем случае шаблон у нас уже есть с привязанным к нему узлом сети. Переходим в “Настройка” -> “Шаблоны” -> Выбираем наш шаблон ->Выбираем “Элементы данных” и нажимаем кнопку “Создать элемент данных”

Zabbix-создаём элементы данных

Дальше необходимо вписать наши условия, оставляем все пункты по умолчанию, кроме “Имя” и “Ключ”. Вписываем любое угодное нам имя и в поле ключ нажимаем “Выбрать”

Zabbix-Выбираем ключ

Ищем в списке ключ “proc.num”, выбираем его.

Вот что про данный ключ пишут в документации Zabbix-а:

proc.num
	Количество процессов.	Целое число	имя – имя процесса (по умолчанию “все процессы”)пользователь – имя пользователя (по умолчанию “все пользователи”)состояние – возможные значения: all (по умолчанию), run, sleep, zombcmdline – фильтр по командной строке (является регулярным выражением)	Примеры ключей: ⇒ proc.num – количество процессов выполняемых под пользователем mysql ⇒ proc.num – количество процессов apache2 выполняемых под пользователем www-data ⇒ proc.num – количество процессов в спящем состоянии выполняемых под oracle и имеющих oracleZABBIX в содержимом командной строкиСмотрите заметки по выбору процессов с параметрами и (специфика для Linux).В Windows, поддерживаются только параметры имя и пользователь.

Затем нам необходимо указать необходимые параметры для ключа. К примеру мы хотим настроить мониторинг демона под названием “sendsms”, тогда ключ у нас будет таким:

proc.num

1	proc.numsendsms,,

Если нам необходимо настроить мониторинг служб с одинаковым названием, но в дальнейшем их мониторить по отдельности, то можно указать параметры таким образом:

proc.num[java,,,»config /home/devuser/production/kkt_java/kkt.forwarded.setter.conf»]

1	proc.numjava,,,»config /home/devuser/production/kkt_java/kkt.forwarded.setter.conf»

Мы передаём название демона и к примеру путь, откуда была запущена служба, что конкретизирует как раз нужную нам.

В нашем случае параметр будет таким:

proc.num

1	proc.numjava,,,logstash

Нажимаем “Обновить” и в списке появиться наш элемент данных.

Так же вы можете проверить правильно ли вы составили ключ, и будет ли он выдавать нужное нам значение, напрямую через консоль, командой:

zabbix_agent -t proc.num

1	zabbix_agent-tproc.numjava,,,logstash

Zabbix-проверка правильности ключа

Должен вернуть количество найденных служб.

Так же после создания элемента данных можно проверить, что возвращается в консоли Zabbix, необходимо перейти во вкладку “Мониторинг”->”Последние данные”, там найти нужный элемент и посмотреть значение.

Ребут и агента нет

Бывают случаи, когда агент был успешно установлен и настроен на хосте, мониторинг работает как надо. НО! При очередном запланированном перезапуске сервера (хоста) Zabbix-агент не смог запуститься.

Причин тому может быть несколько:

Агент запускается от доменной учетной записи, но на момент старта сервера связи с доменом не оказалось.
В момент запуска агент пытался запуститься, когда еще не “поднялся” доступ к сети.

При этом в файле лога агента может не быть какой-либо полезной информации, но она есть в системных журналах ОС. Чаще всего это поведение встречал в ОС Windows.

Решение достаточно простое: нужно установить для службы Windows режим запуска “Автоматически (отложенный запуск)”. В большинстве случаев проблема будет решена.

Быстро и просто!