Комментарии 17
в центре не кафка, жестко
Круто! Можно короткое описание сценариев/функциональности и пару картинок по интеграциям?
Мы интегрировали Zabbix с мессенджером Telegram и Microsoft Teams, активно используемыми в командах
На данный момент у нас реализован телеграмм-бот, сценарии пока достаточно простые, например: активация бота, отобразить список доступных команд, показать активные проблемы, агрегированный отчёт по проблемам продукта. В перспективе планируем сделать полноценный сервис для команд и всех заинтересованных, который будет включать такой функционал, как:
Что хотели бы видеть на картинках?
- Сервис подписки на алерты с выбором информационной системы и интересующих алертов;
- Сервис отчётности по состоянию информационной системы
- Сервис real-time проверок с возможностью выбора состава проверок.
Что хотели бы видеть на картинках?
А такой вопрос. Оценочно, сколько человеко-времени ушло на создание и допиливание этой впечатляющей системы мониторинга? Ну, если не секрет, конечно. Человеко-год?
У нас масса идей и планов по развитию и допиливанию системы, сейчас мы ещё в начале пути, так что всё самое интересное впереди. Фактически, если отбросить проработку концепта, административных вопросов и прочего, то работы стартовали в начале года. Посчитать конкретно в людях не так просто сходу, т.к. у нас работы включают не только развитие системы и ядра, но и ещё большой объём работ по аналитике, сбору метрик, настройке алертов, проработке инструментов и прочее.
И если нужно провести технические работы, и мы что-то принудительно отключаем, их число вырастает в разы.
Чтобы этого избежать в Zabbix предусмотрена замечательная возможность «Обслуживание», в которой можно задать период недоступности и соотвествующие группы сервисов. Пока активен период обслуживания алерты отправляться не будут.
Кем мониторинг используется? Направлением эксплуатации? Что происходит в рамках реагирования на отдельно взятую проблему, кто подключается к решению проблемы? Как это помогает разработчикам?
Кем мониторинг используется? Направлением эксплуатации?
Мониторинг\данные мониторинга используется:
- Эксплуатацией
- Командами
- Бизнес-заказчиками
Что происходит в рамках реагирования на отдельно взятую проблему, кто подключается к решению проблемы?
К решению проблемы подключается круглосуточная тех.поддержка по переданным алертам или непосредственный ответственный за устранение проблемы, если это возможно однозначно определить. Алертами на этапе отладки, подготовки инструкций, узкоспециализированными алертами занимается эксплуатация. Помимо этого, у нас есть отдельные каналы коммуникации для команд с интересующими их алертами по их системе\системам.
Как это помогает разработчикам?
Даёт понимание командам о том, что происходит с их системой. Особенно это важно в том случае, когда причина проблемы и её устранение находится вне зоны ответственности команды.
Вы хорошо описали свою подход реализации комплексной системы мониторинга приложений и получаемый сейчас эффект от созданного ее ядра. В эксплуатацию идут алерты не только от вашей системы, но и от других локальных систем мониторинга. Вы собираетесь стать зонтиком над ними? Кстати, среди перечисленных задач мониторинга не было мониторинга проблем пользователей системы, чья это задача? В частности всегда ли выявляемые проблемы в приложениях и инфраструктуре, алерты ощущаются пользователями, и наоборот ухудшение характеристик у пользователей коррелируются с алертами?
В эксплуатацию идут алерты не только от вашей системы, но и от других локальных систем мониторинга. Вы собираетесь стать зонтиком над ними?
На текущий момент у нас есть небольшая часть алертов, которые к нам поступают не из нашей системы мониторинга, а из сторонней, например, когда отправка алерта настроена на стороне самого приложения. Это некоторое «легаси», оставшееся со времён, когда централизованной системы мониторинга ещё не было. Выход из таких ситуаций — получение метрик в нашу систему (API\prometheus\логи...) и настройка алерта на стороне нашей системы.
Кстати, среди перечисленных задач мониторинга не было мониторинга проблем пользователей системы, чья это задача?
Если я правильно понял вопрос, то проблемы у пользователей у нас отлавливаются на уровне бизнес-метрик и UI (указано на одном из изображений в статье).
В частности всегда ли выявляемые проблемы в приложениях и инфраструктуре, алерты ощущаются пользователями, и наоборот ухудшение характеристик у пользователей коррелируются с алертами?
Проблемы в приложении и инфраструктуре не всегда ощущаются пользователями. Например, недоступность 1 из 4 нод в кластере БД — это проблема, но пользователь её не заметит, т.к. оставшиеся 3 держат нагрузку и никакой деградации при этом нет.
Если смотреть со стороны пользователей, то ситуация похожа и также не всегда может коррелировать с проблемами приложения и инфраструктуры. Например, мы можем наблюдать резкий спад пользователей через несколько минут после того, как заканчивается какая-то промо-акция :)
Спасибо. Интересная статья. С точки зрения мониторинга вы правильно выбрали и красиво реализовали ключевые задачи. И точно сформулировали задачи системы на перспективу: Корреляция событий в разных слоях, Root cause analysis и визуализация возможных первопричин (это не обязательно один алерт), возможно еще автоматически запускаемые действия по отработке определенных событий. Тяжелые и трудоемкие задачи.
«На текущий момент у нас есть небольшая часть алертов, которые к нам поступают не из нашей системы мониторинга, а из сторонней, например, когда отправка алерта настроена на стороне самого приложения. Это некоторое «легаси», оставшееся со времён, когда централизованной системы мониторинга ещё не было. Выход из таких ситуаций — получение метрик в нашу систему (API\prometheus\логи...) и настройка алерта на стороне нашей системы.»
Используемые другими отделами сторонние продукты мониторинга, могут иметь функционал, который вам не имеет смысл реализовывать у себя, в частности собирать низкоуровневые метрики, важные для проактивности на их уровне, формировать соответствующие алерты. Вы уверены, что должны все затягивать в свою систему? Например на уровнях ИБ, сети, VDI? Нужно ли все их заменять собой или достаточно учитывать ключевые метрики, существенные для корреляции и алертов чек-листа?
«На текущий момент у нас есть небольшая часть алертов, которые к нам поступают не из нашей системы мониторинга, а из сторонней, например, когда отправка алерта настроена на стороне самого приложения. Это некоторое «легаси», оставшееся со времён, когда централизованной системы мониторинга ещё не было. Выход из таких ситуаций — получение метрик в нашу систему (API\prometheus\логи...) и настройка алерта на стороне нашей системы.»
Используемые другими отделами сторонние продукты мониторинга, могут иметь функционал, который вам не имеет смысл реализовывать у себя, в частности собирать низкоуровневые метрики, важные для проактивности на их уровне, формировать соответствующие алерты. Вы уверены, что должны все затягивать в свою систему? Например на уровнях ИБ, сети, VDI? Нужно ли все их заменять собой или достаточно учитывать ключевые метрики, существенные для корреляции и алертов чек-листа?
Используемые другими отделами сторонние продукты мониторинга, могут иметь функционал, который вам не имеет смысл реализовывать у себя, в частности собирать низкоуровневые метрики, важные для проактивности на их уровне, формировать соответствующие алерты. Вы уверены, что должны все затягивать в свою систему? Например на уровнях ИБ, сети, VDI? Нужно ли все их заменять собой или достаточно учитывать ключевые метрики, существенные для корреляции и алертов чек-листа?
Всё правильно, всё подряд затягивать в нашу систему не имеет смысла. Состав затягиваемых метрик, в случае, если система эксплуатируется нами (инциденты\работа с алертами и прочее), состоит из определённых нами ключевых метрик + метрики, которые предоставит команда с расшифровкой их значимости.
Если система нами не эксплуатируется или же команда хочет собирать какие-то низкоуровневые метрики для себя, то мы предоставляем мониторинг, как сервис. В этом случае проработка метрики, условие алерта и обработка алерта ложится на заказчика:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторим Спортмастер — как и чем