Язык запросов

В этом разделе описан язык запросов для выборки и фильтрации по логам. В интерфейсе Monium и API используется единый язык запросов для получения данных. Язык позволяет применять фильтрующие выражения к каждой строчке лога. По аналогии с SQL — задавать условные выражения в часть WHERE.

Типы данныхТипы данных

Тип данных определяется из записи выражения в литеральной форме. Язык запросов поддерживает примитивные типы данных:

• String (строка) — любое литеральное выражение записанное в кавычках (одинарных или двойных) будет представлено как строка.

• Scalar — вещественное число с плавающей точкой двойной точностью по стандарту IEEE 754, не включая специальное значение NaN и бесконечность.

  При записи чисел поддерживаются запись с мантиссой, а также следующие суффиксы:

  • k — 10³;
  • M — 10⁶;
  • G — 10⁹;
  • T — 10¹²;
  • P — 10¹⁵;
  • E – 10¹⁸.

  Например:

  101
  75.3
  20G
  1E-3
  

Язык выборки и фильтрации логовЯзык выборки и фильтрации логов

Язык запросов используется для описания фильтров по логам и похож на язык селекторов мониторинга. Для выбора множества логов используется набор селекторов, фильтрующих значения меток. Поля верхнего уровня (например message, level) в данном контексте рассматриваются как такие же метки как и в labels и в meta.
Селектор состоит из имени метки, оператора и выражения, описывающего множество значений меток. Условия внутри селектора объединяются по AND.

Пример:

{project="folder__b1g86q4m5vej********", service="fetcher", cluster="production", duration > 500}

Операторы:Операторы:

Для операторов > >= < <= операнд справа всегда ожидается числовым литералом (за исключением метки level) и сравнение происходит с приведением типа метки так же к числу, если привести значение метки не получилось — результат вычисления именно этой части выражения считается ложным.

Для поиска по меткам, хранящимся в метаинформации meta, обязательно указание полного квалификатора имени meta.label_name, при этом доступны все те же операторы, что используются для меток с верхнего уровня и labels.

Ниже приведены примеры селекторов, на основе следующих данных:

....
project="folder__b1g86q4m5vej********"
service="fetcher"
cluser="production"
level=ERROR
labels={hook_type="LIVENESS", object_type="WORKLOAD", start_time=1708348144767787, fail_reason=2000, state="EHttpGetState_SUCCESS"}
meta={user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 YaBrowser/24.1.0.0 Safari/537.36"}

Селектор, фильтрующий строчки лога с уровнем логирования INFO или DEBUG

{project="folder__b1g86q4m5vej********", service="fetcher", cluser="production", level="INFO|DEBUG"}

Селектор, фильтрующий строчки лога у которых в метке fail_reason (один из ключей в поле labels) содержится целое число больше 1000

{project="folder__b1g86q4m5vej********", service="fetcher", cluser="production", fail_reason>1000}

Поиск всех ошибок, произошедших при запросе от определенного агента

{project="folder__b1g86q4m5vej********", service="fetcher", cluser="production", level>="ERROR", fail_reason=200, meta.user_agent=*"Chrome"}

В имени метки допустимы символы ., они рассматриваются как часть имени одной метки. Такие символы в селекторе не экранируются.

{exception.type="java.lang.RuntimeException"}

или для meta

{meta.exception.message="cannot replace metrics*"}

Минимально необходимый селекторМинимально необходимый селектор

Для селектора, есть минимально необходимый набор меток, которые обязательны в каждом запросе. Фактически это означает максимальную область поиска для одного селектора. Это обязательное наличие меток project + service или log_group_id.

Ограничения на минимальный селектор

Ограничение на меткиОграничение на метки

На ряд меток действуют ограничения по операторам и значениям для них

Особенности работы с trace.idОсобенности работы с trace.id

В языке запросов допускается опускать произвольное количество leading zeroes в значении trace.id.
Так, следующие селекторы эквивалентны:

• {trace.id="000000000000000036a91077c9806b4c"}
• {trace.id="000036a91077c9806b4c"}
• {trace.id="36a91077c9806b4c"}

Рекомендации по написанию эффективных селекторовРекомендации по написанию эффективных селекторов

Для разреженных данных (подробнее) используются оптимизации, позволяющие искать только в части хранилища, поэтому чем более точно запрос сужает выборку, тем быстрее он работает. Например:

• {project = "...", service = "...", meta.order.id = "*abc*123*"}
  В запросе нет точного значения атрибутов, поэтому искать придется везде

• {project, service, meta.order.id = "bf090941d4f44867"}
  Есть точное значение — можем искать быстро (если id встречается редко)

• {project, service, meta.order.id = "*abc*123*", meta.request.id = "c7438471-fc0f46b9bc68"}
  Не можем искать быстро по order.id, но можем по request.id!

• {project, service, geo.city = "very_small_city"}
  Работает также для labels

• {project, service, geo.city = "very_small_city", meta.purchase_token = "f97b68f2450e43e4"}
  Данный запрос еще быстрее предыдущего, т.к. мы сначала отсеяли часть по geo.city, а после еще отсеяли часть по purchase_token

• {project, service, trace.id="00008dsf7d8df7d"}
  Работает и для trace.id, span.id

Высококардинальные значения, в том числе идентификаторы, лучше записывать в метаинформацию.