Эпоха монолитных приложений почти прошла. Современные системы разделены на множество компонентов. Даже в самом простом приложении может быть много микросервисов, а у тех есть свои составляющие, например база данных, так что число элементов в системе растёт в геометрической прогрессии.

Посмотрите на пирамиду SRE из книги Google о SRE — в её основании лежит мониторинг. Мы должны очень хорошо понимать, что происходит в нашей системе в каждый момент времени.

Чем качественнее наблюдение, тем меньше багов. А ещё можно вовремя находить узкие места и тратить меньше времени на обслуживание системы. В этой статье мы поговорим о наблюдаемости и её главных инструментах.

Зачем нам наблюдаемость?

Чтобы было понятнее, возьмём для примера приложение, которое обрабатывает создание аккаунтов.

1. UI Microservice — бэкенд-сервис, который будет обрабатывать запросы, полученные от пользовательского интерфейса (это может быть мобильное или веб-приложение). Получив данные от пользователя, этот микросервис будет делать запрос к Accounts Microservice.

2. Accounts Microservice проверяет, есть в базе данных такой аккаунт или нет. Если нет, добавляет новый аккаунт. Если есть, ничего не делает.

Логи

Лог — это запись, которая описывает событие, произошедшее в системе или сервисе. Обычно логи включают метаданные с контекстом, например метку времени, когда произошло событие. Логи можно структурировать в любом формате (скажем, JSON) или отображать как обычный текст.

Например, наш микросервис Accounts может занести в лог ошибку, возвращённую базой данных: 

{   
"timestamp":"2022–08–09T14:30:31Z", 
"action":"create_account",
"user":"user@example.com",
"type":"SQL_ERROR",
"message":"SQL Example Error"
}

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

Логи очень просты, но при этом эффективны для анализа события в системе, если предоставляют качественный контекст. Правда, тут надо действовать с умом: 

1. Если мы записываем слишком много подробностей, страдает производительность приложения.

2. Если мы храним логи, нужно проследить, чтобы хранилище не обходилось слишком дорого.

3. В логах НЕ должно быть конфиденциальной информации.

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

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

1. Fluentd — опенсорс-проект, с помощью которого можно загружать логи в разные хранилища.

2. Если сервис развёрнут в облаке (AWS, Azure, GCP и т. д.), там уже есть управляемый сервис для сбора логов. Например, AWS CloudWatch или GCP Cloud Monitoring.

3. Datadog, ELK Stack и New Relic — платформы наблюдаемости, которые предлагают инструменты для сбора, анализа и хранения логов.

Метрики

Метрики помогают измерять количественные характеристики системы.  У метрики обычно есть имя, значение, метка времени и метки.

Кстати, следите за кардинальностью меток — если она слишком высокая, пострадает производительность системы. Не пытайтесь уместить очень много информации в одной метрике.

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

Метрики можно использовать двумя способами:

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

2. Непрямой мониторинг — оповещения. Можно определить пороговое значение и настроить уведомления о том, что метрика пересекла этот порог.

Для работы с метриками есть две категории инструментов.

Опенсорс-проекты

Если мы хотим использовать опенсорс-решения, придётся комбинировать несколько продуктов.

1. Для сбора метрик обычно используется Prometheus. Он предлагает SDK по реализации и сбору метрик для разных языков программирования.

2. Prometheus может хранить метрики, но хранилище у него не лучшее. Если вы планируете долго хранить метрики, а система производит очень много метрик, лучше использовать Thanos. Thanos оптимизирован для долгосрочного хранения метрик Prometheus. 

3. Prometheus и Thanos позволяют визуализировать хранимые метрики, но если нам нужны расширенные возможности визуализации, стоит использовать Grafana с её продуманными дашбордами.

4. Для оповещений у нас есть Alert Manager, уже интегрированный в Prometheus, где можно определять правила. Alert Manager можно интегрировать с разными решениями для on-call.

Облачные платформы и коммерческие решения

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

У Datadog, ELK Stack и New Relic тоже есть SDK для отправки метрик и весь стек, необходимый для работы с ними.

Трассировки

В распределённых системах метрик и логов может быть недостаточно для полноценного анализа события. В этом случае используются трассировки, которые записывают информацию на протяжении всего жизненного цикла действия, включая результат, время, потраченное в каждом сервисе, и другие полезные сведения.

В нашем примере давайте рассмотрим запрос пользователя на регистрацию аккаунта:

Для этого запроса трассировка может выглядеть так:

{
   {
      "name":"example-trace-ui-microservice",
      "start_time":"2022-08-09T14:29:21Z",
      "end_time":"2022-08-09T14:29:25Z",
      "trace_id":1234,
      "span_id":1,
      "Events":[
         {
            "Name":"”send-account-microservice-request”",
            "timestamp":"2022-08-09T14:29:23Z"
         }
      ]
   },
   {
      "name":"“example-trace-account-microservice",
      "start_time":"2022-08-09T14:29:26Z",
      "end_time":"2022-08-09T14:29:30Z",
      "trace_id":1234,
      "span_id":2,
      "events":[
         {
            "name":"”get-request”",
            "timestamp":"2022-08-09T14:29:26Z"
         },
         {
            "name":"”send-database-request”",
            "timestamp":"2022-08-09T14:29:27Z"
         },
         {
            "name":"”get-database-response”",
            "result":"Success",
            "timestamp":"2022-08-09T14:29:27Z"
         }
      ]
   },
   {
      "name":"example-trace-ui-microservice-2",
      "start_time":"2022-08-09T14:29:31Z",
      "end_time":"2022-08-09T14:29:31Z",
      "trace-id":1234,
      "span_id":3,
      "events":[
         {
            "name":"”get-account-microservice-response”",
            "result":200,
            "timestamp":"2022-08-09T14:29:32Z"
         }
      ]
   }
}

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

Для распределённой трассировки доступны следующие инструменты:

1. Среди опенсорс-проектов можно выделить два: OpenTelemetry и Jaeger. Если мы хотим визуализировать трассировки, можно использовать их родные инструменты визуализации или интегрировать их с Grafana, чтобы получить больше возможностей.

2. На облачных платформах есть свои сервисы для сбора трассировок.

3. Также можно использовать решения Datadog, New Relic и ELK Stack.

Универсальное решение?

Наверное, вы уже заметили, что инструменты для наблюдаемости можно разделить на две большие категории:

1. Отдельные опенсорс-решения, которые мы собираем и настраиваем сами.

2. Сервисы на облачных платформах или сторонние стеки (Datadog, ELK Stack, New Relic).

А как насчёт опенсорс-проекта для комплексного подхода к наблюдаемости? OpenTelemetry сочетает в себе два решения для мониторинга — OpenTracing и OpenCensus — и развивается как единый инструмент для всех задач, связанных с мониторингом.

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