Комментарии 7
Спасибо за подробный разбор.
Хочу подсветить важный аспект: 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, но делать это постепенно, следя за возможными проблемами, так как этот инструментарий мне нравится.
Наблюдаемость “по-взрослому”: опыт внедрения OpenTelemetry