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