Мониторинг и наблюдаемость IT-инфраструктуры: практическое руководство

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

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

Мониторинг и наблюдаемость — не синонимы

Классический мониторинг отвечает на заранее сформулированные вопросы: доступен ли узел, сколько свободного места, превышена ли загрузка CPU. Он необходим, но в распределённой системе отдельный «зелёный» сервер ещё не означает исправный бизнес-сценарий.

Наблюдаемость объединяет контекст нескольких сигналов:

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

OpenTelemetry рассматривает метрики, логи и трассировки как взаимодополняющие телеметрические сигналы. Инструмент не заменяет архитектуру: поля, корреляция, хранение и ответственные всё равно проектируются командой.

Начните с критических путей

Составьте короткий список пользовательских цепочек: авторизация, создание заказа, платёж, отправка кода, формирование документа. Для каждой определите:

1. точку входа и ожидаемый результат;
2. зависимые сервисы, базы, очереди и внешние API;
3. допустимое время ответа;
4. признак успешного завершения;
5. владельца, который принимает решение при деградации.

Так появляется карта сервиса, а не каталог серверов. Для потока уведомлений полезно отдельно наблюдать очередь, принятие платформой, конечные статусы и истечение TTL. Детали транспортного уровня разобраны в сравнении SMPP и HTTP API.

SLI, SLO и SLA: разные уровни обещания

SLI — фактически измеряемый показатель: доля успешных запросов, задержка p95, свежесть данных. SLO — внутренняя цель для SLI за период. SLA — договорное обязательство и последствия нарушения.

Хороший SLI видит сервис глазами потребителя. Средняя загрузка CPU может быть полезна инженеру, но для бизнеса понятнее доля успешных платежей или уведомлений, завершившихся до заданного срока.

Сценарий	Полезный SLI	Недостаточный заменитель
Веб-сервис	Успешные ответы и p95/p99	Среднее время ответа
Очередь	Возраст старейшего сообщения	Только длина очереди
Резервное копирование	Успешное тестовое восстановление	Факт запуска задания
SMS-код	Доставка до TTL	Принятие API-запроса

Не ставьте SLO равным 100% без бизнес-обоснования: такая цель не оставляет пространства для изменений и может требовать несоразмерных затрат.

Какие данные собирать

Метрики

На уровне инфраструктуры нужны загрузка CPU и памяти, дисковые задержки, ошибки файловой системы, сетевые потери и исчерпание соединений. На уровне приложения — rate, errors и duration, размеры пулов, состояние очередей и внешних зависимостей.

Логи

Лог должен быть структурированным событием, а не абзацем текста. Полезные поля: timestamp с часовым поясом, service, environment, version, severity, event name, trace ID и безопасный correlation ID.

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

Трассировки

Распределённая трассировка связывает операции одного запроса. Контекст должен передаваться через HTTP, очередь и фоновые задания. Sampling уменьшает объём, но ошибки и редкие критичные операции стоит сохранять с более высоким приоритетом.

Как проектировать алерты

Алерт должен требовать действия. Если дежурный ничего не делает, это событие для дашборда или отчёта, а не срочное оповещение.

Для каждого алерта зафиксируйте:

• условие и окно оценки;
• бизнес-влияние;
• уровень срочности;
• ссылку на дашборд и runbook;
• владельца и маршрут эскалации;
• условие автоматического закрытия.

Предпочтительнее алерты на симптомы — рост ошибок, нарушение SLO, возраст очереди — чем на любую аномалию отдельного ресурса. Инфраструктурный сигнал остаётся полезным как причина или раннее предупреждение, но не должен создавать десятки одинаковых уведомлений.

Наблюдаемость во время инцидента

Единый correlation ID позволяет перейти от неуспешной операции к trace, затем к логам конкретного сервиса и метрикам узла. Синхронизируйте время, помечайте версию приложения и события развёртывания: без этого сложно отличить причинную связь от совпадения.

Во время расследования сохраняйте:

1. время начала и обнаружения;
2. затронутые сценарии и масштаб;
3. последние изменения;
4. гипотезы и подтверждающие сигналы;
5. принятое решение и результат;
6. последующие действия с владельцами.

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

План внедрения на четыре итерации

1. Инвентаризация

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

2. Базовые SLI

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

3. Корреляция

Передавайте trace/correlation ID, добавьте версию релиза, связывайте логи и трассировки. Проверьте поиск по одному реальному запросу.

4. Операционный цикл

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

Чек-лист качества

• Критические пользовательские пути известны и имеют владельцев.
• SLI измеряют результат, а не только загрузку ресурсов.
• Метрики, логи и traces используют единые service/environment/version.
• Персональные данные и секреты маскируются.
• Каждый срочный алерт содержит действие и runbook.
• События релиза видны на временной шкале.
• Есть контроль стоимости и срока хранения телеметрии.
• Учебный инцидент подтверждает, что данные помогают найти причину.

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

CTA: «Лоджик Телеком» может помочь описать критичные зависимости и контур наблюдаемости для корпоративной инфраструктуры. Начните с одного бизнес-сценария и проверяемого SLO, а не с бесконечного списка датчиков.