Когда возникает задача по контролю устройств в локальной сети, я сходу не могу придумать решение. Начинаю вспоминать, что в каких-то системах мониторинга с автообнаружением есть уведомления о появлении новых устройств, либо в некотором софте для инвентаризации и базе данных оборудования. А вот что-то отдельное под эту задачу мне было неизвестно до тех пор, пока не узнал про Pi.Alert.
Это небольшое приложение, которое выполняет одну конкретную задачу — периодически сканирует локальную сеть и оповещает тебя, если появляется новое устройство, которого нет в его базе данных. Управление в Pi.Alert осуществляется через веб интерфейс. Соответственно в нём же вы ведёте базу данных всех своих устройств, которые видны в сети.
Для обнаружения устройств используются три метода в зависимости от настроек программы:
1️⃣ По умолчанию используется утилита arp-scan для arp запросов.
2️⃣ Pi.Alert в своём составе имеет известный DNS сервер Pi-hole. Если он используется, то в дополнении к методу 1, проверяется активность на DNS сервере Pi-hole. Там ведётся лог запросов.
3️⃣ Если у вас используется в качестве DHCP сервера dnsmasq, то информация о новых устройствах берётся в том числе и в его leases.
Из особенностей и удобств Pi.Alert отмечу, то у него есть отдельный раздел с календарём, где можно посмотреть видимость различный устройств с привязкой к дням. Выглядит это удобно. Ну и добавлю, что есть лог по каждому устройству.
По названию программы и интеграции с Pi-hole становится понятно, что его можно установить на Raspberry Pi. Именно для этого устройства есть готовый скрипт для установки (есть в репозитории), который актуален и для Debian. На любом другом Linux Pi.Alert можно запустить в Docker. Есть готовый образ с хорошим описанием возможностей и параметров запуска, так что не буду дублировать тут эту информацию.
Уже в процессе тестирования я понял, что Docker образ от другого автора, который взял за основу оригинальный Pi.Alert и очень сильно его доработал, существенно расширив функциональность. Там и интеграция с nmap, с home assistent, API, проверки по snmp, построение карты сети, более расширенная база данных устройств. И вообще много всего полезного. Посмотрите сами в другом репозитории. Получилась полноценная система учёта и контроля устройств в сети.
Так что если вам нужен простой контроль устройств, используйте Pi.Alert от автора (pucherot). Там минимум настроек, которые задаются в процессе установки. Потом даже раздела настроек нет в веб интерфейсе. Если же вам надо расширенный функционал, берите версию от jokob-sk. Я и ту, и другую попробовал. Последняя вообще крутотень. Мне очень понравилась и по возможностям, и по внешнему виду. Там даже мониторинг сайтов есть. По сути это больше похоже на систему мониторинга с простыми сетевыми проверками. Имеет смысл добавить её в подборку с системами мониторинга. Очень просто и быстро запустить и настроить.
#network #мониторинг
Это небольшое приложение, которое выполняет одну конкретную задачу — периодически сканирует локальную сеть и оповещает тебя, если появляется новое устройство, которого нет в его базе данных. Управление в Pi.Alert осуществляется через веб интерфейс. Соответственно в нём же вы ведёте базу данных всех своих устройств, которые видны в сети.
Для обнаружения устройств используются три метода в зависимости от настроек программы:
1️⃣ По умолчанию используется утилита arp-scan для arp запросов.
2️⃣ Pi.Alert в своём составе имеет известный DNS сервер Pi-hole. Если он используется, то в дополнении к методу 1, проверяется активность на DNS сервере Pi-hole. Там ведётся лог запросов.
3️⃣ Если у вас используется в качестве DHCP сервера dnsmasq, то информация о новых устройствах берётся в том числе и в его leases.
Из особенностей и удобств Pi.Alert отмечу, то у него есть отдельный раздел с календарём, где можно посмотреть видимость различный устройств с привязкой к дням. Выглядит это удобно. Ну и добавлю, что есть лог по каждому устройству.
По названию программы и интеграции с Pi-hole становится понятно, что его можно установить на Raspberry Pi. Именно для этого устройства есть готовый скрипт для установки (есть в репозитории), который актуален и для Debian. На любом другом Linux Pi.Alert можно запустить в Docker. Есть готовый образ с хорошим описанием возможностей и параметров запуска, так что не буду дублировать тут эту информацию.
Уже в процессе тестирования я понял, что Docker образ от другого автора, который взял за основу оригинальный Pi.Alert и очень сильно его доработал, существенно расширив функциональность. Там и интеграция с nmap, с home assistent, API, проверки по snmp, построение карты сети, более расширенная база данных устройств. И вообще много всего полезного. Посмотрите сами в другом репозитории. Получилась полноценная система учёта и контроля устройств в сети.
Так что если вам нужен простой контроль устройств, используйте Pi.Alert от автора (pucherot). Там минимум настроек, которые задаются в процессе установки. Потом даже раздела настроек нет в веб интерфейсе. Если же вам надо расширенный функционал, берите версию от jokob-sk. Я и ту, и другую попробовал. Последняя вообще крутотень. Мне очень понравилась и по возможностям, и по внешнему виду. Там даже мониторинг сайтов есть. По сути это больше похоже на систему мониторинга с простыми сетевыми проверками. Имеет смысл добавить её в подборку с системами мониторинга. Очень просто и быстро запустить и настроить.
#network #мониторинг
Напомню тем, кто не знает. У Grafana есть облачный сервис по мониторингу и сбору логов с бесплатным тарифным планом. Называется, как нетрудно догадаться - Grafana Cloud. Для регистрации не надо ничего, кроме адреса почты. Есть бесплатный тарифный план с комфортными ограничениями: 50 GB логов в месяц, 10k метрик.
Это отличный способ оценить все возможности системы. Например, хотите посмотреть, как работает мониторинг Linux хоста. Идёте в раздел Connections, добавляете новое соединение типа Linux Server. Открывается готовая инструкция по добавлению хоста:
1️⃣ Устанавливаете Grafana Agent: выбираете тип системы и архитектуру, создаёте API токен, копируете команду для установки агента с интегрированным токеном, запускаете её на хосте. Дожидаетесь установки, проверяете соединение.
2️⃣ Настраиваете интеграцию с облаком — добавляете в конфигурацию агента информацию по сбору метрик и логов. Всё, что необходимо добавить, копируете в готовом виде. Перезапускаете агента на хосте.
3️⃣ Устанавливаете необходимые дашборды. Достаточно жмакнуть на кнопку Install. Всё само установится.
4️⃣ Идёте в раздел Dashboards и смотрите необходимые панели, выбирая в выпадающем списке добавленный хост.
5️⃣ Для просмотра логов (он автоматом все подтягивает из journald и /var/log) идёте в раздел Explore, выбираете в выпадающем списке источник данных с окончанием -log и смотрите логи. Можно как текстовые логи из файлов смотреть, так и systemd с разбивкой на сервисы, уровни важности и т.д.
Таким образом в полуавтоматическом режиме можно добавить все поддерживаемые системы и сервисы: Docker, Nginx, MySQL, Redis, Ceph и т.д. Список огромный.
Grafana - это давно уже не только графики и дашборды, но и полноценная система мониторинга и сбора логов. И всё это в одном месте. Выглядит очень круто и удобно. Если честно, мне всё труднее и труднее объяснить кому-нибудь зачем ему Zabbix. Глядя на Графану, понимаешь, каким простым, красивым и удобным может быть мониторинг. Zabbix удерживает только безграничными возможностями привычного велосипедостроения. Если мониторить что-то типовое, то он давно уже не лучший вариант.
#мониторинг #grafana
Это отличный способ оценить все возможности системы. Например, хотите посмотреть, как работает мониторинг Linux хоста. Идёте в раздел Connections, добавляете новое соединение типа Linux Server. Открывается готовая инструкция по добавлению хоста:
1️⃣ Устанавливаете Grafana Agent: выбираете тип системы и архитектуру, создаёте API токен, копируете команду для установки агента с интегрированным токеном, запускаете её на хосте. Дожидаетесь установки, проверяете соединение.
2️⃣ Настраиваете интеграцию с облаком — добавляете в конфигурацию агента информацию по сбору метрик и логов. Всё, что необходимо добавить, копируете в готовом виде. Перезапускаете агента на хосте.
3️⃣ Устанавливаете необходимые дашборды. Достаточно жмакнуть на кнопку Install. Всё само установится.
4️⃣ Идёте в раздел Dashboards и смотрите необходимые панели, выбирая в выпадающем списке добавленный хост.
5️⃣ Для просмотра логов (он автоматом все подтягивает из journald и /var/log) идёте в раздел Explore, выбираете в выпадающем списке источник данных с окончанием -log и смотрите логи. Можно как текстовые логи из файлов смотреть, так и systemd с разбивкой на сервисы, уровни важности и т.д.
Таким образом в полуавтоматическом режиме можно добавить все поддерживаемые системы и сервисы: Docker, Nginx, MySQL, Redis, Ceph и т.д. Список огромный.
Grafana - это давно уже не только графики и дашборды, но и полноценная система мониторинга и сбора логов. И всё это в одном месте. Выглядит очень круто и удобно. Если честно, мне всё труднее и труднее объяснить кому-нибудь зачем ему Zabbix. Глядя на Графану, понимаешь, каким простым, красивым и удобным может быть мониторинг. Zabbix удерживает только безграничными возможностями привычного велосипедостроения. Если мониторить что-то типовое, то он давно уже не лучший вариант.
#мониторинг #grafana
На днях у известного мониторинга Netdata вышло крупное обновление. Я когда-то давно писал о нём, но с тех пор этот мониторинг сильно продвинулся вперёд. Вообще, это хороший продукт. Я бы даже сказал, что лучший для мониторинга одиночного сервера. А вот чтобы мониторить множество серверов, нужно регистрироваться у них в облаке и подключать их туда. В текущих условиях я бы не стал это делать, хотя всё работает нормально, я проверял. Есть бесплатный тарифный план.
Из основных нововведений отмечу парочку самых значимых:
◽Появился Marketplace интеграций, где их уже более 800.
◽Добавили удобный обзор логов systemd journal.
Посмотреть на этот мониторинг можно через публичный Demo:
⇨ https://app.netdata.cloud/spaces/netdata-demo
Покажу на примере, как быстро и легко установить Netdata на одиночный сервер. Устанавливаем на любой Linux:
Установка будет из deb/rpm пакетов, если они есть под вашу систему. Если нет, будут использованы static builds или сборка из исходников.
После установки можно сразу идти браузером на ip сервера и порт 19999. По умолчанию аутентификации нет. Сразу же увидите базовые метрики. Можно оценить, как это выглядит и работает.
Допустим, у вас на этом сервере работает Nginx и мы хотим его мониторить. Идём в раздел Integration и ищем Nginx. Видим подробную инструкцию. Нам надо включить вывод статистики Nginx через модуль ngx_http_stub_status_module. Для этого добавляем в конфиг Nginx виртуального хоста default:
Перечитываем конфигурацию:
Настраиваем Netdata:
Можно ничего не редактировать, а сохранить конфиг как есть. Перезапускаем Netdata:
Идём в веб интерфейс, открываем хост local, справа в столбце Overview выбираем раздел Nginx и смотрим доступные метрики.
Подобным образом настраиваются все поддерживаемые интеграции, а их там очень много. Это реально просто, удобно, быстро, красиво. В общем, мониторинг хорош, рекомендую попробовать👍.
Поддержка Windows тоже есть. Работает она следующим образом. На Windows ставится Prometheus exporter for Windows. На любом Linux хосте с установленным Netdata настраиваем:
Добавляем в самый конец:
Указанный url это метрики экспортера. После установки он автоматически запускается, можно проверить браузером, только не забудьте файрвол настроить. Далее создаём файл
guid смотрим на Windows в консоли poershell:
Перезапускаем netdata и видим в веб интерфейсе новый Windows сервер в разделе Nodes. Получилась краткая инструкция по настройке Netdata. Можно сохранить.
⇨ Сайт / Исходники / Обзор / Demo
#мониторинг #netdata
Из основных нововведений отмечу парочку самых значимых:
◽Появился Marketplace интеграций, где их уже более 800.
◽Добавили удобный обзор логов systemd journal.
Посмотреть на этот мониторинг можно через публичный Demo:
⇨ https://app.netdata.cloud/spaces/netdata-demo
Покажу на примере, как быстро и легко установить Netdata на одиночный сервер. Устанавливаем на любой Linux:
# curl https://my-netdata.io/kickstart.sh > /tmp/netdata-kickstart.sh # sh /tmp/netdata-kickstart.shУстановка будет из deb/rpm пакетов, если они есть под вашу систему. Если нет, будут использованы static builds или сборка из исходников.
После установки можно сразу идти браузером на ip сервера и порт 19999. По умолчанию аутентификации нет. Сразу же увидите базовые метрики. Можно оценить, как это выглядит и работает.
Допустим, у вас на этом сервере работает Nginx и мы хотим его мониторить. Идём в раздел Integration и ищем Nginx. Видим подробную инструкцию. Нам надо включить вывод статистики Nginx через модуль ngx_http_stub_status_module. Для этого добавляем в конфиг Nginx виртуального хоста default:
location = /basic_status { stub_status;}Перечитываем конфигурацию:
# nginx -s reloadНастраиваем Netdata:
# cd /etc/netdata && ./edit-config go.d/nginx.confМожно ничего не редактировать, а сохранить конфиг как есть. Перезапускаем Netdata:
# systemctl restart netdataИдём в веб интерфейс, открываем хост local, справа в столбце Overview выбираем раздел Nginx и смотрим доступные метрики.
Подобным образом настраиваются все поддерживаемые интеграции, а их там очень много. Это реально просто, удобно, быстро, красиво. В общем, мониторинг хорош, рекомендую попробовать👍.
Поддержка Windows тоже есть. Работает она следующим образом. На Windows ставится Prometheus exporter for Windows. На любом Linux хосте с установленным Netdata настраиваем:
# cd /etc/netdata && ./edit-config go.d/windows.confДобавляем в самый конец:
jobs: - name: win_server1 vnode: win_server1 url: http://172.27.49.225:9182/metricsУказанный url это метрики экспортера. После установки он автоматически запускается, можно проверить браузером, только не забудьте файрвол настроить. Далее создаём файл
/etc/netdata/vnodes/vnodes.conf- hostname: win_server1 guid: fda4c985-1ce4-4e74-aaec-93a5365bac36guid смотрим на Windows в консоли poershell:
> [guid]::NewGuid() Перезапускаем netdata и видим в веб интерфейсе новый Windows сервер в разделе Nodes. Получилась краткая инструкция по настройке Netdata. Можно сохранить.
⇨ Сайт / Исходники / Обзор / Demo
#мониторинг #netdata
Я вчера рассказал, как собрать Nginx с модулем статистики vts. Расскажу теперь, как его настроить и собрать метрики в систему мониторинга Prometheus.
Для настройки статистики вам достаточно добавить в основной файл конфигурации
И в любой виртуальных хост ещё один location. Я обычно в default добавляю:
Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.
Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
Идём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.
Теперь ставим Grafana, можно на этот же хост с Prometheus:
Идём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.
Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.
Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.
На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.
#nginx #мониторинг #prometheus #grafana
Для настройки статистики вам достаточно добавить в основной файл конфигурации
nginx.conf в секцию http:vhost_traffic_status_zone;И в любой виртуальных хост ещё один location. Я обычно в default добавляю:
server { listen 80; server_name localhost;.........................location /status { vhost_traffic_status_display; vhost_traffic_status_display_format html;}..................Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.
Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
# mkdir prom_data && cd prom_data && touch prometheus.yamlglobal: scrape_interval: 5s evaluation_interval: 5srule_files:scrape_configs: - job_name: prometheus static_configs: - targets: ['localhost:9090'] - job_name: nginx_vts metrics_path: '/status/format/prometheus' static_configs: - targets: ['10.20.1.56:80']Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
# docker run -p 9090:9090 -d --name=prom \-v ~/prom_data/prometheus.yaml:/etc/prometheus/prometheus.yml \ prom/prometheusИдём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.
Теперь ставим Grafana, можно на этот же хост с Prometheus:
# docker run -p 3000:3000 -d --name=grafana grafana/grafanaИдём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.
Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.
Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.
На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.
#nginx #мониторинг #prometheus #grafana
Много раз в заметках упоминал про сервис по рисованию различных схем 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
Речь пойдёт про плагин к Графане — 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
Хочу предложить вашему вниманию bash скрипт по проверке статуса работы Nginx. Обращаю внимание именно на него, потому что он классно написан и его можно взять за основу для любой похожей задачи. Сейчас подробно расскажу, что там происходит.
Для начала отмечу, что этот скрипт check_nginx_running.sh из репозитория Linux scripts. Его ведёт автор сайта https://blog.programs74.ru. Я с ним не знаком, но часто пользовался его материалами и скриптами. Всё классно написано и рассказано. Так что рекомендую.
Что делает этот скрипт:
1. Проверяет, запущен ли он под root.
2. Проверяет существование master и worker процессов nginx.
3. Проверяет занимаемую ими оперативную память.
4. Записывает все свои действия в текстовый файл.
5. Перезапускает службу, если она не запущена.
6. Перед перезапуском проверяет конфигурацию на отсутствие ошибок.
Возможность логирования и перезапуска включается или отключается по желанию.
Этот скрипт легко адаптировать под мониторинг любых других процессов Linux. Какие-то проверки можно убрать, логику упростить. Пример с Nginx как раз удобен, так как тут и 2 разных процесса, и проверка конфигурации. Сразу сложный пример разобран.
Если у вас есть какая-то система мониторинга, и она не умеет мониторить процессы Linux, можно использовать подобный скрипт. Проще всего настроить анализ лог файла и выдавать оповещения в зависимости от его содержимого. Не придётся особо ломать голову, как реализовать. Уже всё реализовано.
Например, в Zabbix из коробки для мониторинга служб есть ключи proc.num и proc.mem, которые считают количество запущенных процессов с заданным именем и используемую память. Это всё, что есть встроенного по части процессов. Если нужна какая-то реакция, например, запуск упавшего процесса, то нужно всё равно писать bash скрипт для этого, который будет запускаться триггером.
Соответственно, у вас есть 2 пути по настройке контроля за процессом: использовать скрипт типа этого про крону и в мониторинге наблюдать за ним, либо следить за состоянием процесса через мониторинг и отдельным скриптом совершать какие-то действия. Что удобнее, решать по месту в зависимости от используемой архитектуры инфраструктуры. Позволять через Zabbix запускать скрипты на удалённых машинах не всегда удобно и безопасно. У локального скрипта в cron тоже есть свои минусы. Решать надо по ситуации.
#script #bash #мониторинг
Для начала отмечу, что этот скрипт check_nginx_running.sh из репозитория Linux scripts. Его ведёт автор сайта https://blog.programs74.ru. Я с ним не знаком, но часто пользовался его материалами и скриптами. Всё классно написано и рассказано. Так что рекомендую.
Что делает этот скрипт:
1. Проверяет, запущен ли он под root.
2. Проверяет существование master и worker процессов nginx.
3. Проверяет занимаемую ими оперативную память.
4. Записывает все свои действия в текстовый файл.
5. Перезапускает службу, если она не запущена.
6. Перед перезапуском проверяет конфигурацию на отсутствие ошибок.
Возможность логирования и перезапуска включается или отключается по желанию.
Этот скрипт легко адаптировать под мониторинг любых других процессов Linux. Какие-то проверки можно убрать, логику упростить. Пример с Nginx как раз удобен, так как тут и 2 разных процесса, и проверка конфигурации. Сразу сложный пример разобран.
Если у вас есть какая-то система мониторинга, и она не умеет мониторить процессы Linux, можно использовать подобный скрипт. Проще всего настроить анализ лог файла и выдавать оповещения в зависимости от его содержимого. Не придётся особо ломать голову, как реализовать. Уже всё реализовано.
Например, в Zabbix из коробки для мониторинга служб есть ключи proc.num и proc.mem, которые считают количество запущенных процессов с заданным именем и используемую память. Это всё, что есть встроенного по части процессов. Если нужна какая-то реакция, например, запуск упавшего процесса, то нужно всё равно писать bash скрипт для этого, который будет запускаться триггером.
Соответственно, у вас есть 2 пути по настройке контроля за процессом: использовать скрипт типа этого про крону и в мониторинге наблюдать за ним, либо следить за состоянием процесса через мониторинг и отдельным скриптом совершать какие-то действия. Что удобнее, решать по месту в зависимости от используемой архитектуры инфраструктуры. Позволять через Zabbix запускать скрипты на удалённых машинах не всегда удобно и безопасно. У локального скрипта в cron тоже есть свои минусы. Решать надо по ситуации.
#script #bash #мониторинг
На днях поднимал вопрос сбора логов веб сервера и забыл упомянуть одну систему, которую я знаю уже очень давно. Пользуюсь лет 8. Речь пойдёт про New Relic. Это очень мощная SaaS платформа по мониторингу и аналитике веб приложений и всего, что с ними связано, в том числе серверов. Я не раз уже писал о нём, но можно и ещё раз напомнить.
Сервис постоянно развивается и меняется. Когда я начинал им пользоваться для базового мониторинга серверов, там был бесплатный тарифный план на 10 хостов. В какой-то момент они бесплатный тарифный план совсем убрали, потом вернули в другом виде.
В итоге сейчас есть бесплатный тарифный план без необходимости привязки карты. Просто регистрируетесь на email. Вам даётся 100 ГБ для хранения всех данных с любых сервисов системы. А их там море, они все разные. Это очень удобно и просто для контроля. Хотите мониторить сервера - подключайте хосты, настраивайте метрики. Хотите логи - грузите их. Используется то же доступное пространство.
Вообще говоря, это лучший мониторинг, что мне известен. Нигде я не видел такой простоты, удобства и массы возможностей. Если покупать за деньги, то стоит очень дорого. Отмечу сразу, что вообще он больше заточен под высокоуровневый мониторинг приложений, но и всё остальное в виде мониторинга серверов, сбора логов сделано удобно.
Работа с New Relic по мониторингу сервера и сбора логов выглядит следующим образом. Регистрируетесь в личном кабинете, получаете ключ. Во время установки агента используете этот ключ. Сервер автоматом привязывается к личному кабинету. Дальше за ним наблюдаете оттуда. В настройках агента можно включить сбор логов. Какие - выбираете сами. Можно systemd логи туда отправить, или какие-то отдельные файлы. К примеру, логи Nginx. Если предварительно перевести их в формат json, то потом очень легко настраивать визуализацию в личном кабинете.
Понятное дело, что у такого подхода есть свои риски. Агент newrelic имеет полный доступ к системе. А уж к бесплатному тарифному плану привязываться и подавно опасно. Используйте по месту в каких-то одиночных серверах или временно для дебага.
Мониторинг сервера позволяет посмотреть статистику по CPU, I/O, Memory в разрезе отдельных процессов. Это очень удобно и нигде больше не видел такой возможности.
#мониторинг #logs
Сервис постоянно развивается и меняется. Когда я начинал им пользоваться для базового мониторинга серверов, там был бесплатный тарифный план на 10 хостов. В какой-то момент они бесплатный тарифный план совсем убрали, потом вернули в другом виде.
В итоге сейчас есть бесплатный тарифный план без необходимости привязки карты. Просто регистрируетесь на email. Вам даётся 100 ГБ для хранения всех данных с любых сервисов системы. А их там море, они все разные. Это очень удобно и просто для контроля. Хотите мониторить сервера - подключайте хосты, настраивайте метрики. Хотите логи - грузите их. Используется то же доступное пространство.
Вообще говоря, это лучший мониторинг, что мне известен. Нигде я не видел такой простоты, удобства и массы возможностей. Если покупать за деньги, то стоит очень дорого. Отмечу сразу, что вообще он больше заточен под высокоуровневый мониторинг приложений, но и всё остальное в виде мониторинга серверов, сбора логов сделано удобно.
Работа с New Relic по мониторингу сервера и сбора логов выглядит следующим образом. Регистрируетесь в личном кабинете, получаете ключ. Во время установки агента используете этот ключ. Сервер автоматом привязывается к личному кабинету. Дальше за ним наблюдаете оттуда. В настройках агента можно включить сбор логов. Какие - выбираете сами. Можно systemd логи туда отправить, или какие-то отдельные файлы. К примеру, логи Nginx. Если предварительно перевести их в формат json, то потом очень легко настраивать визуализацию в личном кабинете.
Понятное дело, что у такого подхода есть свои риски. Агент newrelic имеет полный доступ к системе. А уж к бесплатному тарифному плану привязываться и подавно опасно. Используйте по месту в каких-то одиночных серверах или временно для дебага.
Мониторинг сервера позволяет посмотреть статистику по CPU, I/O, Memory в разрезе отдельных процессов. Это очень удобно и нигде больше не видел такой возможности.
#мониторинг #logs
Мой первый настроенный мониторинг в роли системного администратора Linux был на базе rrd графиков, которые рисовались с помощью rrdtool и скриптов, которые забирали информацию с сенсоров и записывали в rrd базу. Было это ещё на Freebsd примерно в 2007-2008 году. Потом переехал на Zabbix версии 1.6 или 1.8, не помню точно.
Сейчас rrd графики выглядят старомодно, хотя лично мне их стилистика нравится. Я к чему обо всём этом. Есть неплохой и вполне современный мониторинг LPAR2RRD, у которого все графики rrd. Это старый open source продукт, который монетизируется платной поддержкой этого и ещё одного своего продукта - STOR2RRD.
Отличает lpar2rrd простота установки и настройки. У него есть как свой агент, так и интеграция с популярными программными продуктами. Например, он умеет через API мониторить Proxmox. Просто делаете для lpar2rrd учётку с доступом на чтение к API и он автоматом забирает все необходимые метрики с определённой периодичностью. Другой пример интеграции - PostgreSQL. Тут то же самое. Делаете учётку с доступом на чтение, lpar2rrd забирает всю информацию вплоть до отдельной базы и рисует мониторинг.
Причём поддерживает lpar2rrd всех крупных современных вендоров, коммерческие и open source продукты, облачных провайдеров:
◽IBM Power Systems, VMware, Oracle Solaris, RHV, oVirt, XenServer, Citrix, Hyper-V
◽PostgreSQL, MSSQL, Oracle Database
◽Docker, Kubernetes, OpenShift
◽AWS, Google Cloud, Azure
Ну и обычные агенты под ОС Linux. Выше список не полный. Поддержка Windows тоже есть, но специфичная. Ставится агент на какую-то одну ОС, и он по WMI опрашивает все необходимые машины.
Посмотреть, как всё это выглядит, можно в публичном Demo, где очень удобно представлены все наиболее популярные системы. Можно увидеть в каком виде все метрики будут организованы в мониторинге. Если кто не знает, то временные интервалы задаются мышкой прям на самом графике. Сразу добавлю, что rrd ещё удобен тем, что из него легко картинки графиков автоматом забирать.
Мониторинг, конечно, выглядит простовато по сегодняшним меркам. Пригодится он может в основном тем, кому нужно что-то простое и обзорное, чтобы поставил и не морочился с настройкой и внедрением. И на этот вопрос он реально отвечает. Дал доступ к кластеру Proxmox и получил автоматом мониторинг вплоть до загрузки сетевого интерфейса отдельного lxc контейнера. А так как всё хранится в локальной rrd базе, ему даже полноценная СУБД не нужна.
Можно как дублирующий внешний контур для основного мониторинга использовать. Когда он ляжет, чтобы хоть примерно понимать, как у тебя обстановка.
⇨ Сайт / Demo / Установка
#мониторинг
Сейчас rrd графики выглядят старомодно, хотя лично мне их стилистика нравится. Я к чему обо всём этом. Есть неплохой и вполне современный мониторинг LPAR2RRD, у которого все графики rrd. Это старый open source продукт, который монетизируется платной поддержкой этого и ещё одного своего продукта - STOR2RRD.
Отличает lpar2rrd простота установки и настройки. У него есть как свой агент, так и интеграция с популярными программными продуктами. Например, он умеет через API мониторить Proxmox. Просто делаете для lpar2rrd учётку с доступом на чтение к API и он автоматом забирает все необходимые метрики с определённой периодичностью. Другой пример интеграции - PostgreSQL. Тут то же самое. Делаете учётку с доступом на чтение, lpar2rrd забирает всю информацию вплоть до отдельной базы и рисует мониторинг.
Причём поддерживает lpar2rrd всех крупных современных вендоров, коммерческие и open source продукты, облачных провайдеров:
◽IBM Power Systems, VMware, Oracle Solaris, RHV, oVirt, XenServer, Citrix, Hyper-V
◽PostgreSQL, MSSQL, Oracle Database
◽Docker, Kubernetes, OpenShift
◽AWS, Google Cloud, Azure
Ну и обычные агенты под ОС Linux. Выше список не полный. Поддержка Windows тоже есть, но специфичная. Ставится агент на какую-то одну ОС, и он по WMI опрашивает все необходимые машины.
Посмотреть, как всё это выглядит, можно в публичном Demo, где очень удобно представлены все наиболее популярные системы. Можно увидеть в каком виде все метрики будут организованы в мониторинге. Если кто не знает, то временные интервалы задаются мышкой прям на самом графике. Сразу добавлю, что rrd ещё удобен тем, что из него легко картинки графиков автоматом забирать.
Мониторинг, конечно, выглядит простовато по сегодняшним меркам. Пригодится он может в основном тем, кому нужно что-то простое и обзорное, чтобы поставил и не морочился с настройкой и внедрением. И на этот вопрос он реально отвечает. Дал доступ к кластеру Proxmox и получил автоматом мониторинг вплоть до загрузки сетевого интерфейса отдельного lxc контейнера. А так как всё хранится в локальной rrd базе, ему даже полноценная СУБД не нужна.
Можно как дублирующий внешний контур для основного мониторинга использовать. Когда он ляжет, чтобы хоть примерно понимать, как у тебя обстановка.
⇨ Сайт / Demo / Установка
#мониторинг
У меня написаны заметки по всем более ли менее популярным бесплатным системам мониторинга. И только одну очень старую систему я всегда обходил стороной, за что неоднократно получал комментарии на эту тему. Надо это исправить и дополнить мою статью с обзором систем мониторинга (20 штук).
Речь пойдёт про старичка Cacti, он же Кактус, который хранит данные и рисует графики с помощью очень старой TSDB — RRDTool. Работает Cacti на базе стандартного LAMP стэка, так как написан на PHP, настройки хранит в MySQL. Поднять сервер можно даже на Windows под IIS. Сбор метрик крутится в основном вокруг SNMP, но можно их собирать и другими способами на базе собственных Data Collectors, в качестве которых могут выступать и обычные скрипты. Кактус ориентирован в основном на мониторинг сетевых устройств.
Cacti поддерживает шаблоны, правила автообнаружения, расширяет свои возможности через плагины, имеет разные механизмы аутентификации пользователей, в том числе через LDAP. То есть там полный набор полноценной системы мониторинга. Система очень старая, из 2001 (😎) года, но поддерживается и развивается до сих пор.
Это такая самобытная, добротная, с приятным интерфейсом система мониторинга. Если честно, я не знаю, что может заставить её использовать сейчас. Разве что её интерфейс дашборды. Сказать, что она легко и быстро разворачивается не могу. Чего-то особенного в ней тоже нет. Используется мало где, и мало кому нужна. Не знаю ни одного аргумента, который бы оправдал её использование вместо того же Zabbix или более современных систем.
Если в каких-то других системах мониторинга я могу увидеть простоту установки и настройки, необычный внешний вид или удобные дашборды, то тут ничего такого нет. Настраивать придётся вручную, изучать сбор метрик и принцип работы, разбираться. Материалов не так много, все в основном старые. Это скорее система для тех, кто с ней знаком и работал раньше. Сейчас её изучать смысла не вижу.
Посмотреть внешний вид и основные возможности можно вот в этом обзорном видео: ▶️ https://www.youtube.com/watch?v=Xww5y9V1ikI Возможно вас эта система чем-то зацепит. Как я уже сказал, она самобытная с необычным интерфейсом и дашбордами. Выглядит неплохо. Мне, к примеру, RRD графики нравятся больше чем то, что сейчас есть в Zabbix.
Отдельно отмечу, что у Cacti есть плагин для NetFlow. Можно собирать информацию о трафике с сетевых устройств и смотреть в Кактусе. Пример того, как это может выглядеть в связке с Mikrotik, можно посмотреть в видео. Хотя лично я считаю, что лучше отдельную систему под это, так как это не совсем мониторинг.
В Debian Cacti есть в базовых репах и ставится автоматически весь стек:
После этого идёте в веб интерфейс по адресу http://172.17.196.25/cacti/. Учётка admin / cacti. Для теста можете поставить локально службу snmpd и добавить хост localhost в систему мониторинга.
⇨ Сайт / Исходники / Видеоинструкции
#мониторинг
Речь пойдёт про старичка Cacti, он же Кактус, который хранит данные и рисует графики с помощью очень старой TSDB — RRDTool. Работает Cacti на базе стандартного LAMP стэка, так как написан на PHP, настройки хранит в MySQL. Поднять сервер можно даже на Windows под IIS. Сбор метрик крутится в основном вокруг SNMP, но можно их собирать и другими способами на базе собственных Data Collectors, в качестве которых могут выступать и обычные скрипты. Кактус ориентирован в основном на мониторинг сетевых устройств.
Cacti поддерживает шаблоны, правила автообнаружения, расширяет свои возможности через плагины, имеет разные механизмы аутентификации пользователей, в том числе через LDAP. То есть там полный набор полноценной системы мониторинга. Система очень старая, из 2001 (😎) года, но поддерживается и развивается до сих пор.
Это такая самобытная, добротная, с приятным интерфейсом система мониторинга. Если честно, я не знаю, что может заставить её использовать сейчас. Разве что её интерфейс дашборды. Сказать, что она легко и быстро разворачивается не могу. Чего-то особенного в ней тоже нет. Используется мало где, и мало кому нужна. Не знаю ни одного аргумента, который бы оправдал её использование вместо того же Zabbix или более современных систем.
Если в каких-то других системах мониторинга я могу увидеть простоту установки и настройки, необычный внешний вид или удобные дашборды, то тут ничего такого нет. Настраивать придётся вручную, изучать сбор метрик и принцип работы, разбираться. Материалов не так много, все в основном старые. Это скорее система для тех, кто с ней знаком и работал раньше. Сейчас её изучать смысла не вижу.
Посмотреть внешний вид и основные возможности можно вот в этом обзорном видео: ▶️ https://www.youtube.com/watch?v=Xww5y9V1ikI Возможно вас эта система чем-то зацепит. Как я уже сказал, она самобытная с необычным интерфейсом и дашбордами. Выглядит неплохо. Мне, к примеру, RRD графики нравятся больше чем то, что сейчас есть в Zabbix.
Отдельно отмечу, что у Cacti есть плагин для NetFlow. Можно собирать информацию о трафике с сетевых устройств и смотреть в Кактусе. Пример того, как это может выглядеть в связке с Mikrotik, можно посмотреть в видео. Хотя лично я считаю, что лучше отдельную систему под это, так как это не совсем мониторинг.
В Debian Cacti есть в базовых репах и ставится автоматически весь стек:
# apt install cactiПосле этого идёте в веб интерфейс по адресу http://172.17.196.25/cacti/. Учётка admin / cacti. Для теста можете поставить локально службу snmpd и добавить хост localhost в систему мониторинга.
⇨ Сайт / Исходники / Видеоинструкции
#мониторинг
Тема мониторинга imap сервера Dovecot всегда обходила меня стороной. Я даже и не знал, что там есть встроенный модуль, который умеет отдавать кучу своих метрик. Не видел особой надобности. Я всегда настраивал fail2ban на перебор учёток Dovecot и мониторинг доступности TCP портов службы. В общем случае мне этого достаточно.
На днях читал новость про обновления в очередной новой версии Dovecot и увидел там изменения в модуле статистики. Заинтересовался и решил изучить его. Оказалось, там всё не так просто, как думалось на первый взгляд. Ожидал там увидеть что-то типа того, что есть в статистике Nginx или Php-fpm. А на самом деле в Dovecot очень много всевозможных метрик и их представлений: в линейных, логарифмических, средних, перцинтильных видах. Плюс фильтры, наборы метрик и т.д. Постараюсь кратко саму суть рассказать. А позже, скорее всего, сделаю небольшой шаблон для Zabbix и настрою мониторинг.
Включаем мониторинг и добавляем некоторый набор метрик, который описывает документация, как пример. Добавляем в конфиг Dovecot:
Перезапускаем Dovecot. Метрики можно увидеть по HTTP на порту сервера 9900 (не забудьте настроить ограничение на firewall) или в консоли:
Описание увиденных полей смотрите в документации, в разделе listing-statistic. Все метрики, что не count, выводятся в микросекундах. Я долго не мог понять, что это за огромные числа и зачем они нужны, пока не нашёл описание в документации.
В данном примере мы вывели статистику по успешным и неуспешным аутентификациям, по всем imap и smtp (не понял, что это за smtp метрики, у меня они по нулям) командам, и по успешным доставкам почты в ящики. Полный список событий, которые можно выводить, смотрите в разделе Events. А возможности фильтрации в Event Filtering. В принципе, тут будет вся информация по поводу метрик и их вывода.
Я посмотрел все возможные метрики и прикинул, что реально полезных, за которыми стоит следить, не так много. Перечислю их:
1️⃣ Uptime сервера. Выводится по умолчанию, отдельно настраивать эту метрику не надо. Соответственно, можно делать триггер на перезапуск сервера.
2️⃣ Количество успешных и неудачных аутентификаций. Причём интересны не абсолютные значения, а изменение в минуту. Сделать триггер на превышение среднего значения, например, в 1,5-2 раза. Если у вас резко выросли аутентификации, то, возможно, кто-то наплодил ящиков и заходит в них. А если много неудачных попыток, то, возможно, fail2ban сломался и начался подбор паролей.
3️⃣ Число успешных доставок почты. Если резво выросло число доставленных писем на каком-то большой интервале, то это повод обратить внимание. Интервал надо брать побольше, чем минута, иначе на какие-то легитимные рассылки будет реакция. Взять, думаю, надо интервал 30-60 минут и сравнивать изменения на нём. Можно и накопительную метрику сделать за сутки, чтобы быстро оценить количество входящей почты.
Вот, в принципе, и всё. Остальные метрики это уже тонкая настройка отдельных служб или слежение за производительностью. Dovecot умеет считать выполнение в микросекундах каждой своей команды и выводить min, max, avg, median, персинтили. Можно очень гибко следить за производительностью в разрезе отдельной imap команды, если для вас это важно.
#dovecot #mailserver #мониторинг
На днях читал новость про обновления в очередной новой версии Dovecot и увидел там изменения в модуле статистики. Заинтересовался и решил изучить его. Оказалось, там всё не так просто, как думалось на первый взгляд. Ожидал там увидеть что-то типа того, что есть в статистике Nginx или Php-fpm. А на самом деле в Dovecot очень много всевозможных метрик и их представлений: в линейных, логарифмических, средних, перцинтильных видах. Плюс фильтры, наборы метрик и т.д. Постараюсь кратко саму суть рассказать. А позже, скорее всего, сделаю небольшой шаблон для Zabbix и настрою мониторинг.
Включаем мониторинг и добавляем некоторый набор метрик, который описывает документация, как пример. Добавляем в конфиг Dovecot:
service stats { inet_listener http { port = 9900 }}metric auth_success { filter = event=auth_request_finished AND success=yes}metric auth_failures { filter = event=auth_request_finished AND NOT success=yes}metric imap_command { filter = event=imap_command_finished group_by = cmd_name tagged_reply_state}metric smtp_command { filter = event=smtp_server_command_finished group_by = cmd_name status_code duration:exponential:1:5:10}metric mail_delivery { filter = event=mail_delivery_finished group_by = duration:exponential:1:5:10}Перезапускаем Dovecot. Метрики можно увидеть по HTTP на порту сервера 9900 (не забудьте настроить ограничение на firewall) или в консоли:
# doveadm -f table stats dumpОписание увиденных полей смотрите в документации, в разделе listing-statistic. Все метрики, что не count, выводятся в микросекундах. Я долго не мог понять, что это за огромные числа и зачем они нужны, пока не нашёл описание в документации.
В данном примере мы вывели статистику по успешным и неуспешным аутентификациям, по всем imap и smtp (не понял, что это за smtp метрики, у меня они по нулям) командам, и по успешным доставкам почты в ящики. Полный список событий, которые можно выводить, смотрите в разделе Events. А возможности фильтрации в Event Filtering. В принципе, тут будет вся информация по поводу метрик и их вывода.
Я посмотрел все возможные метрики и прикинул, что реально полезных, за которыми стоит следить, не так много. Перечислю их:
1️⃣ Uptime сервера. Выводится по умолчанию, отдельно настраивать эту метрику не надо. Соответственно, можно делать триггер на перезапуск сервера.
2️⃣ Количество успешных и неудачных аутентификаций. Причём интересны не абсолютные значения, а изменение в минуту. Сделать триггер на превышение среднего значения, например, в 1,5-2 раза. Если у вас резко выросли аутентификации, то, возможно, кто-то наплодил ящиков и заходит в них. А если много неудачных попыток, то, возможно, fail2ban сломался и начался подбор паролей.
3️⃣ Число успешных доставок почты. Если резво выросло число доставленных писем на каком-то большой интервале, то это повод обратить внимание. Интервал надо брать побольше, чем минута, иначе на какие-то легитимные рассылки будет реакция. Взять, думаю, надо интервал 30-60 минут и сравнивать изменения на нём. Можно и накопительную метрику сделать за сутки, чтобы быстро оценить количество входящей почты.
Вот, в принципе, и всё. Остальные метрики это уже тонкая настройка отдельных служб или слежение за производительностью. Dovecot умеет считать выполнение в микросекундах каждой своей команды и выводить min, max, avg, median, персинтили. Можно очень гибко следить за производительностью в разрезе отдельной imap команды, если для вас это важно.
#dovecot #mailserver #мониторинг
