Сегодня наш рассказ будет о том, как можно начать следить за состоянием системы, работающей на базе 1С:Предприятие и технологии 1С:Fresh. Как и в любой информационной системе, в ней могут возникать проблемы эксплуатации, в том числе и по части, операционной системы и в железе, поэтому необходим механизм мониторинга и оповещения об инцидентах.
Для реализации мониторинга будем использовать Zabbix версии 4.
Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым.
Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP.
Мониторинг в Zabbix складывается из нескольких элементов, присутствующих в данной системе:
Предметом мониторинга является сам сервер администрирования и связанный с ним менеджер кластера. Сервер администрирования может быть расположен отдельно от менеджера кластера, тогда именно его нужно использовать как узел мониторинга, но в дальнейшем мы предполагаем, что сервер администрирования расположен с менеджером кластера на одном узле.
На узле с ним обязательно должен располагаться Zabbix Agent — он будет заниматься сборкой и отправкой метрик на Zabbix Server.
Установка Zabbix Agent, как и Zabbix Server, сводится к установке пакетов в операционную систему, которые можно получить по ссылке https://www.zabbix.com/ru/download. Там же располагается инструкция по установке.
Технология 1С:Fresh реализовывается поверх клиент-серверной технологии работы с 1С:Предприятие. Соответственно, все ниже приведенные методики работают не только для 1С:Fresh, но и для любой клиент-серверной инсталляции.
Самая важная компонента кластера, при помощи которой можно реализовать не только мониторинг, но и проводить операции администрирования — это служба RAS и клиент доступ к нему RAC.
RAS представляет собой службу администрирования кластера 1С:Предприятие и является кроссплатформенным, как и клиент RAC, реализующий интерфейс взаимодействия администратора с кластером.
К сожалению, штатный механизм управления службой в текущих версиях платформы и пакетах для Linux не реализован, поэтому мы можем использовать следующие варианты запуска службы:
ras cluster --daemon любым способом (в ручную или через скрипт);systemd (любой актуальный дистрибутив Linux, например, CentOS 7).Для реализации второго способа нужно в командной строке воспользоваться любым текстовым редактором, например nano, создать файл /etc/systemd/system/ras.service, и включить следующий текст:
[Unit]
Description=RAS
After=syslog.target
After=network.target
[Service]
Type=forking
WorkingDirectory=/opt/1C/v8.3/x86_64User=usr1cv8
Group=grp1cv8
OOMScoreAdjust=-100
ExecStart=/opt/1C/v8.3/x86_64/ras cluster --daemon -p 1545
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
TimeoutSec=300
Restart=always[Install]
WantedBy=multi-user.target
Исполняем команды systemctl daemon-reload, systemctl enable ras, systemctl start ras для включения и запуска службы.
Далее добавим сервер со службой администрирования в Zabbix и привяжем шаблоны для мониторинга.
Первоначальный объект мониторинга — это сам сервер/ВМ и его операционная система. Для этого можно применить стандартные шаблоны, уже существующие в Zabbix. Они являются достаточными для базового мониторинга состояния сервера и позволяют мониторить статус служб — таких как менеджер кластера, служба администрирования, а также веб-сервер.
Добавление узла мониторинга в Zabbix производится через форму создания «Настройка» — «Узлы сети».
Имя узла сети — это имя, которым будет представляться узел в дальнейшем в Zabbix, в том числе и в уведомлениях.
Важным параметром является группы — для начала можно воспользоваться встроенными в Zabbix группами и добавить узел туда, но в будущем при масштабировании рекомендуется вынос узлов в отдельно созданные вручную группы — это позволит привязывать шаблоны целиком на группу узлов, связанных общим функционалом и собираемыми метриками, например, узлы кластера 1С, веб-сервера или сервера СУБД.
Дальнейшим важным шагом является привязка уже существующих шаблонов к узлу:
В данной вкладке можно подключить шаблоны мониторинга ОС, например, Template OS Linux, а также в будущем подключать новые шаблоны к узлам сети.
Чтобы не заниматься «изобретательством» по части 1С и уже сейчас запустить мониторинг — мы можем импортировать уже существующие в сети шаблоны по ссылке — https://www.zabbix.com/integrations/1c.
Рассмотрим для примера первое решение в списке, расположенное по ссылке github.com/bessonovevgen/srv-1c-zabbix-template.
Установка шаблона довольно проста — нужно импортировать .xml файл шаблона в веб-интерфейсе Zabbix и расположить. conf файл в /etc/zabbix/zabbix_agent.d, либо включить содержимое файла в zabbix_agent.conf.
Импорт шаблона осуществляется штатным способом через форму «Настройки» — «Шаблоны».
Далее шаблон привязывается к узлу во вкладке шаблонов.
В данном решении применяется вызов клиента администрирования для сбора метрик:
UserParameter=onec-session,/opt/1C/v8.3/x86_64/rac session --cluster=<uuid> list --infobase=<uuid> | grep 1CV8C | wc -lUserParameter=onec-bgj,/opt/1C/v8.3/x86_64/rac session --cluster=<uuid> list --infobase=<uuid> | grep BackgroundJob | wc -lUserParameter=web-session,/opt/1C/v8.3/x86_64/rac session --cluster=<uuid> list --infobase=<uuid> | grep WebClient | wc -l# UserParameter=fat-session,/opt/1C/v8.3/x86_64/rac session --cluster=<uuid> list --infobase=<uuid> | grep 1CV8 | wc -l UserParameter=designer-session,/opt/1C/v8.3/x86_64/rac session --cluster=<uuid> list --infobase=<uuid> | grep Designer | wc -l
В файле конфигурации необходимо заменить <uuid> на идентификаторы кластера и идентификаторы баз данных, необходимые для мониторинга. Получить uuid кластера можно с помощью команды /opt/1C/v8.3/x86_64/rac cluster list, а при известном uuid кластера мы можем получить uuid баз данных, расположенных в данном кластере — /opt/1C/v8.3/x86_64/rac infobase --cluster=<uuid> summary list. Для сбора метрик со всего кластера достаточно знать uuid кластера, а опцию —-infobase <uuid> можно исключить из данных строк.
Применяя штатные механизмы Linux по работе со строковыми потоками данных можно разработать сбор практически любых метрик, работая с выводом программы.
Добавим мониторинг количества соединений с веб-сервером и сервером СУБД.
UserParameter=apachec, pgrep apache | wc -l
UserParameter=postgresc, pgrep postgres | wc -l
В Zabbix соответственно нужно добавить элементы данных с данным ключом в шаблон, чтобы иметь возможность собирать эти метрики:
Аналогично и для postgresc.
Ещё один важный элемент Zabbix — это система оповещений. Он уже имеет набор способов оповещений, среди которых можно найти Email, Jabber и SMS, но также существует возможность создания своих собственных способов оповещений — при помощи создания скриптов и программ, принимающих на вход части сообщения и обрабатывающие их далее.
На скриншоте показана интеграция проекта https://github.com/ableev/Zabbix-in-Telegram в Zabbix. Проект позволяет отправлять оповещения в личные сообщения Telegram, группы, а также получать изображение графиков в сообщениях с помощью кнопок. По интеграции данного решения подробно описаны в репозитории GitHub по ссылке.
Но чтобы сообщения отправлялись, независимо от интегрируемого способа, необходимо описать «Действие», которое будет исполняться в зависимости от тех или иных условий, которые вступили в силу. Шаблон условия при срабатывании триггеров выглядит следующим образом:
В следующих вкладках идёт непосредственное описание действий, происходящих при срабатывании:
Аналогичные настройки расположены и в остальных вкладках, которые отвечают за операцию восстановления (возвращение триггера в исходное состояние), и обновление (если администратор отреагировал на проблему и обновил статус «проблемы»).
Данной информации хватает для базового понимания принципов работы с Zabbix и в частности с тем, как можно работать с 1С и следить за её состоянием. RAS далеко не единственный способ мониторинга работы информационной системы, и возможно также применение иных принципов:
Но об этом мы расскажем позже.