С вас вопросы, с нас ответы. Часть 8

Главное правило: лог — это последовательность операций.

• Забудьте про Plain Text. Фраза User logged in прекрасна, пока у вас один пользователь. В проде используйте структурированный JSON. Добавляйте в логи контекст (какой пользователь, откуда пришел, какая у него роль, user-agent и так далее). Богатый контекст лога ой как пригодится при расследовании нетривиальных инцидентов, когда окажется, что ошибка возникает только у пользователей, которые не обновили приложение, хотя им об этом напоминали 2 года подряд.
• Используйте OpenTelemetry для контекста. Вместо того чтобы вручную прокидывать ID везде, используйте OTel SDK. Он автоматически подмешает TraceId и SpanId в ваши логи. Теперь, найдя ошибку в Elastic/Loki/VictoriaLogs или другом хранилище, вы в один клик перейдете к трейсу в Tempo и увидите весь путь выполнения запроса.
• Уровни логирования. Прекратите пихать в ERROR всё, что вам не нравится. Если база временно недоступна, но есть ретраи — это WARN. Если всё упало окончательно — вот тогда выбирайте ERROR.

Ориентируйтесь на 4 золотых сигнала. Они покрывают большинство кейсов для технических метрик сервисов.

1. Latency: Насколько долго мы заставляем пользователя страдать? Измеряйте квантили (p95, p99), а не среднее арифметическое. Средняя температура по больнице 36.6, даже если половина пациентов в морге.
2. Traffic: Какой объем запросов мы перевариваем (RPS).
3. Errors: Как часто мы отвечаем 500-ками.
4. Saturation: Насколько забит пул соединений к БД или очередь сообщений.

Prometheus — это стандарт де-факто для сбора метрик. Более того, это уже имя нарицательное. Вы можете использовать VictroriaMetrics для метрик и все равно называть это сбором метрик по модели prometheus.

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

Конечно же при росте объемов метрик задуматься о нагрузке уже придется.

Это современный индустриальный стандарт для построения по-настоящему наблюдаемых систем.

OpenTelemetry (OTel) — это не база данных, не конкретное техническое решение. Это стандарт и набор инструментов (SDK + Collector) для сбора всего: логов, метрик и трейсов, и даже профилей.

В чем кайф? Вы один раз инструментируете код с помощью OTel SDK. Если завтра вы решите уйти из дорогого Datadog в условно бесплатный Grafana-стек, вам нужно будет только поменять конфиг в OTel Collector, а не переписывать тысячи строк кода в 2000 сервисов.

Потому что их пишут люди, а читают… тоже люди в состоянии стресса (и ИИ агенты, конечно).

• Проблема: Ошибка без контекста. NullPointerException бесполезен без контекста.
• Решение: Внедрите атрибуты OpenTelemetry. Каждый лог должен автоматически обогащаться данными о среде (env), версии сервиса и, главное, контекстом выполнения. Если вы не можете по логу восстановить всю цепочку событий в микросервисах — ваши логи просто дорогой поток байт, сливающий бюджеты на диски или s3 в облаке или on-prem.

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

• Никогда не пишите user_id, order_id или email в лейблы (labels) метрик Prometheus. Каждое уникальное значение создает новый временной ряд (Time Series).
• email , user_id так же не стоит писать, потому что это можно иногда отнести к персональным данным, обработка которых строго регулируется.

Поздравляем, у вас Alert Fatigue (усталость от алертов). Если в канале 100+ уведомлений в день, значит, алертов у вас ноль. Никто не будет следить за таким потоком и один единственный важный алерт обязательно будет пропущен.

• Удалите алерты по CPU/RAM. Сервер может быть загружен на 90% и прекрасно работать.
• Настройте алертинг по SLO на основе бизнес метрик. Если пользователи не могут оплатить заказ или поиск длится больше 2 секунд - вот тогда будите дежурного. Всё остальное - просто шум, который подождет до утра.
• Нужны технические метрики? Делайте алертинг на основе 4-х золотых сигналов. Все уже придумано за нас.

Хороший алерт должен включать:

1. Суть: Что сломалось и на кого влияет?
2. Срочность: Это пожар или подождет до завтра? А если подождет, то нужен ли такой алерт?
3. Runbook: Ссылка на конкретную инструкцию. Дежурный не должен в 3 часа ночи вспоминать нюансы починки конкретной вундервафли, про существование которой узнал из алерта минуту назад. Сервисы могут быть очень (!) сложными.
4. Dashboard: Ссылка на уже отфильтрованную панель в Grafana.

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

1. Поставьте коллектор рядом с приложением.
2. Подключите автоматическую инструментацию (для Java это просто javaagent, для Python — opentelemetry-instrument).
3. Вы начнете видеть дерево вызовов (те самые трейсы) и поймете, на каком именно SQL-запросе виснет ваша система, даже не меняя код приложения.

Не пытайтесь за один квартал внедрить трейсинг во все системы.
Шаг 1: Сбор базовых метрик (RPS, Error Rate) через Prometheus.
Шаг 2: Централизация логов в Grafana Loki.
Шаг 3: Внедрение OpenTelemetry для распределенной трассировки. Именно здесь магия: вы увидите, как запрос проходит сквозь всю вашу систему.