Решаем практические задачи в zabbix с помощью javascript

Введение

Если у вас еще нет готовой системы мониторинга, можете воспользоваться моей статьей по установке и настройке zabbix на centos или freebsd.

Задача по своей сути не сложная. Нечто похожее я уже делал, когда настраивал мониторинг температуры процессора в windows сервере. Мы берем текстовый файл, парсим его с помощью bat файлов и передаем готовые числовые или строковые значения в Zabbix через windows агента и функционал UserParameter.

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

Результат в Zabbix – метрики и триггеры

В итоге мы получаем метрики в Zabbix.

На представленном графике показаны значения метрик по одной Киевской точке. Мы видим, какими в период с 19 до 20 часов были значения показателей:

• время кухни в инфо-табло – зеленая линия;

• количество заказов – красные точки;

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

На основании полученных метрик мы настроили триггеры.

Триггеры – это выражения, определяющие порог проблемы:

• когда результаты всех неравенств в выражении триггера становятся истинными, открывается проблема;

• как только хотя бы одно неравенство будет возвращать ложь, проблема закрывается.

На примере показан триггер, открывающий проблему, когда время отдачи кухни будет на 5 минут больше, чем регламентное. Это мы можем увидеть в последнем неравенстве, где MaxTimeKitchen.last() > TimeOfKitchenInInfo.last() + 5. Все остальные неравенства всегда истинны и указаны здесь, потому что в Zabbix в оповещениях о проблеме нельзя использовать метрики, если они не присутствуют в выражении триггера.

Файл userparameter_XXX.conf

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

Т.е., для получения данных по параметру агент должен запустить скрипт и передать на сервер результат выполнения.

После рестарта Zabbix-агента () у него появляется возможность собирать данные для параметра и отправлять их на сервер.

Резюме

Понимание Zabbix’а ко мне приходило (и всё ещё приходит) достаточно тяжело. Тем не менее я считаю его прекрасным инструментом, особенно после того, как для меня открылась простота добавления собственных параметров мониторинга (элементов данных). По большому счёту, достаточно добавить один файл на сервер с агентом () с shell-командой для сбора данных и настроить Zabbix-сервер на получение этих данных через web-интерфейс. И всё — можно накапливать данные, строить графики, анализировать изменения и создавать триггера, реагирующие на эти изменения.

Smartctl и smartmontools

писалиподход

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

• uHDD.i
• uHDD.health

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

здесь

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

зависимых элементов данных

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или произвольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких как JSON path, XPath или Regex выделяют из текста нужную метрику.

шаблон для сервера

Оповещения в Telegram

Соответственно из этих метрик мы сделали оповещения через Telegram – в СушиВок для оперативной информации используется именно Telegram, а не почта. Причем, в Zabbix оповещения для Telegram настраиваются «из коробки».

В оповещениях операционный отдел просил указывать всю информацию о точке – количество поваров, сумма чеков, количество чеков в комплектации и т.д., чтобы можно было полностью понимать, какая ситуация на точке была во время сбоя. Из-за этого в выражении триггера и нужны были эти лишние всегда истинные неравенства. Но при большом объёме срабатывающих триггеров из-за всей этой информации сообщения стали не читаемы – получалось полотно из слов.

Поэтому я воспользовался советом Родислава Гандапаса из книги «К выступлению готов», где он при подготовке к выступлениям на карточках рекомендует использовать пиктограммы, т.к. они быстрее читаются при беглом взгляде.

Так в наших оповещениях появились:

• ножи – это кухня;

• черепашки – это доставка;

• огоньки – если проблема не закрыта больше 10 мин.

Операционный отдел был очень доволен данными оповещениями.

Возможности Zabbix 5

Более подробно вы можете изучить возможности на официальном сайте Что нового в Zabbix 5.0 LTS. Я хочу отметить важные для меня возможности:

1. Zabbix можно развернуть локально или в облаке
2. Реализована одна и та же политика источника для iframe, что означает, что Zabbix веб-интерфейс нельзя поместить во фреймы на другом домене
3. Переписан Zabbix Agent с поддержкой плагинов и сохранением состояния
4. Обнаружение счетчиков JMX (Java расширений управления)
5. Обнаружение счетчиков производительности Windows
6. Встроенная интеграция с системами ITSM (IT Service Management) — управление IT- услугами. Zabbix 5 представляет набор готовых интеграций со стандартными облачными и локальными системами ITSM: Jira, OTRS, Redmine, Zendesk, Zammad, Servicenow.
7. Встроенные интеграции с системами оповещений: XMPP (Jabber), Telegram, Slack, Mattermost, Msteams, Victorops, PagerDuty, OpsGenie.
8. Добавлены новые шаблоны и плагины для мониторинга различных сервисов, приложений и устройств. Большинство шаблонов теперь используют дополнительные возможности для автоматического обнаружения различных ресурсов. Из коробки существуют шаблоны Zabbix для ClickHouse, MySQL, nginx, Redis, PostgreSQL, Haproxy, Memcached, Elasticsearch.
9. Возможность сброса SNMP кэша, изменений контекста SNMPv3

Шаблоны Zabbix в версии 5 стали более сложными с кучей макросов и автообнаружений.

Напоследок

Чтобы иметь наглядную картину, я создал для каждой RG соответствующую группу хостов на Zabbix-сервере и сделал для каждой RG скрин, на котором видно общее состояние хостов группы и графики для различных метрик.

Получилось примерно так:

В процессе продакшн-эксплуатации шаблона выявилась проблема с опросом значений счетчиков производительности для RF: по непонятным мне причинам агент Zabbix перестает получать их показания и генерирует в своем логе ошибки вида «perf_counter» is not supported: Cannot obtain performance information from collector. Средствами же самой Windows (perfmon, typeperf, Get-Counter) эти счетчики опрашиваются нормально. Лечится перезапуском службы Zabbix Agent. Проблема касается только RF-счетчиков, счетчики для других сущностей (например, для подключений) агент опрашивает без проблем.

Шаблон и инструкции по установке есть на GitHub и Zabbix Share. Забирайте!

Буду рад конструктивной критике и предложениям по улучшению шаблона.

Источники вдохновения

Параметры мониторинга

Плагин, который я анализировал, предполагал выполнение отдельной команды для получения отдельного параметра (элемента данных, item’а):

Т.е., для получения данных по 12 параметрам агент должен будет 12 раз выполнить различные наборы команд. А если мне нужно мониторить параметры, которые сложно извлечь цепочкой команд и нужно будет писать отдельный shell-скрипт или полноценную программу? Для таких «хотелок» Zabbix предлагает вариант с зависимыми элементами данных. Суть его в том, что на стороне агента скриптом формируется набор данных (например, в формате JSON), который передаётся на сервер в виде строкового параметра. Затем на стороне сервера происходит разбор полученных данных и вычленение из них отдельных элементарных параметров.

Основной элемент данных

Я описал основной элемент данных строкового типа с периодом обновления в 1 мин., без сохранения истории изменений:

Предположительно, на стороне агента должен генерироваться такой JSON:

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

Зависимый элемент данных

Тестовый параметр зависит от и сохраняет свои значения в базе в течение 90 дней. Периодичность мониторинга параметра зависит от базового элемента ():

Значение параметра извлекается из значения при помощи инструкций JSONPath:

По аналогичной схеме описываются остальные зависимые элементы данных (параметры мониторинга), которые передаются в виде JSON’а. Вот пример описания числового параметра :

Формула для извлечения значения из JSON’а:

Вычисляемый элемент данных

Для вычисления фрагментации памяти используется отношение / и на его базе определяется триггер, срабатывающий при превышении отношением значения 1.5. В Zabbix’е есть вычисляемый тип элементов данных:

Значение для параметра вычисляется каждую минуту на основании последних значений двух других параметров ( и ), сохраняется в базе в течение 90 дней и т.д.

Передача json данных в zabbix

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

Для примера возьму мониторинг работы ноды Bitcoin. В данном случае это совершенно не принципиально, так как подход к парсингу json в zabbix одинаковый везде. Формат json сейчас очень популярен. Большое число сервисов его поддерживают для вывода информации или логов. У биткоин ноды есть команды для вывода информации о состоянии ноды. Вывод идет в формате json. Вот пример:

# bitcoin-cli getblockchaininfo

{
  "chain": "test",
  "blocks": 1447503,
  "headers": 1447503,
  "bestblockhash": "506a6952d47b939e9d7baa34fc290b4356c446",
  "difficulty": 12691409.16925421,
  "mediantime": 1544607906,
  "verificationprogress": 0.9999915635029165,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000db56207f5987ad3",
  "size_on_disk": 23159068639,
  "pruned": false,
  "softforks": ,
  "bip9_softforks": {
    "csv": {
      "status": "active",
      "startTime": 1456790400,
      "timeout": 1493596800,
      "since": 770112
    },
    "segwit": {
      "status": "active",
      "startTime": 1462060800,
      "timeout": 1493596800,
      "since": 834624
    }
  },
  "warnings": "Warning: unknown new rules activated (versionbit 28)"
}

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

Настройка парсинга json в zabbix будет состоять из следующих шагов:

1. Передаем всю json строку в исходном виде в итем в заббиксе.
2. С помощью зависимых элементов данных формируем отдельные итемы с нужными значениями.
3. Используем полученные итемы по назначению.

Для начала делаем простой скрипт для получения json — /etc/zabbix/scripts/getblockchaininfo.sh

#!/bin/bash
/usr/bin/bitcoin-cli -rpcuser=user -rpcpassword=password -rpcport=8332 getblockchaininfo

Проверьте, что скрипт выдает корректную строку json. Далее создаем UserParameter. Я предпочитаю их хранить в разных конфигах, разделяя по функционалу. Создаю файл /etc/zabbix/zabbix_agentd.d/btc.conf следующего содержания:

UserParameter=blockchaininfo,/etc/zabbix/scripts/getblockchaininfo.sh

Сохраняем и перезапускаем zabbix-agent. Проверяем, что json корректно передается в нужном виде, без ошибок и прочих проблем:

# zabbix_agentd -t blockchaininfo

На выходе должны увидеть тот же самый json.

Zabbix агент подготовили. Для продолжения настройки, переходим на сервер.

Настройка 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 — Мониторинг коммутатора через SNMP

Хотите узнать, как настроить Zabbix для мониторинга коммутатора с использованием SNMP? В этом руководстве мы покажем вам, как контролировать сетевой коммутатор через SNMP-сервер Zabbix.

• Zabbix версия: 4.4.0

Прежде чем мы начнем, вам нужно настроить SNMP на вашем сетевом коммутаторе.

Вот несколько примеров конфигурации SNMP:

• Конфигурация SNMP на коммутаторе HP
• Конфигурация SNMP на коммутаторе Cisco

Список оборудования:

В следующем разделе представлен список оборудования, использованного для создания этого учебника Zabbix.

Каждое оборудование, перечисленное выше, можно найти на сайте Amazon.

Zabbix Playlist:

На этой странице мы предлагаем быстрый доступ к списку видео, связанных с установкой Zabbix.

Playlist

Не забудьте подписаться на наш канал на YouTube FKIT.

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

Учебное пособие — Zabbix Monitor Switch через SNMP

Получите доступ к панели инструментов Zabbix-сервера и добавьте сетевой коммутатор в качестве хоста.

Откройте браузер и введите IP-адрес вашего веб-сервера плюс / zabbix.

В нашем примере в браузере был введен следующий URL:

• http://192.168.0.10/zabbix

На экране входа в систему используйте имя пользователя по умолчанию и пароль по умолчанию.

• Имя пользователя по умолчанию: Admin
• Пароль по умолчанию: zabbix

После успешного входа вы будете отправлены на Zabbix Dashboard.

На экране панели инструментов откройте меню «Конфигурация» и выберите опцию «Хост».

В правом верхнем углу экрана нажмите кнопку «Создать хост».

На экране конфигурации хоста вам нужно будет ввести следующую информацию:

• Имя хоста — введите имя хоста для идентификации коммутатора.
• Видимое имя хоста — повторите имя хоста.
• Новая группа — введите имя для идентификации группы похожих устройств.
• Интерфейс агента — нажмите на кнопку Удалить.
• Интерфейс SNMP — нажмите кнопку «Добавить» и введите IP-адрес сетевого коммутатора.

Вот оригинальное изображение, перед нашей конфигурацией.

Вот новое изображение с нашей конфигурацией.

Далее нам нужно настроить сообщество SNMP, которое Zabbix будет использовать для подключения к сетевому коммутатору.

Откройте вкладку «Макросы» в верхней части экрана.

Создайте макрос с именем: {$ SNMP_COMMUNITY}

Значение макроса {$ SNMP_COMMUNITY} должно быть сообществом сетевого коммутатора SNMP.

В нашем примере значением {$ SNMP_COMMUNITY} является GokuBlack

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

По умолчанию Zabbix поставляется с большим разнообразием шаблонов мониторинга.

Откройте вкладку «Шаблоны» в верхней части экрана.

Найдите и выберите шаблон с именем: Шаблон Net Network Generic Device SNMPv2

Нажмите на кнопку Добавить.

Через несколько минут вы сможете увидеть первоначальный результат на Zabbix Dashboard.

Окончательный результат займет не менее часа.

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

По умолчанию Zabbix будет ждать 1 час, прежде чем собирать информацию из интерфейсов сетевого коммутатора.

Поздравляем! Вы настроили Zabbix сервер для мониторинга сетевого коммутатора.

2020-01-08T17:13:12-03:00

Начальное положение

• README.md
• redis-userparameter.conf

А затем каждый параметр мониторинга извлекался агентом из файла при помощи средств самой операционной системы. Инструкции для этого размещались в конфигурации Zabbix-агента . Например, вот так выглядят инструкция для извлечения параметра (использование памяти Redis-сервером):

То есть, в файле с выводом по ключу ищется строка ()

которая затем разбивается на столбцы по разделителю «:» (). На выходе агент получает число и присваивает его параметру .

Остаётся через web-интерфейс настроить сервер, чтобы он периодически отправлял запросы агенту на получение данных по параметру , после чего данные начинают литься на сервер, сохраняться в базе, по ним можно строить графики и создавать триггера, реагирующие на изменения этого параметра.

Шаг 8 — Настройка брандмауэра для Zabbix

В этом случае я использую UFW, вы должны были на первом шаге его настроить . Далее нам нужно разрешить порты протокола HTTP, HTTPS и зарезервированные порты для работы с Zabbix агентами.

Проверяем есть ли строки в файле services, если нет дописываем

# cat /etc/services | grep Zabbix
zabbix-agent	10050tcp			# Zabbix Agent
zabbix-agent	10050udp			# Zabbix Agent
zabbix-trapper	10051tcp			# Zabbix Trapper
zabbix-trapper	10051udp			# Zabbix Trapper

Команды для UFW

$ sudo ufw allow 'Apache Full'
$ sudo ufw allow 10050
$ sudo ufw allow 10051

В итоге должна получится такая настройка фаервола:

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
 
To                         Action      From
--                         ------      ----
22tcp (OpenSSH)           ALLOW IN    Anywhere
80,443tcp (Apache Full)   ALLOW IN    Anywhere
10050                      ALLOW IN    Anywhere
10051                      ALLOW IN    Anywhere
22tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80,443tcp (Apache Full (v6)) ALLOW IN    Anywhere (v6)
10050 (v6)                 ALLOW IN    Anywhere (v6)
10051 (v6)                 ALLOW IN    Anywhere (v6)

Шаг 5 — Настройка базы данных MySQL для Zabbix

Импортируем схему базы данных для Zabbix сервера. Логинемся на сервер MySQL с учетной записью root и создаем базу данных MySQL и пользователя с помощью следующих команд.

# mysql -uroot -p
password
mysql> create database zabbix character set utf8 collate utf8_bin;
mysql> create user zabbix@localhost identified by 'password';
mysql> grant all privileges on zabbix.* to zabbix@localhost;
mysql> quit;

Импорт начальной схему и данных Заббикс производим от пользователя MySQL созданного выше.

# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix
Enter password

Настроим подключение Заббикса к базе данных, для это следует отредактировать файл /etc/zabbix/zabbix_server.conf и задать пароль для подключения к MySQL. Остальные 3 параметра уже настроены, если вы конечно не извращались с именем пользователя и базы данных.

DBPassword=password
DBHost=localhost
DBName=zabbix
DBUser=zabbix

Мониторинг инфраструктуры Openshift 4.x с помощью Zabbix Operator

Для установки агентов Zabbix на кластер Openshift Cluster будем использовать оператор Zabbix. Затем сконфигурируем их так, чтобы они отправляли собираемые данные на внешний Zabbix Server, как показано на схеме ниже.

Установка Zabbix Server

● Первым делом обновим сервер и поставим httpd:

● Затем установим и настроим СУБД MariaDB:

● Теперь ставим сам Zabbix Server:

Удостоверимся, что все требования в наличии , и нажимаем Next:

Вводим учетные данные для подключения к БД и жмем Next:

Поле Name можно не заполнять. Проверяем остальное и жмем Next:

Перепроверяем, нажимаем Next, а затем Finish:

Настройка Zabbix Server

Логинимся, используя следующие учетные данные:

Пароль пользователя Admin, конечно, лучше затем поменять.

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

Теперь создадим группу хостов для серверов Openshift:

Нажимаем Configuration > Host Groups > Create host group, вводим имя группы и жмем Add:

Теперь настроим саморегистрацию агентов, чтобы наши ноды регистрировались в zabbix автоматически. Для этого щелкаем в боковом меню Configuration > Actions, затем в раскрывающемся списке вверху вкладки выбираем Autoregistrion actions и щелкаем Create action:

Настраиваем action, используя следующие значения, и затем жмем Add:

На вкладке Operations щелкаем Add и вводим следующие операции:

Добавляем новые операции:

После такой настройки каждый новый агент будут автоматически регистрироваться в группе «OpenShift Cluster» и получать шаблон «Template OS Linux by Zabbix agent active».

Установка Zabbix Operator

Теперь установим и настроим Zabbix Operator на Openshift.

В OperatorHub ищем и выбираем Zabbix, а затем щелкаем Install:

Еще раз щелкаем Install:

Дожидаемся завершения установки и щелкаем имя Zabbix Operator:

Ищем вкладку Zabbix Agent, щелкаем там Create ZabbixAgent > Select YAML View, задаем приведенные ниже параметры и жмем Create:

Настройка Zabbix Operator

Теперь в проекте Zabbix щелкаем Daemonset > zabbix-agent > Tolerations и добавляем Toleration с указанными ниже параметрами, чтобы создать поды на master-нодах:

Как видим, daemonset смасшитабировался до 5 подов (3 master-а и 2 worker-а)

Запросим список подов, чтобы просто проверить имена и статус:

Теперь в консоли Zabbix идем в Configuration > Hosts.

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

Для большей наглядности щелкнем имя хоста и добавим к OpenShift-имени (поле Host name) еще и понятное имя в поле Visible name, а затем нажмем Update:

Чтобы понять, отправляют ли уже наши хосты данные на Zabbix Server, щелкнем Monitoring > Latest data.

На этом экране отображается список уже собранных элементов вместе со значениями, а также дата и время последнего сбора данных:

Итак, теперь Zabbix ведет мониторинг нашего кластера:

ак, мы показали, как мониторить неизменную инфраструктуру Openshift с помощью Zabbix Operator. Собирая данные по использованию ресурсов (cpu, нагрузка, память, сеть, дисковое пространство), затем можно создавать оповещения и задавать пороги предупреждений, чтобы упреждать критическое развитие ситуации с ресурсами.

Заключение

Я показал простейший пример работы с json для тех, кто никогда не использовал его в zabbix. Благодаря тому, что в какой-то не очень давней версии появились зависимые элементы, работа с мониторингом сильно упростилась. Первое, что мне пришло в голову, когда нужно было выбрать отдельные значения из json вывода — написать баш скрипт. Это не сложно, я бы быстро распарсил и вытащил те данные, что мне нужны. Но вспомнив про зависимые элементы и возможность обработки данных в самом заббиксе, решил посмотреть в эту сторону и не ошибся. Так действительно проще и удобнее. За нас уже все сделали разработчики.

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

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

• Познакомитесь с Terraform.
• Изучите систему управления конфигурацией Ansible.
• Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
• Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
• В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Итоги интеграции

На этом это пока все, что мы успели сделать за месяц активной работы с Zabbix.

Оценим трудозатраты…

• Мы работаем по SCRUM’у, поэтому разработка интеграции у нас заняла четыре спринта – четыре недели (спринты у нас длятся одну неделю).

• Оповещения в Telegram и дашборды в Grafana заработали уже после двух первых спринтов.

• Работали над проектом два программиста 1С и затратили 16,5 ч/ч разработки.

С какими трудностями интеграции и настройки Zabbix мы столкнулись?

• Как я уже упоминал, в оповещениях можно использовать только метрики присутствующие в выражении триггера, из-за этого выражения превращаются в нечитаемую простыню неравенств.

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

• Третье – это назначение прав только группе пользователей на группу узлов, из-за этого человеку, который управляет одной точкой, нужно создавать отдельную группу узлов сети и отдельную группу пользователей.

• Ну и последнее – в метрике может храниться только одно значение. Архитектурно мне понятно, почему так сделано в Zabbix, но из-за этого приходится создавать одну метрику, считающую количество, например, претензий, а второй метрикой запрашивать темы этих претензий, чтобы не просто оповещать что у вас новая претензия, а давать пользователю хотя бы часть информации – о чем эта претензия. И было бы намного проще, если бы в метрике хранилось значение + какой-то комментарий.

Но все это было не критично, поэтому перейдем к подведению итогов интеграции.

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

Благодаря этому, меньше чем за месяц у нас появилось более ста метрик.

Удобное устройство шаблонов в Zabbix и макросы позволили подключать новые города с 50 точками за 20 минут.

За счёт этого мониторинг уже работает более чем на 300 точках.

Получившийся инструмент полезен не только для операционного отдела, но и для других. Например:

• тех. поддержка использует для мониторинга времени обработки заказов с сайта;

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

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

За счет автоматизации контроля состояния точек, получилось сократить количество сотрудников, занимающихся этим до появления Zabbix.

Раньше они следили за временем отдачи на точках, временем доставки, открывали и закрывали сбои в 1С, повышали время и останавливали работу точек в экстренных ситуациях и т.д. Теперь все это делает Zabbix.