Добавление пользовательского шаблона в Zabbix

В VK Private Cloud управление системой мониторинга Zabbix происходит через Ansible.

Если стандартных шаблонов для использования Zabbix недостаточно, добавьте пользовательские шаблоны. С их помощью можно:

• собирать дополнительные метрики, которые важны для мониторинга инфраструктуры Платформы;
• настраивать свои триггеры, графики и дашборды;
• применять мониторинг одинаково на всех нужных узлах через Ansible;
• сохранять настройки при обновлениях и восстановлении Платформы — это защитит их от потери.

Добавление пользовательских шаблонов в Zabbix выполняется в следующем порядке:

1. Выполните подготовку.
2. Настройте получение метрик.
3. Создайте конфигурационный файл с UserParameter.
4. Создайте шаблон в веб-интерфейсе Zabbix.
5. (Опционально) Создайте общую панель и экспортируйте ее.
6. Загрузите файлы в Ansible.

В итоге получите набор файлов:

• (Опционально) Файл с расширением .sh или .py — скрипт для получения метрик.
• Файл с расширением .conf. Содержит пользовательские параметры (UserParameter) — указания для Zabbix по запуску скрипта или bash-команды.
• Файл XML — настройки шаблона Zabbix: элементы данных, триггеры, графики.
• (Опционально) Файл JSON — настройки дашборда.

В примере приведен мониторинг открытых файлов (LimitNOFILE) для systemd-сервисов.

1. Подключитесь к деплой-ноде по SSH (подробнее — в разделе Подключение к деплой-ноде).
2. Убедитесь в наличии доступа к Inventory-файлам vkcloud и ansible-openstack.
3. Подготовьте доступ в веб-интерфейс Zabbix с правами администратора.

Настройте способ получения метрик на одном из узлов с работающим агентом Zabbix (zabbix-agent) и целевым источником данных.

Каждую отдельную метрику можно получить двумя способами:

• С помощью bash-команды. Подходит для метрик, которые можно получить в нужном формате с помощью bash-команды.

  Команду нужно добавить напрямую в файл с UserParameter на шаге 2. Пример команд — в разделе Использование bash-команд.

• С помощью скрипта. Подходит для метрик, получение которых требует сложной логики: условий, обработки вывода, несколько источников. Подробнее о создании скрипта — в разделе Использование скрипта.

Пример получения данных из /proc:

1. Получите PID процесса сервиса. Пример команды для получения PID процесса сервиса mariadb-glance:

    
   $ systemctl status mariadb-glance | grep PID

   Пример ответа:

    
   Main PID: 347075 (mysqld)

2. Получите лимиты процесса:

    
   $ cat /proc/347075/limits

   Здесь 347075 — PID процесса сервиса, полученный на предыдущем шаге.

   Пример ответа:

    
   Limit                   Soft Limit      Hard Limit      UnitsMax cpu time            unlimited       unlimited       secondsMax file size           unlimited       unlimited       bytesMax data size           unlimited       unlimited       bytesMax stack size          8388608         unlimited       bytesMax core file size      unlimited       unlimited       bytesMax resident set        unlimited       unlimited       bytesMax processes           257065          257065          processesMax open files          163640          163640          filesMax locked memory       8388608         8388608         bytesMax address space       unlimited       unlimited       bytesMax file locks          unlimited       unlimited       locksMax pending signals     257065          257065          signalsMax msgqueue size       819200          819200          bytesMax nice priority       0               0Max realtime priority   0               0Max realtime timeout    unlimited       unlimited       us

3. Получите значение лимита на максимальное количество разрешенных открытых файлов (Hard Limit):

    
   $ grep "Max open files" /proc/347075/limits | tr -s ' ' | cut -d' ' -f5

   Пример ответа:

    
   163640

4. Получите количество открытых файлов:

    
   $ sudo find "/proc/347075/fd" -mindepth 1 -maxdepth 1 | wc -l

   Пример ответа:

    
   54

После выполнения bash-команд будут получены данные для передачи в Zabbix. Если формат вывода и способ получения вас устраивают, добавьте команду в файл с UserParameter и перейдите к шагу 2. Если нет, настройте сбор метрик с помощью скрипта. Подробнее — в разделе Использование скрипта.

Скрипт служит прослойкой между Zabbix и операционной системой: Zabbix передает имя сервиса, скрипт находит его PID и возвращает метрики. Это избавляет от привязки к PID, который постоянно меняется.

