OpenTelemetry стек в Go: Metrics, Tracing, Logs

[anaxita]

Хабр это онлайн блокнот для вас?)

100%, 0% объяснений, но в начале писали «ща мы разберем»

[alserok]

Здравствуй! Отвечая на вопрос, а почему нет?

Относительно замечания, я написал "Будет минимум теории — пройду чисто по шагам: что сделать, для чего и как увидеть результат".

Вроде не соврал: показал какие контейнеры запускать, какие конфиги юзать, по моему мнению где было совсем неясно писал комментарии, показал два минимальных приложения для того чтобы увидеть результаты и показал скрины самих результатов. Можно было больше написать и объяснить? - да, но я хотел показать что "вот так делай и будет работать".

Спасибо за мнение!

[chemtech]

Спасибо за стать! Подскажите как настроить OpenTelemetry Collector чтобы найти виновника высокого значения trace_too_large ?

[alserok]

Добрый день! Исходя из того что я вижу, мне кажется что ошибка кроется в том что трейс был отклонен из-за превышения лимита его размера (может быть кол-во спанов слишком большое или кол-во байт в трейсе, что собственно понятно из "trace_too_large").

Для начала, я бы все-таки глянул логи коллектора в дебаг режиме и логи Tempo (ну или того что вы используете), может по ним сразу будет понятно что идет не так, очевидно, но все же. Из того что можно попробовать сделать:

Попробовать включить компрессию(если ее нет), навряд ли поможет, но можно попробовать:
exporters:
otlp:
compression: gzip

Попробовать поиграть с параметрами Tempo(если используете его), просто увеличить допустимый размер трейса:
overrides:
max_bytes_per_trace: ваше значение

тут стоит смотреть по вашей версии образа какие поля нужны (max_trace_size_bytes, max_spans_per_trace, max_bytes_per_trace), также структура overrides тоже зависит от версии.

Ну и на всякий случай, глянуть по коду, может быть где-то не завершается спан, не контролируется их кол-во(асинхронно запустили много задач и они наплодили спанов), спаны сами по себе слишком большие по размеру и возможно если есть такая возможность попробовать их уменьшить.

Надеюсь получилось хоть как-то помочь!)

[chemtech]

А как узнать какое приложение отправляет большие трейсы?

[alserok]

Попробуйте посмотреть в дебаг логах (сначала коллектора, и, если не поможет то самого tempo), также трейсы можно представить в виде таблицы, и у ресурса есть аттрибут service.name по которому также можно понять кто какой трейс шлет.

[gr-pr-moi-do]

>> Почему нельзя UUID в метрики: UUID в label создаёт высокую cardinality

встречал такую же рекомендацию для Loki, не могли бы вы пояснить мысль? Допустим, мы имеем лог в виде {"@m": "{UserId} logout", "UserId": "UUID"}. Это оно?

Можно пример использования "UUID в label"

[alserok]

Привет! При большой кардинальности будет раздуваться индекс и сильно использоваться оперативка. Использовать те же uuid в теле json - ок, использовать как лейбл - не ок. Как лейбл, лучше использовать что-то что не будет сильно "разнообразным", а все остальное пусть лежит как json, а вот для поиска по конкретному айди например, можно использовать текстовый поиск.

[gr-pr-moi-do]

лейбл это {UserId} или значение "00001111-2222-...." ? из объяснения и совета выглядит как второе. Но в структрированных логах я в принципе (кроме интерполяции строк) не могу передать этот конкретный айди для текстового поиска без использования конструкции {"@m": "{UserId} logout", "UserId": "00001111-2222-...."}

или писать logger.Info($"{UserId} logout");