Size: a a a

Мониторинг

2021 June 10

AE

Ant0n Erem1n in Мониторинг
​​Существует простой и легкий мониторинг Monit. Проекту очень много лет. Я знал его, когда только начинал администрировать. Тем не менее, он развивается и живет своей жизнью. Есть в системных репах популярных дистрибутивов.

https://mmonit.com/monit/
https://bitbucket.org/tildeslash/monit/

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

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

 check process postfix with pidfile /var/spool/postfix/pid/master.pid
  start program = "systemctl start postfix"
  stop program = "systemctl stop postfix"
  if cpu > 60% for 2 cycles then alert
  if cpu > 80% for 5 cycles then restart
  if totalmem > 200.0 MB for 5 cycles then restart
  if children > 250 then restart
  if loadavg(5min) greater than 10 for 8 cycles then stop
  if failed host INSERT_THE_RELAY_HOST port 25 type tcp protocol smtp
    with timeout 15 seconds
   then alert
  if 3 restarts within 5 cycles then timeout

Управляется Monit через веб интерфейс и конфиги. Для работы нужна база данных. В простом варианте это может быть SQLite. Для одиночного хоста хватает за глаза. Например, для веб сервера, чтобы автоматом поднимать упавший apache или php-fpm.

Мониторинг для тех, кто устал (это про меня) от всяких модных штук, yaml конфигов, докеров, jsonoв и вот этого всего хипстерского. Кто просто хочет мониторить свой локалхост, получать алерты, перезапускать сервисы, когда они падают. И при этом тратить минимум ресурсов. Писать понятные конфиги без учёта отступов, пробелов, скобок.

Есть еще те, кто использует Monit?

#мониторинг
источник

А

Артём in Мониторинг
Для локалхоста, действительно, то что нужно
источник

D

Dan in Мониторинг
На чем делать бэк, может ктото подскажет, надо соорудить себе узкоспециализированый гипотетически высоконагруженый мониторинг коллектор -> тут чтото mq/db/логика->фронт, вот как бы уменьшить пересылку однотипных данных, предполагается пакетная засылка. Вопрос в выборе mq/db
источник

AE

Ant0n Erem1n in Мониторинг
смотря какой у вас стек технологий
источник

D

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

AE

Ant0n Erem1n in Мониторинг
вы хотите сделать свою систему мониторинга?
источник

AE

Ant0n Erem1n in Мониторинг
источник

D

Dan in Мониторинг
Да, она будет заточена исключительно под свои нужды, есть концепт с визуализацией. Швейцарский нож на все случаи не нужен.
источник

AE

Ant0n Erem1n in Мониторинг
ну так расскажите про свои нужды
источник

D

Dan in Мониторинг
Спасибо
источник

AE

Ant0n Erem1n in Мониторинг
у вас веб сервис?
источник

D

Dan in Мониторинг
Ну если коротко там визуализация которую не смог получить в заббиксе и графане
источник

D

Dan in Мониторинг
+ обратная связь для управления
источник

D

Dan in Мониторинг
- лишнее
источник

D

Dan in Мониторинг
Сугубо узконаправленая штука, для чего не хочу говорить пока не сдеоаем. Есть чтото типа pOc а на коленке
источник

D

Dan in Мониторинг
Вроде зашло
источник

D

Dan in Мониторинг
Теперь надо по нормальному архитектуру придуматт
источник

AE

Ant0n Erem1n in Мониторинг
вы раньше архитектуры придумывали для сервисов?
источник

AV

Aliaksandr Valialkin in Мониторинг
онлайн-трансляция с big monitoring meetup в Питере - https://www.youtube.com/watch?v=mkg_mCAW81Y
источник

AE

Ant0n Erem1n in Мониторинг
#машины_разное

Однажды я спросил у кандидата про отличие между мониторингом (monitoring) и наблюдаемостью (observability). Не получив удовлетворительного ответа, я позже поинтересовался у своих коллег-приятелей - и оказалось, что тема непрозрачная и не до конца понятная.

Оно и очевидно, observability попала в “тренды” незадолго после появления eBPF, и к кому бы не сходить за ее определением, как к одному из пионеров индустрии… Однако, получаем больше вопросов, чем ответов.

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

Отличий как таковых и нет - наблюдаемость дополняет мониторинг. Если мониторинг опирается на определенные метрики, глядя на которые можно понять, как чувствует себя программный продукт, в инструментарий observability еще входят обработка логов и отслеживание запросов (tracing).

Что позволяет “наблюдать” не только за одной системой, но и ее связкой с остальными.
источник