Как на практике выглядит идея Observability

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

Уже пару лет я наблюдаю, как на рынке постепенно набирает обороты концепция observability. Observability (Обсервабилити) - это совмещение инструментов наблюдения за продуктом, в частности, мониторинга и логирования, которое позволяет подняться на следующий уровень абстракции над конкретными метриками и увидеть состояние системы в целом.
Параллельно на рынке появляются реальные проекты, где обозримость востребована и видны ее преимущества. В этой статье расскажу о том, как вижу эту концепцию, зачем она нужна и какие дает результаты.

Работу цифровых сервисов необходимо контролировать:
— Сервис мониторинг помогает отслеживать любые метрики — программного обеспечения, оборудования, виртуальных серверов — в формате графиков, алертов и т. п. Метрики пишутся в базу данных в полном объеме или в сокращенном виде — после предварительной обработки. Разносторонние метрики помогают фиксировать проблемы с сервисами или оборудованием, на котором они запущены.
— Сервис сбора логов собирает в единое хранилище журналы работы различных инструментов — базового ПО, операционной системы, железа и т. п. — предоставляя удобные инструменты поиска и обработки этих данных. Логирование помогает находить и устранять причины инцидентов, оптимизировать работу инструментов и т. п.
— Веб Трейсы в дополнение к данным мониторинга помогают отследить пути запросов в системе и структуру этих запросов.

Еще несколько лет назад можно было себе представить крупный сервис с мониторингом, но без логирования и трейсинга (или наоборот). Но постепенно индустрия пришла к пониманию, что эти компоненты дополняют друг друга, особенно при поддержке больших проектов. А сейчас эти инструменты объединяются в общую концепцию observability, которая обеспечивает дополнительные преимущества за счет семантических связей между компонентами.

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

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

На рынке уже появляются инструменты, которые объединяют в себе эти функции. В 2023 году Gartner видел этот рынок примерно так:

Но внедрять новый инструмент - не всегда хорошее решение. Практика наших проектов показала, что на существующих (и принятых в индустрии) инструментах вполне можно построить неплохую практическую реализацию observability, по крайней мере так, как ее понимаю я.

Обычно мониторинг, логирование и трейсинг обеспечивается служебным ПО, которое как правило размещается “вокруг” части с бизнес-логикой. И если бизнес-логику еще имеет смысл разрабатывать собственными силами по ТЗ, то для сопутствующих задач проще использовать готовые инструменты, которые позволят анализировать и строить гипотезы.

Для сбора метрик зачастую используется Prometheus и Telegraph. Для визуального отображения - Grafana, которая позволяет строить дашборды, собирая на один экран метрики разных сервисов или оборудования. Например, можно вывести на одном экране потребление памяти и количество запросов на сервис, сравнивая их визуально.
Для сбора логов популярен ELK-стек - Elasticsearch, Logstash, Kibana. С его помощью логи также можно анализировать визуально, настраивать алерты и т.п. А трейсы собирают и обрабатывают при помощи Jaeger, Zipkin, SigNoz и Elastic APM.

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

Приведу несколько примеров:

Допустим, мы можем взять лог php и в качестве метрики выводить на дашборд его ошибки, сравнивая их с нагрузкой на железо, либо с использованием пулов самого php. Попробуем раскрыть эту идею подробнее на примере nginx + php.

В подобных проектах для nginx желательно использовать плагин VTS. Он позволяет снимать расширенные метрики работы nginx, такие как время ответа и коды ошибок для каждого апстрима.
Для php-fpm есть прекрасный php-fpm exporter, который позволяет снимать обширный пул метрик с php. Из них наиболее полезные в диагностике проблем — это использование пулов, времени ответа, средняя общая утилизация и текущее количество дочерних процессов.

Комбинируя необходимые метрики в виде графиков, можно создать ряд дашбордов, в частности, можно вывести на один дашборд:
— показания самой машины (процессора, памяти, сети)
— показания необходимых апстримов веб-сервера (количество запросов, код ответа)
— показания php-fpm (количество запросов, использование пулов, времени ответа)
С таким дашбордом сразу будет понятно, с каким апстримом возникли проблемы и почему. Если это был всплеск трафика и сайт не справился с нагрузкой, мы увидим повышение сетевой активности на графиках, увеличение количества запросов и уменьшение количества свободных пулов php-fpm. Если повышения сетевого трафика нет, но есть повышение нагрузки на процессор, то на графиках php-fpm будет видно возросшее время ответа, что говорит об однотипных долгих запросах в php, которые приводят к исчерпанию доступных подключений в пулах.

В моей практике был проект, когда мы долго и мучительно искали источник проблемы, а по факту им оказались как раз ошибки php, непокрытого мониторингом. Будь у нас тогда под рукой подобный дашборд, потратили бы гораздо меньше времени.

Предположим, MySQL неожиданно завершает работу и веб-приложение перестает отвечать.

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

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

Допустим, потребители получают не все данные из Kafka. Анализ проблемы ускоряет быстрый доступ к метрикам:
— задержки между продюсерами и потребителями;
— размера очередей;
— времени обработки сообщений;
— ошибок подключений.

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

Например, мы выявили проблему - значительное замедление выполнения поисковых запросов. Анализ проблемы можно провести с помощью мониторинга:
— использования дискового пространства,
— количества запросов на чтение и запись (IOPS),
— времени отклика нод Elasticsearch,
— состояния кластеров (например, количества реплик и шардов).
Предположим, мы видим, что одна из нод перегружена запросами на запись. Решение может включать перераспределение шардов на другие ноды или увеличение мощности узлов. Также можно оптимизировать настройки кэширования и уменьшить количество реплик, чтобы снизить нагрузку на дисковую систему.

В базе данных PostgreSQL часто возникают дедлоки (deadlocks) между транзакциями, что замедляет обработку данных и приводит к ошибкам в приложении. Чтобы избежать этой проблемы можно следить за:
— метриками блокировок транзакций;
— временем выполнения SQL-запросов;
— причинами дедлоков.
В то же время логирование PostgreSQL помогает идентифицировать конкретные транзакции, которые вызвали дедлок.

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

Допустим, приложение работает медленно, а пользовательские запросы к базе данных занимают больше времени, чем обычно. Использование трассировки и метрик позволяет отслеживать медленные запросы (slow queries) в MySQL. Observability система может фиксировать такие параметры, как время выполнения запросов, количество блокировок (locks), использование CPU и RAM.
На основании метрик вполне может обнаружится, что один из SQL-запросов выполняется слишком долго и создает блокировки других операций. Проведя анализ slow query log и оптимизировав запрос (например, добавив индекс или изменив структуру таблицы), можно значительно улучшить производительность базы данных и сократить время ответа.

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

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