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