​​Мой первый настроенный мониторинг в роли системного администратора 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 / Установка

#мониторинг

​​У меня написаны заметки по всем более ли менее популярным бесплатным системам мониторинга. И только одну очень старую систему я всегда обходил стороной, за что неоднократно получал комментарии на эту тему. Надо это исправить и дополнить мою статью с обзором систем мониторинга (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 есть в базовых репах и ставится автоматически весь стек:
# 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:

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 #мониторинг

​​Предлагаю вашему вниманию любопытный проект по мониторингу одиночного хоста с Docker - domolo. Сразу скажу, что это продукт уровня курсовой работы с каких-нибудь курсов по DevOps на тему мониторинга. Он представляет из себя преднастроенный набор контейнеров на современном стеке.

Domolo состоит из:
◽Prometheus вместе с Pushgateway, AlertManager и Promtail
◽Grafana с набором дашбордов
◽Loki для сбора логов с хоста и контейнеров
◽NodeExporter - для сбора метрик хоста
◽cAdvisor - для сбора метрик контейнеров
◽Caddy - реверс прокси для prometheus и alertmanager

Сначала подумал, что это какая-та ерунда. Не думал, что заработает без напильника. Но, на моё удивление, это не так. Всё заработало вообще сразу:
# git clone https://github.com/ductnn/domolo.git
# cd domolo
# docker-compose up -d

Идём в Grafana по адресу http://ip-хоста:3000, учётка admin / changeme. Здесь мы можем наблюдать уже настроенные дашборды на все случаи жизни. Там есть буквально всё, что надо и не надо. Loki и сбор логов тоже работает сразу же без напильника. Идём в Explore, выбираем Datasource Loki и смотрим логи.

Если вам нужно мониторить одиночный хост с контейнерами, то это прям полностью готовое решение. Запускаете и наслаждаетесь. Репозиторий domolo удобен и для того, чтобы научиться всё это дело настраивать. Все конфиги и docker-compose файлы присутствуют. На мой взгляд для обучения это удобнее, чем какая-нибудь статья или обучающее видео. Здесь всё в одном месте и гарантированно работает.

Можно разобраться, настроить под себя и, к примеру, добавить туда поддержку внешних хостов. Надо будет добавить новые внешние Datasources и какие-то метки внедрить, чтобы различать хосты и делать общие дашборды. Получится ещё одна курсовая работа.

Сам проект не развивается и не обновляется. Так что ждать от него чего-то сверх того, что там есть, не имеет смысла.

#мониторинг #grafana #docker #prometheus

​​Выбирая между софтовым или железным рейдом, я чаще всего выберу софтовый, если не будет остро стоять вопрос быстродействия дисковой подсистемы. А в бюджетном сегменте обычно и выбирать не приходится. Хотя и дорогой сервер могу взять без встроенного рейд контроллера, особенно если там быстрые ssd или nvme диски.

Под софтовым рейдом я в первую очередь подразумеваю реализацию на базе mdadm, потому что сам её использую, либо zfs. Удобство программных реализаций в том, что диски и массивы полностью видны в системе, поэтому для них очень легко и просто настроить мониторинг, в отличие от железных рейдов, где иногда вообще невозможно замониторить состояние рейда или дисков. А к дискам может не быть доступа. То есть со стороны системы они просто не видны. Хорошо, если есть развитый BMC (Baseboard Management Controller) и данные можно вытянуть через IPMI.

С софтовыми рейдами таких проблем нет. Диски видны из системы, и их мониторинг не представляет каких-то сложностей. Берём smartmontools
# apt install smartmontools
и выгружаем всю информацию о диске вместе с моделью, серийным номером и смартом:
# smartctl -i /dev/sdd -j
# smartctl -A /dev/sdd -j

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

То же самое с mdadm. Смотрим состояние:
# mdadm -Q --detail /dev/md1
Добавляем утилиту jc:
# apt install jc
Выгружаем полную информацию о массиве в формате json:
# mdadm -Q --detail /dev/md1 | jc --mdadm -p
И отправляем это в мониторинг.

Настройка простая и гибкая. У вас полный контроль за всеми устройствами и массивами. Замена тоже проста и понятна и не зависит от модели сервера, рейд контроллера, вендора и т.д. Всё везде одинаково. Я за эту осень уже 4 диска менял в составе mdadm на разных серверах и всё везде прошло одинаково: вовремя отработал мониторинг, планово сделал замену.

Надеюсь найду время и напишу когда-нибудь подробную статью по этой теме. Есть старая: https://serveradmin.ru/monitoring-smart-v-zabbix, но сейчас я уже делаю не так. В статье до сих пор скрипт на perl и парсинг консольными утилитами. Сейчас я всё вывожу в json и парсю уже на сервере мониторинга.

#железо #mdadm #мониторинг

​​Существует довольно старая система мониторинга под названием Sensu. Ей лет 10 точно есть. Изначально она была написана на Ruby. На этом же языке писались и самостоятельные проверки, дополнения и т.д. Судя по всему в какой-то момент разработчики поняли, что это не самая удачная реализация и переписали всё на Go, а язык для проверок реализовали на JavaScript.

По сути сейчас это новая система мониторинга, полностью заточенная на реализацию подхода IaC в виде его уточнения - Monitoring-as-Code. Я изучил сайт, посмотрел возможности, обзорное видео, инструкцию по разворачиванию. Выглядит современно и удобно. Сами они себя позиционируют как инструмент для DevOps и SRE команд. При этом я вообще нигде и никогда не видел упоминание про этот мониторинг ни в современных статьях, ни где-то в выступлениях на тему мониторинга.

Базовый продукт open source. То есть можно спокойно развернуть у себя. Sensu состоит из следующих компонентов:

◽Sensu Backend - основной компонент, который собирает, обрабатывает и хранит данные.
◽Sensu API - интерфейс для взаимодействия с бэкендом.
◽Sensuctl - CLI интерфейс для взаимодействия с бэкендом через API.
◽Sensu Agent - агенты, которые устанавливаются на конечные хосты для сбора и отправки данных.

Из архитектуры понятно, что это агентский мониторинг. Реализован он немного необычно, с акцентом на простоту и скорость разворачивания агентов. Все правила по сбору метрик вы настраиваете на сервере. Каждое правило - отдельный yaml файл. Когда вы разворачиваете агент, указываете только url апишки и набор подписок на сервере. Всё, на агенте больше ничего настраивать не надо.

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

# sensuctl create -f metric-storage/influxdb.yaml
# sensuctl create -f alert/slack.yaml
# sensuctl create -r -f system/linux/cpu

Создали конфигурацию хранилища, добавили оповещения и метрику для сбора информации о нагрузке на cpu. Теперь настройки этой метрики можно опубликовать, а агенты на неё подпишутся и будут отправлять данные. После каждой выполненной команды будет создан соответствующий yaml файл, где можно будет настроить параметры. Sensu поддерживает namespaces для разделения доступа на большой системе. Примерно так, как это реализовано в Kubernetes. Sensu вообще в плане организации работы сильно похожа на кубер.

Подобная схема идеально подходит под современный подход к разработке и эксплуатации со встраиванием мониторинга в пайплайны. При этом Sensu объединяет в себе метрики, логи и трейсы. То есть закрывает все задачи разом.

Сам сервер Sensu под Linux. Есть как deb и rpm пакеты, так и Docker контейнер. Агенты тоже есть под все Linux, а также под Windows. У Sensu много готовых интеграций и плагинов. К примеру, он умеет забирать метрики с экспортеров Prometheus или плагинов Nagios. Может складывать данные в Elasticsearch, InfluxDB, TimescaleDB. Имеет интеграцию с Grafana.

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

По описанию и возможностям система выглядит очень привлекательно. Разработчики заявляют, что она покрывает всё, от baremetal до кластеров Kubernetes. Мне не совсем понятна её малая распространённость и известность. Может это особенность русскоязычной среды. Я вообще ничего не знаю и не слышал про этот мониторинг. Если кто-то использовал его, поделитесь информацией на этот счёт.

⇨ Сайт / Исходники / Видеообзор

#мониторинг

​​Я активно использую технологию wake on lan в личных целях. Запускаю разное железо дома, когда это нужно. Сам для этого использую Mikrotik и его функциональность в виде tool wol и встроенной системы скриптов. Скрипт выглядит вот так:

tool wol interface=ether1 mac=00:25:21:BC:39:42

Что-то вручную запускаю, что-то по таймеру. Если у вас нету Микротика, либо хочется что-то более красивое, удобное, то можно воспользоваться готовой панелькой для этого - UpSnap. Это простенькая веб панель с приятным внешним видом. Запустить можно в Docker:

# git clone https://github.com/seriousm4x/UpSnap
# cd UpSnap
# docker compose up

Всё, можно идти смотреть на http://172.20.4.92:8090/_/. Это админский url, где нужно будет зарегистрироваться. Сам дашборд будет доступен под той же учёткой, только по адресу без подчёркивания: http://172.20.4.92:8090/

Основные возможности UpSnap:

▪ Общий Dashboard со всеми добавленными устройствами, с которыми можно выполнять настроенные действия: будить, завершать работу, наблюдать за открытыми портами и т.д.
▪ Использовать планировщик для запланированных действий
▪ Сканировать сеть с помощью nmap
▪ Разделение прав с помощью пользователей

Выглядит симпатично. Подойдёт и в качестве простого мониторинга. Не знаю, насколько эти применимо где-то в работе, а для дома нормально. У меня всё то же самое реализовано на базе, как уже сказал, Mikrotik и Zabbix. Я и включаю, и выключаю, и слежу за запущенными устройствами с его помощью. Обычно перед сном смотрю, что в доме включенным осталось. Если дети или жена забыли свои компы выключить, могу это сделать удалённо. То же самое с дачей, котлом, компом и камерами там. Понятно, что для личного пользования Zabbix для этих целей перебор, но так как это один из основных моих рабочих инструментов, использую его везде.

UpSnap может заменить простенький мониторинг с проверкой хостов пингом и наличием настроенных открытых tcp портов. Разбираться не придётся, настроек минимум. Можно развернуть и сходу всё настроить.

⇨ Исходники

#мониторинг

​​В ОС на базе Linux есть разные способы измерить время выполнения той или иной команды. Самый простой с помощью утилиты time:

# time curl http://127.0.0.1/server-status
Active connections: 1 
server accepts handled requests
 6726 6726 4110 
Reading: 0 Writing: 1 Waiting: 0 

real 0m0.015s
user 0m0.006s
sys 0m0.009s

Сразу показал на конкретном примере, как я это использовал в мониторинге. Через curl обращаюсь на страницу со статистикой веб сервера Nginx. Дальше распарсиваю вывод и забираю в том числе метрику real, которая показывает реальное выполнение запроса. Сама по себе в абсолютном значении эта метрика не важна, но важна динамика. Когда сервер работает штатно, то эта метрика плюс-минус одна и та же. И если начинаются проблемы, то отклик запроса страницы растёт. А это уже реальный сигнал, что с сервером какие-то проблемы.

Сейчас в репозитории современных систем приехал более продвинутый инструмент для отслеживания времени выполнения консольных команд - hyperfine:

# apt install hyperfine

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

Например, в hyperfine можно обернуть какую-то команду и получить информацию по её выполнению. Покажу на примере создания дампа mysql базы:

# hyperfine --runs 1 --export-json mysqldump.json 'mysqldump --opt -v --no-create-db db01 -u'user01' -p'pass01' > ~/db01.sql'

На выходе получаем файл mysqldump.json с информацией:

{
 "results": [
  {
   "command": "mysqldump --opt -v --no-create-db db01 -u'user01' -p'pass01' > ~/db01.sql",
   "mean": 2.7331184105,
   "stddev": null,
   "median": 2.7331184105,
   "user": 2.1372425799999997,
   "system": 0.35953332,
   "min": 2.7331184105,
   "max": 2.7331184105,
   "times": [
    2.7331184105
   ],
   "exit_codes": [
    0
   ]
  }
 ]
}

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

Точно так же можно собирать информацию о реальном отклике сайта:

# hyperfine --runs 3 'curl -s https://github.com/'

Можно раз в минуту прогонять по 3 теста с нужной вам локации, записывать результат и сравнивать со средним или с заданным пределом.

Я привел примеры только для мониторинга. Так то hyperfine многофункционален. Так что берите на вооружение.

#linux #мониторинг #perfomance

​​Я когда-то давно уже рассказывал про сервис мониторинга UptimeRobot. Хочу лишний раз про него напомнить, так как сам с тех пор им так и пользуюсь для личных нужд.

По своей сути это простая пинговалка, проверка открытых TCP портов и доступности сайтов. У неё есть бесплатный тарифный план на 50 проверок с периодичностью не чаще одного раза в 5 минут. Для личных нужд этого за глаза.

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

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

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

#мониторинг #бесплатно

​​На днях разработчики Angie анонсировали свой готовый Dashboard для мониторинга веб сервера через Prometheus и Grafana. Решил сразу его попробовать. Забегая вперёд скажу, что всё это существенно упрощает настройку мониторинга, который и так уже был на хорошем уровне в Angie. Стало просто отлично.

Напомню, что у Angie есть встроенный prometheus exporter. Включаем его так. Добавляем куда-нибудь location. Я обычно на ip адрес его вешаю в default сервер и ограничиваю доступ:

  location =/p8s {
    prometheus all;
    allow 127.0.0.1;
    allow 1.2.3.4;
    allow 4.3.2.1;
    deny all;
  }

И добавляем в секцию http:

include prometheus_all.conf;

Далее добавляем в prometheus:

scrape_configs:
- job_name: "angie"
scrape_interval: 15s
metrics_path: "/p8s"
static_configs:
- targets: ["1.2.3.4:80"]

Только убедитесь, что ваш веб сервер отдаёт метрики по http://1.2.3.4/p8s. Либо какой-то другой url используйте, который настроили.

Вот и всё. Теперь идём в свою Grafana и добавляем готовый дашборд. Вот он:

⇨  https://grafana.com/grafana/dashboards/20719-angie-dashboard

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

server {
server_name serveradmin.ru;
status_zone serveradmin.ru;
................
}

Перезапускаем Angie и переходим в Dashboard. В разделе HTTP Server Zones появится отдельная статистика по этому виртуальному хосту. То же самое можно сделать с отдельными location. Добавим отдельную зону в основной location и с php бэкендом:

location / {
status_zone main;
...............
}

или

location ~ \.php$ {
status_zone php;
...................
}

Идём в раздел HTTP Location Zones и смотрим там статистику по указанным location.

Статистика по бэкендам, зонам с лимитами тоже подхватывается автоматически, если они у вас настроены, и сразу видна в дашборде.

Сделано всё очень удобно. Мониторинг веб сервера настраивается максимально быстро и при этом очень функционально.

Отдельно напомню, что у Angie вся эта же статистика видна в веб интерфейсе Console Light. И так же доступна через модуль API. Я через него сделал шаблон для Zabbix с основными метриками. Шаблон по ссылке стоит рассматривать только как пример создания. Он был сделан на скорую руку. Я его у себя немного доделал, но новую версию не выкладывал. Уже не помню, какие там отличия. С выходом этого дашборда для графаны мне шаблоном для Zabbix заниматься не хочется. Довольно хлопотно всё это реализовывать в нём и не особо имеет смысл, раз уже всё сделано за нас. Графаной я и так постоянно пользуюсь в связке с Zabbix, и Prometheus тоже использую.

📌 Ссылки по теме:

⇨ Настройка панели Prometheus
⇨ Модуль API
⇨ Директива status_zone
⇨ Web Console Demo

Как по мне, возможностей бесплатного веб сервера Angie на текущий момент существенно больше, чем у бесплатного Nginx. И речь не только о мониторинге. Там есть много других удобств. Разница в функциональности тянет уже на отдельную заметку.

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

​​Расскажу про очень простую и функциональную систему отправки уведомлений во все современные каналы - Apprise. Она представляет из себя консольное приложение, в которое через параметры командной строки можно передавать настройки для отправки уведомлений.

Apprise поддерживает Telegram, Discord, Mattermost, NextcloudTalk, Revolt, Rocket.Chat, Slack, WhatsApp и т.д. Помимо мессенджеров сообщения можно доставлять в Syslog, Pushover, ntfy, Mailgun, обычную почту и кучу других сервисов, в том числе пуши на комп можно отправлять. Они все перечислены в репозитории. Список очень большой.

Работает это примерно так. Ставим Apprise из pip:

# apt install python3-pip
# pip install apprise --break-system-packages

Открываем репозиторий и смотрим синтаксис необходимого вам направления. Пример для Telegram:

# uptime | apprise -vv \
  'tgram://1393668911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw/211805263'

От правили вывод утилиты uptime в Telegram. Формат конфигурации такой:

tgram://bottoken/ChatID

или для нескольких чатов

tgram://bottoken/ChatID1/ChatID2/ChatIDN

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

С помощью Apprise легко настроить отправку пушей через сервис pushover.net. У него бесплатный тарифный план позволяет отправлять 10,000 в месяц. Для многих задач этого будет заглаза.

Настройки можно выполнять через веб интерфейс. Для этого собрали готовый Docker образ. Там можно подготовить конфигурации отправлений, протэгировать их и использовать в консольных командах, отправляя запросы к Apprise API.

Система простая в настройке. Не надо изучать и разбираться с API сторонних сервисов. В Apprise они уже все собраны, а работа с ними унифицирована с помощью встроенного API или конфигураций. У продукта есть подробная wiki.

⇨ Исходники / Docker

#мониторинг

​​После установки обновлений иногда необходимо выполнить перезагрузку системы. Точно надо это сделать, если обновилось ядро. Необходимо загрузиться с новым ядром. В коммерческих системах Linux от разных разработчиков есть механизмы обновления ядра без перезагрузки. В бесплатных системах такого не видел.

Для того, чтобы отслеживать этот момент, можно воспользоваться программой needrestart. Она есть в базовых репах:

# apt install needrestart

В rpm дистрибутивах название будет needs-restarting. Если просто запустить программу, то она в интерактивном режиме покажет, какие службы необходимо перезапустить, чтобы подгрузить обновлённые библиотеки, либо скажет, что надо перезапустить систему, чтобы применить обновление ядра.

Для того, чтобы использовать её в автоматизации, есть ключ -b, batch mode:

# needrestart -b
NEEDRESTART-VER: 3.5
NEEDRESTART-KCUR: 5.10.0-25-amd64
NEEDRESTART-KEXP: 5.10.0-29-amd64
NEEDRESTART-KSTA: 3
NEEDRESTART-SVC: cron.service
NEEDRESTART-SVC: dbus.service
NEEDRESTART-SVC: getty@tty1.service
NEEDRESTART-SVC: ifup@ens18.service
NEEDRESTART-SVC: qemu-guest-agent.service
NEEDRESTART-SVC: rsyslog.service
NEEDRESTART-SVC: systemd-journald.service
NEEDRESTART-SVC: systemd-logind.service
NEEDRESTART-SVC: systemd-timesyncd.service
NEEDRESTART-SVC: systemd-udevd.service

Здесь перечислены службы, которые нужно перезапустить после обновления системы. И показана информация об ядре. Значение NEEDRESTART-KSTA может принимать следующие состояния необходимости обновления ядра:

0: неизвестно, либо не удалось определить
1: нет необходимости в обновлении
2: ожидается какое-то ABI совместимое обновление (не понял, что это такое)
3: ожидается обновление версии

Если у вас значение 3, как у меня в примере, значит систему нужно перезагрузить, чтобы обновлённое ядро 5.10.0-29-amd64 заменило текущее загруженное 5.10.0-25-amd64.

Значение NEEDRESTART-KSTA можно передать в мониторинг и отслеживать необходимость перезагрузки. Например, В Zabbix можно передать вывод следующей команды:

# needrestart -b | grep 'NEEDRESTART-KSTA' | awk '{print $2}'

Если на выходе будет 3, активируем триггер. Передать значение можно любым доступным способом, которому вы отдаёте предпочтение в своей инфраструктуре:

◽с помощью локального скрипта и параметра UserParameter в агенте
◽с помощью EnableRemoteCommands в агенте и ключа system.run на сервере
◽с помощью zabbix_sender
◽с помощью скрипта и передачи значения ключа напрямую в сервер через его API

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

После перезагрузки значение NEEDRESTART-KSTA станет равно единице:

# needrestart -b
NEEDRESTART-VER: 3.5
NEEDRESTART-KCUR: 5.10.0-29-amd64
NEEDRESTART-KEXP: 5.10.0-29-amd64
NEEDRESTART-KSTA: 1

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

Покажу, как строку сразу преобразовать в нормальный json, чтобы потом можно было легко анализировать:

# needrestart -b | tr ':' '=' | tr -d ' ' | jo -p
{
  "NEEDRESTART-VER": 3.5,
  "NEEDRESTART-KCUR": "5.10.0-29-amd64",
  "NEEDRESTART-KEXP": "5.10.0-29-amd64",
  "NEEDRESTART-KSTA": 1
}

Обработал в лоб. Взял утилиту jo, заменил : на = c помощью tr, потому что jo понимает только =, потом убрал лишние пробелы опять же с помощью tr. Получили чистый json, из которого с помощью jsonpath можно забрать необходимое для анализа значение.

# needrestart -b | tr ':' '=' | tr -d ' ' | jo -p | jq .'"NEEDRESTART-KSTA"'
1

Придумал это без помощи ChatGPT. Даже не знаю уже, хорошо это или плохо. По привычке трачу время и пишу такие штуки сам.

#linux #мониторинг

​​Наиболее популярным и простым в настройке мониторингом сейчас является Prometheus. Простым не в плане возможностей, а в плане начальной настройки. Так как для него очень много всего автоматизировано, начать сбор метрик можно в несколько простых действий. Мониторинг сразу заработает и дальше с ним можно разбираться и настраивать.

Напишу краткую шпаргалку по запуску связки Prometheus + Grafana, чтобы её можно было сохранить и использовать по мере надобности. Я установлю их в Docker, сразу буду мониторить сам Prometheus и локальных хост Linux. Подключу для примера ещё один внешний Linux сервер.

Ставим Docker:

# curl https://get.docker.com | bash -

Готовим файл docker-compose.yml:

# mkdir ~/prometheus && cd ~/prometheus
# touch docker-compose.yml

Содержимое файла:

version: '3.9'
networks:
monitoring:
driver: bridge
volumes:
prometheus_data: {}

services:

prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
container_name: prometheus
hostname: prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
expose:
- 9090
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

node-exporter:
image: prom/node-exporter
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
container_name: exporter
hostname: exporter
command:
- '--path.procfs=/host/proc'
- '--path.rootfs=/rootfs'
- '--path.sysfs=/host/sys'
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
expose:
- 9100
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

grafana:
image: grafana/grafana
user: root
depends_on:
- prometheus
ports:
- 3000:3000
volumes:
- ./grafana:/var/lib/grafana
- ./grafana/provisioning/:/etc/grafana/provisioning/
container_name: grafana
hostname: grafana
restart: unless-stopped
environment:
TZ: "Europe/Moscow"
networks:
- monitoring

И рядом кладём конфиг prometheus.yml:

scrape_configs:
- job_name: 'prometheus'
scrape_interval: 5s
scrape_timeout: 5s
static_configs:
- targets: ['localhost:9090']

- job_name: 'node-local'
scrape_interval: 5s
static_configs:
- targets: ['node-exporter:9100']

Запускаем весь стек:

# docker-compose up -d

Если будут ошибки, прогоните весь yaml через какой-нибудь валидатор. При копировании он часто ломается.

Ждём, когда всё поднимется, и идём по IP адресу сервера на порт 3000. Логинимся в Grafana под учёткой admin / admin. Заходим в Connections ⇨ Data sources и добавляем источник prometheus. В качестве параметра Prometheus server URL указываем http://prometheus:9090. Сохраняем.

Идём в Dashboards, нажимаем New ⇨ Import. Вводим ID дашборда для Node Exporter - 1860. Сохраняем и идём смотреть дашборд. Увидите все доступные графики и метрики хоста Linux, на котором всё запущено.

Идём на удалённый Linux хост и запускаем там любым подходящим способом node-exporter. Например, через Docker напрямую:

# docker run -d --net="host" --pid="host" -v "/:/host:ro,rslave" prom/node-exporter:latest --path.rootfs=/host

Проверяем, что сервис запущен на порту 9100:

# ss -tulnp | grep 9100

Возвращаемся на сервер с prometheus и добавляем в его конфиг еще одну job с этим сервером:

- job_name: 'node-remote'
scrape_interval: 5s
static_configs:
- targets: ['10.20.1.56:9100']

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

# docker compose restart

Идём в Dashboard в Grafana и выбираем сверху в выпадающем списке job от этого нового сервера - node-remote.

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

❗️В проде не забывайте ограничивать доступ ко всем открытым портам хостов с помощью файрвола.

#мониторинг #prometheus #devops

​​Вчера была заметка про быструю установку связки Prometheus + Grafana. Из-за лимита Telegram на длину сообщений разом всё описать не представляется возможным. А для полноты картины не хватает настройки уведомлений, так как мониторинг без них это не мониторинг, а красивые картинки.

Для примера я настрою два типа уведомлений:

◽SMTP для только для метки critical
◽Telegram для меток critical и warning

Уведомления будут отправляться на основе двух событий:

▪️ С хоста нету метрик, то есть он недоступен мониторингу, метка critical
▪️ На хосте процессор занят в течении минуты более чем на 70%, метка warning

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

Постить сюда все конфигурации в формате yaml неудобно, поэтому решил их собрать в архив и прикрепить в следующем сообщении. Там будут 4 файла:

- docker-compose.yml - основной файл с конфигурацией всех сервисов. Его описание можно посмотреть в предыдущем посте. Там добавился новый контейнер с alertmanager и файл с правилами для prometheus - alert.rules
- prometheus.yml - настройки Прометеуса.
- alert.rules - файл с двумя правилами уведомлений о недоступности хоста и превышении нагрузки CPU.
- alertmanager.yml - настройки alertmanager с двумя источниками для уведомлений: email и telegram. Не забудьте там поменять токен бота, id своего аккаунта, куда бот будет отправлять уведомления и настройки smtp.

Для запуска всего стека с уведомлениями достаточно положить эти 4 файла в отдельную директорию и там запустить compose:

# docker compose up

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

# docker compose stop

Исправляйте конфиги и заново запускайте. Зайдя по IP адресу сервера на порт 9090, вы попадёте в веб интерфейс Prometheus. Там будет отдельный раздел Alerts, где можно следить за работой уведомлений.

В данном примере со всем стэком наглядно показан принцип построения современного мониторинга с подходом инфраструктура как код (IaC). Имея несколько файлов конфигурации, мы поднимаем необходимую систему во всей полноте. Её легко переносить, изменять конфигурацию и отслеживать эти изменения через git.

#мониторинг #prometheus #devops

​​Когда речь заходит о современном мониторинге, в первую очередь на ум приходит Prometheus и прочие совместимые с ним системы. Более возрастные специалисты возможно назовут Zabbix и в целом не ошибутся. Сколько его ни хоронят, но на самом деле он остаётся вполне современным и востребованным.

А вот дальше уже идёт список из менее популярных систем, которые тем не менее живут, развиваются и находят своё применение. Про один из таких современных мониторингов с вполне солидной историей я кратко расскажу. Речь пойдёт про TICK Stack (Telegraf, InfluxDB, Chronograf, Kapacitor). Я могу ошибаться, но вроде бы мониторинг на базе InfluxDB и Telegraf появился чуть раньше, чем подобный стэк на базе Prometheus. По крайней мере я про них давно знаю. Он был немного экзотичен, но в целом использовался. Сам не пробовал, но читал много обзорных статей по его использованию.

TICK Stack состоит из следующих компонентов:

◽Telegraf — агент, который собирает метрики, логи и передаёт в базу influxdb, но умеет также передавать в elasticsearch, prometheus или graphite.
◽InfluxDB — СУБД для хранения временных рядов (TSDB - time series database).
◽Chronograf — веб интерфейс для визуализации метрик.
◽Kapacitor — система поиска аномалий и отправки уведомлений.

Из этого стэка при желании можно убрать Chronograf и Kapacitor, а вместо них взять Grafana. Она поддерживает просмотр метрик из Influxdb. TICK Stack архитектурно похож на мониторинг на базе Prometheus. Тот же набор компонентов - агент для метрик, база данных, веб интерфейс и уведомления.

📌 Основные отличия Prometheus от TICK Stack:

🔹Ключевое отличие скорее всего в языке запросов - InfluxQL против PromQL. Первый сильно похож на SQL, в то время как PromQL вообще ни на что не похож. Его придётся учить с нуля.
🔹InfluxDB полностью поддерживает хранение строк. То есть туда можно складывать и логи. Она нормально с ними работает.
🔹Подход сбора метрик у низ разный. Пром сам собирает метрики по модели pull, а TICK Stack получает их от агентов по модели push, которые сами отправляют данные.
🔹У InfluxDB есть коммерческая версия с готовым масштабируемым кластером.
🔹В среднем TICK Stack потребляет больше ресурсов, чем аналог стека на базе Prometheus.

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

# git clone https://github.com/influxdata/sandbox.git
# cd sandbox
# ./sandbox up

Будет поднято окружение по предоставленному docker-compose.yaml. У меня не запустился контейнер с Chronograf. Посмотрел его лог, ругается на то, что не хватает прав. Разбираться не стал, просто дал директориям chronograf/data права 777 и ещё раз запустил. Стэк поднялся полностью.

Chronograf запускается на порту 8888. Можно идти в веб интерфейс и смотреть, как там всё устроено. Примеры конфигов в соответствующих директориях в репозитории. По умолчанию Telegraf передаёт только метрики CPU и самой InfluxDB. Полная информация по деплою есть в документации.

Мониторинг TICK Stack ориентирован как на мониторинг контейнеров, в том числе кластеров Kubernetes и конечных приложений, так и непосредственно операционных систем. У Telegraf есть готовые плагины на все случаи жизни. Полный список можно посмотреть в документации. Чего там только нет. Поддерживаются все популярные системы, в том числе Windows. Можно, к примеру, собирать её логи. То есть система универсальна. Тут и мониторинг, и логи. Два в одном.

Из необычного, нашёл плагин для мониторинга за ютуб каналами - подписчики, просмотры, видео. Есть плагин мониторинга таймеров systemd, sql запросов в субд, атрибутов смарт через smartctl, гипервизора proxmox, плагин для сбора метрик с экспортеров прометеуса и много всего интересного. На вид система неплохо выглядит. Как на практике, не знаю. Я не использовал.

⇨ Сайт / Список плагинов

#мониторинг