Привет! При большой кардинальности будет раздуваться индекс и сильно использоваться оперативка. Использовать те же uuid в теле json - ок, использовать как лейбл - не ок. Как лейбл, лучше использовать что-то что не будет сильно "разнообразным", а все остальное пусть лежит как json, а вот для поиска по конкретному айди например, можно использовать текстовый поиск.
Не стоит забывать, что все эти люди имеют прямое отношение к ИИ и им выгодно продвигать такие нарративы, но да, изменения происходят и будут происходить
Попробуйте посмотреть в дебаг логах (сначала коллектора, и, если не поможет то самого tempo), также трейсы можно представить в виде таблицы, и у ресурса есть аттрибут service.name по которому также можно понять кто какой трейс шлет.
Добрый день! Исходя из того что я вижу, мне кажется что ошибка кроется в том что трейс был отклонен из-за превышения лимита его размера (может быть кол-во спанов слишком большое или кол-во байт в трейсе, что собственно понятно из "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 тоже зависит от версии.
Ну и на всякий случай, глянуть по коду, может быть где-то не завершается спан, не контролируется их кол-во(асинхронно запустили много задач и они наплодили спанов), спаны сами по себе слишком большие по размеру и возможно если есть такая возможность попробовать их уменьшить.
Относительно замечания, я написал "Будет минимум теории — пройду чисто по шагам: что сделать, для чего и как увидеть результат".
Вроде не соврал: показал какие контейнеры запускать, какие конфиги юзать, по моему мнению где было совсем неясно писал комментарии, показал два минимальных приложения для того чтобы увидеть результаты и показал скрины самих результатов. Можно было больше написать и объяснить? - да, но я хотел показать что "вот так делай и будет работать".
В разделе по БД, стоит ли делать вьюхи (материальные и обычные)? Насколько они могут ускорить время ответа и когда их стоит и не стоит создавать?(например, материальные нужно синхронизировать чтобы были актуальные данные, поэтому их не получится использовать в системах где эти данные часто меняются, какие еще есть случаи?)
Добрый день! Cогласен со всеми замечаниями, однако хочу добавить:
CQRS/ES — это инструмент для специфичных сценариев, где важны: Полный аудит и трассируемость изменений, Сложная бизнес-логика с частыми изменениями правил, Гибкость в создании новых представлений данных, Приемлемость получения данных с задержкой проекций (Eventual Consistency)
Для высоконагруженных сценариев вроде аутентификации можно использовать гибрид: ES для "долгой" логики (заказы, платежи) + CRUD/кэш для "горячих" путей (сессии, профили).
P.S. Если проект не требует этих преимуществ — действительно, проще обойтись CRUD операциями. ES добавляет сложности, которые должны окупаться бизнес-требованиями.
Да, вы правы! Первый вариант с Kafka делает приложение stateless.
Раньше приложение было stateful, но с Kafka: состояние переносится в очередь – A просто принимает сообщения и отправляет их в Kafka, не заботясь о маршрутизации.
Да, верно. Лейбл это именно 00011...и тд. Вариант с хранением id именно в теле лога самый оптимальный.
Привет! При большой кардинальности будет раздуваться индекс и сильно использоваться оперативка. Использовать те же uuid в теле json - ок, использовать как лейбл - не ок. Как лейбл, лучше использовать что-то что не будет сильно "разнообразным", а все остальное пусть лежит как json, а вот для поиска по конкретному айди например, можно использовать текстовый поиск.
Не стоит забывать, что все эти люди имеют прямое отношение к ИИ и им выгодно продвигать такие нарративы, но да, изменения происходят и будут происходить
Попробуйте посмотреть в дебаг логах (сначала коллектора, и, если не поможет то самого tempo), также трейсы можно представить в виде таблицы, и у ресурса есть аттрибут service.name по которому также можно понять кто какой трейс шлет.
Добрый день! Исходя из того что я вижу, мне кажется что ошибка кроется в том что трейс был отклонен из-за превышения лимита его размера (может быть кол-во спанов слишком большое или кол-во байт в трейсе, что собственно понятно из "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 тоже зависит от версии.
Ну и на всякий случай, глянуть по коду, может быть где-то не завершается спан, не контролируется их кол-во(асинхронно запустили много задач и они наплодили спанов), спаны сами по себе слишком большие по размеру и возможно если есть такая возможность попробовать их уменьшить.
Надеюсь получилось хоть как-то помочь!)
Здравствуй! Отвечая на вопрос, а почему нет?
Относительно замечания, я написал "Будет минимум теории — пройду чисто по шагам: что сделать, для чего и как увидеть результат".
Вроде не соврал: показал какие контейнеры запускать, какие конфиги юзать, по моему мнению где было совсем неясно писал комментарии, показал два минимальных приложения для того чтобы увидеть результаты и показал скрины самих результатов. Можно было больше написать и объяснить? - да, но я хотел показать что "вот так делай и будет работать".
Спасибо за мнение!
В разделе по БД, стоит ли делать вьюхи (материальные и обычные)? Насколько они могут ускорить время ответа и когда их стоит и не стоит создавать?(например, материальные нужно синхронизировать чтобы были актуальные данные, поэтому их не получится использовать в системах где эти данные часто меняются, какие еще есть случаи?)
Добрый день!
Cогласен со всеми замечаниями, однако хочу добавить:
CQRS/ES — это инструмент для специфичных сценариев, где важны: Полный аудит и трассируемость изменений, Сложная бизнес-логика с частыми изменениями правил, Гибкость в создании новых представлений данных, Приемлемость получения данных с задержкой проекций (Eventual Consistency)
Для высоконагруженных сценариев вроде аутентификации можно использовать гибрид: ES для "долгой" логики (заказы, платежи) + CRUD/кэш для "горячих" путей (сессии, профили).
P.S. Если проект не требует этих преимуществ — действительно, проще обойтись CRUD операциями. ES добавляет сложности, которые должны окупаться бизнес-требованиями.
Да, вы правы! Первый вариант с Kafka делает приложение stateless.
Раньше приложение было stateful, но с Kafka: состояние переносится в очередь –
Aпросто принимает сообщения и отправляет их в Kafka, не заботясь о маршрутизации.Спасибо за замечание! Поправлю статью.