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

Введение

За основу мониторинга Mikrotik я возьму стандартный шаблон Zabbix от разработчиков. Он очень качественно сделан. Забирает информацию по snmp. Итемы и триггеры настраиваются через автообнаружение. Вот основные метрики, которые в нем реализованы:

1. Состояние процессоров (загрузка, температура).
2. Статус и характеристика интерфейсов (трафик, активность, ошибки, тип, скорость).
3. Хранилища (общий объем и используемый).
4. Использование оперативной памяти.
5. Проверка доступности пингом.
6. Версия прошивки, модель, система, серийный номер, расположение, описание устройства.
7. Время работы (uptime).

Для всех основных метрик есть графики. На все значимые события настроены триггеры:

• Высокая температура процессора.
• Изменение серийного номера, прошивки.
• Сетевая недоступность по icmp.
• Высокая загрузка памяти или процессора.
• Окончание свободного места на хранилищах.
• Уменьшилась скорость на интерфейсе.
• Высокая утилизация интерфейса.
• Большое количество ошибок на интерфейсе.
• Интерфейс отключился.

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

1. Mikrotik отправляет логи подключений на удаленный syslog сервер.
2. На syslog сервере логи анализирует zabbix-agent.
3. По определенному шаблону агент определяет имя и ip адрес подключившегося к микротику и отправляет эту информацию в уведомлении.

В целом, никаких сложностей в этой настройке нет. У меня уже есть статьи по сбору логов с микротиков — отправка в elk stack и на удаленный rsyslog сервер. Сегодня я актуализирую эту информацию и опишу еще раз.

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

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

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

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

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

Введение

Ранее я рассказывал об использовании утилиты управления упсами марки apc — apcupsd. Я показал, как установить apcupsd на hyper-v и xenserver для корректного завершения работы при отключении электричества. Рекомендую ознакомиться, если вас интересует этот вопрос. Его не всегда получается быстро и удобно решить. На помощь приходит apcupsd.

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

Заранее позаботьтесь об этих вещах. Пишу об этом, потому что сам недавно на одном объекте все запитал от упсов, но забыл про свитч. В итоге об отключении электричества я узнал уже после того, как его вернули назад и сервера автоматически поднялись. Если у вас еще не настроен сервер мониторинга, рекомендую мою подробную статью с видео об установке и настройке zabbix на centos 9 или установка zabbix 3.4 на debian 9.

Настройка мониторинга SMART параметров диска

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

Для сервера zabbix версии 3.4 используйте обновленный шаблон автора.

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

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

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

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

Это достаточно много, но мне так было надо. Рекомендую снизить этот параметр до 50 или 45 градусов.

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

Создание триггера на событие из лога

Мы будем слать оповещение не только в момент отключения электричества, но и тогда, когда оно снова появится. Так что в триггере будут два условия:

1. Условие активации события.
2. И условие его прекращения.

Открываем вкладку с триггерами хоста и добавляем туда новый триггер со следующими параметрами:

Name	Имя триггера. Может быть любым.
Problem expression	{xm-xen02:log[/var/log/apcupsd.events].str(Power failure.)}=1
Recovery expression	{xm-xen02:log[/var/log/apcupsd.events].str(Power is back.)}=1

Рассказываю подробнее, что тут написано. xm-xen02 — имя сервера. Power failure. — строка в лог файле, которая появляется при отключении электричества. Когда оно возвращается, появляется запись Power is back. В общем виде лог выглядит примерно следующим образом:

2016-11-07 23:17:23 +0300 Power failure.
2016-11-07 23:17:29 +0300 Running on UPS batteries.
2016-11-07 23:21:20 +0300 Mains returned. No longer on UPS batteries.
2016-11-07 23:21:20 +0300 Power is back. UPS running on mains.
2016-11-16 14:20:42 +0300 Power failure.
2016-11-16 14:20:48 +0300 Running on UPS batteries.
2016-11-16 14:20:51 +0300 Mains returned. No longer on UPS batteries.
2016-11-16 14:20:51 +0300 Power is back. UPS running on mains.

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

Настройка

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

Настраиваем сервера, требующие сканирования

Необходимо разрешить Zabbix агенту выполнять удаленные команды. Для этого на всех серверах, для ктороых требуется сканирование, измените параметры в файле конфигурации zabbix-agent как показано ниже:

Файл конфигурации zabbix-агента обычно расположен здесь:

Если вы хотите использовать функционал по устранению найденных уязвимостей с помощью Zabbix Threat Control, вам необходимо разрешить пользователю zabbix выполнять обновление пакетов (но не их установку или удаление).

Для RPM-дистрибутивов строка выглядит так:

Для DEB-дистрибутивов немного по-другому:

Подключаемся к Vulners

Для использования Vulners API вам нужен api-ключ. Чтобы получить его:

• Зарегистрируйтесь на vulners.com
• В личном кабинете перейдите на вкладку API KEYS
• Выберите «Scan» в области Scope и нажмите «GENERATE NEW KEY».

Вы получите api-ключ, который выглядит следующим образом: RGB9YPJG7CFAXP35PMDVYFFJPGZ9ZIRO1VGO9K9269B0K86K6XQQQR32O6007NUK

Теперь вам нужно добавить api-ключ Vulners в конфигурационный файл плагина

Пример:

Подключаемся к Zabbix

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

• адрес веб-интерфейса Zabbix для работы с Zabbix-API;
• имя и пароль пользователя, под которым будем подключаться к Zabbix API.

Пример:

Подготавливаем Zabbix

Необходимо создать в Zabbix объекты, обеспечивающие работу плагина. Для этого нужно запустить скрипт . Скрипт проверит что плагин сконфигурирован верно и, используя API создаст в Zabbix:

1. Хост-группу, в которую добавятся хосты, отображающие уязвимости.
2. Шаблон, с помощью которого собирается отчет об ОС со всех серверов.
3. Хосты для отображения уязвимостей по пакетам, серверам, бюллетеням и общей статистики.
4. Экшен для выполнения удаленных команд по исправлению уязвимостей.
5. Дашборд для удобного отображения все этой информации.

После создания в Zabbix всех объектов скрипт покажет:

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

После того, как в Zabbix буду созданы все необходимые объекты, необходимо зайти в веб-интерфейс Zabbix и слинковать только что созданный скриптом шаблон «Vulners OS-Report» со всеми теми серверами, для которых требуется сканирование на уязвимости.

После этого остается дождаться запуска плагина в указанное при инсталляции время.

Дополнительные материалы по Zabbix

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

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

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

Рекомендую полезные материалы по Zabbix:
Настройки системы
Установка 4.0 Обновление 3.0 -> 3.2 Обновление 3.4 -> 4.0 Установка Zabbix Proxy Работа на NGINX Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm.
Мониторинг служб и сервисов
Температура процессора Nginx и php-fpm Mysql репликация Службы Linux Рейд mdadm Транки Asterisk Synology Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix.
Мониторинг различных значений
Мониторинг сайта Мониторинг бэкапов Размер бэкапа Делегирование домена Значения из текстового файла Мониторинг логов Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога.

Сбор метрик на стороне 1С

Теперь обратимся к тому, что было сделано в 1С.

Мы добавили иерархический справочник «Метрики Zabbix», в котором у элемента есть ключ метрики, по которому 1С понимает, какую именно метрику в данный момент запрашивает Zabbix.

Для каждого элемента справочника «Метрики Zabbix» указывается текст запроса, который нужно выполнить, поэтому для добавления новых метрик не надо обновлять 1С. Это очень удобно.

Ну и какие запросы без параметров.

На слайде показан параметр Guid, значение которого мы передаем в JSON с помощью макроса узла сети. Значение этого параметра сразу же подхватывается в запрос и позволяет получить данные по нужной торговой точке.

Также параметры могут быть:

• ссылками на элементы базы данных;

• списком ссылок;

• и даже исполняемым кодом, как ТекущаяДата на представленном примере.

Следующим этапом мы добавили в справочник «Метрики Zabbix» постобработку – это было необходимо для формирования более сложных JSON-ов с несколькими полученными запросом результатами.

Настройка Zabbix

Импорт шаблона

Откройте веб-интерфейс Zabbix. По умолчанию он находится по адресу http://IP-адрес сервера/zabbix.

Зайдите в систему. 

• Логин —Admin
• Пароль —zabbix

Перейдите в раздел Configuration > Templatesи нажмите в правом углу кнопкуImport. В списке шаблонов появитсяTemplate App R-Keeper 7. 

Выберите загруженный файл и снова нажмите кнопку Import.Рекомендуем удалить ненужные шаблоны. Для этого отметьте их галочками и нажмите кнопкуDeleteвнизу.

Создание хостов

Чтобы создать хост, необходимо сначала создать группу. Для создания перейдите в Configuration > Host Groups и нажмите кнопкуCreate host groupв правом углу .Укажите название новой группы и нажмитеAdd

Теперь создайте сами хосты. Перейдите в Configuration > Host и нажмитеCreate host 

Заполните поля:

• Host name— имя хоста. Разрешена только латиница без пробелов. Обязательно должно совпадать с именем, указанным в INI-файле сервера.
• Visible name— отображаемое имя. Может содержать пробелы и русский язык
• Groups— группа хостов
• Agent interfaces— адрес Zabbix-агента. Укажите здесь IP и порт с r_keeper_7, который вы хотите мониторить
• Остальные поля заполнять не нужно. 

Перейдите на вкладку Templates, нажмитеAddи выберите в списке шаблон Template App R-Keeper 7, установленный ранее. Это действие можно сделать позже в массовом порядке.

НажмитеSelect. Шаблон добавится к хосту. Нажмите кнопкуAdd, чтобы сохранить настройки хоста.

Хост появится в списке. Повторите действия для всех нужных хостов.Убедитесь, что для каждого хоста выбран правильный шаблон, иначе данные отображаться не будут.

На этом настройка завершена, можно переходить к наблюдению. 

В другой руке Vulners

• Агрегатор данных об уязвимостях из более чем 115 источников
• Удобное API для различных способов сканирования
• Выдает данные в нормализованном, машино-читаемом виде
• Работает очень быстро
• Позволяет коррелировать данные из различных источников

Мы попробовали их друг с другом интегрировать и вот что из этого получилось.

Zabbix Threat Control

Это плагин к Zabbix, с открытым исходным кодом, написан на Python, который:

• Отображает в веб-интерфейсе Zabbix информацию об уязвимостях, найденных в вашей инфраструктуре.
• Показывает уровень угрозы каждой уязвимости по стандарту CVSS.
• И предлагает легко применимые способы устранения найденных уязвимостей.

CVSS это открытый промышленный стандарт оценки критичности уязвимости. По сути — 10 бальная шкала.

Zabbix Moscow Meetupвидео

Выбирайте стратегии устранения уязвимостей

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

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

Поэтому всегда стоит выбор — какие пакеты мы можем безболезненно обновить. По каким пакетам необходим отдельный план работ по реализации компенсирующих мер. А по каким мы можем принять риски.

Предлагаемый в плагине подход позволяет выбирать подходящую вам стратегию устранения уязвимостей:

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

Подготовка zabbix agent

Мониторинг значений SMART жесткого диска будет выполняться с помощью smartmontools. Установить их можно следующей командой для CentOS:

# yum install smartmontools

Либо аналогично в Debian/Ubuntu

# apt install smartmontools

Далее нам понадобится скрипт на perl для автообнаружения дисков и вывода информации о них в JSON формате, который понимает заббикс. Создадим такой скрипт.

# mcedit /etc/zabbix/scripts/smartctl-disks-discovery.pl

#!/usr/bin/perl

#must be run as root

$first = 1;

print "{\n";
print "\t\"data\":[\n\n";

for (`ls -l /dev/disk/by-id/ | cut -d"/" -f3 | sort -n | uniq -w 3`)
{
#DISK LOOP
$smart_avail=0;
$smart_enabled=0;
$smart_enable_tried=0;

#next when total 0 at output
        if ($_ eq "total 0\n")
                {
                        next;
                }

    print "\t,\n" if not $first;
    $first = 0;

$disk =$_;
chomp($disk);

#SMART STATUS LOOP
foreach(`smartctl -i /dev/$disk | grep SMART`)
{

$line=$_;

        # if SMART available -> continue
        if ($line = /Available/){
                $smart_avail=1;
                next;
                        }

        #if SMART is disabled then try to enable it (also offline tests etc)
        if ($line = /Disabled/ & $smart_enable_tried == 0){

                foreach(`smartctl -i /dev/$disk -s on -o on -S on | grep SMART`) {

                        if (/SMART Enabled/){
                                $smart_enabled=1;
                                next;
                        }
                }
        $smart_enable_tried=1;
        }

        if ($line = /Enabled/){
        $smart_enabled=1;
        }


}

    print "\t{\n";
    print "\t\t\"{#DISKNAME}\":\"$disk\",\n";
    print "\t\t\"{#SMART_ENABLED}\":\"$smart_enabled\"\n";
    print "\t}\n";

}

print "\n\t]\n";
print "}\n";

Сохраняем скрипт и делаем исполняемым.

# chmod u+x smartctl-disks-discovery.pl

Выполняем скрипт и проверяем вывод. Должно быть примерно так с двумя дисками.

