​​Расскажу про простой и быстрый способ увидеть лог smtp сессии при обращении к какому-то почтовому серверу. Как вы уже знаете из прошлой заметки про curl, она умеет работать с различными протоколами. В том числе и с smtp.

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

# curl smtp://mail.site.ru:25 -v \
--mail-from sysadmin@site.ru \
--mail-rcpt sysadmin@site.ru \
--user 'sysadmin@site.ru:password' \
--upload-file ~/email.txt

Содержимое email.txt примерно такое:

From: sysadmin@site.ru
To: sysadmin@site.ru
Subject: test email
Date: Mon, 17 Apr 2023 00:17:16

Dear Sysadmin,
Welcome to this test email. What a lovely day.

В консоли будете наблюдать лог smtp сессии. Если что-то не так, увидите ошибку.

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

Мне захотелось разобраться в проблеме, поэтому погрузился в тематику. Выяснил, что Zabbix отправляет почту через curl. Со стороны почтового сервера было не очень понятно, в чём конкретно проблема, он просто ругался на неправильную аутентификацию. Немного поигрался в консоли с curl и понял, в чём проблема.

Curl почему-то по умолчанию предлагает аутентификацию DIGEST-MD5 и она по какой-то причине происходит с ошибкой. По идее, клиент дальше должен пробовать другие методы, но конкретно в этой ситуации curl получал ошибку аутентификации и больше никаких попыток не делал. Дело было на сервере Centos 7, где curl очень старой версии. В сети нашёл информацию, что на нём реально могут быть проблемы с аутентификацией. Обновил утилиту до последней версии, но мне это не помогло.

Дальше разбираться не стал. Слишком много времени ушло, а проблема не критичная. Обошёл её, сделав исключение для конкретного IP адреса.

Вот эта же проблема, описанная на форуме Zabbix, а вот предложенное решение по обновлению curl на centos 7, которое мне не помогло.

#linux #curl #zabbix

​​Давно не было заметок о Zabbix, хотя я с ним регулярно работаю. В основном привычные настройки делал. Из последнего — настраивал мониторинг сайтов, docker контейнеров, бэкапов. Стандартный шаблон для Docker очень нравится. Полезные метрики, оповещения, всё на автообнаружении сделано. Ручной работы нет. Статьи в целом актуальны по смыслу и идеям реализации, но где-то в деталях и картинках устарели. Планирую после релиза 7.0 весь раздел по Zabbix на сайте актуализировать.

От команды Zabbix последнее время не было каких-то значимых новостей, заметок в блоге или на ютуб канале. Я за всем этим слежу. Из более ли менее интересных событий отмечу следующие:

▪ Появился шаблон оповещений для интеграции с новой технологией Event-Driven Ansible.

▪ На днях в блоге вышла очень хорошая статья, описывающая принципы создания новых метрик с использованием различных преобразований. Для примера там взяли типовой шаблон для Nginx и показали, как к базовым метрикам добавить новые. Например, показать динамику изменения числа запросов к веб серверу и вывести метрику на дашборд. Таких примеров там много, статья большая. Рекоvендую, если осваиваете Zabbix.

▪ Ещё одна интересная статья про добавление в Zabbix метеокарты. К сожалению, статья слишком поверхностная и у меня быстро не получилось повторить настройку. Более детально разбираться не было времени. Хотел для личного использования настроить.

▪ В Zabbix 6.4 появилась возможность выгружать события из Zabbix в режиме реального времени в другие системы. В статье описан пример реализации этой функциональности.

▪ Цикл видео про настройку мониторинга Kubernetes с помощью Zabbix (1, 2, 3 части)

▪ 25 мая будет вебинар на русском языке — Обзор системы мониторинга Zabbix.

💡Релиз Zabbix 7.0 LTS обещают к концу этого года. Думаю, перенесут на начало 2024, как это обычно бывает. Там много полезного обещают завести. Например, сбор метрик из сторонних TSDB, наконец-то обновление раздела Inventory. Я думал, они его в конце концов уберут. Обновление мониторинга сайтов обещают, но пока даже не начали разработку. Скорее всего отложат.

#zabbix

​​На днях реализовал мониторинг безопасности Linux сервера с помощью Lynis и Zabbix. Я давно планировал реализовать что-то подобное, но всё руки не доходили. Lynis делает неплохие проверки, которые легко читаются и понимаются. В нём есть хорошая база, на которую удобно ориентироваться.

Изначально планировал написать полноценную статью, но, как обычно, не нашёл для этого времени. Целый день потратил на реализацию, так что когда напишу статью — неизвестно. Пусть хоть заметка будет. Может кому-то пригодиться.

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

Основная проблема данной задачи — длительность проверки Lynis. Она может длиться минуту-две. Из-за этого неудобно запускать проверку через Zabbix, ждать вывода и потом его парсить. Нужны очень большие таймауты. К тому же вывод у Lynis очень длинный. Пришлось идти другим путём, менее удобным и гибким — писать bash скрипт, запускать его по таймеру и анализировать вывод.

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

В итоге написал скрипт, результат его работы вывел в 2 текстовых файла:
◽lynis-exitcode.txt — в Lynis есть отличный параметр error-on-warnings=yes. Если его активировать, то статус выхода lynis после проверки будет ненулевым, если есть какие-то замечания по безопасности. Скрипт выводит exit code команды в этот файл.
◽lynis-warnings.txt — в этот файл через парсинг лога Lynis я вывожу все его замечания и список пакетов с уязвимостями.

Сам скрипт выложил на pastebin. Я положил его в /etc/zabbix/scripts, туда же кладу логи. Настройте выполнение скрипта через systemd.timers. Мне кажется, достаточно раз в час выполнять или даже реже, пару раз в день.

Далее сделал простой шаблон под Zabbix 6.0 с двумя айтемами типа лог, которые забирают значения из lynis-exitcode.txt и lynis-warnings.txt. И там же один триггер, который срабатывает, если в файле lynis-warnings.txt нет строки All is OK, которую туда пишет скрипт, если exit code после работы Lynis равен 0 (т.е. всё в порядке). Когда срабатывает триггер, на почту прилетает оповещение, в тексте которого есть информация из lynis-warnings.txt, куда записаны предупреждения и список проблемных пакетов.

Для того, чтобы отключить ту или иную проверку на хосте, надо в файл конфигурации Lynis, который живёт по адресу /etc/lynis/default.prf добавить исключения по одному в каждой строке:
skip-test=CRYP-7902
skip-test=PKGS-7392
skip-test=MAIL-8818

Отладка работы примерно так и выглядит. Запускаете скрипт, смотрите результат. Будут какие-то замечания. Сделайте для них исключение и снова запустите скрипт. Так и проверяйте всю последовательность действий вплоть до оповещений. Потом, соответственно, так же на хосте настраиваются исключения, если какие-то проверки для него неактуальны. Например, тест tls сертификатов. Он по какой-то причине очень долго идёт. Я его отключил.

Заметка получилась немного сумбурная. Тема не для новичков, а для тех, кто умеет работать с Zabbix и bash. В коротком очерке её не раскрыть. Надеюсь, получится написать статью. Там уже подробно всё распишу.

Мне понравился результат. Удобно сразу получить информацию о проблеме на почту. Подробную информацию по коду ошибки можно получить либо в полном логе Lynis на самом сервере в файлах /var/log/lynis.log и /var/log/lynis-report.dat или на сайте https://cisofy.com/lynis/controls/ в разделе с описанием проверок.

#zabbix

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

Мониторинг безопасности сервера с помощью Lynis и Zabbix
⇨ https://serveradmin.ru/monitoring-bezopasnosti-servera-s-pomoshhyu-lynis-i-zabbix

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

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

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

#zabbix #security

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

Речь пойдёт про сервис ntfy.sh. Сразу покажу, как им пользоваться, чтобы было понятно, о чём идёт речь. Идёте по ссылке в веб приложение: https://ntfy.sh/app. Разрешаете ему отправлять уведомления. Подписываетесь на новую тему. После этого получаете ссылку вида: ntfy.sh/Stkclnoid6pLCpqU

