Как создать оповещение в полях журнала на основе процента отказов? - PullRequest
1 голос
/ 04 июня 2019

У меня логирование на сумологическом. Журнал JSON содержит время ответа на запрос. Пусть это будет ключ JSON с именем response_time. Каждый запрос идентифицируется уникальным идентификатором, обозначаемым JSON-ключом «request_id». и URL, обозначенный JSON-ключом "url". Мне нужно предупредить о слабом канале на основе следующего условия.

1) Если в окне 10 минут, если есть 100 запросов, и если более 5% запросов имеют время отклика более 100 мс, тогда оповещают "url", "request_id" и "response_time" всех эти запросы. 2) Если время ответа меньше или равно 5% запросов превышает 100 мс, то вообще не следует оповещать. Я написал такой запрос.

_sourceName=<my_source_name> 
| json field=_raw "response_time" as response_time 
| json field=_raw "request_id" as request_id 
| if (num(response_time) > 100, 1, 0) as higher 
| if (num(response_time) <= 100, 1, 0) as lower 
| count as total_requests, sum(higher) as 
response_time_greater_than_100, sum(lower) as 
response_time_less_than_100 
| (response_time_greater_than_100/total_requests) as failure_ratio 
| where (failure_ratio > 0.05)

Выше запрос дает мне все запросы, когда более 5% запросов имеют время отклика более 100 мс. Но он дает мне все запросы независимо от времени ответа. В противном случае результаты не возвращаются.

Наряду с этим результатом я хочу отфильтровать вышеуказанный запрос с запросами, имеющими «response_time»> 100 мс. Когда бы ни были результаты, он дает две вкладки. Один для «Сообщения» и другой для «Агрегаты». и я хочу отправить поля на вкладке «Сообщения» в свободный канал. Как этого добиться?

1 Ответ

2 голосов
/ 04 июня 2019

Вкладки - Совокупности и сообщения

Во-первых, давайте проясним эти две вкладки. Первая (Сообщение) содержит все эти оригинальные строки журнала, которые дали результат. Второй (Aggregates) является результатом вашего фактического запроса с группировкой. Обратите внимание, что вы используете | count, который является оператором группировки (аналогично GROUP BY в SQL).

Любые исходящие взаимодействия всегда основаны на фактическом результате запроса (Агрегаты). Необработанные строки видны только в пользовательском интерфейсе для проверки (также видны в API).

Фактический запрос

Если бы вы просто хотели получить все запросы с временем ответа> 100, было бы достаточно иметь такой запрос:

_sourceName=<my_source_name> 
| json field=_raw "response_time" as response_time 
| json field=_raw "request_id" as request_id 
| where response_time > 100

Говоря декларативно, я понимаю, что вы хотите чего-то другого: получить все ответы выше 100, но только если запросы выше 100 составляют> 5% от общего числа запросов, иначе пустой набор результатов.

_sourceName=<my_source_name> 
| 1 as expected_failure_ratio_violation
| where [subquery:
  _sourceName=<my_source_name> 
  | json field=_raw "response_time" as response_time 
  | json field=_raw "request_id" as request_id
  | if (num(response_time) > 100, 1, 0) as higher 
  | if (num(response_time) <= 100, 1, 0) as lower 
  | count as total_requests, sum(higher) as response_time_greater_than_100, 
    sum(lower) as response_time_less_than_100 
  | (response_time_greater_than_100/total_requests) as failure_ratio 
  | where (failure_ratio > 0.05)
  | count as expected_failure_ratio_violation 
  | compose expected_failure_ratio_violation        
]
| json field=_raw "response_time" as response_time 
| json field=_raw "request_id" as request_id
| where response_time > 100

Используется трюк сопоставления (константа) 1 с количеством нарушений в подзапросе (expected_failure_ratio_violation).

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

Отказ от ответственности: в настоящее время я работаю в Sumo Logic

...