Иван Матвеев. Трассировка и логгирование в микросервисах: зачем, как, а также грабли и как наступать на них аккуратно

Когда вы строите микросервисную архитектуру, никто не думает о плохом. Но со временем у вас могут появиться проблемы: скажем, вы забудете оповестить о чем-то важном сервисы, или ключевой разработчик, который держал все в голове, решит сменить работу. И вот уже это не совсем ваше приложение…

Я хочу поделиться нашим опытом решения задачи “Как всегда понимать, как оно работает в целом”, и расскажу:
* почему единообразие логов и правильная трассировка — это маст хэв
* какие проблемы встают перед командой в начале пути к такому единообразию — и проблемы ли это?
* немного — про политическую волю
* какие результаты и сайдэффекты мы получили на выходе
* и куда хотим двигаться дальше

Transcript

1. Трассировка запросов и
   единообразие логов
   

   View Slide

2. Проблемы
   Разные хранилища логов у разных сервисов
   Скорость роста -> выбор разных хранилищ
   Отсутствие трассировки между сервисами на
   уровне логов
   Разные подходы к тому, что и как логируется
   Скорость роста -> много команд
   

   View Slide

3. Разные хранилища логов у
   разных сервисов
   Только команда знает, что и где лежит
   Разные доступы к системам
   Приход черного сапортера
   

   View Slide

4. Отсутствие трассировки
   между сервисами
   Нельзя отследить цепочку действий, которую
   породило действие пользователя
   Нельзя связать ошибку и цепочку действий
   Сложно восстановить систему после сбоя
   

   View Slide

5. Разные подходы к тому,
   что и как логируется
   Разные понимания, что кладется в логи
   Access логи
   Полнота логов
   Ошибки, которые никто не замечает
   

   View Slide

6. Проблемы ли?
   Частичное падение сервисов
   Саппорт / дежурные, что и где искать
   Ошибки-долгожители
   

   View Slide

7. Куда идем
   Трассировка запроса по всей системе
   Единообразие логов, их применение и
   хранение
   Минимизация телодвижений со стороны
   разработчиков
   

   View Slide

8. Что в окружении
   PHP / Symfony 4.x
   RabbitMQ
   GuzzleHTTP
   Docker
   

   View Slide

9. Трассировка запроса (ТЗ)
   Запрос - это либо запрос от пользователя
   или от внешней системы, либо cron
   request-id как уникальный идентификатор
   запроса
   AMQP headers / HTTP headers как транспорт
   для request-id
   

   View Slide

10. ТЗ HTTP
    Автоматический подхват из HTTP запроса
    $request_id из nginx как значение для
    request-id
    Автоматическое добавление обработчика в
    \GuzzleHttp\Client (тег в конфигурации)
    

    View Slide

11. ТЗ AMQP / RabbitMQ
    Автоматический подхват из AMQP consumer
    Автоматическое добавление заголовка request-id при
    публикации AMQP
    

    View Slide

12. Логирование
    Удобный trait для добавления logger'а с
    поддержкой каналов
    2 хранилища для логов (sentry + ELK / beats)
    

    View Slide

13. Где логируем
    Действия пользователя
    Запуски консольныйх команд
    Обертка вокруг RabbitMQ consumer
    

    View Slide

14. Что логируем
    request-id / uid / process.id
    Имя канала и приложения
    user.id
    Переменные окружения
    Исключения
    

    View Slide

15. Лог ошибок
    Sentry
    1 приложение - 1 проект в Sentry
    Настройка оповещений
    

    View Slide

16. Лог всего
    Kibana / elastic search
    Модуль для filebeat, JSON как формат
    Лог действия пользователей и работы
    бизнес логики
    

    View Slide