Теперь идёте в любую консоль и отправляете с помощью curl себе уведомление:

# curl -d "Test Message" ntfy.sh/Stkclnoid6pLCpqU

Получаете оповещение от веб приложения. То же самое можно сделать, установив на смартфон приложение. Сервис бесплатный. При этом серверная часть open source. Вы можете развернуть сервер у себя и отправлять уведомления через него. Есть репозитории под все популярные системы. Инструкция прилагается.

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

var response,
  payload,
  params = JSON.parse(value),
  wurl = params.URL,
  msg = params.Message,
  request = new CurlHttpRequest();
  request.AddHeader('Content-Type: text/plain');
  response = request.Post(wurl, msg);

В качестве URL укажите свою подписку в ntfy. Теперь это оповещение можно добавлять пользователям. Им будет приходить уведомление с текстом, который передаёт макрос {ALERT.MESSAGE}.

Либо совсем простой пример для какой-то операции в консоли:

# rsync -a /mnt/data user_backup@10.20.1.1:/backups/srv01 \
 && curl -H prio:low -d "SRV01 backup succeeded" ntfy.sh/Stkclnoid \
 || curl -H tags:warning -H prio:high -d "SRV01 backup failed" ntfy.sh/Stkclnoid

Если бэкап успешен, отправляем одно уведомление, если нет, то другое.

Такой вот простой и удобный сервис.

⇨ Сайт / Исходники

#мониоринг #zabbix #devops

​​У Zabbix вчера была рассылка с новостями. Давно ничего не писал про него, потому что новостей особо не было. Буднично проходили новости об очередных обновлениях и конференциях в разных странах. А в этот раз они немного подробностей дали по поводу новой версии 7.0, у которой уже 3-я альфа вышла. Так что работа идёт и релиз всё ближе.

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

Помимо новых визуализаций, появится виджет с топом триггеров. Я так понял, что это виджет из отчёта 100 наиболее активных триггеров (в русском интерфейсе). Он показывает триггеры, которые чаще всего меняли своё состояние (срабатывали) за указанный период времени. Кстати, удобный отчёт, который позволяет подредактировать триггеры, которые слишком часто срабатывают.

Из тех обновлений, что точно будут в 7.0, отмечу:
◽увеличится поддержка версий до MySQL 8.1 MariaDB 11
◽появится шаблон для мониторинга за PostgreSQL через ODBC
◽появится шаблон для Cisco SD-WAN
◽появится возможность выполнения удалённых команд при активных проверках
◽некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
◽увеличат возможности обработки в aggregation functions

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

#zabbix

​​Много раз в заметках упоминал про сервис по рисованию различных схем draw.io. Судя по отзывам, большая часть использует именно его в своей работе. Схемы из draw.io относительно легко можно наложить на мониторинг на базе Grafana. Если вы с ней работаете, то особых проблем не должно возникнуть. Если нет, то не скажу, что настройка будет простой. Но в целом, ничего особенного. Мне когда надо было, освоил Grafana за пару дней для простого мониторинга.

Речь пойдёт про плагин к Графане — flowcharting. Он есть в официальном списке плагинов на сайте, так что с его установкой вопросов не должно возникнуть. Сразу скажу, что с помощью этого плагина можно нарисовать схему и связать через через Графану его с мониторингом на Zabbix.

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

1️⃣ Вы берёте схему в draw.io и выгружаете её в xml формате.
2️⃣ Создаёте dashboard в Grafana и добавляете туда панель flowcharting.
3️⃣ Загружаете xml код схемы в эту панель и получаете визуализацию.
4️⃣ Сопоставляете объекты на схеме с объектами в Графане, сразу переименовывая их так, чтобы было удобно.
5️⃣ Дальше к объектам можно добавлять метрики, как это обычно делается в Grafana. Соответственно, в качестве Data Source можно использовать тот же Zabbix.

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

