Zabbix как сканер безопасности / хабр

Введение

Настройка Zabbix мониторинга, это самое главное что должен делать каждый нормальный системный администратор.

Главных причин по которым вам надо использовать мониторинг несколько:

Не возможно качественно поддерживать работоспособность сети без постоянного анализа её параметров;
Вы первый будете в курсе при возникновении проблемы на обслуживающем оборудовании.

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

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

Например, один клиент поймал шифровальщик файлов и восстановление данных ему обошлось в кругленькую сумму. Другой, который заключил договор на обслуживание (я успел на 80 % выполнить работы по защите баз данных и мониторинга сети) отделался легким испугом.

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

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

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

Введение

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

Введение

Рассказываю подробно, что я хочу получить в конце статьи. В стандартном шаблоне Zabbix для Linux есть несколько триггеров. Они могут немного отличаться в названиях, в зависимости от версии шаблона, но смысл один и тот же:

High CPU utilization
Load average is too high
Too many processes on hostname

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

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

Моя задача посмотреть на список процессов именно в момент нагрузки. Более того, мне даже не нужны все процессы, достаточно первой десятки самых активных, нагружающих больше всего систему. Я буду реализовывать этот мониторинг следующим образом:

Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.
Разрешаю на zabbix agent запуск внешних команд.
Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.

Приступаем к реализации задуманного. Я буду настраивать описанную схему на Zabbix Server версии 5.2. Если у вас его нет, читайте мою статью по установке и настройке zabbix. В качестве подопытной системы будет выступать Centos. Так же предлагаю мои статьи по ее установке и предварительной настройке.

Сразу же сделаю важное замечание. Все, что написано далее, полностью придумано и реализовано мной

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

Обзор

Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.

Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.

На данный момент доступна система Zabbix 4.4. Скачать ее можно на официальном сайте. Там же можно найти официальные курсы и вебинары для начинающих пользователей системы.

Далее рассмотрим, из чего состоит и как работает технология Zabbix в доступном формате «для чайников».

API

Аутентификация

server:~# apt install curl

server:~# curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
   "jsonrpc": "2.0",
   "method": "user.login",
   "params": {
      "user": "Admin",
      "password": "zabbix"
   },
   "id": 1
} ' http://127.0.0.1/zabbix/api_jsonrpc.php

{"jsonrpc":"2.0","result":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","id":1}

Работа с объектами host/template

server:~# apt install jq

Получение списка узлов и шаблонов из Zabbix

server:~# curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
    "jsonrpc": "2.0",
    "method": "host.get",
    "params": {},
    "auth": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "id": 2
} ' http://127.0.0.1/zabbix/api_jsonrpc.php | jq
...

...
    "method": "template.get",
...

Пример запроса определенных атрибутов и с фильтром

...
    "params": {
        "output": ,
        "templateids": 
    },
...

Доступ к результатам мониторинга

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
    "jsonrpc": "2.0",
    "method": "history.get",
    "params": {
        "output": "extend",
        "history": 0,
        "itemids": "NNNNN",
        "sortfield": "clock",
        "sortorder": "DESC",
        "limit": 10
    },
    "auth": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "id": 2
} ' http://127.0.0.1/zabbix/api_jsonrpc.php | jq

Оформление запросов в виде BASH скриптов

server:~# export AUTH=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

server:~# cat /root/zab_get_hosts.sh

#!/bin/sh

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"host.get\",
    \"params\": {},
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php

server:~# /root/zab_get_hosts.sh | jq

Список имен узлов
server:~# /root/zab_get_hosts.sh | jq '.result | .[] | { host: .host} | tostring' | tr -d '{}\\' | tr '"' ' ' | cut -d ' ' -f5

Получение списка карт и их элементов из Zabbix

server.corp1.un:~# cat /root/zab_get_maps.sh

#!/bin/sh

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"map.get\",
    \"params\": {
        \"selectLinks\": \"extend\",
        \"selectSelements\": \"extend\"
    },
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php | jq

Пример изменения конфигурации через Zabbix API

server.corp1.un:~# cat /root/zab_set_map_name.sh

#!/bin/sh

MAPID=$1
MAPNAME=$2

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"map.update\",
    \"params\": {
        \"sysmapid\": \"${MAPID}\",
        \"name\": \"${MAPNAME}\"
    },
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php

server.corp1.un:~# /root/zab_set_map_name.sh 2 "Super MAP"

Создание пользователей

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

На Master

На мастере создаем нового пользователя командой:

sudo -u postgres createuser -P mon_replication

* в данном примере мы создадим пользователя mon_replication
* после ввода команды система потребует ввести новый пароль. Задаем более сложный, например, repl_password3.

Открываем конфигурационный файл pg_hba.conf. Для этого сначала смотрим путь расположения конфигурационных файлов:

ps aux | grep postgres | grep — -D

В полученном ответе мы увидим в конце строки что-то на подобие:

… -D /var/lib/pgsql/9.6/data/

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

Открываем pg_hba.conf:

vi /var/lib/pgsql/9.6/data/pg_hba.conf

Добавляем строку:

host template1 mon_replication 127.0.0.1/32 md5

* данная строка должна быть выше строки host all all 127.0.0.1/32 ident

Перезапускаем postgresql:

systemctl restart postgresql-9.6

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

На Slave

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

sudo -u postgres psql -c «SELECT * FROM pg_user;»

После нам нужно внести настройки в конфигурационном файле pg_hba.conf:

vi /var/lib/pgsql/9.6/data/pg_hba.conf

* обратите внимание, что путь до /var/lib/pgsql/9.6/data на разных серверах может быть другой. Добавляем строку:

Добавляем строку:

host template1 mon_replication 192.168.1.10/32 md5

* где вместо 192.168.1.10 должен быть адрес мастер-сервера.

Перезапускаем postgresql:

systemctl restart postgresql-9.6

Снова на мастере

Проверяем, что мы можем подключиться и выполнить запросы проверки состояния к нашим серверам.

Экспортируем пароль для созданного нами ранее пользователя:

export PGPASSWORD=’repl_password3′

* в данном примере мы создали пользователя с паролем repl_password3. Данная команда создаст системную переменную PGPASSWORD — ее значение принимает в качестве пароля сервер PostgreSQL.

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

psql -Umon_replication template1 -h127.0.0.1 -c «SELECT pg_current_xlog_location();»

* где mon_replication — созданный нами пользователь; 127.0.0.1 — сервер, к которому мы подключаемся, то есть, к самому себе.

Мы должны получить ответ, на подобие:

pg_current_xlog_location
—————————
0/30694B8
(1 строка)

Пробуем получить состояние репликации для слейва:

psql -Umon_replication template1 -h192.168.1.11 -c «SELECT pg_last_xlog_replay_location();»

* где 192.168.1.11 — IP-адрес нашего сервера slave.

Мы должны получить ответ, похожий на ответ от мастера.

Модуль 3: Базовые сущности Zabbix

Лабораторные работы: Базовые элементы процесса мониторинга

Визуализация данных

Monitoring->Latest data
  ya.ru->check perf http ya.ru
  Zoom: 1h

Простые проверки доступности системы gate.isp.un и (не обязательно) сервиса RDP на windows client1 через server (методически лучше удалить host “Zabbix server” и добавить host server с адресом 127.0.0.1 и любым интерфейсом)

уведомляющего о недоступности gate.isp.un/ya.ru (с зависимостью друг от друга)
Отчет о проблемах

Monitoring->Triggers
  или
Monitoring->Problems

Сравнение мгновенных и средних значений за период на комплексном графике

gate# apt install wondershaper 

gate# wondershaper eth1 10 10

gate# wondershaper eth1

gate# wondershaper clear eth1

уведомляющего о ухудшении качества доступа в Интернет на основании повышения среднего времени ответа за период
(включают отображение триггеров)

Asterisk. Интеграция

или просто:

Обработка полей формы и вызов внешних программ

Web сценарии (обзор значений в Latest data позволит создать соответствующие триггеры)

# tail -f /var/log/apache2/access.log  | grep ast

Вопросы

Верно ли, что система Zabbix позволяет осуществлять мониторинг только тех систем, на которых установлен агент?
Перечислите, какие интерфейсы может использовать Zabbix для мониторинга?
Есть ли возможность осуществлять мониторинг системы, не имеющей поддерживаемых Zabbix интерфейсов?
Как можно уменьшить количество сообщений системы мониторинга в случае сбоев больших коммутационных узлов?
Приведите примеры использования вычисляемых элементов.
Для чего нужны пользовательские графики?
Какие возможности, по сравнению с net.tcp.service.perf предоставляют Web сценарии?
Можно ли мониторить работоспособность неуправляемого коммутатора?

Модуль 1: Развертывание IT инфраструктуры предприятия

Лабораторные работы: Развертывание объектов мониторинга

Настраиваем необходимый для мониторинга минимум из курса Администрирование сервисов UNIX с использованием

Для локальной сети использовать VirtualBox Host-Only Ethernet Adapte (понадобится в лабораторной работе про простые проверки)
gate и server
Создать в Putty профили
Сервис DHCP (понадобится в лабораторной работе про LLD)
Финальная настройка DNS сервера (понадобится в лабораторной работе про простые проверки)
Настройка клиента DNS на gate и server

# cat /etc/resolv.conf

search corpX.un
nameserver 192.168.X.10

Запуск системы client1

Модуль 8: Активная регистрация оборудования

Лабораторные работы: Мониторинг систем с динамическими адресами

необходимо настроить firewall,
может измениться IP адрес (для демонстрации можно сменить mac адрес)
LLD в пассивном режиме использует имя системы, и, если его нет в DNS — не работает.

# grep 192.168.X.102 /var/log/zabbix/zabbix_server.log
...
12202:20190605:125020.551 cannot send list of active checks to "192.168.X.102": host  not found
...

Для решения можно использовать инфраструктуру MS AD, или или активный режим агента

Активный режим (клонирование шаблонов и настройка элементов на активный режим агента, настройка авто регистрации систем с активными агентами и настройка агента client1 на активный режим.

Домашнее задание — отключить уведомления о включении/выключении (…just been restarted…, Zabbix agent on … is unreachable…) клиентских компьютеров

Вопросы

Чем отличается активный режим от пассивного в zabbix агенте?
Придумайте варианты конфигураций сети, при которых необходимо использовать активный режим агента zabbix.

Логи наше все

Логи по традиции мира *.nix хранятся в текстовых файлах и располагаются в каталоге ‘/var/log/zabbix’.

В этом же каталоге можно увидеть файлы логов Zabbix-агента. Чаще всего на сервере Zabbix для отслеживания работы сервера установлен агент. Да, Zabbix-сервер следит сам за собой.

Прочитать содержимое можно стандартными для Linux способами:

Смотрим файл логов с возможностью прокрутки.

Просмотр файла логов в реальном времени.

Смотрим первые записи

Смотрим последние события

Получаем только записи с ошибками

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

Вот, например, вывод последних 10 событий из файла логов.

Здесь мы видим события процесса housekeeper, который отвечает за удаление устаревшей информации из базы данных мониторинга. Далее идут более интересные события об ошибке связи с хостом “YY-COMP”, а также события последующего восстановления соединения с агентом этого хоста.

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

Архитектура Zabbix

У Zabbix есть 4 основных инструмента, с помощью которых можно мониторить определенную рабочую среду и собирать о ней полный пакет данных для оптимизации работы.

Сервер — ядро, хранящее в себе все данные системы, включая статистические, оперативные и конфигурацию. Дистанционно управляет сетевыми сервисами, оповещает администратора о существующих проблемах с оборудованием, находящимся под наблюдением.
Прокси — сервис, собирающий данные о доступности и производительности устройств, который работает от имени сервера. Все собранные данные сохраняются в буфер и загружаются на сервер. Нужен для распределения нагрузки на сервер. Благодаря этому процессу можно уменьшить нагрузку на процессор и жесткий диск. Для работы прокси Zabbix отдельно нужна база данных.
Агент — программа (демон), которая активно мониторит и собирает статистику работы локальных ресурсов (накопители, оперативная память, процессор и др.) и приложений.
Веб-интерфейс — является частью сервера системы и требует для работы веб-сервер. Часто запускается на том же физическом узле, что и Zabbix.

Установка и запуск proxy

sqlite3

Из репозитория Zabbix

# apt install zabbix-proxy-sqlite3

# mkdir /var/lib/zabbix

# zcat /usr/share/doc/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix.db

Из репозитория Debian

# apt install zabbix-proxy-sqlite3

# less /usr/share/doc/zabbix-proxy-sqlite3/README.Debian

# zcat /usr/share/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix.db

Настройка и запуск

# chown -R zabbix:zabbix /var/lib/zabbix

# vim /etc/zabbix/zabbix_proxy.conf

...
Hostname=gate
ConfigFrequency=60
Server=server
DBName=/var/lib/zabbix/zabbix.db

MySQL

Из репозитория Debian

gate# apt install zabbix-proxy-mysql

gate# cat zabbix_proxy.sql

#drop database zabbix_proxy;
create database zabbix_proxy character set utf8 collate utf8_bin;
grant all privileges on zabbix_proxy.* to zabbix@localhost identified by 'zabbix';

gate# mysql < zabbix_proxy.sql

gate# zcat /usr/share/zabbix-proxy-mysql/schema.sql.gz | mysql -uzabbix -pzabbix zabbix_proxy

gate# cat /etc/zabbix/zabbix_proxy.conf

...
Hostname=gate
ConfigFrequency=60
Server=server
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=zabbix

gate# systemctl enable zabbix-proxy

gate# service zabbix-proxy start

Проверка отправки списка процессов

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

# cat /dev/zero | bzip2 -c > /dev/null
# md5sum /dev/urandom

Они достаточно быстро нагрузили единственное ядро тестового сервера, так что оставалось только подождать активации триггера. Через 5 минут это случилось.

Иду в раздел Последние данные и вижу там список процессов, которые нагрузили мой сервер.

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

Получение доступа к API Яндекс

Вам нужно будет заполнить несколько обязательных полей:

Название приложения.
В качестве платформы указать Веб-сервисы.
Callback URI установить — https://oauth.yandex.ru/verification_code.
В Доступах указать: Яндекс.Метрика, Получение статистики, чтение параметров своих и доверенных счетчиков.

Все остальное можно не указывать. Вы должны получить ID приложения и Пароль.

После разрешения, вы получите токен, с помощью которого можно подключаться к api.

Используя этот токен, можно получать данные из Метрики через API. Для примера зайдем на сервер мониторинга и через консоль запросим данные о посещаемости сайта. Для этого нам нужно узнать номер его id в метрике. Можно это сделать прямо в ней же.

Далее формируем запрос через curl с указанием токена в header.

# curl --header "Authorization: OAuth AgAAaaaaaaaaaaaDDDDDDDDDddd" --header "Content-Type: application/x-yametrika+json" -X GET "https://api-merika.yandex.ru/stat/v1/data?&ids=23506456&metrics=ym:s:users,ym:s:visits,ym:s:pageviews&dimensions=&date1=today&pretty=true"

В данном запросе я указал:

AgAAAAAAGk3WAAaaYZaUSgzNyU7uvqAKCGwDSro — токен;
ids=23506456 — id сайта в метрике;
metrics=ym:s:users,ym:s:visits,ym:s:pageviews — запрошенные метрики — пользователи, визиты, просмотры страниц;
date1=today — дата, сегодняшний день в данном случае;
pretty=true — вывести в формате удобочитаемого json.

Получили ответ в виде подробного json. Он отлично подходит для zabbix, так как последний умеет из коробки парсить json. У вас есть 2 варианта дальнейшей настройки мониторинга:

Сделать скрипт на сервере, который будет слать запросы в api яндекса и передавать полученное значение в zabbix с помощью агента. Плюс решения в том, что нагрузка на сервер мониторинга минимальная. Неудобство в том, что нужно куда-то добавлять скрипт.
Слать запросы к api напрямую с zabbix сервера с помощью HTTP Агента. И сразу там же парсить полученный ответ. Плюс этого подхода в том, что все настройки хранятся в шаблоне и легко сохраняются или переносятся через экспорт шаблона. Минус в том, что все вычисления и запросы выполняются самим заббиксом.
Я обычно иду по второму пути, потому что так удобнее.

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

Модуль 6: Низкоуровневое обнаружение (LLD)

Лабораторные работы: Управление конфигурацией с помощью шаблонов и LLD

6.1 Первое знакомство с LLD

Configuration->Hosts->...->Items
                         ->Triggers
                         ->Graphs
                                ->Mounted filesystem discovery: ...
                                ->Network interface discovery: ...

Administration->General->Regular expressions

6.2 Создание своего шаблона с LLD

gate# cat /etc/network/interfaces

gate# ifup eth2

gate# cat /etc/default/isc-dhcp-server

gate# cat /etc/dhcp/dhcpd.conf

gate# service isc-dhcp-server restart

Разработка шаблона, использующего Low-Level Discovery (LLD) для мониторинга использования адресного пространства DHCP сетей (как вариант, преподаватель разрабатывает шаблон и скрипты которые загружают слушатели)

Придумайте свои варианты задач, при которых может понадобиться LLD.
Как можно отфильтровать только нужные элементы в процессе discovery?

Модуль 4: Использование шаблонов

Лабораторные работы: Управление конфигурацией с помощью шаблонов

4.2 Использование готовых шаблонов

Обзор шаблона “Template OS Linux”
Установка zabbix agent на server (, можно оставить конфигурацию по умолчанию)
Применить к созданному host server шаблоны “Template OS Linux” и “Template App Zabbix Server”

4.3 Создание шаблона на основе существующего

на основе Template App SSH Service с добавлением макроса, определяющего порт сервиса
Установка zabbix agent на gate () (рассмотреть и, в конце, отключить PSK аутентификацию и на агенте и на сервере, для удобства выполнения последующих лабораторных работ)
Назначаем шаблон системам server и gate
Меняем порт () на gate и переопределяем значение макроса

gate# /usr/sbin/sshd -p 2222

gate# kill `cat /var/run/sshd.pid`

Чем шаблоны лучше клонирования?
Что можно использовать к качестве переменных в выражениях триггеров?
Как работает переопределение и наследование макросов?
Какой синтаксис у макроса?
Что произойдет с объектами хостов при изменении описывающего их шаблона?
Можно ли поменять значение объекта хоста, описанного шаблоном?
Как обеспечить безопасную связь между zabbix агентом и сервером?

API

Аутентификация

server:~# apt install curl

server:~# curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
   "jsonrpc": "2.0",
   "method": "user.login",
   "params": {
      "user": "Admin",
      "password": "zabbix"
   },
   "id": 1
} ' http://127.0.0.1/zabbix/api_jsonrpc.php

