У vmagent, vlagent и vtagent есть параметр -remoteWrite.rateLimit, который ограничивает поток данных на эндпоинт. Его как раз можно использовать после восстановления работы бэкэнда. В Vector есть возможность настройки условий "не более 5 запросов в секунду", "не более 2 одновременных запросов" и "до 1 MiB несжатых данных в одном полном batch". И у него есть еще одна фича — Adaptive Request Concurrency, который уже смотрит на задержку бэкэнда. Остальные агенты прямых ограничений не имеют.
Спасибо за ваше замечание, дополнил статью информацией по этому поводу.
Как в системе решали корреляцию событий? Если одновременно упали питание, серверы, сеть и несколько приложений, оператор получает один инцидент или десятки независимых тревог?
Использовалась ли CMDB или какая-то единая модель инфраструктуры? Или связи между объектами хранятся непосредственно в самописной системе?
Почему решили писать свою верхнеуровневую систему самостоятельно, а не посмотреть в сторону готовых решений для зонтичного мониторинга и корреляции?
Эх, а я думал тут сейчас будем расписано как вы эффективно использовали Codex и получили некую красоту.
В конфиге otel-коллектора я бы посоветовал добавить memory_limiter на случай всплесков данных или недоступности клика, а ещё batch-процессор можно передвинуть в конец (сначала фильтруем и обогащаем, потом батчим).
Поддерживаем, делали в iTop похожую логику. Только нужен хороший аналитик, как автор статьи. Ну, и в iTop такое будет не на уровне интерфейса администратора делаться, а на уровне xml кода.
У vmagent, vlagent и vtagent есть параметр
-remoteWrite.rateLimit, который ограничивает поток данных на эндпоинт. Его как раз можно использовать после восстановления работы бэкэнда. В Vector есть возможность настройки условий "не более 5 запросов в секунду", "не более 2 одновременных запросов" и "до 1 MiB несжатых данных в одном полном batch". И у него есть еще одна фича — Adaptive Request Concurrency, который уже смотрит на задержку бэкэнда. Остальные агенты прямых ограничений не имеют.Спасибо за ваше замечание, дополнил статью информацией по этому поводу.
Эх, жаль, что вас опередил d-pub.ru
Как-то вы жестко все усложнили. В настройках хоста в 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 поставляется в виде платформы, в которой можно исполнять роботов и от перечисленных вами систем. Это их ключевое отличие.