⇨ Страница плагина в Grafana
⇨ Инструкция по настройке
▶️ Плейлист Flowcharting Grafana (29 видео)

Все видео в плейлисте на португальском языке. Можно включить перевод субтитров на русский. В целом, там важно смотреть, как и что он делает. А что говорит, не так важно. В плейлисте полностью раскрыта тема построения мониторинга с помощью этого плагина. В том числе и в связке с Zabbix (26-й ролик).

Плагин давно не обновлялся. Я не уверен, что он нормально заработает на свежих версиях, хотя, по идее должен. Я до сих пор пользуюсь 7-й версией. И там он работает.

#мониторинг #zabbix #grafana

​​После публикации про мониторинг Newrelic, где можно наблюдать за каждым процессом в системе в отдельности, решил прикинуть, а как подобное реализовать в Zabbix. Итоговое решение по всем метрикам пока не созрело, но контроль использования памяти уже реализовал. Решил поделиться своими наработками. Может кто-то подскажет другие пути решения задачи.

Прикинул, как снимать метрики. Тут особо не пришлось ломать голову, так как сразу родилась идея с утилитами jc и jq, которые я давно знаю. Взял вывод ps, обернул его в json с помощью jc, отсортировал по метрике rss и вывел top 10:

# ps axu | jc --ps -p | jq 'sort_by(.rss)' | jq .[-10:]
..................................
]
 {
  "user": "servera+",
  "pid": 1584266,
  "vsz": 348632,
  "rss": 109488,
  "tty": null,
  "stat": "S",
  "start": "19:41",
  "time": "0:28",
  "command": "php-fpm: pool serveradmin.ru",
  "cpu_percent": 0.5,
  "mem_percent": 2.7
 },
 {
  "user": "mysql",
  "pid": 853,
  "vsz": 2400700,
  "rss": 782060,
  "tty": null,
  "stat": "Ssl",
  "start": "Aug28",
  "time": "365:40",
  "command": "/usr/sbin/mariadbd",
  "cpu_percent": 1.8,
  "mem_percent": 19.4
 }
]
..........................................

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

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

[{"{#COMMAND}":"php-fpm7.4"},{"{#COMMAND}":"mariadbd"}.........,{"{#COMMAND}":"smtpd"}]

