Метрики, логи и трассировка
Что это такое
Три вида сигналов отвечают на разные вопросы. Метрика — это число, замеренное во времени и достаточно дешёвое, чтобы хранить его месяцами, поэтому она подходит для трендов и порогов. Лог — запись об одном событии с той подробностью, какую решил включить автор, поэтому он подходит, чтобы понять, что произошло в конкретном случае. Трассировка прослеживает один запрос через все сервисы, которых он коснулся, поэтому она подходит, чтобы найти, куда ушло время. Наблюдаемость — это практика иметь достаточно всех трёх, связанных одними и теми же идентификаторами.
Почему это важно
Команды обычно начинают с логов, потому что они даются бесплатно, а потом обнаруживают, что объём неуправляем, а на вопрос, который у них на самом деле есть — это нормально? — записью об отдельных событиях не ответить. Метрики отвечают на этот вопрос дёшево, но они агрегированы и теряют подробность, нужную для диагностики одного отказа. Трассировки закрывают недостающую середину, показывая путь и его тайминги. Навык — выбирать сигнал по вопросу, а не по тому, какой сигнал уже есть.
Ключевые идеи
Метрики дешёвы, агрегированы и хороши для трендов
Метрика — это именованный временной ряд с метками, которые различают его измерения. Поскольку это число, его можно хранить с высокой частотой и долго и сравнивать с порогом. Чего метрика не может — сказать, почему: доля ошибок говорит, что что-то падает, но не говорит, какой запрос или какой клиент.
http_requests_total{route="/checkout", status="500"} 12
http_requests_total{route="/checkout", status="200"} 3418
Метки делают метрики мощными и дорогими
Метки разбивают ряд на измерения, и каждая отдельная комбинация — это отдельный ряд. Метка с неограниченным множеством значений — идентификатор пользователя, идентификатор запроса — порождает взрыв рядов, которые съедают память и хранилище, ничего не отвечая. Правило — помечать измерениями, по которым вы будете группировать: маршрут, статус, регион, инстанс, и никогда — идентичностью.
Логи должны быть структурированными, а там, где их много, — с выборкой
Структурированный лог с согласованными полями можно запрашивать, считать и соединять; строку свободного текста можно только читать. Информационные логи большого объёма лучше хранить с выборкой или в сводном виде, чем целиком, а подробные — за короткое окно. Срок хранения — это решение о затратах, и принимать его следует явно, а не по умолчанию.
Трассировка показывает путь и его тайминги
Запрос получает идентификатор корреляции в точке входа, и каждый сервис, через который он проходит, записывает свой участок (span) с началом, длительностью и родителем. Результат — дерево, которое показывает, где потрачено время и где произошёл отказ; это единственный практический способ диагностировать проблему, размазанную по пяти сервисам.
Три сигнала связываются идентификаторами
Идентификатор трассировки в строке лога и метрика, разбитая по маршруту и статусу, позволяют одному расследованию переходить между сигналами: оповещение срабатывает по метрике, трассировка показывает, какой шаг был медленным, а логи этого шага — ошибку. Без общих идентификаторов эти три сигнала остаются раздельными системами, и расследование начинается заново в каждой.
Хранить каждую трассировку дорого, поэтому трассировки берут с выборкой: часть из них, с большим вниманием к ошибкам и медленным запросам. Поскольку решение о выборке принимается в точке входа и распространяется дальше, выбранный запрос записан целиком, а не частично. Знать долю выборки важно, когда число из трассировок сравнивают с числом из метрик.
Инструментируйте то, о чём будете спрашивать
Полезные метрики — обычно частота запросов, доля ошибок, длительность и насыщение для каждого сервиса плюс небольшое число метрик про бизнес. Дашборд из графиков процессора хостов отвечает на вопрос, который во время инцидента никто не задавал. Инструментирование четырёх золотых сигналов сначала покрывает большинство инцидентов.
Практика
Добавьте четыре сигнала одному сервису
Инструментируйте сервис количеством запросов, количеством ошибок, задержкой и мерой насыщения, каждую — с метками маршрута и статуса.
Готово, когда: график может показать долю ошибок и задержку для одного маршрута за час, а в наборе меток нет неограниченных значений.
Проследите один запрос
Возьмите запрос, который проходит через два сервиса, запишите идентификатор корреляции в логах обоих сервисов и проследите его от строки лога до трассировки.
Готово, когда: вы можете назвать каждый сервис, которого коснулся запрос, и сколько занял каждый шаг.
Частые ошибки
- Метка метрики с идентификатором запроса или пользователя — число рядов взрывается; исправить: помечайте маршрутом, статусом и подобными ограниченными измерениями.
- Логировать всё большим объёмом и навсегда — хранилище растёт, а находится быстрее ничего; исправить: структурируйте логи, берите выборку из шумных и задавайте срок хранения осознанно.
- Выбирать сигнал по удобству, а не по вопросу — дашборд не может ответить на то, что спрашивают; исправить: берите метрики для трендов, логи для подробностей, трассировки для путей.
- Трассировать без распространения идентификатора — трассировки частичны и непригодны; исправить: распространяйте идентификатор корреляции через каждый вызов.
- Инструментировать хосты вместо сервисов — график зелёный, пока приложение падает; исправить: инструментируйте путь запроса и четыре сигнала.
Что читать дальше
- Мониторинг и наблюдаемость (Prometheus / Grafana) (06-cloud-devops/18-monitoring-observability-prometheus-grafana) — дисциплина, из которой состоят эти три сигнала.
- Дашборды и оповещения (06-cloud-devops/18-monitoring-observability-prometheus-grafana/02-dashboards-and-alerting) — что делать с сигналами, когда они уже есть.
- Администрирование Linux (06-cloud-devops/09-linux-administration) — чтение логов по каждому хосту, которое этот трек масштабирует.