{"jsonrpc":"2.0","result":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","id":1}

Работа с объектами host/template

server:~# apt install jq

Получение списка узлов и шаблонов из Zabbix

server:~# curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
    "jsonrpc": "2.0",
    "method": "host.get",
    "params": {},
    "auth": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "id": 2
} ' http://127.0.0.1/zabbix/api_jsonrpc.php | jq
...

...
    "method": "template.get",
...

Пример запроса определенных атрибутов и с фильтром

...
    "params": {
        "output": ,
        "templateids": 
    },
...

Доступ к результатам мониторинга

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d '
{
    "jsonrpc": "2.0",
    "method": "history.get",
    "params": {
        "output": "extend",
        "history": 0,
        "itemids": "NNNNN",
        "sortfield": "clock",
        "sortorder": "DESC",
        "limit": 10
    },
    "auth": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "id": 2
} ' http://127.0.0.1/zabbix/api_jsonrpc.php | jq

Оформление запросов в виде BASH скриптов

server:~# export AUTH=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

server:~# cat /root/zab_get_hosts.sh

#!/bin/sh

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"host.get\",
    \"params\": {},
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php

server:~# /root/zab_get_hosts.sh | jq

Список имен узлов
server:~# /root/zab_get_hosts.sh | jq '.result | .[] | { host: .host} | tostring' | tr -d '{}\\' | tr '"' ' ' | cut -d ' ' -f5

Получение списка карт и их элементов из Zabbix

server.corp1.un:~# cat /root/zab_get_maps.sh

#!/bin/sh

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"map.get\",
    \"params\": {
        \"selectLinks\": \"extend\",
        \"selectSelements\": \"extend\"
    },
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php | jq

Пример изменения конфигурации через Zabbix API

server.corp1.un:~# cat /root/zab_set_map_name.sh

#!/bin/sh

MAPID=$1
MAPNAME=$2

curl -s -k -X POST -H 'Content-Type: application/json-rpc' -d "
{
    \"jsonrpc\": \"2.0\",
    \"method\": \"map.update\",
    \"params\": {
        \"sysmapid\": \"${MAPID}\",
        \"name\": \"${MAPNAME}\"
    },
    \"auth\": \"${AUTH}\",
    \"id\": 2
} " http://127.0.0.1/zabbix/api_jsonrpc.php

server.corp1.un:~# /root/zab_set_map_name.sh 2 "Super MAP"

Модуль 5: Внешние проверки и пользовательские параметры

Лабораторные работы: Мониторинг с использование внешних программ/скриптов

(обсудить)

Настройка триггеров

Задание, сделать триггер, по аналогии

5.2 Настройка мониторинга статистики сервиса DHCP

(демонстрирует преподаватель)
в zabbix-agent для мониторинга количества выданных ip сервисом DHCP

Configuration->Host->gate
  Items
    Name: DHCP stat CUR
      ...
    Name: DHCP stat MAX
      ...
  Graphs
    Name: DHCP stat CUR MAX
      ...

Использование для отображения процента выданных адресов
“On gate dhcp subnet is full”

Какое ограничение накладывает zabbix на выполнение внешних скриптов?
Какие варианты имеются для запуска скриптов на удаленных системах из zabbix?
Как можно передать в zabbix результаты, получаемые в результате длительного времени?

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

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

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

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

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

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

Настройка UserParameter агента Zabbix

На мастере открываем настройки zabbix агента:

vi /etc/zabbix/zabbix_agentd.conf

Добавляем строку:

UserParameter=pg_repl_mon,/etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

* в данном случае, мы создаем в zabbix агенте пользовательский параметр с именем pg_repl_mon — при его вызове будет запускаться скрипт /etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh, который мы ранее создали.

Перезапускаем агента:

systemctl restart zabbix-agent

Проверяем работу параметра. Для этого с сервера zabbix выполняем команду:

zabbix_get -s 192.168.1.10 -k pg_repl_mon

* данной командой мы обращаемся к серверу 192.168.1.10 (это должен быть адрес сервера, на котором мы настроили агента и скрипт); pg_repl_mon — параметр, который мы вызывает.

… команда должна вернуть либо 0 (если есть проблемы с репликацией), либо 1.

Таймаут выполнения скриптов

Еще небольшой ошибкой может быть ситуация, когда на сервер не поступают данные по каким-либо элементам данных, а в логах агента можно увидеть ошибки вида:

Так происходит, поскольку выполняемый скрипт не укладывается в заданное время выполнения. Время задается также в конфигурации агента Zabbix и по умолчанию составляет 3 секунды.

Имеется три основных варианта решения:

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

Второй вариант — разобраться в причинах долгого выполнения и попытаться их исправить. Конечно, если это возможно.
Отказаться от сбора этих метрик

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

Продолжение следует

Это была еще одна небольшая публикация по теме мониторинга с помощью Zabbix. В следующих статьях мы поговорим об обновлении Zabbix с версии 4.0 на 5.0, создадим свой шаблон для сбора метрик и рассмотрим некоторые особенности этого процесса, настроим уведомления в Telegram-канал, а также получении данных с Prometheus и визуализации данных в Grafana. И, конечно же, оптимизация производительности сервера мониторинга Zabbix!

Будьте на связи

Будьте в курсе

Создание материалов будет продолжаться. Хотите быть в курсе последних обновлений? Подписывайтесь на канал.

По любым вопросам пишите на электронную почту. Адрес в самом низу страницы.