Такую строку он сможет взять, на основе переданных значений {#COMMAND} создать айтемы. Как мою json от ps приспособить под эти задачи, я не знал. Для этого можно было бы сделать обработку на javascript прямо в айтеме, но мне показалось это слишком сложным для меня путём. Решил всё сделать по старинке на bash.

Взял вот такую конструкцию, которая анализирует вывод ps, формирует удобный список, который можно отсортировать с помощью sort и взять top 10 самых нагруженных по памяти процессов и в итоге вывести только их имена:

# ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'

Далее обернул её в скрипт для формирования json для автообнаружения в Zabbix.

top_mem.discovery.sh:

#!/bin/bash

TOPPROC=`ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{print $2}'`

JSON=$(for i in ${TOPPROC[@]}; do printf "{\"{#COMMAND}\":\"$i\"},"; done | sed 's/^\(.*\).$/\1/')
printf "["
printf "$JSON"
printf "]"

На выходе получаем то, что нам надо:

[{"{#COMMAND}":"php-fpm7.4"},........{"{#COMMAND}":"smtpd"}]

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

top_mem.sh:

#!/bin/bash

ps axo rss,comm | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | grep $1 | awk '{print $1}'

Проверяем:
# ./top_mem.sh mariadbd
780840

Добавляем в конфиг zabbix-agent:
UserParameter=top.mem.discovery, /bin/bash /etc/zabbix/scripts/top_mem.discovery.sh
UserParameter=top.mem[*], /bin/bash /etc/zabbix/scripts/top_mem.sh $1

Теперь идём на сервер, создаём шаблон, правило автообнаружения, прототип айтема, графика и сразу делаем панель.

Получилось удобно и функционально. Все нюансы не смог описать, так как лимит на длину поста. Нерешённый момент - особенности реализации LLD не позволяют автоматом закидывать все процессы на один график. Без API не знаю, как это сделать. Текущее решение придумал и опробовал за пару часов.

#zabbix

​​Провёл аудит своих систем мониторинга Zabbix в связке с Grafana. У меня работают версии LTS 5.0 и 6.0. Промежуточные обычно только для теста ставлю где-то в одном месте. Разбирался в первую очередь с базовым шаблоном для Linux серверов.

У Zabbix есть особенность, что обновление сервера не касается самих шаблонов, а они тоже регулярно обновляются. У этого есть как плюсы, так и минусы. Плюс в том, что всё стабильно и никаких непредвиденных обновлений не будет. Если вы вносили правки в шаблон, они останутся и всё будет работать как раньше с новым сервером. А минус в том, что эти обновления надо проводить вручную.

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

Для серверов 6-й версии взял за основу шаблон Linux by Zabbix agent, не забыв указать ветку репозитория 6.0. Методика обновления может быть разной. Безопаснее всего текущий установленный шаблон переименовать, добавив, к примеру, к названию приписку OLD. Потом импортировать новый и вручную накидывать его на хосты, заменяя старый шаблон. Это немного муторно, так как ручной труд.

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

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

Единообразие шаблонов для Linux позволило сделать единый для всех серверов дашборд в Grafana, куда я вынес наиболее актуальные на мой взгляд метрики, чтобы можно было быстро оценить состояние хоста. Пример, как это выглядит, на картинке. Сам дашборд выложил на сайт, можно скачать. В шаблоне можно выбрать Datasource и конкретный хост. То есть с его помощью можно смотреть все подключенные хосты с такой же версией шаблона Linux. Это намного быстрее и удобнее, чем делать то же самое в самом Zabbix. По настройке Grafana с Zabbix у меня есть отдельная статья.

Ну и в завершении напомню, что обновление шаблонов приносит очень много мелких хлопот на местах, так как опять потребуется калибровка под конкретные хосты. Где-то не нужны какие-то триггеры, например на swap, на отсутствие свободной оперативы, где её и не должно быть, на скорость отклика дисков, потому что они медленные и т.д. Приходится макросы поправлять, триггеры отключать, какие-то изменения в шаблоны и хосты добавлять с зависимостями. Все tun интерфейсы почему-то определяются со скоростью 10 Мегабит в секунду, что приводит к срабатыванию триггеров на загрузку интерфейса. Пока не понял, как это решить, не отключая триггеры.

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

#zabbix #grafana

​​В процессе актуализации мониторинга обновил также и Grafana до последней 10-й версии. Расскажу, как это делаю я. Это не руководство к действию для вас, а только мой персональный опыт, основанный на том, что у меня немного дашбордов и Data sources.

Всю ценность в Grafana у меня представляют только настройки источников данных и несколько дашбордов, поэтому прорабатывать перенос данных или бэкап нет никакого смысла. Если что-то меняется, то я просто выгружаю json и сохраняю новую версию. А так как это происходит нечасто, меня такая схема устраивает.

Соответственно и обновление у меня выглядит максимально просто и быстро:
1️⃣ Выгружаю Data sources и Dashboards в json.
2️⃣ Обновляю Docker образ grafana:latest и запускаю новый контейнер с ним.
3️⃣ Переключаю на Nginx Proxy трафик на новый контейнер.
4️⃣ Захожу в него и импортирую свои данные.

Если что-то забыл, то заглядываю в старый контейнер, который остаётся некоторое время. Как это всё реализуется технически, описано в моей старой статье:

⇨ Обновление Grafana

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

Предвещая вопросы, отвечу, что Grafana использую исключительно для более удобной и простой визуализации данных с Zabbix Server. А также для объединения на одном дашборде информации с разных серверов. Это актуально для триггеров. У меня есть обзорный дашборд с активными триггерами со всех своих серверов. Ну и дополнительно есть несколько дашбордов с другой необходимой мне информации. Один из таких дашбордов с обзорной информацией о сервере я показал в утренней заметке.

Ниже картинка с обзором триггеров.

#grafana #zabbix