Существует много интерфейсных взаимодействий между системой А и системой Б, но был период времени, когда интерфейс часто сообщал об ошибках.Как разработчик, если бы вы не могли знать проблему и решить ее вовремя, вы бы получали жалобы со стороны бизнеса и выступление месяца было классным.
Если у вас тоже такой сценарий, то вам нужна функция своевременного оповещения.
План реализации
Существует два сценария реализации своевременных оповещений:
- Имеется сбор логов ELK
- Нет сбора журнала ELK
Сценарии без сбора журнала ELK
Очень просто, создайте среду для сбора логов (O(∩_∩)О, ха-ха~)Необходимо внедрить жесткое кодирование в бизнес-код и отправлять информацию о тревоге непосредственно на платформу сигнализации для оповещения каждый раз, когда улов ненормальный.
Схема со сбором логов ELK
Ядром является компонент elasticsearch.Предварительным условием всех решений по тревогам является то, что журнал тревог должен войти в ES, а затем периодически извлекать журнал тревог (например, журнал ERROR), соответствующий бизнес-требованиям, из ES. log соответствует определенным условиям, это будет инициировать оповещение.
Основные методы реализации следующие:
-
НАБЛЮДАТЕЛЬ Э.С. Это официальный подключаемый модуль для elasticsearch. Он может предоставлять оповещения и уведомления в соответствии с изменениями данных. В настоящее время за него взимается плата. Конкретную конфигурацию операции см.официальный адрес
-
эласталерт Это фреймворк сигнализации, написанный Yelp на основе python, вы можете перейти на GitHub, чтобы проверить конкретное использование.elastalert
-
заказная разработка
реализация заказной разработки
В основном это достигается за счет следующих шагов:
- Отдельные журналы тревог из бизнес-журналов
- Для анализа журналов в logstash и построения форматированных журналов тревог необходимы следующие ключевые параметры: Уровень журнала, время журнала, описание журнала, модуль разработки, связанный первичный ключ, параметры запроса, параметры ответа
- Запланированная задача отправляется в ES для получения журналов, соответствующих требованиям, через равные промежутки времени и отправляет уведомление о тревоге, если они получены.
основной код
- форматирование журнала Мы напрямую создаем отформатированный журнал на клиенте и выводим его в файл журнала в виде json, чтобы синтаксический анализ json можно было использовать непосредственно при разборе logstash. Этот шаг необязателен, вы можете свободно создать формат журнала, а затем использовать синтаксис grok для его анализа при анализе logstash.
public class AlarmLog {
/**日志级别*/
private String logLevel;
/**日志描述*/
private String message;
/**关联主键 一般使用requestId*/
private String refCode;
/**请求参数*/
private String parm;
/**响应数据*/
private String response;
/**开发模块,根据此参数配置模块负责人*/
private String module;
/**日志时间*/
private long logTime;
...
}
- ключевой запрос Используйте следующий синтаксис запроса в отдельном элементе таймера для получения определенных журналов сигналов тревоги. После извлечения вы можете узнать конкретного ответственного за модуль в соответствии с полем модуля в журнале, а затем отправить тревожное уведомление ответственному лицу.
public List<LogDoc> findRangeLogByLevel(DateTime minRange, DateTime maxRange, String logLevel) {
//需要强制转换成小写
logLevel = logLevel.toLowerCase();
SearchQuery searchQuery = new NativeSearchQueryBuilder()
.withQuery(boolQuery()
//module 必须有值才能告警
.must(existsQuery("module"))
.must(termQuery("logLevel", logLevel))
.must(rangeQuery("logTime")
.from(minRange.getMillis())
.to(maxRange.getMillis())))
.build();
return elasticsearchTemplate.queryForList(searchQuery, LogDoc.class);
}