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