AWS CloudWatch Logs метрики для обработанных и необработанных исключений

У меня интересный сценарий с AWS CloudWatch Logs. В настоящее время я использую log4net и перекачиваю все журналы в CloudWatch Logs с помощью агента CloudWatch Logs. У меня есть метрика в CloudWatch, которая в основном сканирует записи [ERROR], а Alarm передает их другой службе для уведомлений разработчиков по мере их появления (порог> = 1, период - 1 мин). Все это отлично работает.

Теперь я хочу по-другому обрабатывать некоторые ошибки. Например, в зависимости от типа исключения я хочу активировать тревогу только тогда, когда в течение N минут произошло X событий. Итак, в этом случае я бы создал метрику для этого условия, а затем назначил бы ей Alarm. Проблема в том, что общая метрика ошибок, описанная в первой части этого вопроса, все еще отслеживает каждое отдельное возникновение ошибки. Итак, теперь я получаю несколько уведомлений. Один для каждой ошибки и один после X повторений.

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


person Sergey Akopov    schedule 06.12.2016    source источник
comment
Не могли бы вы рассказать, как вы использовали log4net для отправки журналов в CloudWatch?   -  person andrew.w.lane    schedule 14.12.2016
comment
@ andrew.w.lane, я использую агент CloudWatch Logs Agent, работающий на EC2, и периодически передаю журналы из определенного места в CloudWatch.   -  person Sergey Akopov    schedule 16.12.2016


Ответы (1)


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

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

Псевдокод:

  • Используйте API DescribeAlarms, чтобы получить состояние вашего агрегированного сигнала тревоги о необработанном исключении. . Если совокупный аварийный сигнал находится в состоянии «Тревога», продолжайте.
  • Use FilterLogEvents API to get log events matching:
    • Your Log Group
    • Ваш поток журнала
    • FilterPattern: метрический фильтр вашего индивидуального необработанного исключения.
    • StartTime: отметка времени будильника - период
    • EndTime: отметка времени будильника
  • Use GetLogEvents API to get all log events matching:
    • Your Log Group
    • Ваш поток журнала
    • StartTime: отметка времени будильника - период
    • EndTime: отметка времени будильника
  • Если количество «всех событий» и «отфильтрованных событий» совпадает, а совокупный аварийный сигнал находится в состоянии аварийного сигнала, не отправляйте уведомление. В противном случае используйте API-интерфейсы SES или SNS, чтобы отправить себе уведомление.

Если вы хотите и дальше получать уведомления через SNS, не используйте повторно ту же тему, которую использует будильник для активации лямбда-выражения, - создайте отдельную тему для мобильных / sms-уведомлений.


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

person Anthony Neace    schedule 06.12.2016
comment
Отличный ответ! Спасибо! - person Sergey Akopov; 07.12.2016