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

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

тут ведь много факторов. например фактор нагрузки. то есть — решения типа егеря умеют в ловлю логов — но плохо. а скакать между егерем и логами… что куда пошло. не. это не работает. когад система одна (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.

все просто.

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

нууу… что ELK что sentry на dev кластере поднять не проблема… а newrelic… он там не нужен прям до конца… на production нужен… а тут… если чет где то не так — то это покажет либо мониторнинг самого кластера, либо метрики… и там ты уже просто с blackfire залезешь и посмотришь, кто хулиганит… поэтому… вообщем мы не смогли придумать, зачем нам нужен егерь :)

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

нет, не знаем.
да, это не так важно.

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

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

open telemetry здесь стоит немного сбоку. и в целом на нее смотрели — но отказались. так как сам подход — хорош, но какой то… обрывочный… просто — что показывает jaeger? окей — трейсы, спаны. но этого мало. и зачастую платный newrelic более продаваем руководству, чем бесплатный (относительно) jaeger.
плюс там проблемы с интеграцией — newrelic встает и все начинает работать. а open telemetry надо пропихнуть во все запросы (HTTP / AMQP) и ловить везде (HTTP / AMQP). вменяемого бандла для того же symfony нет…

поэтому обзор бесплатных инструментов в open telemetry оставил двоякое ощущение. да — круто. но пользы по факту мало от этого… надо прям нормальтно все допиливать. и тут получается что для руководства проще платить за newrelic чем оплачивать работу своих кодеров, за поддержку этого всего и прочее…

Пользовательские репозитории в ORM Doctrine 2

так писать не просто правильнее с точки зрения отладки, но и читаемее. Мы ведь помним о том парне с дубиной, который суппортит наш проект, не правда ли? :)

Пользовательские репозитории в ORM Doctrine 2

Наравне с пользовательскими репозитариями также удобно пользоваться пользовательскими QueryBuilder'ами, куда запирать общие части запросов. Тогда сами запросы внутри методов репозитория будут компактнее и читаемее + для каждого репозитория может существовать (или не существовать) свой класс QueryBuilder'а.

Пример продвинутого метода репозитория:

public function fincAllActive()
{
return $this->getQueryBuilder('users')->onlyActive()->getResult();
}


Соответственно — в QueryBuilder'е есть такие методы:

public function getResult()
{
return $this->getQuery()->getResult();
}

public function onlyActive()
{
return $this
->andWhere($this->getAlias() . '.active = :activeStatus')
->setParameter('activeStatus', true);
}


Пример начала миграции к такому подходу в рабочем проекте:

репозитоий:
github.com/litecommerce/core/blob/1.0-master/src/classes/XLite/Model/Repo/ARepo.php#L1257

QueryBuilder:
github.com/litecommerce/core/blob/1.0-master/src/classes/XLite/Model/QueryBuilder/AQueryBuilder.php

Активного использования пользовательского QueryBuilder'а там нету — но будет :)

OpenStore — бесплатная сборка интернет — магазина на основе Drupal и Ubercart

Софт использует ORM Doctrine 2, а он требует PHP 5.3.0
+ заложились на то, что пока пишут — PHP 5.3.х завоюет мир

OpenStore — бесплатная сборка интернет — магазина на основе Drupal и Ubercart

К времени перехода в стабильное состояние, PHP 5.3.x может уже завоевать таки себе большой кусок хостеров. Все равно, PHP 5.3.х — это следующая ветка. Рано или поздно хостеры на нее перейдут…