Внедрение мониторинга и оповещений на практике

Хотя основная часть системы мониторинга может быть развернута на выделенном сервере или серверах, данные необходимо собирать из разных источников в вашей инфраструктуре. Для этого на каждом отдельном компьютере в сети устанавливается агент мониторинга - небольшое приложение, предназначенное для сбора и пересылки данных в конечную точку сбора. Эти агенты собирают статистику и показатели использования с хоста, на котором они установлены, и отправляют их в программное обеспечение центрального мониторинга.

Агенты работают как всегда включенные демоны на каждом хосте в системе. Они могут включать в себя базовую конфигурацию для безопасной аутентификации на удаленной конечной точке данных, определения частоты данных или политик выборки и установки уникальных идентификаторов для данных хостов. Чтобы уменьшить влияние на другие службы, агент должен использовать минимальные ресурсы и иметь возможность работать практически без управления. В идеале, установить агент на новом узле и начать отправку метрик в центральную систему мониторинга должно быть тривиально.

Агенты мониторинга обычно собирают общие метрики уровня хоста, но также доступны агенты для мониторинга программного обеспечения, такого как веб-серверы или серверы баз данных. Однако для большинства специализированных типов программного обеспечения необходимо будет собирать и экспортировать данные либо путем изменения самого программного обеспечения, либо путем создания собственного агента путем создания службы, которая анализирует конечные точки состояния программного обеспечения или записи журнала. Многие популярные решения для мониторинга имеют библиотеки, которые облегчают добавление пользовательских инструментов в ваши службы. Как и в случае с агентским программным обеспечением, необходимо позаботиться о том, чтобы ваши индивидуальные решения минимизировали их занимаемую площадь, чтобы не влиять на здоровье или производительность ваших приложений.

До сих пор мы делали некоторые предположения относительно архитектуры мониторинга на основе push, когда агенты передают данные в центральное местоположение. Тем не менее, дизайн на основе тяги также доступны. В системах мониторинга на основе запросов отдельные хосты отвечают за сбор, агрегирование и обслуживание метрик в известном формате на доступной конечной точке. Сервер мониторинга опрашивает конечную точку метрик на каждом хосте для сбора данных метрик. Программное обеспечение, которое собирает и представляет данные через конечную точку, предъявляет многие из тех же требований, что и агент, но часто требует меньше настроек, так как не требует знания доступа к другим машинам.

Одной из самых загруженных частей системы мониторинга в любой момент времени является компонент входа метрик. Поскольку данные постоянно генерируются, процесс сбора данных должен быть достаточно устойчивым, чтобы справляться с большим объемом операций и координировать действия со слоем хранения для правильной записи входящих данных.

Для push-систем конечная точка входа метрик - это центральное место в сети, куда каждый агент мониторинга или агрегатор статистики отправляет свои собранные данные. Конечная точка должна иметь возможность аутентифицировать и получать данные от большого количества хостов одновременно. Входные конечные точки для систем метрик часто сбалансированы по нагрузке или распределены в масштабе как для надежности, так и для поддержки большого объема трафика.

Для систем на основе извлечения соответствующий компонент представляет собой механизм опроса, который обращается и анализирует конечные точки метрик, выставленные на отдельных хостах. Это имеет некоторые из тех же требований, но некоторые обязанности меняются. Например, если отдельные хосты осуществляют аутентификацию, процесс сбора метрик должен быть в состоянии предоставить правильные учетные данные для входа в систему и доступа к защищенной конечной точке.

Уровень управления данными отвечает за организацию и запись входящих данных из входного компонента метрик и за ответ на запросы и запросы данных из административных уровней. Данные метрик обычно записываются в формате, называемомtime series, который представляет изменения значения во времени. Базы данных временных рядов - базы данных, которые специализируются на хранении и запросе данных этого типа - часто используются в системах мониторинга.

Основной задачей уровня управления данными является хранение входящих данных в том виде, в котором они получены или получены от хостов. Как минимум, уровень хранения должен записывать сообщаемую метрику, наблюдаемое значение, время создания значения и хост, который его создал.

Для сохранения в течение более длительных периодов времени уровень хранения должен обеспечивать способ экспорта данных, когда сбор превышает локальные ограничения для обработки, памяти или хранения. В результате уровень хранения также должен иметь возможность импортировать данные в большом количестве, чтобы при необходимости повторно вводить исторические данные в систему.

Уровень управления данными также должен обеспечивать организованный доступ к хранимой информации. Для систем, использующих базы данных временных рядов, эта функциональность обеспечивается встроенными языками запросов или API. Их можно использовать для интерактивных запросов и исследования данных, но основными потребителями, вероятно, будут панели мониторинга представления данных и система оповещения.

Поверх уровня управления данными построены интерфейсы, с которыми вы взаимодействуете для понимания собираемых данных. Поскольку метрики являются данными временного ряда, данные лучше всего представить в виде графика со временем на оси X. Таким образом, вы можете легко понять, как значения меняются со временем. Метрики можно визуализировать в различных временных масштабах, чтобы понять тенденции за длительные периоды времени, а также последние изменения, которые могут повлиять на ваши системы в настоящее время.

Слои визуализации и управления данными участвуют в обеспечении того, чтобы данные с различных хостов или из разных частей стека вашего приложения могли накладываться и просматриваться целостно. К счастью, данные временных рядов обеспечивают согласованную шкалу, которая помогает идентифицировать события или изменения, которые произошли одновременно, даже когда воздействие распространяется на различные типы инфраструктуры. Возможность интерактивного выбора данных для наложения позволяет операторам создавать визуализации, наиболее полезные для выполняемой задачи.

Обычно используемые графики и данные часто объединяются в сохраненные панели мониторинга. Они полезны в ряде случаев, либо в качестве постоянного представления текущих показателей работоспособности для постоянно включенных дисплеев, либо в качестве целевых порталов для устранения неполадок или глубокого погружения в определенные области вашей системы. Например, панель мониторинга с подробной разбивкой физической емкости хранилища по всему парку может быть важна при планировании емкости, но для ежедневного администрирования может не потребоваться ссылка на нее. Упрощение построения как обобщенных, так и целевых панелей мониторинга может помочь сделать ваши данные более доступными и действенными.

Хотя графики и информационные панели будут вашими инструментами для понимания данных в вашей системе, они полезны только в тех случаях, когда пользователь просматривает страницу. Одна из самых важных обязанностей системы мониторинга - освободить членов команды от активного наблюдения за вашими системами, чтобы они могли выполнять более ценные действия. Чтобы сделать это возможным, система должна иметь возможность запрашивать ваше внимание, когда это необходимо, чтобы вы могли быть уверены, что вы будете в курсе важных изменений. Системы мониторинга используют определенные пользователем метрические пороги и системы оповещения для достижения этой цели.

Цель системы оповещения состоит в том, чтобы надежно уведомлять операторов, когда данные указывают на важное изменение, и в противном случае оставлять их в покое. Поскольку для этого требуется, чтобы система знала, что вы считаете значительным событием, вы должны определить критерии оповещения. Определения предупреждений состоят из метода уведомления и метрического порога, который система непрерывно оценивает на основе входящих данных. Порог обычно определяет максимальное или минимальное среднее значение для показателя за определенный период времени, в то время как метод уведомления описывает, как отправить предупреждение.

Одной из самых сложных частей оповещения является поиск баланса, который позволяет вам реагировать на проблемы, не переусердствовав при этом. Для этого вам необходимо понять, какие метрики являются лучшими признаками реальных проблем, какие проблемы требуют немедленного внимания и какие методы уведомления лучше всего подходят для различных сценариев. Для этого язык определения порога должен быть достаточно мощным, чтобы адекватно описывать ваши критерии. Аналогичным образом, компонент уведомления должен предлагать методы связи, подходящие для различных уровней серьезности.

Начиная с типа предупреждения с наивысшим приоритетом,pages представляют собой уведомления, которые пытаются срочно привлечь внимание к критической проблеме в системе. Эта категория оповещения должна использоваться для ситуаций, которые требуют немедленного разрешения из-за их серьезности. Для системы подкачки требуется надежный, агрессивный способ обращения к людям, на которых лежит ответственность и возможность работать над решением проблемы.

Страницы должны быть зарезервированы для критических проблем с вашей системой. Из-за типа проблем, которые они представляют, они являются наиболее важными оповещениями, которые отправляет ваша система. Хорошие пейджинговые системы надежны, настойчивы и достаточно агрессивны, поэтому их нельзя игнорировать. Чтобы обеспечить ответ, системы подкачки часто включают опцию уведомления вторичного лица или группы, если первая страница не была подтверждена в течение определенного периода времени.

Поскольку страницы по своей природе невероятно деструктивны, их следует использовать с осторожностью: только тогда, когда становится ясно, что существует операционно неприемлемая проблема. Часто это означает, что страницы привязаны к наблюдаемым симптомам в вашей системе с использованием методов черного ящика. Несмотря на то, что может быть трудно определить, как бэкэнд-хостинг использует максимальное количество подключений, значение недоступности вашего домена гораздо менее неоднозначно и может потребовать страницы.

По степени серьезностиnotifications похожи на электронные письма и билеты. Они предназначены для того, чтобы оставить постоянное напоминание о том, что операторы должны исследовать развивающуюся ситуацию, когда они в состоянии сделать это. В отличие от страниц, оповещения в стиле уведомлений не предназначены для указания необходимости немедленных действий, поэтому они обычно обрабатываются работающим персоналом, а не оповещают сотрудника по вызову. Если в вашей компании не работают администраторы постоянно, уведомления должны соответствовать ситуациям, которые могут подождать до следующего рабочего дня.

Билеты и электронные письма, сгенерированные мониторингом, помогают командам понять работу, на которой они должны сосредоточиться, когда они будут активны в следующий раз. Поскольку уведомления не должны использоваться для критических проблем, в настоящее время затрагивающих производство, они часто основаны на индикаторах «белого ящика», которые могут предсказать или выявить развивающиеся проблемы, которые необходимо будет решить в ближайшее время.

В других случаях оповещения уведомлений настроены на то же поведение, что и оповещения на пейджинге, но имеют более низкие, менее критические пороговые значения. Например, вы можете определить оповещение-уведомление, когда ваше приложение показывает небольшое увеличение задержки в течение определенного периода времени, и отправлять соответствующую страницу, когда задержка увеличивается до неоправданного значения.

В целом, уведомления являются наиболее подходящими в ситуациях, которые требуют ответа, но не представляют непосредственной угрозы стабильности вашей системы. В этих случаях вы хотите привлечь внимание к проблеме, чтобы ваша команда могла исследовать и уменьшитьbefore, когда она влияет на пользователей или превращается в более серьезную проблему.

Хотя это технически не является предупреждением, иногда вы можете захотеть отметить конкретное наблюдаемое поведение в месте, к которому вы можете легко получить доступ позже, не обращая на него внимание кого-либо сразу. В этих ситуациях может быть полезна установка пороговых значений, которые будут простоlog информацией. Они могут быть записаны в файл или использованы для увеличения счетчика на панели мониторинга в вашей системе мониторинга. Цель состоит в том, чтобы предоставить легко скомпилированную информацию для целей расследования, чтобы сократить количество запросов, которые операторы должны построить для сбора информации.

Эта стратегия имеет смысл только для сценариев, которые имеют очень низкий приоритет и не нуждаются в самостоятельном реагировании. Их наибольшая полезность заключается в сопоставлении связанных факторов и обобщении данных на определенный момент времени, которые позже можно будет ссылаться на дополнительные источники. Вероятно, у вас не будет много триггеров этого типа, но они могут быть полезны в тех случаях, когда вы обнаруживаете, что просматриваете одни и те же данные каждый раз, когда возникает проблема. Альтернативы, обеспечивающие некоторые из тех же преимуществ, - это сохраненные запросы и пользовательские панели мониторинга.

Как упоминалось ранее, оповещения, основанные на сценариях с реальным воздействием на пользователя, являются лучшими. Это означает анализ различных сценариев сбоя или снижения производительности и понимание того, как и когда они могут переходить на уровни, с которыми взаимодействуют пользователи.

Для этого требуется хорошее понимание избыточности вашей инфраструктуры, взаимосвязи различных компонентов и целей вашей организации в отношении доступности и производительности. Ваша цель - найти симптоматические метрики, которые могут надежно указывать на существующие или надвигающиеся проблемы, влияющие на пользователя.

После того, как вы определили симптоматические метрики, следующая задача - определить подходящие значения для использования в качестве пороговых значений. Возможно, вам придется использовать метод проб и ошибок, чтобы определить правильные пороговые значения для некоторых показателей.

Если возможно, проверьте исторические значения, чтобы определить, какие сценарии требовали исправления в прошлом. Для каждого показателя целесообразно определить «аварийный» порог, который будет вызывать запуск страницы, и один или несколько «канареечных» порогов, связанных с обменом сообщениями с более низким приоритетом. После определения новых предупреждений попросите дать отзыв о том, были ли пороговые значения чрезмерно агрессивными или недостаточно чувствительными, чтобы вы могли настроить систему так, чтобы она наилучшим образом соответствовала ожиданиям вашей команды.

Минимизация времени, необходимого респондентам для начала расследования проблем, помогает быстрее восстанавливаться после инцидентов. С этой целью полезно попытаться предоставить контекст в тексте предупреждения, чтобы операторы могли быстро понять ситуацию и начать работу над соответствующими последующими шагами.

В оповещениях должны быть четко указаны затронутые компоненты и системы, пороговое значение метрики, которое было инициировано, и время начала инцидента. Предупреждение также должно содержать ссылки, которые можно использовать для получения дополнительной информации. Это могут быть ссылки на конкретные панели мониторинга, связанные с сработавшей метрикой, ссылки на вашу систему создания билетов, если были сгенерированы автоматические заявки, или ссылки на страницу предупреждений вашей системы мониторинга, где доступен более подробный контекст.

Цель состоит в том, чтобы предоставить оператору достаточно информации, чтобы направить его первоначальный ответ и помочь ему сосредоточиться на происходящем инциденте. Предоставление каждой имеющейся у вас информации о событии не требуется и не рекомендуется, но предоставление базовой информации с несколькими вариантами дальнейших действий может сократить начальную фазу обнаружения вашего ответа.

Оповещения бесполезны, если они не действуют. Часто то, является ли предупреждение действующим, зависит от уровня знаний, опыта и разрешения, которое имеет отвечающий человек. Для организаций определенного размера выбор подходящего человека или группы для сообщения прост в одних случаях и неоднозначен в других. Разработка ротационной ротации для разных групп и разработка конкретного плана эскалации может устранить некоторую неопределенность в этих решениях.

Вращения по вызову должны включать достаточно способных людей, чтобы избежать выгорания и сильной усталости. Лучше всего, если ваша система оповещения включает механизм для планирования смены по вызову, но если нет, вы можете разработать процедуры для ручного поворота контактов оповещения на основе ваших расписаний. У вас может быть несколько ротаций по вызову, заполненных владельцами определенных частей ваших систем.

План эскалации - это второй инструмент, позволяющий убедиться, что инциденты доведены до нужных людей. Если у вас есть персонал, работающий с вашими системами 24 часа в сутки, лучше отправлять оповещения, генерируемые системой мониторинга, сотрудникам, работающим в смену, а не по очереди. Затем респонденты могут самостоятельно выполнить меры по смягчению или принять решение о том, чтобы вручную вызывать операторов по вызову, если им нужна дополнительная помощь или опыт. Наличие плана, в котором указано, когда и как обостряются проблемы, можно свести к минимуму ненужные оповещения и сохранить чувство срочности, которое должны представлять страницы.