Каковы некоторые хорошие шаблоны для очистки шумовых оповещений регистрации
В дополнение к традиционному ведению журнала из приложений, входящих в, например, Elasticsearch, организация может иметь систему оповещения " Sentry", которая получает сообщения журнала / события исключений, отправленные приложениями по HTTP, и уведомляет разработчиков о потенциальных проблемах.
Предположим, что Sentry теперь содержит не только "действенные" события (например, ошибка подключения к базе данных. Devops должен исследовать), но и был загрязнен большим количеством "неактивных" событий (например, пользовательский ввод не может быть обработан - ожидание пользователя попробовать еще раз, нечего делать девопам).
Какие есть варианты перехода от системы, полной смешанных хороших и плохих данных о событиях, к чистой системе, содержащей только хорошие данные, чтобы предупреждения снова стали значимыми и не игнорировались?
Примеры: 1) Постепенно прорабатывайте каждое событие, начиная с низко висящих фруктов / наиболее распространенных событий, решая, будет ли оно действенным. 2) Создать новую систему и постепенно переносить в нее действенные события.
2 ответа
Каждое предупреждение должно требовать разумного действия. Никаких действий не требуется, оповещения гарантируют усталость оповещения и в конечном итоге пропускают реальные проблемы Реальные проблемы приводят к сообщениям о состоянии поврежденных сервисов или открытым проблемам с разработчиками программного обеспечения.
Создание нормальных изменений в шумной системе - труд. Скорее всего, отставание не будет работать достаточно быстро.
Подумайте об объявлении банкротства оповещения и об удалении всех оповещений. Добавьте обратно самые основные элементы, такие как коэффициент ошибок на ваших серверах API и среднее время отклика пользователя. См. Для вдохновения четыре золотых сигнала из книги Google SRE.
В дальнейшем проведите анализ первопричин незапланированных событий и случайностей. Если у вас есть данные, которые предсказывают проблему, добавьте предупреждение. Запланируйте предупреждение для удаления, когда устранена основная причина, и предупреждение не сработало в течение длительного времени.
Если ваши данные о событиях имеют уровни классификации, вы можете пройти путь от высокой серьезности до низкой. Как правило, наивысшая степень серьезности должна быть намного меньше выходной (например, Fatal), и, надеюсь, более важной.
Затем вы можете начать спускаться к более низкой серьезности и остановиться, когда вы нажмете уменьшенную отдачу.
Другой вариант, если группа событий в большом объеме - это оповещение о метриках временных рядов, полученных из журналов.