Комментарии 15
Подпишусь под мыслью, что никакие графики не заменят хороший, вовремя отправленный алерт. Всегда стоит начинать с алертов, и затем уже добавлять графики по желанию.
Бывало, что график есть, мы на него посматриваем, мы спокойны. Но забыли о том, что алерт так и не настроен. Как закономерность — поломку просмотреть проще простого.
Простите :), не могу не упомянуть https://github.com/balerter/balerter
Мы создали у себя этот инструмент как раз для тонкой настройки алертов. Когда появилась необходимость не только по временнЫм рядам делать анализ, но и по данных из различных БД, из логов (loki) и тд;
У инженеров не возникает трудностей в написании скриптов? Не бывает ситуаций, когда плохо написанный скрипт аффектит производительность?
Я одно время искал что-то подобное, но пришел к тому, что людям обычно лень писать скрипты, нужен гуй, особенно на этапе передачи проекта из развертывания в поддержку и сопровождение
С написанием проблем не возникает, так как пишут те, кто умеет писать в общем то. С проблемами производительности тоже не сталкиваемся, так как скрипты выполняются не "каждую секунду".
GUI хорошо. Но когда мы столкнулись с кейсами, где для принятия решения об алерте надо получить инфо из prometheus, clickhouse и postgres, вот тут такой проект и родился. Потому и только скрипты. Что, в общем-то, не отменяет возможности приделать к balerter какой-то GUI для создания скриптов)
В тоже время, очень важно иметь мониторинг резервных каналов или нод т.к. за месяцы и годы эксплуатации резерв может сам по себе выйти из строя и в нужный момент подведет.
Так же рекомендую 7 раз подумать об уровнях тревоги, если уровень катастрофа, то то это реально должна быть катастрофа, а не повисший сервис. Низкая чувствительность событий по началу будет доставлять, но со временем начнутся восприниматься как спам, и реально критичное событие(ошибка чтения/записи диска) будет проигнорировано. И уж точно раз 20 подумать, какие сообщения и в какое время следует отправлять по СМС.
Метрик лучше собирать больше. Если это не очень дорого по деньгам выходит.
Отправляются и пусть отправляются, лежат себе в бд и пусть лежат. Есть не просят, никому не мешают.
Когда они понадобятся для поиска редкой ошибки собрать метрики за прошлое уже не выйдет.
Я не про обычную отладку. А скорее про поиск аномалий. Когда очень хочется посмотреть а не было ли чего-то похожего раньше? И если посмотреть некуда это очень обидно и заметно затрудняет поиск.
В вашем примере, как мне кажется, метрики портов можно группировать по номерам портов и вынести на отдельный дашборд.
К тому же, как уже заметили, заранее не предугадать, пригодится ли та или иная метрика, и когда, а потому, уж лучше пусть они будут. Тут как у самураев — если меч понадобится один раз, ты будешь носить его всю жизнь.
А с позицией по алертингу полностью согласен — только строгая организация, только тонкая настройка.
Итак, вы решили создать систему мониторинга. Первым шагом предлагаю задуматься о том какие метрики собирать:
Нужно задуматься не об этом, а о том с чего собирать, в контексте какие у Вас ОС и железо. Ну например у Вас AIX и Oracle, да случай наверно редкий, еще более редкое IBM zSeries, но оно есть. И зная это у вас резко, причем прям реально резко сокращается круг решений, сразу отпадает например прометей. Ну что остается сами догадайтесь.
Так что начинать нужно не с того что хочется, а с того что есть у Вас и что потенциально может быть.
Такое хорошее начало было у статьи… А потом все скатилось опять в "инженерный мониторинг". Это не плохо, но оно не дает на самом деле понимания реального положения дел. Простой пример из жизни — по всем метрикам почтовый сервер работает, а почта во вне не ходит — накосячили с spf. По итогу, пока разбирались, получили кучу претензий. А ведь достаточно было сделать простую проверку функции — отправлять письмо и проверять что оно дошло.
Таких историй огромное количество...
Но вы правы, тема не раскрыта, постараюсь затронуть её в дальнейшем
А ведь еще бизнес-мониторинг, где еще и бабки привязаны к процессам =)
Но тут очень тонкая грань проходит:
Есть метрики работоспособности бизнес-процессов — это «иженерный мониторинг». Тут задача состоит в обеспечении функционирования бизнеса.
А есть бизнес-метрики — данные о продажах, притоку/оттоку клиентов, графики выручки и прочее. Это зона BI-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».
Вторую категорию я не рассматриваю — нет релевантного опыта.
Вот уже четвертый год я занимаюсь организацией того, что принято называть Observability
Но при этом, пишите, что мониторинг — это сбор, хранение, визуализация метрик и получения по ним алертов.
Это же совсем не так.
Observability подход — это сбор метрик, сбор трейсов приложения, логов и предоставления контекста данных. И ко всему прочему, observability это про автоматизацию процесса мониторинга.
Зачем «изобретать велосипед», когда уже есть готовые решения? Например платформа Instana, недавно про нее писали — habr.com/ru/company/proto/blog/530158
Давайте обсудим мониторинг