Комментарии 15
jaeger, open telemetry? Зачем вы советуете платные saas решения, не рассказав про существование кучи oss альтернатив, которые можно поставить на своё железо?
Привет, не понял вопрос.
Метрики у нас собираются вообще statsd, но это за рамками статьи.
Ни jaeger, ни open telemetry не имеют экстеншенов для пыха, чтобы маркировать весь трафик. Тут как раз и идет рассказ о том, как мы делали расширения для стандартных библиотек (guzzle, rabbit) откуда уже легко можно слать данные в тот же jaeger.
Метрики у нас собираются вообще statsd, но это за рамками статьи.
Ни jaeger, ни open telemetry не имеют экстеншенов для пыха, чтобы маркировать весь трафик. Тут как раз и идет рассказ о том, как мы делали расширения для стандартных библиотек (guzzle, rabbit) откуда уже легко можно слать данные в тот же jaeger.
open telemetry здесь стоит немного сбоку. и в целом на нее смотрели — но отказались. так как сам подход — хорош, но какой то… обрывочный… просто — что показывает jaeger? окей — трейсы, спаны. но этого мало. и зачастую платный newrelic более продаваем руководству, чем бесплатный (относительно) jaeger.
плюс там проблемы с интеграцией — newrelic встает и все начинает работать. а open telemetry надо пропихнуть во все запросы (HTTP / AMQP) и ловить везде (HTTP / AMQP). вменяемого бандла для того же symfony нет…
поэтому обзор бесплатных инструментов в open telemetry оставил двоякое ощущение. да — круто. но пользы по факту мало от этого… надо прям нормальтно все допиливать. и тут получается что для руководства проще платить за newrelic чем оплачивать работу своих кодеров, за поддержку этого всего и прочее…
плюс там проблемы с интеграцией — newrelic встает и все начинает работать. а open telemetry надо пропихнуть во все запросы (HTTP / AMQP) и ловить везде (HTTP / AMQP). вменяемого бандла для того же symfony нет…
поэтому обзор бесплатных инструментов в open telemetry оставил двоякое ощущение. да — круто. но пользы по факту мало от этого… надо прям нормальтно все допиливать. и тут получается что для руководства проще платить за newrelic чем оплачивать работу своих кодеров, за поддержку этого всего и прочее…
Все всегда заканчивается, в тот момент когда тестировать надо в закрытом контуре, без доступа к интернетикам.
нууу… что ELK что sentry на dev кластере поднять не проблема… а newrelic… он там не нужен прям до конца… на production нужен… а тут… если чет где то не так — то это покажет либо мониторнинг самого кластера, либо метрики… и там ты уже просто с blackfire залезешь и посмотришь, кто хулиганит… поэтому… вообщем мы не смогли придумать, зачем нам нужен егерь :)
Sentry можно поставить на своё железо, но не уверен, что Business Source License – oss.
Так как вы телеметрию делаете, расскажете?
Вот вы генерируете request-id (aka span id), он потом идет в RabbitMQ например (уже с другим span id), потому идет в другой сервис via HTTP (с другим span id), etc., потом в одном из сервисов это падает с исключением которое вы видите в sentry/kibana. Как вы потом собираете эти отдельные несвязанные куски информации между собой? Jaeger/Zipkin/Google Trace/etc. собрали бы это в одну цепочку, а как вы это делаете с вашим набором инструментов?
Вот вы генерируете 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. А в каким порядке они друг с другом связаны вы (как читатель логов) не знаете, но я предполагаю что это не так важно?
То есть в вашем случае span id — это, скорее trace id. А в каким порядке они друг с другом связаны вы (как читатель логов) не знаете, но я предполагаю что это не так важно?
нет, не знаем.
да, это не так важно.
просто как бы… есть таки еще newrelic, который умеет в и в телеметрию и в services maps, прчием умеет это комплексно и лучше егеря. поэтому всегда можно посмотреть еще и в newrelic. а там еще и APM хороший и вообще… но для логов newrelic не очень… потому получается, что левый глаз смотрит в sentry/ELK а правый еще и в newrelic. чуть неудобно, но в целом ок.
да, это не так важно.
просто как бы… есть таки еще 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.
все просто.
тут ведь много факторов. например фактор нагрузки. то есть — решения типа егеря умеют в ловлю логов — но плохо. а скакать между егерем и логами… что куда пошло. не. это не работает. когад система одна (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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Трассировка и логирование в микросервисах: как мы втаскивали единый стандарт на 30 независимых команд