А вот это проблема которую, проще всего действительно решать на уровне приложения через логгеры. filelog коллектор тоже не умеет правильно "склеивать" json/xml, если Docker уже разбил их на части. Так что грамотное инструментирование для вывода цельного json - лучшее решение.
Конечно. В каждом микросервисе есть модуль (с библиотеками pythonjsonlogger , opentelemetry, prometheus_fastapi_instrumentator), который задает кастомизацию логирования в json формате и интегрируется с OpenTelemetry. В частности в каждый лог я кладу trace_id и span_id, чтобы можно было легко связать логи с распределёнными трейсовыми событиями. Также, как уже сказано в статье автоматически добавляю метаданные (container, label’ы для Loki). Вот, например, что генерирует у меня микросевис отвечающий за BFF:
Такой лог позволяет искать логи по trace_id и span_id и быстро находить всю цепочку вызовов между сервисами, а также анализировать ответы на внешние запросы. Пока работает так, в перспективе планирую наращивать корреляцию логов и метрик для сбора более прозрачной картины.
Спасибо за вопрос. Резкий переход на универсальное решение сопряжен с определёнными рисками. Лично я предпочитаю вносить изменения в инфраструктуру последовательно, чтобы изучить компоненты под рабочими нагрузками и принять соответствующие выводы и меры.
Кроме того, привязка к одному решению OpenTelemetry в перспективе может лишить нас преимуществ классических, специализированных инструментов. Обычно хорошие инструменты выполняют свою задачу эффективнее чем комплексное решение "все в одном".
В перспективе я буду пробовать новые компоненты OpenTelemery, но делать это постепенно, следя за возможными проблемами, так как этот инструментарий мне нравится.
Всё зависит от масштабов и условий. Если речь идёт о нескольких серверах в стабильной сети, использование GitLab Runner действительно может быть удобнее. Однако в случае сотен узлов, разбросанных географически, где некоторые элементы инфраструктуры могут быть временно недоступны, гитлаб раннер уже не будет таким надёжным.
Кроме того, при большом количестве раннеров возможна высокая нагрузка на GitLab, что приведёт к снижению его производительности или даже сбоям
Не совсем, созданным нами пользователем ansible он забирает через ssh плейбук с ролями из GitLab, доступ к которому настроен через rsa ключ. После локальной загрузки запускает его на узле для localhost.
Использовал их, чтобы проиллюстрировать все разнообразие парка машин. Статистика показывает, как ни странно, что Centos 7 еще часто встречается в legacy системах
тогда определенно стоит посмотреть, может ли это текущая прошивка, либо альтернативная. Благодарю.
Если этот вариант сработает, тогда децентрализованные экспортеры будут нужны для проверки качества сети на различных участках, и, как следствие, поиска "узких мест", где трафик замедляется из-за некачественного сетевого оборудования.
Проблема, что в качестве роутера выступал старенький D-Link, поэтому зеркалирование трафика было единственным быстрым решением. А ELK это хорошо, лишним точно не будет.
Особенно если в режиме 24/7 не инвазивные носимые датчики в виде браслетов буду мониторить организм. А служба доставки еды будет автоматически подстраивать рацион питания для поддержания организма в норме.
Тенденции к тому что нейросети окружат каждого и предоставят ему персональные услуги. Люди будут чуть более социально разделены. Услуги живого психолога или доктора буду привилегией обеспеченных людей.
Спасибо за статью, будет здорово если в подобных статьях вы буде использовать тестовое приложение с открытого репозитория, чтобы каждый мог повторить все настройки и убедиться в их работоспособности. Подпишусь и надеюсь на продолжение!
А вот это проблема которую, проще всего действительно решать на уровне приложения через логгеры. filelog коллектор тоже не умеет правильно "склеивать" json/xml, если Docker уже разбил их на части. Так что грамотное инструментирование для вывода цельного json - лучшее решение.
Конечно. В каждом микросервисе есть модуль (с библиотеками
pythonjsonlogger , opentelemetry, prometheus_fastapi_instrumentator), который задает кастомизацию логирования в json формате и интегрируется с OpenTelemetry. В частности в каждый лог я кладу trace_id и span_id, чтобы можно было легко связать логи с распределёнными трейсовыми событиями. Также, как уже сказано в статье автоматически добавляю метаданные (container, label’ы для Loki).Вот, например, что генерирует у меня микросевис отвечающий за BFF:
{"message": "172.18.0.3:33948 - "GET /merch/clothing HTTP/1.1" 200", "container_name": "front0ui", "trace_id": "41b59ec943b6cadfd8ab1cd117437983", "span_id": "30e1c2d0de328a4b", "time": "2025-06-25T10:00:39.309Z", "level": "info", "container": "front0ui", "msg": "172.18.0.3:33948 - "GET /merch/clothing HTTP/1.1" 200", "labels": {"container": "front0ui", "level": "info"}}Такой лог позволяет искать логи по
trace_idиspan_idи быстро находить всю цепочку вызовов между сервисами, а также анализировать ответы на внешние запросы. Пока работает так, в перспективе планирую наращивать корреляцию логов и метрик для сбора более прозрачной картины.Спасибо за вопрос.
Резкий переход на универсальное решение сопряжен с определёнными рисками. Лично я предпочитаю вносить изменения в инфраструктуру последовательно, чтобы изучить компоненты под рабочими нагрузками и принять соответствующие выводы и меры.
Кроме того, привязка к одному решению OpenTelemetry в перспективе может лишить нас преимуществ классических, специализированных инструментов. Обычно хорошие инструменты выполняют свою задачу эффективнее чем комплексное решение "все в одном".
В перспективе я буду пробовать новые компоненты OpenTelemery, но делать это постепенно, следя за возможными проблемами, так как этот инструментарий мне нравится.
Спасибо за дополнение!
стоит изучить, полезный труд
Сделали своего агента для Ansible? Круто, хоть и трудозатратнее.
Всё зависит от масштабов и условий. Если речь идёт о нескольких серверах в стабильной сети, использование GitLab Runner действительно может быть удобнее. Однако в случае сотен узлов, разбросанных географически, где некоторые элементы инфраструктуры могут быть временно недоступны, гитлаб раннер уже не будет таким надёжным.
Кроме того, при большом количестве раннеров возможна высокая нагрузка на GitLab, что приведёт к снижению его производительности или даже сбоям
Не совсем, созданным нами пользователем ansible он забирает через ssh плейбук с ролями из GitLab, доступ к которому настроен через rsa ключ. После локальной загрузки запускает его на узле для localhost.
Согласен, падение джобы узла без доработок незаметно. Нужны системы сбора и анализа логов, с кредами надо думать.
Использовал их, чтобы проиллюстрировать все разнообразие парка машин. Статистика показывает, как ни странно, что Centos 7 еще часто встречается в legacy системах
тогда определенно стоит посмотреть, может ли это текущая прошивка, либо альтернативная. Благодарю.
Если этот вариант сработает, тогда децентрализованные экспортеры будут нужны для проверки качества сети на различных участках, и, как следствие, поиска "узких мест", где трафик замедляется из-за некачественного сетевого оборудования.
Проблема, что в качестве роутера выступал старенький D-Link, поэтому зеркалирование трафика было единственным быстрым решением. А ELK это хорошо, лишним точно не будет.
Второе, телевизор работал фоном.
Да, в комнату. Обычно у них телевизоры ставят с коаксиальным кабелем, поэтому на этот факт изначально никто не обратил внимания.
В перспективе да, но хотелось не усложнять. За ссылку спасибо, хорошая статья.
Особенно если в режиме 24/7 не инвазивные носимые датчики в виде браслетов буду мониторить организм. А служба доставки еды будет автоматически подстраивать рацион питания для поддержания организма в норме.
Тенденции к тому что нейросети окружат каждого и предоставят ему персональные услуги. Люди будут чуть более социально разделены. Услуги живого психолога или доктора буду привилегией обеспеченных людей.
Любопытно. Смесь Horizen и Грани будущего?) Есть кто уже играл?
Спасибо за статью, будет здорово если в подобных статьях вы буде использовать тестовое приложение с открытого репозитория, чтобы каждый мог повторить все настройки и убедиться в их работоспособности. Подпишусь и надеюсь на продолжение!
То есть Prometheus на инстансах создают изолированные базы метрик и высылают их корневому серверу в http запросах?