Comments 12
Спасибо за подробный разбор.
Хочу подсветить важный аспект: OpenTelemetry Gateway становится единой точкой отказа для всей телеметрии. При его падении, например при неправильном конфиге, теряются одновременно метрики, логи и трейсы — именно когда они больше всего нужны для разбора инцидента. При проблемах на стороне Tempo, Prometheus, Loki у OpenTelemetry будет переполнятся память и возможно он упадет. Этот риск нужно учитывать.
Спасибо за дополнение!
при неправильном конфиге
Ну можно начать с того, что на прод среду неправильный конфиг доехать и не должен вовсе, как минимум, это должно быть предварительно протестировано на препрод и\или тесте. Если все правится руками на горячую - ну тогда это вообще последняя проблема ;)
OpenTelemetry будет переполнятся память и возможно он упадет.
Ну давайте не делать из разработчиков лог-агрегаторов идиотов, пожалуйста ;)
Все подобные агрегаторы, типа Otel, Fluent-bit, Vector, Filebeat, и т.д. проектируется с учетом вероятных проблем на стороне экспортеров и такой кейс заведомо предусматривается, поэтому делается логика ограниченного буфера на диске или в памяти, при достижении лимита, в зав-сти от продукта и настроек, происходит либо очистка старых записей в буфере, либо остановка пайплайна, давая знать вышестоящим источникам об этом ( условно, если это происходит по HTTP - то дает знать при помощи кода 429 агентам ), и вышестоящие источники уже на стороне агентов верно интерпретируют это, останавливая чтение, если это возможно. Этот механизм везде называют по разному, но мне нравится backpresure - именно так можно встретить в документации Vector и Fluent-bit, например. Ну еще вот эта страница у Vector может быть интересна.
Сам тезис про единую точку отказа разбивается только лишь об тот факт, что в реальной прод нагрузке инстансов агрегаторов все же больше одного, а то и десятки, если мы говорим про сколько-нибудь заметную нагрузку highload или приближенную к нему. Если же у вас нагрузка настолько микроскопическая, что вам достаточно одного агрегатора, то скорее всего он вам и не нужен действительно ;)
Спасибо, как раз думаю над рефакторингом мониторинга.
В пару к прометею стоит добавить мимир, это позволит хранить данные в s3, возможно даже от самого прометея можно отказаться если коллектор может пушить метрики в пром. Также можно использовать mimir alertmanager что позволит рулить алертами через графану.
Еще за забором остался момент про организацию сервис-дискавери, который позволяет не трогать конфигурацию прометея при добавлении нод (не актуально если можно избавиться от прометея )
А чем первая картинка отличается от третьей?
:-)))
Спасибо за подробную статью.
Не думали заменить весь зоопарк инструментов одним решением, например OpenOnserver? Какие преимущества дает ваш подход в сравнении с одним инструментом?
Спасибо за вопрос.
Резкий переход на универсальное решение сопряжен с определёнными рисками. Лично я предпочитаю вносить изменения в инфраструктуру последовательно, чтобы изучить компоненты под рабочими нагрузками и принять соответствующие выводы и меры.
Кроме того, привязка к одному решению OpenTelemetry в перспективе может лишить нас преимуществ классических, специализированных инструментов. Обычно хорошие инструменты выполняют свою задачу эффективнее чем комплексное решение "все в одном".
В перспективе я буду пробовать новые компоненты OpenTelemery, но делать это постепенно, следя за возможными проблемами, так как этот инструментарий мне нравится.
А поделитесь опытом, как вы организовали логирование коммуникаций между сервисами или с внешними системами? В статье про это нет, а логи там бывают большими и многострочными.
Конечно. В каждом микросервисе есть модуль (с библиотеками 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 и быстро находить всю цепочку вызовов между сервисами, а также анализировать ответы на внешние запросы. Пока работает так, в перспективе планирую наращивать корреляцию логов и метрик для сбора более прозрачной картины.
Спасибо, но я не совсем это имел в виду. Меня интересует вычленение многострочных json/xml из общего потока логов. Мало того, что коллекторы вроде vector (promtail не пробовал) и так это делают не сильно хорошо, так ещё вмешивается docker, который может лог разрезать на несколько. У меня не получилось это нормально настроить, пришлось отправлять логи через amqp в тот же вектор. Т.е. решать на уровне приложения, а не докера.
Наблюдаемость “по-взрослому”: опыт внедрения OpenTelemetry