← Предыдущая
публикация

Следующая
публикация →

Zabbix Documentation 3.0

Обзор

Раздел Мониторинг → Триггеры отображает состояния триггеров.

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

Состояние
состояние отображаемого триггера — ОК или ПРОБЛЕМА.По умолчанию, состояние будет мигать 30 минут у триггеров, которые недавно изменили свое состояние

Кроме того, триггеры, которые перешли в состояние ОК, будут еще отображаться в течении 30 минут, даже если фильтр задан на отображение только проблем.
Цвет текста и опции мигания можно настроить в Администрирование → Общие → Опции отображения триггеров.

Инфо
Серая иконка со знаком вопроса показывает, что имеется некоторая важная информация. Если вы наведете курсор мыши на неё, отобразится сообщение.
Последнее изменение
Дата и время последнего изменения состояния отображаемого триггера.
Возраст
Возраст последнего изменения состояния отображаемого триггера.
Подтверждено
Состояние подтверждения отображаемого триггера:Подтверждено — зеленый текст показывает, что триггер подтвержден
Триггер считается подтвержденным, если всего его события о проблемах подтверждены (или если были только ОК события).
Подтвердить — красная ссылка показывает, что имеются события о проблемах (и их количество в круглых скобках).
Если вы нажмете на эту ссылку, то перейдете на экран массового подтверждения, где все события этого триггера можно подтвердить за раз.
Обратите внимание: Если вы желаете подтвердить только одно событие, перейдите в Мониторинг → События.
Нет событий — если у триггера нет событий о проблеме. Отображение этой строки поддерживается начиная с Zabbix 2.0.4; до этого подобные триггеры отображались как Подтверждено.

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

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

Описание
Ссылка на описание триггера.Ссылка на добавление описаний к триггерам созданным при помощи низкоуровневого обнаружения была удалена в Zabbix 3.0.6. Такие описания всё равно позже удалялись низкоуровневым обнаружением, если они отсутствовали в оригинальном прототипа триггеров.

Отрицательная длительность проблемы

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

Если какой-либо узел сети наблюдается прокси и происходит сетевая ошибка, которая приводит к тому, что данные от прокси не поступают некоторое время, тогда триггер item.nodata() сработает на стороне сервера. Когда соединение восстановится, сервер получит данные по элементу данных от прокси, у этих данных будет время из прошлого. Тогда проблема item.nodata() будет решена и у нее будет отрицательная длительность проблемы;
Когда данные элемента данных, которые решают событие проблемы поступили от Zabbix sender и содержат штамп времени более старый чем время создания проблемы, в этом случае также отобразится отрицательная длительность проблемы.

Использование фильтра

Вы можете использовать фильтр для отображения только тех триггеров в которых вы заинтересованы. Фильтр располагается выше таблицы.

По умолчанию отображаются триггеры только в состоянии ‘Недавняя проблема’ — включая как проблемные триггеры, так и триггеры, которые только совсем недавно изменили свое состояние в ОК. Вы можете выбрать на отображение триггеров только в состоянии ‘Проблема’ (только проблемные триггеры) или ‘Любое’.

Обратите внимание, если вы выберите ‘Любое’, тогда количество обрабатываемых данных на больших инсталляциях может быть огромным и загрузка страницы может занять весьма продолжительное время, если вообще загрузится. Вы можете исправить такое поведение, заменив URL параметры на ?filter_rst=1, чтобы сбросить фильтр

Опции массового редактирования

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

Массовое подтверждение — подтверждение выбранных триггеров

Чтобы использовать эту опцию, отметьте соответветствующие триггеры и нажмите на Массовое подтверждение.

Заключение

Онлайн курс «SRE практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «SRE практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и Linux. Обучение длится 3 месяц, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

На курсе вы узнаете как:

Внедрить SRE практики в своей организации
Управлять надежностью, доступностью и эффективностью сервисов
Управлять изменениями
Осуществлять мониторинг
Реагировать на инциденты и производительность
Работать со следующим технологическим стеком: Linux, AWS, GCP, Kubernetes, Ansible, Terraform, Prometheus, Go, Python.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .