Как в системе решали корреляцию событий? Если одновременно упали питание, серверы, сеть и несколько приложений, оператор получает один инцидент или десятки независимых тревог?
Использовалась ли CMDB или какая-то единая модель инфраструктуры? Или связи между объектами хранятся непосредственно в самописной системе?
Почему решили писать свою верхнеуровневую систему самостоятельно, а не посмотреть в сторону готовых решений для зонтичного мониторинга и корреляции?
Эх, а я думал тут сейчас будем расписано как вы эффективно использовали Codex и получили некую красоту.
В конфиге otel-коллектора я бы посоветовал добавить memory_limiter на случай всплесков данных или недоступности клика, а ещё batch-процессор можно передвинуть в конец (сначала фильтруем и обогащаем, потом батчим).
Поддерживаем, делали в iTop похожую логику. Только нужен хороший аналитик, как автор статьи. Ну, и в iTop такое будет не на уровне интерфейса администратора делаться, а на уровне xml кода.
Добрый день! Да, гибкость и бесплатность Grafana серьезные преимущества перед готовым коммерческим решением. В ITOps Board уже из коробки работает передача статуса сервисов от потомков к родителю и рассчитывается SLA на основе событий. Для реализации аналогичного функционала в Grafana нужно приложить определенные усилия плюс затем поддерживать этот кастом. Сравнение ITOps Board с Grafana похоже на сравнение PRTG c Zabbix — упирается в вопрос трудозатрат и денег.
Как-то вы жестко все усложнили. В настройках хоста в Zabbix можно выбрать один или несколько вариантов подключения. Без шифрования тоже можно.
Несколько вопросов:
Как в системе решали корреляцию событий? Если одновременно упали питание, серверы, сеть и несколько приложений, оператор получает один инцидент или десятки независимых тревог?
Использовалась ли CMDB или какая-то единая модель инфраструктуры? Или связи между объектами хранятся непосредственно в самописной системе?
Почему решили писать свою верхнеуровневую систему самостоятельно, а не посмотреть в сторону готовых решений для зонтичного мониторинга и корреляции?
StatsHouse, конечно, хорошо, но не думали о переезде на ClickStack. Он поинтереснее будет.
Спасибо за статью! А можете в одной из следующих рассказать как вы ужимаете данные Observability? Или пока этим вопросом не занимались?
Спасибо за статью. А ELK решили оставить или будет продолжение?
Эх, а я думал тут сейчас будем расписано как вы эффективно использовали Codex и получили некую красоту.
В конфиге otel-коллектора я бы посоветовал добавить memory_limiter на случай всплесков данных или недоступности клика, а ещё batch-процессор можно передвинуть в конец (сначала фильтруем и обогащаем, потом батчим).
Лучше бы Grafana Alloy вместо Promtail. Последний уже EOL.
В верхней части статьи честно написано, что это перевод и указана ссылка на источник. А что не так?
Смотря с какой версии на какую. Берите свою БД, делаете реплику и проводите апгрейд с одновременным замером времени апгрейда.
А вот тут недавно было про открытые системы. Еще iTop неплох, он тоже бесплатный.
Да лучше в новой статье расскажите о тонкой настройке и конкретных кейсах.
а где же легендарный iTop от Combodo? Публиковали о нем статью на Хабре по части интеграции с Zabbix
Ну и в самом ELK тоже можно трейсы хранить
Поддерживаем, делали в iTop похожую логику. Только нужен хороший аналитик, как автор статьи. Ну, и в iTop такое будет не на уровне интерфейса администратора делаться, а на уровне xml кода.
Посмотрите в сторону Keep (keephq.dev)
Из бесплатных неплохая еще iTop (используем ее в качестве CMDB и визуализации сервисно-ресурсной модели)
Реализуется при помощи рескоринга https://www.elastic.co/guide/en/elasticsearch/reference/8.15/filter-search-results.html#rescore
Servicetrace поставляется в виде платформы, в которой можно исполнять роботов и от перечисленных вами систем. Это их ключевое отличие.
https://gals.software/#solutions_fmain — вот правильная ссылка. Странно, что # пропала из ссылки.
Добрый день! Да, гибкость и бесплатность Grafana серьезные преимущества перед готовым коммерческим решением. В ITOps Board уже из коробки работает передача статуса сервисов от потомков к родителю и рассчитывается SLA на основе событий. Для реализации аналогичного функционала в Grafana нужно приложить определенные усилия плюс затем поддерживать этот кастом. Сравнение ITOps Board с Grafana похоже на сравнение PRTG c Zabbix — упирается в вопрос трудозатрат и денег.