Устранение неполадок

Устранение неполадок

Переименование метрик count

В некоторых обстоятельствах пользовательские метрики с суффиксом .count имеют разные имена в классических метриках и на платформе Ключ-АСТРОМ. Хотя автоматический конвертер автоматически выполняет необходимую коррекцию, некоторые исключительные сценарии требуют дополнительных шагов. Этот раздел поможет определить, относитесь ли вы к таким пользователям, и что с этим делать.

Классические метрики, загруженные в формате count, должны иметь суффикс .count (или _count).

http_requests count,delta=10

В этом примере с использованием протокола загрузки метрик http_requests загружается в формате count. Поскольку у неё ещё нет суффикса .count, классические метрики добавляют суффикс после загрузки.

http_requests.count:splitBy():value

Следовательно, метрику можно запросить как http_requests.count в классических метриках.

Что отличается на платформе?

На платформе Ключ-АСТРОМ больше не различаются форматы gauge и count, и, следовательно, это поведение добавления суффикса больше не применяется при загрузке. Автоматический конвертер компенсирует поведение добавления суффикса, чтобы создать правильный DQL:

timeseries sum(http_requests)

Теперь DQL использует http_requests, как было указано изначально.

Что, если вы загружаете http_requests.count?

Как это выглядит на платформе?

http_requests.count count,delta=10

Если вы загружаете метрику с суффиксом .count, автоматический конвертер распознаёт правильное использование:

timeseries sum(http_requests.count)

В конечном итоге ваша метрика на платформе соответствует тому, что вы загрузили.

Но что, если вы загружаете и http_requests, и http_requests.count?

Например, вы могли настроить второй сервер спустя долгое время после настройки первого сервера.

http_requests, host.name="My Server 2019" count,delta=5
http_requests.count, host.name="My Server 2024" count,delta=5

В этих примерах два хоста мониторят HTTP-запросы. Классические метрики выполняют корректировку и сопоставляют оба с http_requests.count.

http_requests.count:splitBy():value

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

timeseries with_suffix = sum(http_requests.count), no_suffix = sum(http_requests)
| fieldsAdd http_requests = with_suffix[] + no_suffix[]

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

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

Ключ метрики на платформе	Классический ключ метрики	Формат метрики	Загруженный ключ метрики
http_requests	http_requests.count	count	http_requests
http_requests_count	http_requests_count	count	http_requests_count
http_requests.count	http_requests.count	count	http_requests.count
http_requests_count	http_requests_count.gauge	gauge	http_requests_count
http_requests.count	http_requests.count.gauge	gauge	http_requests.count

Преобразование зон управления

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