{
	"data":
}

В данном случае у меня 2 физических диска — sda и sdb. Их мы и будем мониторить.

Настроим разрешение для пользователя zabbix на запуск этого скрипта, а заодно и smartctl, который нам понадобится дальше. Для этого запускаем утилиту для редактирования /etc/sudoers.

# visudo

Добавляем в самый конец еще одну строку:

zabbix ALL=(ALL) NOPASSWD:/usr/sbin/smartctl,/etc/zabbix/scripts/smartctl-disks-discovery.pl

Сохраняем, выходим Это если вы умеете работать с vi. Если нет, то загуглите, как работать с этим редактором. Именно он запускается командой visudo.

Проверим, что пользователь zabbix нормально исполняет скрипт.

# chown zabbix:zabbix /etc/zabbix/scripts/smartctl-disks-discovery.pl
# sudo -u zabbix sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

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

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

# mcedit /etc/zabbix/zabbix_agentd.d/smart.conf

UserParameter=uHDD,sudo smartctl -A /dev/$1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.,sudo smartctl -i /dev/$1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.,sudo smartctl -i /dev/$1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.,sudo smartctl -H /dev/$1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.,sudo smartctl -l error /dev/$1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Версия настроек для агента 3.4

UserParameter=uHDD.A,sudo smartctl -A /dev/$1
UserParameter=uHDD.i,sudo smartctl -i /dev/$1
UserParameter=uHDD.health,sudo smartctl -H /dev/$1 || true
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Сохраняем файл и перезапускаем zabbix-agent.

# systemctl restart zabbix-agent

Проверяем, как наш агент будет отдавать данные. Ключ uHDD.discovery будет одинаковый для обоих версий агента.

# zabbix_agentd -t uHDD.discovery

Вы должны увидеть полный JSON вывод с информацией о ваших диска. Теперь посмотрим, как передаются информация о smart. Запросим температуру дисков для версии 3.2.

# zabbix_agentd -t uHDD

uHDD 

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

Настройка мониторинга логов

Для того, чтобы мониторить лог файл, на сервере должен быть установлен zabbix agent, а сам сервер добавлен в панель мониторинга. Я буду следить за логом программы apcupsd, который располагается по пути /var/log/apcupsd.events. Идем в веб интерфейс заббикса и добавляем новый итем к интересующему нас хосту. Если у вас таких будет несколько, то создавайте сразу шаблон. В моем случае у меня один сервер, поэтому я буду добавлять новый элемент сразу на него.

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

Создаем новый итем со следующими параметрами:

Name	Имя нового итема. Можете указать любое название.
Type	Тип элемента. Обязательно выбираем Zabbix agent (active). По-умолчанию будет другой тип стоять.
Key	Ключ данных, log — тип, в квадратных скобках путь до лог файла.
Type of information	Указываем тип информации, поступающей в итем.

Остальные параметры оставляете на свое усмотрение. Рекомендую время обновления итема ставить поменьше, чтобы оперативно получить информацию об инциденте. У меня стоит 30 секунд.

После того, как вы сохраните новый итем, через несколько минут начнут поступать данные. Проверять их как обычно в Latest data. В данной конфигурации будут сохраняться все строки из файла. В моем случае это не страшно, так как записей будет очень мало. Они создаются только по событиям в электро сети, а они случаются редко, поэтому я не стал делать фильтр по строкам или словам.

Но это только пол дела. Мы стали собирать логи, теперь нам нужно настроить отправку оповещения при пропадании электричества.

Grafana

Но на этом мы не остановились и подключили к Zabbix-у дашборды на основе Grafana. Это кроссплатформенное программное обеспечение с открытым исходным кодом для аналитики и интерактивной визуализации отчетов. Благо эти проекты (Grafana и Zabbix) очень хорошо дружат и настраиваются из коробки.

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

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

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

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

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

Получив такие дашборды, операционный отдел уже хлопал стоя.

Планируемые обновления

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

Примеры триггеров:

• Число файлов в очереди выгрузки в БД SQL стало больше 10
• Число файлов в очереди на отправку на сервер уровнем выше стало больше 10
• Количество ошибок при выгрузке данных в БД SQL стало больше 0

Примеры метрик

• Метрики по сборку данных смен / онлайн данных
• Метрики по процессам синхронизации справочников
• Метрики по бизнес операциям (среднее время чека / работа систем лояльности и т. д.)
• Метрики по мониторингу доступности компонентов (основной / резервный принтеры)

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-сервере раскладываем его по метрикам.

здесь