В примере ниже скрипт собирает четыре метрики:

• discovery — список запущенных systemd-сервисов (для правила обнаружения в Zabbix);
• max — эффективный LimitNOFILE (Hard Limit) у процессов сервиса;
• current — максимальное количество открытых файлов среди процессов сервиса в данный момент;
• total — суммарное количество открытых файлов по всем процессам сервиса.

Чтобы использовать скрипт для получения метрик:

1. Подготовьте скрипт zbx_systemd_fd_test.sh.

   При написании скрипта придерживайтесь следующих рекомендаций:

   • Минимум зависимостей — по возможности получайте данные напрямую из /proc и /sys, а не через специализированные утилиты.
   • Скорость выполнения — лишняя логика увеличивает время работы и может влиять на стабильность сбора метрик.
   • Минимум ресурсов — ресурсозатратные скрипты при частом запуске создают высокую нагрузку на CPU и RAM.
   • По возможности без sudo — если данные доступны без повышения прав, скрипт будет безопаснее.
   Bash-скрипт zbx_systemd_fd_test.sh

   При необходимости скрипт можно написать на языке Python. В этом случае адаптируйте дальнейшие действия под этот скрипт и сохраните файл с расширением .py.

   Python-скрипт zbx_systemd_fd_test.py

2. Проверьте работу скрипта на выбранном ранее узле cpn001:

    
   $ chmod 755 ./zbx_systemd_fd_test.sh

   Пример проверки метрик:

    
   $ sudo ./zbx_systemd_fd_test.sh max mariadb-glance163640$ sudo ./zbx_systemd_fd_test.sh current mariadb-glance54$ sudo ./zbx_systemd_fd_test.sh total mariadb-glance54$ sudo ./zbx_systemd_fd_test.sh max public_haproxy500000$ sudo ./zbx_systemd_fd_test.sh current public_haproxy128$ sudo ./zbx_systemd_fd_test.sh total public_haproxy135

3. Убедитесь, что скрипт выполняется быстро. Пример замера времени выполнения:

    
   $ time sudo ./zbx_systemd_fd_test.sh current public_haproxy128 real    0m0.068suser    0m0.009ssys     0m0.013s

4. После проверки скрипта сохраните его под именем zbx_systemd_fd_test.sh в локальной директории.

5. Проверьте запуск скрипта от пользователя Zabbix и настройте права.

   Скрипт в Zabbix выполняется от имени пользователя zabbix. По умолчанию этот пользователь есть в sudoers, поэтому вызовы с sudo работают без пароля.

   Пример проверки:

    
   $ sudo -u zabbix bash$ sudo ./zbx_systemd_fd_test.sh current public_haproxy129

   Если пользователь zabbix исключен из sudoers, скрипт запросит пароль и в автоматическом режиме не сработает.

   Запускайте метрики без sudo, если им хватает обычных прав, и с sudo — только там, где нужен доступ к системным данным. По возможности вместо sudo дайте пользователю zabbix доступ через группу (как haproxy-admin или etcd-admin). Если без sudo не обойтись, учитывайте дополнительную нагрузку на каждый опрос: проверки sudoers, записи в лог, возможные обращения к LDAP.

Файл с UserParameter определяет, как Zabbix-агент будет запускать скрипт.

1. Подготовьте файл zbx_systemd_fd.conf, который будет содержать UserParameter.

   При подготовке придерживайтесь следующих рекомендаций:

   • В файле с UserParameter всегда указывайте абсолютные пути к файлам и командам.

     Неправильно:

      
     UserParameter=systemd.fd.max[*],grep "Max open files" /proc/$1/limits | tr -s ' ' | cut -d' ' -f5

     Правильно:

      
     UserParameter=systemd.fd.max[*],grep "Max open files" /proc/$1/limits | /usr/bin/tr -s ' ' | /usr/bin/cut -d' ' -f5

   • Добавляйте 2>/dev/null в конце каждого UserParameter, чтобы сообщения об ошибках не попали в Zabbix как значения метрик.

   • Если скрипт или его конкретный режим не принимает параметры, как, например, в случае с discovery, использовать [*] и "$1" не нужно.

   Пример описания UserParameter:

    
   UserParameter=systemd.fd.discovery,/usr/local/bin/zbx_systemd_fd.sh discovery 2>/dev/nullUserParameter=systemd.fd.max[*],/usr/local/bin/zbx_systemd_fd.sh max "$1" 2>/dev/nullUserParameter=systemd.fd.current[*],sudo -n /usr/local/bin/zbx_systemd_fd.sh current "$1" 2>/dev/nullUserParameter=systemd.fd.total[*],sudo -n /usr/local/bin/zbx_systemd_fd.sh total "$1" 2>/dev/null

   В примере приведены три UserParameter с префиксом systemd.fd.*. У каждого — свое назначение (например, текущее значение, максимум, discovery). discovery принимает один аргумент, остальные — два. В Zabbix запрашивается метрика по имени, например systemd.fd.current[public_haproxy]. Агент находит соответствующий UserParameter и запускает команду, например: sudo -n /usr/local/bin/zbx_systemd_fd.sh current public_haproxy. Скрипт возвращает число, например 128 — это и есть значение метрики для Zabbix.

2. Сохраните подготовленный файл zbx_systemd_fd.conf в локальной папке рядом со скриптом.

1. Определите, на каких узлах будет запускаться скрипт:

   • На всех узлах — роль common, группа vkcloud.
   • Только на вычислительных узлах — роль compute, группа vkcloud_compute.
   • Только на управляющих узлах — роль по тематике сервиса.
   • Только на Ceph-узлах — роль ceph.
   • Комбинация ролей или собственная группа.

2. По выбранным узлам определите Ansible-роль и группу, чтобы использовать их далее при настройке. Сохраните название группы.

   В инструкции скрипт предназначен для всех узлов, поэтому далее используется роль common и группа vkcloud.

Чтобы сервис zabbix-server получал данные и появилась возможность настройки на живых метриках, разместите скрипт и файл с UserParameter в веб-интерфейсе Zabbix:

1. Разместите код скрипта из файла zbx_systemd_fd_test.sh в директории /usr/local/bin/ на узле cpn001 под именем zbx_systemd_fd.sh:

    
   $ sudo vi /usr/local/bin/zbx_systemd_fd.sh

2. Дайте права скрипту на исполнение:

    
   $ sudo chmod 755 /usr/local/bin/zbx_systemd_fd.sh

3. Разместите файл с UserParameter в директории /etc/zabbix/zabbix_agentd.d/ под именем zbx_systemd_fd.conf:

    
   $ sudo vi /etc/zabbix/zabbix_agentd.d/zbx_systemd_fd.conf

4. Перезапустите Zabbix-агент:

    
   $ sudo systemctl restart zabbix-agent.service

5. Проверьте, что агент видит метрики.

   Пример проверки через zabbix_agentd:

    
   $ zabbix_agentd -t systemd.fd.discoverysystemd.fd.discovery     [t|{"data":[{"{#SERVICE}":"atd.service"},{"{#SERVICE}":"atopacct.service"},...$ zabbix_agentd -t 'systemd.fd.max[sshd.service]'systemd.fd.max[sshd.service]     [t|524288]$ zabbix_agentd -t 'systemd.fd.current[sshd.service]'systemd.fd.current[sshd.service]     [t|5]$ zabbix_agentd -t 'systemd.fd.total[sshd.service]'systemd.fd.total[sshd.service]     [t|5]

Перейдите в веб-интерфейсе Zabbix (подробнее — в разделе Портал мониторинга).

1. Подготовьте информацию:

   • Логин и пароль администратора Zabbix.
   • Идентификатор дашборда — из URL вида https://<ZABBIX>/zabbix/zabbix.php?action=dashboard.view&dashboardid=376.

2. Получите URL сервера Zabbix с деплой-ноды:

    
   $ ansible -i vkcloud.yml -e env=vkcloud -m debug \  -a "msg={{ zabbix_server_url }}" vkcloud_zabbix[0]

3. Получите токен аутентификации:

    
   $ curl -s -X POST -H "Content-Type: application/json" \  -d '{    "jsonrpc": "2.0",    "method": "user.login",    "params": {      "user": "Admin",      "password": "<ПАРОЛЬ>"    },    "id": 1  }' http://<УЗЕЛ_ZABBIX>/zabbix/api_jsonrpc.php

   Пример ответа:

    
   {"jsonrpc":"2.0","result":"0a6baaa74fce1c60f2f618a3de2019af","id":1}

4. Установите утилиту jq, если она не установлена:

    
   # dnf install jq -y

5. Экспортируйте дашборд:

    
   $ curl -s -X POST -H "Content-Type: application/json" \  -d '{    "jsonrpc": "2.0",    "method": "dashboard.get",    "params": {      "output": "extend",      "selectPages": "extend",      "selectUsers": "extend",      "selectUserGroups": "extend",      "dashboardids": ["<ID_ДАШБОРДА>"]    },    "auth": "<ТОКЕН_АУТЕНТИФИКАЦИИ>",    "id": 1  }' http://<УЗЕЛ_ZABBIX>/zabbix/api_jsonrpc.php \  | jq '.result[0] | del(.dashboardid, .uuid, .pages[].dashboard_pageid, .pages[].widgets[].widgetid)'

   Пример обработанного вывода:

    
   {  "name": "Systemd MaxOpenFiles dashboard",  "userid": "1",  "private": "1",  "display_period": "30",  "auto_start": "1",  "pages": [    {      "name": "",      "display_period": "0",      "widgets": [        {          "type": "problems",          "name": "",          "x": "0",          "y": "0",          "width": "24",          "height": "5",          "view_mode": "0",          "fields": [            {"type": "2", "name": "groupids", "value": "34"},            {"type": "1", "name": "problem", "value": "Open files usage is above 90% of LimitNOFILE"},            {"type": "0", "name": "severities", "value": "3"}          ]        }      ]    }  ],  "users": [],  "userGroups": []}

6. Сохраните результат в файл systemd-maxopenfiles-dashboard.json.

1. Скопируйте файл шаблона в роль zabbix_server:

    
   $ cp ~/zabbix-custom/systemd_fd/Template_App_Systemd_MaxOpenFiles.xml \  ../ansible-openstack/roles/zabbix/zabbix_server/files/zabbix-templates-6/

2. Скопируйте файл дашборда при его наличии:

    
   $ cp ~/zabbix-custom/systemd_fd/systemd-maxopenfiles-dashboard.json \  ../ansible-openstack/roles/zabbix/zabbix_server/files/dashboards-6/

3. В файле group_vars/vkcloud/zabbix.yml зарегистрируйте шаблон, привязку к группе и дашборд:

   1. В секции zabbix_template_list укажите имя файла без расширения. Пример: Template_App_Systemd_MaxOpenFiles.

      Добавление шаблона в zabbix_template_list:

       
      zabbix_template_list:  - Common_monitoring  - HAProxy private  - HAProxy public  # ... другие шаблоны ...  - Template_App_Systemd_MaxOpenFiles #Добавленный файл с шаблоном

   2. В секции zabbix_groups_map_tmp в параметре templates укажите имя шаблона, под которым он будет отображаться в Zabbix. Пример: Template App Systemd MaxOpenFiles.

      Привязка шаблона к группе узлов в zabbix_groups_map_tmp:

       
      zabbix_groups_map_tmp:  VKCP:    meta:      - '{{ consul_dc }}'    templates:      - Common_monitoring      - Linux by Zabbix agent      - Template App Chrony Service      - Template App Systemd MaxOpenFiles #Добавленное имя шаблоном

      В примере используется Zabbix-группа VKCP, которая содержит все узлы инсталляции. Если шаблон нужен только для части узлов, внесите изменения в соответствующую группу в zabbix_groups_map_tmp.

   3. Если вы создали дашборд, добавьте имя его файла без расширения в секцию zabbix_dashboards_6 в файле ./group_vars/vkcloud/zabbix.yml.

      Добавление дашборда в zabbix_dashboards_6:

       
      zabbix_dashboards_6:  - component-status-dashboard  - global-view  - zabbix-server-health  - postgres-dashboards  - systemd-maxopenfiles-dashboard #Добавленный файл с дашбордом

4. Запустите плейбук для применения настроек Zabbix-сервера:

    
   $ ansible-playbook -i vkcloud.yml --diff -e env=vkcloud \  -e zabbix_api4ansible=true \  ../ansible-openstack/playbooks/zabbix_configure_resources.yml

Для дальнейших правок:

• Мелкие изменения вносите напрямую в XML- и JSON-файлы в директории ../ansible-openstack/roles/zabbix/zabbix_server/files/.
• При крупных изменениях повторите экспорт из веб-интерфейса или API и замените файлы.
• В обоих случаях обязательно перезапустите плейбук zabbix_configure_resources.yml.

Скопируйте скрипт и файлы с UserParameter на целевые узлы через Ansible:

1. Выберите Ansible-роль в зависимости от области действия метрики:

   • Мониторинг HAProxy — роль haproxy.
   • Мониторинг вычислительных узлов — роль compute.
   • Мониторинг всех узлов — роль common.

   Группа узлов в Ansible должна совпадать с группой узлов в Zabbix (подробнее — в разделе Определение области действия метрики). Иначе на части узлов UserParameter не будет установлен, либо Zabbix-сервер будет опрашивать не все узлы.

2. Разместите файлы в Ansible-роли:

   1. Через Jinja2 разместите файл с UserParameter в директории templates/, а скрипт просто скопируйте в files/.

   2. Выделите для файлов мониторинга отдельную директорию monitoring/, чтобы не смешивать их с другими файлами роли.

   3. Скопируйте файл с UserParameter в директорию templates/monitoring/ с расширением .j2:

       
      $ mkdir -p ../ansible-openstack/roles/common/templates/monitoring/$ cp ~/zabbix-custom/systemd_fd/zbx_systemd_fd.conf \  ../ansible-openstack/roles/common/templates/monitoring/zbx_systemd_fd.conf.j2

   4. Скопируйте скрипт в директорию files/monitoring/:

       
      $ mkdir -p ../ansible-openstack/roles/common/files/monitoring/$ cp ~/zabbix-custom/systemd_fd/zbx_systemd_fd.sh \  ../ansible-openstack/roles/common/files/monitoring/

3. В файле roles/common/tasks/monitoring.yml добавьте задачи:

    
   - name: "Zabbix | Add custom user params for openfiles checks"  template:    src: "monitoring/zbx_systemd_fd.conf.j2"    dest: "/etc/zabbix/zabbix_agentd.d/zbx_systemd_fd.conf"    owner: root    group: zabbix    mode: 0640  notify: restart zabbix-agent - name: "Zabbix | Add custom zabbix script for openfiles checks"  copy:    src: "monitoring/zbx_systemd_fd.sh"    dest: "/usr/local/bin/zbx_systemd_fd.sh"    owner: root    group: root    mode: 0755  notify: restart zabbix-agent

4. Убедитесь, что в файле handlers/main.yml есть обработчик с именем restart zabbix-agent. Если нет, добавьте его:

    
   - name: restart zabbix-agent  systemd:    name: "{{ 'zabbix-agent2' if 'zabbix-lts-agent2' in ansible_facts.packages else 'zabbix-agent' }}"    state: restarted

5. Если файл tasks/monitoring.yml был создан заново, добавьте его вызов в файл tasks/main.yml:

    
   - include_tasks:    file: tasks/monitoring.yml    apply:      tags: monitoring  tags: monitoring

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

6. Запустите плейбук common.yml:

    
   $ ansible-playbook -i vkcloud.yml --diff -e env=vkcloud \  --tags monitoring ../ansible-openstack/playbooks/common.yml

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

Чтобы сохранить изменения:

1. Убедитесь, что директории vkcloud и ansible-openstack оформлены как Git-репозитории и изменения можно получить командой git status:

   • Пример для Inventory:

      
     $ cd ~/inventory/vkcloud$ git statusOn branch masterChanges not staged for commit:    modified:   group_vars/vkcloud/zabbix.yml

   • Пример для ansible-openstack:

      
     $ cd ../ansible-openstack$ git statusOn branch masterChanges not staged for commit:    modified:   roles/common/tasks/monitoring.ymlUntracked files:    roles/common/files/monitoring/zbx_systemd_fd.sh    roles/common/templates/monitoring/zbx_systemd_fd.conf.j2    roles/zabbix/zabbix_server/files/dashboards-6/systemd-maxopenfiles-dashboard.json    roles/zabbix/zabbix_server/files/zabbix-templates-6/Template_App_Systemd_MaxOpenFiles.xml

2. Создайте директорию для хранения diff-файлов вне репозиториев:

    
   $ mkdir -p ~/zabbix-custom/openfiles-dashboard

3. Сохраните изменения из обоих репозиториев:

    
   $ cd ~/inventory/vkcloud$ git add --all$ git diff --cached --no-renames --full-index \  > ~/zabbix-custom/openfiles-dashboard/vkcloud.diff$ cd ../ansible-openstack$ git add --all$ git diff --cached --no-renames --full-index \  > ~/zabbix-custom/openfiles-dashboard/ansible-openstack.diff

4. После обновления Платформы восстановите изменения:

    
   $ cd ~/inventory/vkcloud$ git apply ~/zabbix-custom/openfiles-dashboard/vkcloud.diff$ cd ../ansible-openstack$ git apply ~/zabbix-custom/openfiles-dashboard/ansible-openstack.diff