Интересно было бы узнать чем именно вам не подошёл Заббикс. У них сейчас есть Заббикс Агент 2, написанный на Go. К нему можно прикручивать собственные плагины и в целом есть где развернуться.
Так а вы ваше решение поставляете в виде установочного пакета? У меня были задачки по настройке трейсинга php-fpm. Вам в любом случае придётся подцеплять SDK инструмента мониторинга — не чужого так своего (тем более оно у вас уже и так есть). Если не нравится облачность rollbar есть же и решения on-prem.
А как у вас реализован второй способ? Где хранится вся логика? Предположительно, она должна расти как снежный ком и всем этим нужно ещё пытаться управлять.
Спасибо за познавательную статью. Интересно было читать как вы прошли путь работы с событиями. Система выглядит интересной. Есть пара вопросов, первый по документации, второй по автоматизации.
1. Можете подробнее рассказать как у вас работает документации по событиям? Судя по скриншоту — это некий гитлаб. Правильно понял, что к каждому событию привязывается ссылка на гитлаб на основе лейбла или наборов лейблов события? Или дежурные сами выполняют поиск по гитлабу и ищут подходящий к событию документ?
2. А вы не делаете первичную диагностику по событиям, на которые должны реагировать дежурные? Ну, например, запускаете синтетическую проверку веб-интерфейса, смотрите хелс-чеки соседних сервисов, проверяете время отклика чего-нибудь, чтобы затем привязать эту информацию к событию, чтобы дежурный видел больше контекста.
В версии 7.0 уже и типы выведены из эксплуатации. Остались индексы и документы. По этой книге будет невозможно работать в 7 версии эластика. Книга «Machine Learning with the Elastic Stack» по мне так была бы более интересна.
Если систем мониторинга несколько (а обычно это так и бывает), события лучше обрабатывать (коррелировать, схлопывать и т.д.) во внешнем event consolidator (или зонтичной системе). Дополнительным плюсом будет единая точка интеграции с системой инцидент-менеджмента.
Ещё одна статья о лечении при следующих сиптомах событийной усталости:
вы не успеваете реагировать на все поступающие события;
вы не знаете на кого назначить полученные события;
вы не понимаете какая должна быть реакция на события;
вы считаете, что критичность события не соответствует действительности;
избыточные события утомляют дежурную группу (история про волки-волки, но потом они на самом деле пришли).
Мне известны кейсы перехода с платного ПО на другое платное, но подешевле. А вот чтобы с платного на бесплатное… не встречался с таким, но в природе, наверняка, случаи были. New Relic — классное решение, жаль, что в России не очень хорошо относятся к облачным системам, которые хостятся за пределами страны.
Некоммерческие проекты не могут попасть в квадрант по определению
Есть прогноз, что будет с Instana после того как их купил IBM?
А можно задать вам вопрос как специалисту по OSM? Что могли бы посоветовать для использования OSM в оффлайн-режиме? Есть ли вообще такая возможность?
А Elastic вы за SIEM не считаете?
Чота ни Grafana ни Zabbix в примерах не было. Про них тоже было бы интересно узнать.
Не совсем понял, а куда у вас отправляются данные после аналитики в Pandas? Где вы их потом разглядываете?
Интересно было бы узнать чем именно вам не подошёл Заббикс. У них сейчас есть Заббикс Агент 2, написанный на Go. К нему можно прикручивать собственные плагины и в целом есть где развернуться.
Основной вопрос к WLSDM один: можно ли автоматизировать постановку и снятие с мониторинга, а также управление конфигурацией при помощи кода.
1. Можете подробнее рассказать как у вас работает документации по событиям? Судя по скриншоту — это некий гитлаб. Правильно понял, что к каждому событию привязывается ссылка на гитлаб на основе лейбла или наборов лейблов события? Или дежурные сами выполняют поиск по гитлабу и ищут подходящий к событию документ?
2. А вы не делаете первичную диагностику по событиям, на которые должны реагировать дежурные? Ну, например, запускаете синтетическую проверку веб-интерфейса, смотрите хелс-чеки соседних сервисов, проверяете время отклика чего-нибудь, чтобы затем привязать эту информацию к событию, чтобы дежурный видел больше контекста.
Мониторим_ИТ — канал об инструментах мониторинга и подходах к нему. Для тех, кого нет в телеграме, есть сателлит на Медиуме.
Глава 4 Цели уровня обслуживания
Глава 6 Мониторинг распределённых систем
Ещё одна статья о лечении при следующих сиптомах событийной усталости: