Мониторинг и логирование

На протяжении курса мы рассматривали разные архитектурные проблемы и выясняли, как сделать приложение более надёжным. Теперь перейдём к вопросу, который до этого не обсуждали прямо: а как понять, что с приложением нужно что-то делать?
Нередко о проблемах сообщают пользователи или представители бизнеса. Но если первые уже начали жаловаться на проблемы, а вторые недовольны проделанной работой, вы уже не в самой выигрышной позиции. Чтобы эффективно решить проблему, нужно быть в числе тех, кто первым её заметил. Поэтому лучше всего самостоятельно следить за состоянием приложения.
В работе с современными распределёнными системами немало сложностей и подводных камней. Их можно обнаружить на каждом этапе жизненного цикла — во время разработки, тестирования, развёртывания и запуска в производство.
Тут на помощь приходит концепция Observability. Она помогает отслеживать «состояние здоровья» сервисов и архитектуры. О методах и инструментах Observability мы будем говорить в этой теме.

Что такое Observability

✏️ Observability (наблюдаемость) — это свойство системы. Оно подразумевает, что вы можете получать информацию о внутренних процессах.
Чтобы сделать систему наблюдаемой, нужно постоянно собирать разные данные о её работе. Вот три ключевых источника информации:
  • Мониторинг — сбор бизнесовых и инфраструктурных метрик (metrics).
  • Логирование — сбор логов (logs).
  • Трейсинг — сбор трейсов внутренних вызовов (traces).
Эти данные помогают глубже понять, как работает система, а также обнаружить проблемы и найти решения.

Сергей

Какую пользу приносит наблюдаемость системы?

Рассмотрим преимущества наблюдаемости более подробно:
  • Улучшение видимости и повышение безопасности системы. Видимость означает, что вы можете получить полное представление о работе системы. Чем выше видимость, тем проще обеспечить безопасность.
  • Более быстрое решение проблем и повышение надёжности системы. С помощью инструментов наблюдения команда может быстрее определить корень проблемы. Следовательно, так её проще устранить и предотвратить в будущем.
  • Повышение быстродействия системы и распределение ресурсов. С помощью инструментов наблюдения можно выявлять узкие места. Это помогает оптимизировать производительность — вы можете проанализировать, как система работает под разными нагрузками.
  • Ускорение рабочего процесса и DevOps. Наблюдаемость способствует оптимизации процессов и сокращению количества ошибок. А это, в свою очередь, помогает ускорить рабочий процесс и улучшить взаимодействие между командами.
  • Ценные бизнес-инсайты. Когда данные, которые вы собираете благодаря наблюдаемости системы, накапливаются, они могут привести вас к бизнес-инсайтам. Они помогут вам принимать стратегические решения более обоснованно.
  • Повышение удовлетворённости пользователей. Своевременное решение проблем, которые связаны с производительностью и функциональностью приложения, улучшает пользовательский опыт.
В этом уроке мы рассмотрим две составляющие концепции наблюдаемости — мониторинг и логирование. Начнём с мониторинга.

Мониторинг

Мониторинг — необходимая составляющая любой архитектуры. Его используют повсеместно — как для разработки и поддержки социальных сетей, так и для создания ПО для Интернета вещей (Internet of Things, IoT).
В сфере программного обеспечения много видов мониторинга. Например:
  • мониторинг производительности,
  • мониторинг безопасности,
  • сетевой мониторинг,
  • мониторинг базы данных.
И это далеко не полный список. Основа любого мониторинга — это метрики.

Метрики для мониторинга

✏️ Метрики представляют собой агрегированные или одиночные данные о том, как себя чувствуют сервисы. Обычно метрика выражается одним числом, которое отслеживают в динамике.
Можно отслеживать три типа метрик.
  1. Показатели системного уровня. К таким метрикам относится потребление ресурсов процессора, памяти и диска.
Эти метрики могут отображаться так:
  • счётчик — количество запросов за определённый период времени,
  • Latency — задержка, связанная с запросами,
  • индикатор — загрузка процессора.
  • Метрики производительности. Например:
    • Response time — время отклика системы,
    • Error rate — количество ошибок.
  • Бизнес-метрики. Каждая организация сама определяет для себя набор бизнес-метрик, которые стоит отслеживать. Например, компания может мониторить:
    • DAU — количество уникальных пользователей за день,
    • Retention — возвращаемость пользователей.
Каждый показатель отслеживает только одну переменную. Желательно, чтобы её хранение и отправка стоили относительно дёшево.
Набор показателей, которые нужно отслеживать в рамках мониторинга, обычно определяют команда DevOps, SRE-инженер и продакт-менеджер. Этот набор может варьироваться в зависимости от сервиса и его общей зрелости. Для MVP, скорее всего, будет что-то совсем простое. А вот для легаси потребуется разветвлённая панель, чтобы хоть как-то поймать очередной факап.
Зачастую команды просматривают панели мониторинга показателей тогда, когда они поставляют новое исправление или релиз. Такой контроль нужен, чтобы оперативно откатить изменения в случае проблем, а не узнать о них от пользователей поздно ночью.
Метрики можно собирать двумя способами.
Во-первых, с помощью инструментов мониторинга, которые разработчики подключили к приложению. Некоторые метрики собирают не напрямую, а на основе других данных. Например, возвраты пользователей, доход или общий процент ошибок системы получают на основе запросов и логов.
Во-вторых, некоторые метрики можно получить от сторонних систем. Например, от Яндекс Метрики.
Метрики можно анализировать и визуализировать с помощью разных инструментов. Например, Grafana или Kibana. Ещё можно настроить уведомления, которые система отправит в случае каких-то определённых изменений.
Так выглядит дашборд с визуализацией данных мониторинга в Grafana. Здесь видно, как менялись показатели с течением времени
Итак, поговорили про виды мониторинга и про метрики. Теперь расскажем, из каких этапов состоит процесс мониторинга.

Этапы мониторинга

Процесс мониторинга не всегда выглядит одинаково. Это зависит от того, какую систему или какое приложение вы собираетесь мониторить и что вы будете отслеживать. Например, банковские системы делают упор на мониторинг безопасности и надёжности. А для соцсетей важнее отслеживать надёжность и быстродействие.
В большинстве случаев мониторинг состоит из пяти этапов:
Этап 1. Определить, какие данные нужно собрать
Этот этап — подготовительный. В зависимости от типа мониторинга вам потребуются разные данные. Если проводите мониторинг безопасности, вам необходимы данные об активности внутренних и внешних пользователей, сканирование на проникновение и так далее. А для мониторинга производительности нужны данные с серверов.
Системе обычно нужен не один вид мониторинга, но об этом часто забывают. Есть много разных метрик. Если компания отслеживает только загрузку CPU, можно сказать, что мониторинга у неё нет вообще.
Этап 2. Собрать данные
На этом этапе используют разные инструменты мониторинга. Например, агенты, фреймворки и стороннее ПО для отправки метрик. Эти инструменты собирают данные из различных источников — из журналов или внешнего API.
Обычно данные собирают в режиме реального времени. Это позволяет оперативно обнаружить проблему и отреагировать на неё.
Этап 3. Отправить данные на хранение
Когда вы собрали информацию, её нужно отправить в хранилище, которое будет агрегировать данные мониторинга. Это можно сделать двумя способами:
  • по модели push — вы отправляете данные во внешнюю систему синхронно или асинхронно.
  • по модели pull — у вас кто-то забирает данные.
В роли хранилища может выступать база данных. Например, InfluxDB или ClickHouse, если вы собираете аналитику. Обычно данные хранят в формализованном и структурированном формате. Так их будет проще запрашивать в дальнейшем.
Этап 4. Проанализировать данные
На этом этапе инструменты мониторинга обрабатывают собранные данные, чтобы обнаружить тенденции, закономерности и проблемы.
Анализ можно выполнять разными способами. Например, с помощью ИИ-инструментов, через проверку порогового значения, через агрегацию или как-то иначе.
Затем информацию можно визуализировать с помощью какого-то инструмента Business Intelligence (BI). Или на основе данных отправлять какие-либо уведомления.
Этап 5. Сформировать отчёт
Результаты анализа обычно представляют в виде отчётов, сводных таблиц или оповещений. Эти данные помогают оценить производительность и поведение системы. А главное — выявить проблему до того, как она станет критической.
Не всегда нужно придумывать решение с нуля. В сфере мониторинга есть проверенные методологии, которые помогают контролировать разные аспекты систем. Дальше посмотрим, какие подходы к мониторингу существуют и чем они отличаются друг от друга.

Основные подходы к мониторингу

Есть несколько базовых подходов к мониторингу, которые обычно используют в технической плоскости. Их можно применять и для бизнеса, но придётся адаптировать.
Это методы:
  • USE,
  • Четыре золотых сигнала,
  • RED.
Рассмотрим эти методы по порядку.

USE

Этот метод разработал Брендан Грегг — компьютерный инженер и признанный эксперт в области повышения производительности вычислений.
Сам создатель метода описывает его так:
«Я разработал метод USE, чтобы научить других, как быстро решать общие проблемы производительности, не забывая о важных областях. Я хотел, чтобы метод был похож на чек-лист чрезвычайной ситуации в руководстве по лётной эксплуатации. То есть — простым, прямолинейным, полным и быстрым».
Суть метода состоит в том, чтобы для каждого ресурса проверять три ключевых показателя. Они отражены в названии подхода:
  • Utilization (утилизация) — это среднее время, которое ресурс занят работой. Измеряется в процентах.
  • Saturation (насыщенность) — объём работы, которую ресурс не может выполнить и вынужден откладывать (например, в очередь), чтобы сохранять работоспособность. Насыщенность можно измерить как длину очереди.
  • Errors (ошибки) — количество ошибок.
Когда использовать этот метод? Метод USE лучше всего работает с ресурсами, производительность которых снижается при интенсивном использовании. К ним относятся серверы и инструменты. А вот с ресурсами, которые используют кэширование, он работает плохо, потому что сложно определить нужные показатели.
В зависимости от того, чью производительность вы отслеживаете, в эти три категории будут попадать разные метрики.

Сергей

Пример

Например, для RAM (оперативная память) нужно отслеживать:
  • Процент использования — эта метрика показывает утилизацию.
  • Память SWAP — показывает насыщенность.
  • Ошибки при работе RAM.
А вот пример метрик, которые помогут отслеживать производительность сервиса:
  • Процент загрузки ресурсов сервера — для утилизации.
  • Очередь или замедление работы из-за постепенного «переваривания запросов» — для насыщенности.
  • Количество ошибок при обработке запросов.
Более подробно о методе USE можете почитать в блоге Брендана Грегга.

Четыре золотых сигнала от Google

SRE-инженеры Google определили четыре основных сигнала мониторинга. Это задержка, трафик, ошибки и насыщенность.
  • Задержка — **это время, которое уходит на доставку запроса по сети от отправителя к получателю.
  • Трафик — это показатель активности пользователей в вашем приложении. Его можно измерить с помощью любого высокоуровневого системного показателя. В веб-приложениях трафик обычно считают как количество HTTP-запросов в секунду.
  • Ошибки — это частота неудачных запросов. Сюда относятся как явные ошибки (например, ошибки с кодом 500), так и неявные — например, статус запроса 200, но контент доставили неправильно.
  • Насыщенность — этот параметр показывает, насколько «заполнена» ваша система. Насыщенность напрямую связана с показателем использования системы, но иногда её сложно измерить. Сбои могут возникнуть даже тогда, когда система не загружена на сто процентов. Поэтому важно определить целевой уровень использования.
