Как стать автором
Обновить

Трассировка и логирование в микросервисах: как мы втаскивали единый стандарт на 30 независимых команд

Время на прочтение 6 мин
Количество просмотров 14K
Всего голосов 38: ↑37 и ↓1 +36
Комментарии 15

Комментарии 15

jaeger, open telemetry? Зачем вы советуете платные saas решения, не рассказав про существование кучи oss альтернатив, которые можно поставить на своё железо?
Привет, не понял вопрос.
Метрики у нас собираются вообще statsd, но это за рамками статьи.
Ни jaeger, ни open telemetry не имеют экстеншенов для пыха, чтобы маркировать весь трафик. Тут как раз и идет рассказ о том, как мы делали расширения для стандартных библиотек (guzzle, rabbit) откуда уже легко можно слать данные в тот же jaeger.
open telemetry здесь стоит немного сбоку. и в целом на нее смотрели — но отказались. так как сам подход — хорош, но какой то… обрывочный… просто — что показывает jaeger? окей — трейсы, спаны. но этого мало. и зачастую платный newrelic более продаваем руководству, чем бесплатный (относительно) jaeger.
плюс там проблемы с интеграцией — newrelic встает и все начинает работать. а open telemetry надо пропихнуть во все запросы (HTTP / AMQP) и ловить везде (HTTP / AMQP). вменяемого бандла для того же symfony нет…

поэтому обзор бесплатных инструментов в open telemetry оставил двоякое ощущение. да — круто. но пользы по факту мало от этого… надо прям нормальтно все допиливать. и тут получается что для руководства проще платить за newrelic чем оплачивать работу своих кодеров, за поддержку этого всего и прочее…
Все всегда заканчивается, в тот момент когда тестировать надо в закрытом контуре, без доступа к интернетикам.
нууу… что ELK что sentry на dev кластере поднять не проблема… а newrelic… он там не нужен прям до конца… на production нужен… а тут… если чет где то не так — то это покажет либо мониторнинг самого кластера, либо метрики… и там ты уже просто с blackfire залезешь и посмотришь, кто хулиганит… поэтому… вообщем мы не смогли придумать, зачем нам нужен егерь :)
Не знал, что sentry появился на on-premise, спасибо!
Так как вы телеметрию делаете, расскажете?

Вот вы генерируете request-id (aka span id), он потом идет в RabbitMQ например (уже с другим span id), потому идет в другой сервис via HTTP (с другим span id), etc., потом в одном из сервисов это падает с исключением которое вы видите в sentry/kibana. Как вы потом собираете эти отдельные несвязанные куски информации между собой? Jaeger/Zipkin/Google Trace/etc. собрали бы это в одну цепочку, а как вы это делаете с вашим набором инструментов?
он потом идет в RabbitMQ например (уже с другим span id)

почему с другим? request-id добавляется в заголовок сообщения рэббита. Как раз сквозная маркировка. Потом можно в кибане по request-id вытащить всех, кого заафектил первичный запрос.
Спасибо, теперь понятно!
То есть в вашем случае span id — это, скорее trace id. А в каким порядке они друг с другом связаны вы (как читатель логов) не знаете, но я предполагаю что это не так важно?
нет, не знаем.
да, это не так важно.

просто как бы… есть таки еще newrelic, который умеет в и в телеметрию и в services maps, прчием умеет это комплексно и лучше егеря. поэтому всегда можно посмотреть еще и в newrelic. а там еще и APM хороший и вообще… но для логов newrelic не очень… потому получается, что левый глаз смотрит в sentry/ELK а правый еще и в newrelic. чуть неудобно, но в целом ок.
Спасибо за ответы

А почему отказались от Performance Monitoring в Sentry в пользу Kibana?
Он в SDK предоставляет неплохой инструментарий для управления транзакциями…


блок в “нашей панельке с «небоскребами»…”


У нас разнообразный стек из python, java, kotlin, php, node, c#, javascript и возможно чего-то ещё… Мы "пробовали" openzipkin & kibana, но сейчас переходим на on-premise sentry, т.к. готовый инструментарий гораздо удобнее в поддержке.

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

тут ведь много факторов. например фактор нагрузки. то есть — решения типа егеря умеют в ловлю логов — но плохо. а скакать между егерем и логами… что куда пошло. не. это не работает. когад система одна (newrelic) — это работает. когда 2 и больше — нет.

далее — в целом newrelic уже был. и как раз для APM. поэтому когда понимали sentry — не было задачи чтотто делать с APM. как и когда понимали ELK (он тоже умеет в APM).

далее — Sentry положить нагрузкой — как нефиг делать :) поэтому Sentry у нас — только для явных ошибок. и все. и хорошо что живой :)

далее — фактор работы-из-коробки. когда ставишь newrelic agent for php — оно просто хоп и заработало. когда ставишь бандл для open telemetry — то надо все приложения перелопачивать, что бы все з0апросы обрабатывались, чтобы rabbitmq бандл правильный использовался и прочее. все тим лиды компании начинают про тебя очень плохзо думать :)

вооот
так что — Sentry для логов с ошибками, ELK — для всех логов. для жосткого APM / отладки — blackfire. для APM в проде — newrelic. и он же для services map, немного для логов, алертинга и для картины в целом. метрики — либо прометей (ибо есть экспортеры — поставил и работает) либо statsd (когда надо чтобы приложение чтото пихало) откуда все сводится в графану.

в результате — то что с приложением все хорошо — просто видно в графане.
если приложению плохо — то об этом проорет sentry / grafana / newrelic. и мы побежим в sentry / ELK / newrelic APM / newrelic services map.

все просто.
У нас примерно также, еще добавили выброс исключения если запрос к сервису пришел без request-id.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий