Внедрение мониторинга и системы оповещений
Система мониторинга помогает отслеживать поведение инфраструктуры и приложений и определить приемлемые диапазоны производительности и надежности. Понимая, какие компоненты отслеживать и на каких метриках сосредоточиться в том или ином сценарии, вы можете приступить к планированию стратегии мониторинга, которая охватывает все критические аспекты сервисов. В статье Сбор метрик инфраструктуры и приложений вы изучили популярную структуру для определения важных метрик, а также узнали, какие данные собирать на разных этапах и уровнях.
В этой статье вы узнаете, из каких компонентов состоит система мониторинга и как использовать их для реализации своей стратегии. Определив основные обязанности эффективной и надежной системы мониторинга, вы сможете понять, как элементы этой системы выполняют эти функциональные требования. Также мы поговорим о том, как лучше всего перенести политики мониторинга в дашборды и политики предупреждений, которые предоставят вашей команде необходимую информацию о важных событиях в системе.
Важные качества системы мониторинга и отправки оповещений
В одном из заключительных разделов статьи Основы мониторинга и сбора метрик мы обсудили некоторые из наиболее важных качеств эффективной системы мониторинга. Чтобы лучше понимать работу основных компонентов этих систем, полезно проанализировать характеристики, которые ранее мы определили как полезные или необходимые:
- Независимость от большинства других инфраструктур: для точного сбора данных и предотвращения негативного воздействия на производительность большинство компонентов мониторинга должны использовать выделенные ресурсы отдельно от других приложений.
- Надежность: поскольку мониторинг используется для оценки состояния здоровья других систем, важно убедиться, что сама система мониторинга работает правильно.
- Простота сведения данных и получения подробного вывода: данные не принесут пользы, если они не понятны или их мало. Возможность объединять данные и получать более подробную информацию о тех или иных областях невероятно ценна в ходе исследований поведения системы.
- Эффективная стратегия сохранения истории: чтобы быстро распознавать аномалии, важно выучить их типичные шаблоны. Со временем вам может потребоваться доступ к более старым данным, потому система должна иметь возможность хранить и извлекать их.
- Возможность корреляции факторов из разных источников: организованное отображение информации из разных частей развертывания очень важно для выявления шаблонов и общих факторов.
- Простота добавления новых метрик или инфраструктур: система мониторинга должна развиваться по мере изменения приложений и инфраструктуры. Если система мониторинга не изменяется или охватывает не все приложения, это снижает доверие к данным.
- Гибкая и мощная система оповещений: эта система должна обеспечивать отправку уведомлений по различным каналам в зависимости от приоритета события и условий.
Компоненты системы мониторинга
Системы мониторинга состоят из нескольких различных компонентов и интерфейсов, которые работают вместе, чтобы собирать и визуализировать метрики, сообщать о работоспособности развертывания и т.п. Ниже мы рассмотрим основные компоненты этой системы.
Распределенные агенты мониторинга и экспортеры данных
Основная часть системы мониторинга может быть развернута на выделенном сервере, но данные об инфраструктуре должны собираться из разных источников. Для этого на каждой отдельной машине по всей сети устанавливается агент мониторинга – небольшое приложение, предназначенное для сбора и пересылки данных в централизованную точку хранения. Эти агенты собирают статистику и показатели использования ресурсов тех хостов, на которых они установлены, и отправляют их на центральное программное обеспечение мониторинга.
Агенты работают как демоны на каждом хосте в системе. Они могут поддерживать базовую конфигурацию для надежной аутентификации с удаленной конечной точкой данных, определять частоту данных или политику выборки и устанавливать уникальные идентификаторы хостов. Чтобы уменьшить влияние на другие сервисы, агент должен использовать минимальное количество ресурсов и иметь возможность работать практически без управления. В идеале, установить агент на новой ноде и начать отправлять метрики в центральную систему мониторинга должно быть очень просто.
Агенты мониторинга обычно собирают общие метрики уровня хоста, но также бывают агенты для мониторинга программного обеспечения (например, веб-серверов или серверов баз данных). Однако данные большинства специализированных типов программного обеспечения необходимо собирать и экспортировать либо путем изменения самого программного обеспечения, либо путем создания собственного агента (через создание сервиса, который анализирует конечные точки состояния программы или записи логов). Многие популярные средства мониторинга имеют библиотеки, позволяющие упростить добавление пользовательских инструментов. Как и в случае с агентами, необходимо свести к минимуму воздействие пользовательских сервисов на систему – они не должны влиять на здоровье или производительность приложений.
До сих пор мы говорили об архитектуре продвижения, в которой агенты загружают собранные данные в центральное место хранения. Но бывают также системы с архитектурой извлечения. В таких системах мониторинга отдельные хосты отвечают за сбор, агрегирование и обслуживание метрик в заданном формате в доступной конечной точке. Сервер мониторинга проверяет конечную точку метрики на каждом хосте и собирает данные. Программное обеспечение, которое собирает и представляет данные через конечную точку, имеет много общих требований с агентами, но проще в конфигурации, поскольку ему не нужно знать, как общаться с другими машинами.
Вхождение метрик
Одной из самых загруженных частей системы мониторинга является компонент вхождения метрики. Поскольку данные генерируются постоянно, процесс сбора данных должен быть достаточно ошибкоустойчивым для обработки большого объема задач и координации с уровнем хранения для правильной записи входящих данных.
В системах продвижения конечной точкой входа метрик является централизованное место в сети, туда отправляет свои собранные данные каждый агент мониторинга или агрегатор статистики. Конечная точка должна иметь возможность одновременно аутентифицировать и принимать данные с большого количества хостов. Конечные точки вхождения метрик часто распределяют нагрузку, что обеспечивает ошибкоустойчивость и обработку больших объемов трафика.
В системах с архитектурой извлечения соответствующий компонент представлен механизмом опроса, который охватывает и анализирует конечные точки метрик на отдельных хостах. Он имеет примерно такие же требования, но некоторые функции представлены наоборот. Например, если отдельные ноды реализуют аутентификацию, процесс сбора метрик должен иметь возможность предоставить правильные учетные данные для входа в систему и доступа к защищенной конечной точке.
Уровень управления данными
Уровень управления данными отвечает за организацию и запись входящих данных из компонента входа и за ответ на запросы от административных уровней. Данные метрик обычно записываются в формате временного ряда, который представляет изменения во времени. Базы данных временных рядов – это базы данных, которые специализируются на хранении и организации данных такого типа, они часто используются в системах мониторинга.
Основной задачей уровня управления данными является сохранение входящих данных по мере их получения или сбора с хостов. Как минимум, уровень хранения должен сохранять полученные метрики, их значения, время создания значения и данные о хосте, к которому относится это значение.
Чтобы хранить данные в течение более продолжительного периода времени, уровень хранения должен обеспечивать экспорт данных, когда набор превысит локальные ограничения обработки, памяти или хранения. Соответственно, уровень хранения также должен иметь возможность импортировать данные, чтобы использовать историю данных системы, когда это необходимо.
Уровень управления данными также должен обеспечивать организованный доступ к сохраненной информации. Для систем, использующих базы данных временных рядов, эта функциональность обеспечивается встроенными языками запросов или API. Они могут использоваться для интерактивного опроса и исследования данных, но основными потребителями этой информации, вероятно, будут дашборды для визуализации данных и система оповещения.
Уровень визуализации
На уровне управления данными основаны интерфейсы, которые помогают пользователю понять собираемые данные. Поскольку метрики выражаются данными временных рядов, такие данные лучше всего визуализировать в виде графика со временем по оси х. Это позволяет легко понять, как значения меняются во времени. Метрики можно визуализировать в разных временных масштабах, чтобы проследить тенденции в течение длительных периодов времени, а также выявить последние изменения, которые могут повлиять на работу системы в настоящее время.
Уровни визуализации и управления данными позволяют накладывать данные с разных нод или из разных частей стека приложений и получать их целостное представление. Данные временных рядов обеспечивают согласованный масштаб, который помогает обнаружить события или изменения, которые происходят одновременно. Интерактивное наложение данных позволяет операторам визуализировать метрики наиболее удобным образом.
Наиболее часто используемые графики и данные часто организуются в дашборды. Дашборды обеспечивают непрерывное представление текущих метрик и могут использоваться для устранения неполадок или глубокого изучения определенных областей вашей системы. Например, дашборд с подробной разбивкой мощности физических хранилищ может пригодиться при планировании ресурсов, но никак не поможет в ежедневном администрировании системы. Общие и специализированные дашборды мониторинга помогут эффективнее использовать данные.
Система оповещений и настройка порогов
Графики и дашборды помогают разобраться с данными системы, но они полезны только тогда, когда администратор системы просматривает страницу. Одной из важнейших функций системы мониторинга является освобождение членов команды от постоянного активного наблюдения за системой. Чтобы минимизировать вмешательство человека в работу, система должна быть в состоянии привлечь внимание оператора в момент, когда это действительно необходимо. Для этого системы мониторинга используют определяемые пользователем пороговые значения и системы оповещения.
Целью системы оповещений является своевременное уведомление операторов о важных событиях или критических изменениях в данных. Поскольку для этого требуется, чтобы система понимала, что считается значительным событием в конкретной системе, вы должны определить свои критерии оповещения. Определения оповещений включают методы уведомлений и пороговые значения, на основе которых система непрерывно оценивает входящие данные. Пороги обычно определяют максимальное или минимальное среднее значение для той или иной метрики за определенный период времени, а метод уведомления описывает, как отправить предупреждение.
Одним из самых сложных аспектов системы оповещений является поиск баланса, который позволит вам вовремя реагировать на проблемы и при этом не перегружать операторов уведомлениями. Для этого вам нужно понять, какие метрики являются лучшими показателями реальных проблем, какие проблемы требуют немедленного внимания, какие методы уведомления лучше всего подходят для разных сценариев. Для этого язык определения порога должен быть достаточно мощным, чтобы адекватно описать ваши критерии. Аналогично, система уведомлений должна предлагать разные методы связи для проблем разного приоритета.
Мониторинг «черного ящика» и «белого ящика»
Теперь вы знаете, как работают и за что отвечают различные части системы мониторинга. Давайте поговорим о способах определения пороговых значений и оптимизации настройки предупреждений.
Мониторинг «черного ящика» и «белого ящика» – это разные модели мониторинга. Они не являются взаимоисключающими, поэтому системы часто комбинируют их, чтобы использовать преимущества каждой из моделей.
Мониторинг «черного ящика» – это определение оповещений или графиков, основанное только на внешне видимых факторах. Эта модель мониторинга берет внешнюю перспективу за основу, что позволяет сосредоточиться на публичном поведении вашего приложения или сервиса. Не зная ничего о состоянии базовых компонентов, мониторинг «черного ящика» предоставляет данные о функциональности системы с точки зрения пользователя. Это позволяет определить проблемы, которые активно влияют на пользовательский опыт клиентов, потому о таких проблемах важно оповещать операторов.
Альтернативная модель – мониторинг «белого ящика» – также невероятно полезна. Мониторинг «белого ящика» собирает внутреннюю информацию о вашей инфраструктуре. Поскольку количество внутренних процессов значительно превышает внешние процессы, часто в системе мониторинга данные «белого ящика» количественно доминируют над данными «черного ящика». Эта модель работает с более полной информацией о ваших системах, потому мониторинг «белого ящика» позволяет строить прогнозы. Например, отслеживая изменения в использовании ресурсов, он может уведомить вас, когда вам может понадобиться масштабирование определенных сервисов.
«Черный» и «белый ящик» – это просто способы классифицировать различные типы перспектив в системе. Имея доступ к данным «белого ящика», вы можете изучать внутренние проблемы, оценивать основные причины их возникновения. С другой стороны, мониторинг «черного ящика» помогает быстро выявить серьезные проблемы в работе приложения, сразу продемонстрировав влияние этой проблемы на пользователя.
Приоритет и типы уведомлений
Отправка предупреждений и уведомлений является одной из наиболее важных частей системы мониторинга. Без уведомлений о важных изменениях команда не будет знать о событиях, влияющих на работу системы. Операторам придется постоянно следить за дашбордами, чтобы оставаться в курсе событий. С другой стороны, избыточное количество уведомлений о неважных событиях с высоким процентом ложных срабатываний может принести больше вреда, чем пользы.
В этом разделе мы поговорим о разных уровнях уведомлений и о том, как наилучшим образом использовать их для максимальной эффективности мониторинга. Также мы обсудим некоторые критерии приоритета событий.
Пейджер
Начнем с предупреждений с наивысшим приоритетом. Пейджеры представляют уведомления, которые пытаются в срочном порядке обратить внимание на критическую проблему с системой. Эта категория предупреждений должна использоваться для серьезных ситуаций, требующих немедленного вмешательства. Системе оповещения требуется надежный способ связаться с людьми, несущими ответственность за решение этой проблемы.
Уведомления пейджеров нужно хранить для решения критических проблем с вашей системой. Это самые важные предупреждения, которые посылает ваша система, их нельзя игнорировать. Чтобы обеспечить реакцию оператора на проблему, системы оповещения часто включают возможность уведомлять другого человека или группу, если первая страница не подтверждается в течение определенного периода времени.
Поскольку пейджеры по своей природе невероятно разрушительны, их следует использовать экономно: только тогда, когда становится ясно, что существует оперативно неприемлемая проблема. Часто они привязываются к методам «черного ящика».
Вторичные уведомления
Следующий уровень приоритетности – это вторичные уведомления, к которым относятся электронные письма и билеты. Они призваны постоянно напоминать о том, что операторы должны исследовать развивающуюся ситуацию. В отличие от оповещений пейджеров, уведомления не сообщают о необходимости немедленных действий, поэтому они обычно обрабатываются персоналом по мере поступления, а не пытаются добиться срочного ответа от оператора. Если в вашей команде нет постоянно работающих администраторов, уведомления должны отправляться в ситуациях, которые могут подождать до следующего рабочего дня.
Билеты и электронные письма, созданные системой мониторинга, позволяют операторам понять, на какой задаче они должны сосредоточиться в ближайшее время. Поскольку уведомления не должны использоваться для извещения о критических проблемах, которые влияют на производительность в настоящее время, они часто привязываются к индикаторам «белого ящика»: это позволяет прогнозировать или идентифицировать возникающие проблемы, которые необходимо будет решить в ближайшее время.
В других случаях оповещения могут отслеживать те же действия, что и пейджеры, но им устанавливаются более низкие, менее критические пороговые значения. Например, вы можете настроить отправку уведомления, когда в течение определенного периода времени немного вырастает задержка приложения, а пейджер будет сообщать, когда задержка увеличивается сильно.
В целом уведомления наиболее подходят в ситуациях, которые требуют вмешательства, но не представляют непосредственной угрозы стабильности работы системы. Они должны привлечь внимание к проблеме, чтобы команда могла исследовать и смягчать ошибки, прежде чем они станут критичными.
Информация логов
Иногда вам может понадобиться информация о конкретном поведении, но при этом не нужно призывать операторов к немедленным действиям. Технически это не предупреждения: в подобных ситуациях может быть полезно установить пороговые значения, которые будут просто записывать информацию в логи или файлы, после чего данные будут использоваться в дашбордах системы мониторинга. Это позволяет предоставить оператору скомпилированную информацию, которая пригодится в исследовании проблемы и может сократить количество запросов для сбора сведений о проблеме.
Эта стратегия имеет смысл только для сценариев, которые имеют очень низкий приоритет и не требуют срочного ответа. Такие данные полезны потому, что позволяют сопоставить связанные факторы и обобщить информацию по времени. Позже эти данные можно использовать в качестве дополнительных источников. Вероятно, у вас не будет много триггеров такого типа, но они могут пригодиться в тех случаях, когда вы вынуждены просматривать одни и те же данные каждый раз, когда возникает проблема. Альтернативным вариантом является сохранение запросов и настойка дашбордов.
В каких случаях не нужно отправлять оповещения?
Важно четко понимать, какие предупреждения должна получать ваша команда. Каждое предупреждение должно сообщать о проблемах, требующих ручного вмешательства оператора или принятия того или иного решения. Потому при настройке системы оповещений нужно обратить внимание на все проблемы, решение которых можно автоматизировать.
Автоматическое восстановление возможно в случаях, когда:
- распознаваемая подпись может надежно идентифицировать проблему
- решение проблемы всегда будет одинаковым
- ответ не требует участия оператора или принятия решений
Некоторые ответы проще автоматизировать, чем другие, но, как правило, автоматизировать можно любой сценарий, который соответствует указанным выше критериям. Метрика по-прежнему может быть привязана к пороговым значениям, но вместо отправки сообщения человеку триггер может запустить сценарий восстановления для решения проблемы. Ведение логов может предоставить ценную информацию о состоянии системы и эффективности пороговых значений и автоматических сченариев.
Важно помнить, что в автоматизированных процессах тоже могут возникнуть проблемы. В таком случае хорошо бы настроить дополнительные предупреждения для сценариев, чтобы оператор был уведомлен о сбое автоматизированного восстановления.
Оптимизация пороговых значений и отправки уведомлений
Теперь, когда мы рассмотрели различные доступные средства оповещения, мы можем поговорить об оптимизации системы предупреждений.
Уведомления, сгенерированные событиями с реальным воздействием пользователя
Как упоминалось ранее, предупреждения, основанные на сценариях с реальным воздействием пользователей, являются наилучшими. Они позволяют анализировать сценарии сбоев или ухудшение производительности на уровнях, с которыми взаимодействуют пользователи.
Это требует хорошего понимания избыточности инфраструктуры, взаимоотношения различных компонентов и целей организации в отношении доступности и производительности. Ваша цель – выявить симптоматические метрики, которые могут достоверно указать на текущие или потенциальные проблемы, влияющие на пользователя.
Пороговые значения разного приоритета
После того, как вы определили симптоматические метрики, нужно выявить соответствующие значения, которые можно использовать в качестве пороговых. Чтобы обнаружить правильные пороговые значения для некоторых метрик, вам придется провести несколько тестов.
Если у вас есть история, проверьте значения в ней, чтобы определить, какие сценарии вы восстанавливали ранее. Для каждой метрики полезно определить аварийный порог, который вызовет оповещение пейджера, и одно или несколько пороговых значений с более низким приоритетом. Определив пороги, убедитесь, что они эффективны в данной среде.
Установка контекста
Минимизировав время, затрачиваемое на извещение операторов о проблеме, вы поможете им быстрее справиться с ситуацией. С этой целью полезно попытаться предоставить контекст в предупреждении, чтобы операторы могли быстро понять проблему и начать устранять ее.
Оповещения должны четко указывать на затронутые компоненты и системы, пороговые значения метрики и время возникновения ошибки. Предупреждение также должно содержать ссылки для получения дополнительной информации. Это могут быть ссылки на конкретные дашборды, связанные с запущенной метрикой, ссылки на систему билетов на страницу оповещений системы мониторинга, где оператор найдет более подробный контекст.
На этом этапе цель состоит в том, чтобы предоставить операторам достаточную информацию для быстрого реагирования и помочь им сосредоточиться на проблеме. Не нужно предоставлять абсолютно всю информацию о событии (это даже не рекомендуется), достаточно базовых сведений с подсказками, где искать дополнительную информацию.
Отправка уведомлений правильным сотрудникам
Оповещения бесполезны, если они не вызывают ответной реакции. Часто реакция зависит от уровня знаний, опыта и прав доступа оператора, который получил оповещение. В большой организации сложно выбрать ответственного человека или группу: если разные аспекты инфраструктуры распределены между сотрудниками, то одних специалистов уведомление будет касаться напрямую, а другие не будут иметь компетенции решать возникшую проблему. Потому нужно четко понимать, кто должен заниматься устранением проблем того или иного характера.
Лучше всего, если ваша система оповещения включает механизм планирования смен, но если нет, вы можете разработать процедуру для ротации оповещений вручную на основе вашего расписания.
План передачи уведомления на более высокие уровни – это второй инструмент, позволяющий убедиться, что уведомление попадет к правильным людям. Если у вас есть персонал, обслуживающий систему 24 часа в сутки, лучше всего отправлять предупреждения системы мониторинга непосредственно сотрудникам смены. Операторы могут сами выполнить смягчение, а если им понадобится помощь, они смогут передать уведомление более опытным сотрудникам. Наличие плана передачи уведомления на более высокие уровни может минимизировать время решения проблемы.
Заключение
Теперь вы знаете, как работают системы мониторинга и оповещения в реальных сценариях. Вы знаете также, из каких компонентов состоит система мониторинга, за что отвечает каждый компонент и какие бывают модели мониторинга. Кроме того, вы можете оптимизировать систему оповещений с учетом приоритета и типа уведомлений.
Tags: Мониторинг