Насыщенность по-разному измеряют для разных систем. Например, для серверов можно использовать процент использования памяти. А для баз данных и приложений потоковой передачи данных — скорость дискового ввода-вывода.
Когда использовать этот метод? Метод золотых сигналов в целом подойдёт любой системе, которая связана с предоставлением API. Он позволяет заметить аномалии в работе заранее и быстро среагировать на ситуацию.
Визуализация мониторинга по методологии четырёх золотых сигналов в Grafana
В следующих уроках мы рассмотрим конкретные инструменты для мониторинга.

RED

Это ещё один популярный метод мониторинга. Его предложил Том Уилки — CTO Grafana и член команды Prometheus. RED тесно связан с подходом «четырёх золотых сигналов». Фактически Том Уилки переосмыслил методологию Google.
Название этого метода, как и название метода USE, является акронимом. Его можно прочитать как обычное слово, но на самом деле это аббревиатура. Она содержит названия трёх показателей:
  • Requests Rate — частота запросов,
  • Errors — ошибки,
  • Duration — длительность.
Посмотрим внимательнее на каждый показатель.
Requests Rate
Это количество запросов, которые обслуживает ваш сервис в секунду. Частота запросов даёт представление о пропускной способности сервиса.
Эта метрика может помочь избежать сбоев — вы будете отслеживать пиковый трафик и сможете прогнозировать, сколько нужно ресурсов.
Errors
Это количество неудачных запросов в секунду. Ошибки напрямую влияют на взаимодействие с потребителями. Следовательно, отслеживать частоту ошибок просто необходимо.
Иногда система определяет как ошибки неправильные, неполные или неожиданные запросы пользователей. В таких случаях определение точной причины ошибок нередко превращается в сложный квест для технических команд. Приходится глубоко погружаться в код приложения или изучать логи — второй источник данных в концепции наблюдаемости.
Duration
Это количество времени, которое уходит на выполнение одного запроса. Чтобы измерить продолжительность в контексте сервисов, обычно используют распределённую трассировку.
Если в двух словах, то распределённая трассировка позволяет отслеживать запрос пользователя в разных сервисах и измерять время, которое заняли события в каждом сервисе. Jaeger — один из самых популярных инструментов для трассировки.
Когда использовать этот метод? Метрики RED измеряют показатели, которые важны для конечных пользователей ваших сервисов. Этот подход можно использовать для мониторинга веб-сервисов, запросов к базам данных, очередей и других подобных систем.
RED эффективен только для сервисов, которые управляются запросами. Он не подходит для сервисов, которые ориентированы на пакетную обработку или потоковые данные.
Например, метод RED отлично подойдёт для мониторинга сервиса скидок в маркетплейсе. Там нет пакетной обработки, важна скорость и минимум ошибок.
Скоро перейдём к следующему компоненту наблюдаемости — логированию. Но перед этим ответьте на несколько вопросов и проверьте, что вам удалось запомнить о мониторинге.

Задание 1

Какая метрика помогает оценить производительность веб-приложения и определить, насколько быстро оно отвечает на запросы пользователей?

Задание 2

Какая метрика показывает, как часто пользователи сталкиваются с ошибками при взаимодействии с сервисом?

Задание 3

Какую из метрик стоит использовать, чтобы определить, насколько эффективно распределяются ресурсы в системе, и выявить узкие места, связанные с насыщенностью?

Задание 4

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

Задание 5

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

Логирование

✏️ Лог — это запись в хранилище (например, в файле или в базе данных), которая содержит информацию о состоянии системы в конкретный момент времени.
Соответственно, логирование — это ведение журнала логов, который фиксирует, как состояние системы изменяется с течением времени.
Логи помогают при отладке разных компонентов приложения, а также позволяют собирать и анализировать данные о работе системы. Это помогает обнаружить ошибки. Ещё логи — это один из источников информации для мониторинга.
Мониторинг и логирование преследуют общую цель. Они помогают сформировать представление о состоянии приложения. Если использовать эти подходы вместе, они смогут компенсировать ограничения друг друга и вы получите более полную картину. Например, система мониторинга прислала алёрт. Можно сразу посмотреть ошибки из логов. Тогда вы быстрее установите причину проблемы.

Уровни логов

Есть несколько классификаций логов. Логи можно разделить по типам в зависимости от того, какую информацию они фиксируют. Например, есть логи аудита, системные логи и так далее.
Ещё можно разделить логи на типы в порядке критичности и полноты информации, которую они предоставляют. Это называют уровнями логов. Их всего шесть:
  • FATAL — отказ сервиса или оборудования.
  • ERROR — ошибочное состояние. Например, «Пользователь заблокирован».
  • WARN — состояние, которое близко к нестандартному поведению системы. Например, «Пользователь неправильно ввёл пароль».
  • INFO — это штатное поведение. Такие логи обычно используют для записи обычных сообщений. Например, «Данные загружены».
  • DEBUG обычно используют для отладки. На продакшн-серверах их не используют, чтобы не засорять логи лишней информацией.
  • TRACE обычно используют в среде разработки и для отладки в тестовом окружении.
Уровень критичности логов настраивает разработчик системы. Логи легко добавить, но главное — не перестараться: они занимают место. Важно определить, сколько логов какого типа вы будете хранить и в каком виде. Логи безопасности обычно хранят дольше, а вот логи работы сервиса — не больше месяца.

Как собирать логи

Логи можно собирать по-разному. Выбор способа зависит от того, какую систему или какое приложение вы собираетесь логировать. 
Логи можно собирать через:
  • Логирование приложений. Фреймворки для построения сервисов обычно имеют встроенные инструменты логирования. Они позволяют разработчикам регистрировать сообщения разного уровня важности и распределять их по категориям.
  • Системное логирование. Операционные системы и сетевые устройства часто предоставляют собственные механизмы логирования. Они позволяют отслеживать системные события. Например, в Linux есть утилита dmesg, которая позволяет читать сообщения, возникающие во время загрузки системы.
  • Логирование с помощью агентов. Многие инструменты и сервисы логирования предлагают агенты или библиотеки, которые можно установить в системы или приложения для сбора логов. Один из таких инструментов — Logstash. Мы рассмотрим его в следующих уроках.
  • Контейнерное логирование. Приложения, работающие в контейнерах на платформах типа Kubernetes, создают логи, которые специфичны для среды контейнера.

Задание 6

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

Задание 7

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

Итоги

  • Observability, или наблюдаемость, — это свойство системы или приложения, которое выражается в возможности получать информацию о внутренних процессах. Чтобы повысить наблюдаемость системы, нужно собирать и анализировать данные из трёх источников: через мониторинг, логирование и трейсинг. В этом уроке мы рассказали про два из них.
  • Мониторинг — это отслеживание метрик. Метрика — это агрегированные или одиночные данные о том, как себя чувствуют сервисы. Обычно метрика выражается одним числом, которое отслеживают в динамике. Метрики бывают трёх основных видов: показатели системного уровня, показатели производительности и бизнес-метрики. Процесс мониторинга обычно состоит из пяти этапов. Сначала нужно определить метрики, которые вы будете отслеживать, затем собрать данные, отправить их в хранилище, проанализировать информацию и сформировать отчёт.
  • Логирование — это ведение журнала логов. Лог — это запись в хранилище, которая содержит информацию о состоянии системы в конкретный момент времени. Логи делятся на типы в зависимости от данных, которые они фиксируют, или в зависимости от критичности и полноты информации в них. Последняя классификация предполагает шесть типов логов: FATAL, ERROR, WARN, INFO, DEBUG, TRACE. В разных видах приложений и систем логи собирают по-разному. Для этого есть как встроенные, так и внешние инструменты.
В следующем уроке мы разберём, как собирать и визуализировать метрики с помощью Prometheus и Grafana.