Состояние видно только в логах сервера
Ошибки пишутся в файл, который никто не открывает. Первым тревогу поднимает клиент, у которого не прошёл платёж, а не система.
Мониторинг и производительность
Об отклонении сообщает мониторинга не клиент
Настраиваем наблюдаемость на всех уровнях: доступность и время ответа, трассировка запросов, медленные SQL, ошибки в браузере. Алерт приходит дежурному инженеру вместе с контекстом, а не в виде сообщения «сайт не работает».
-
30 секчастота внешних проверок доступности
-
P95/P99перцентили вместо среднего
-
5 минот отклонения до дежурного
-
1 экрансводка по всем сервисам
Дежурный экран · пример сводки
P95 времени ответа
оформление заказа
Проверки проходят
12 недель назад
порог 1,5 с
сейчас
Внешние проверки · каждые 30 секунд
- Оформление заказа 1,2 с
- Личный кабинет 0,9 с
- API для партнёров 1,4 с
- Обмен с 1С ок
Алерты дежурному
-
P95 API для партнёров 1,4 с — близко к порогу 1,5 с
предупреждение · рабочее время
-
Медленный запрос к таблице заказов: 2,8 с, запрос в цикле
инцидент · дежурный, 5 мин
Пример сводки. Показатели вашей системы и пороги определим на инвентаризации — за 3–5 дней.
Prometheus
Grafana
Loki
OpenTelemetry
APM и трассировка
внешние проверки доступности
P50 / P95 / P99
журнал медленных запросов
очереди и воркеры
кэш и попадания
ошибки JavaScript на клиенте
Core Web Vitals
алерты и дежурный канал
эскалация по SLA
подавление связанных уведомлений
нагрузочные учения
Разберём вашу ситуацию
Расскажите, из каких сервисов состоит продукт и что уже вызывает тревогу. Предложим набор метрик, порогов и алертов под ваши критичные сценарии.
-
Инвентаризация
3–5 дней
-
Метрики и пороги
1–2 недели
-
Алерты и дежурство
3–5 дней
Разбор ситуации
Оставьте контакт — вернёмся с набором метрик, порогов и алертов под ваши критичные сценарии.
Симптомы
Почему о деградации узнают последними
Собираем типичные причины из проектов, где мониторинг либо отсутствовал, либо был настроен формально.
Медленные запросы к базе никто не ищет
Страница каталога открывается семь секунд, потому что запрос выполняется в цикле. Проблема растёт вместе с базой и однажды становится отказом.
Алерты настроены на всё сразу
Уведомления сыплются десятками в час, включая «диск занят на 62%». Через неделю их перестают читать, и настоящий инцидент проходит незамеченным.
Нет базовой линии для сравнения
«Стало медленнее» — единственная формулировка проблемы. Непонятно, когда началась деградация, какой релиз её вызвал и насколько хуже стало на самом деле.
Клиентская часть вне наблюдения
Сервер отвечает за 200 миллисекунд, а страница у пользователя грузится шесть секунд из-за тяжёлого скрипта и картинок. Метрики этого не видят.
Пик нагрузки выясняется в день распродажи
Ограничения по одновременным соединениям, лимиты воркеров очередей и параметры пула соединений к базе проверяются не заранее, а под реальной нагрузкой.
Уровни наблюдения
Что попадает под наблюдение
Набор уровней подбираем под архитектуру: монолит на виртуальной машине и набор сервисов в Kubernetes требуют разных метрик.
Доступность извне
Проверяем сервис так, как его видит пользователь, а не только с точки зрения сервера.
Что настраиваем
- HTTP-проверки ключевых сценариев каждые 30 секунд с нескольких площадок
- Проверка не только кода ответа, но и содержимого: наличие ожидаемого блока на странице
- Контроль срока действия TLS-сертификатов и делегирования доменов
- Проверка внешних зависимостей: платёжный шлюз, служба доставки, обмен с 1С
Производительность приложения
Измеряем время обработки запросов внутри приложения и раскладываем его по этапам.
Что настраиваем
- Перцентили P50, P95 и P99 по каждому значимому маршруту
- Трассировка медленных запросов: какой код, какой запрос, что заняло время
- Доля ошибок 5xx и исключений с группировкой по типу
- Время выполнения фоновых задач и очередей, длина очереди и число сбоев
База данных и кэш
Чаще всего узкое место находится именно здесь, а не в коде приложения.
Что настраиваем
- Журнал медленных запросов с порогом под ваш профиль нагрузки
- Запросы без индексов, запросы в цикле, лишние выборки в ORM
- Эффективность кэша: доля попаданий, объём, частота сброса
- Блокировки, долгие транзакции и рост размера таблиц
Клиентская часть
То, что реально чувствует пользователь, включая мобильные устройства и слабые сети.
Что настраиваем
- Метрики загрузки страницы: время до первого байта, отрисовка, сдвиг вёрстки
- Ошибки JavaScript на реальных устройствах с привязкой к версии сборки
- Вес и количество ресурсов, влияние сторонних скриптов
- Скорость отклика интерфейса на действия пользователя
Метрики и перцентили
Метрики, по которым видно деградацию
Среднее арифметическое — самый обманчивый показатель производительности: оно остаётся приемлемым, пока часть пользователей уже ждёт секунды. Ниже — модель, на которой это видно за десять секунд, и объяснение, почему порог ставится на P95.
Демонстрация: 1000 запросов
1 000 запросов, быстрые — 100 мс.
6,0 %
8 с
Состав запросов
Медленных запросов: 60 из 1 000
Среднее
574 мс
P50 (типичный опыт)
100 мс
P95 (кому не повезло)
8 с
P99 (худший опыт)
8 с
Среднее осталось в норме, а P95 и P99 уже далеко за порогом: часть пользователей ждёт секунды. На графике среднего этого не видно.
Это модель арифметики перцентилей, а не данные вашей системы: 1000 запросов, быстрые — 100 мс. На реальном трафике порог ставится на P95 значимого маршрута.
Показать это на моей системеПочему среднее время ответа вводит в заблуждение
Среднее арифметическое скрывает проблемы: если тысяча запросов выполняется за 100 миллисекунд, а десять — за 30 секунд, среднее останется приемлемым, а десять пользователей уйдут. Поэтому мы смотрим на перцентили: P50 показывает типичный опыт, P95 и P99 — опыт тех, кому не повезло, и именно они чаще всего становятся источником жалоб и оттока.
Практическое правило: порог алерта ставится на P95 значимого маршрута, а не на среднее. Если P95 оформления заказа вырос с 800 миллисекунд до трёх секунд, реагировать нужно немедленно, даже когда среднее по системе не изменилось.
Алерты
Алерты, которые не игнорируют
Усталость от алертов — главная причина, по которой мониторинг формально есть, а пользы нет. Мы разделяем поводы по срочности и оставляем только те уведомления, по которым есть что делать.
Инцидент
Требует немедленного вмешательства: сценарий не работает или работает с грубой ошибкой.
Будит дежурного
Предупреждение
Отклонение от нормы без отказа: растёт время ответа, приближается порог диска.
Плановая работа в рабочие часы
Информация
Метрика для дашборда и разборов. Повода для действия нет.
Никого не будит
- Каждый алерт устраним действием — иначе он удаляется или переезжает на дашборд
- Связанные уведомления подавляются: падение базы не порождает тридцать алертов зависимых сервисов
- У каждого алерта есть порядок действий — что проверить и что сделать по шагам
Что делать с алертами, которые все игнорируют
Усталость от алертов — главная причина, по которой мониторинг формально есть, а пользы нет. Лечится это дисциплиной: каждый алерт должен быть либо устраним действием, либо удалён. Если по уведомлению нельзя ничего сделать, это не алерт, а метрика для дашборда.
Мы также разделяем поводы: инцидент требует немедленного вмешательства, предупреждение — плановой работы в рабочее время, информационное сообщение не будит никого. Отдельно настраиваем подавление связанных уведомлений, чтобы падение базы не порождало тридцать алертов от всех зависимых сервисов.
Этапы
Как мы ставим мониторинг
Порядок работ выстроен так, чтобы уже на второй неделе у вас были не графики, а работающие алерты и первые найденные узкие места.
-
01 3–5 дней
Инвентаризация
Составляем список сервисов, их владельцев и критичных сценариев. Договариваемся, что считаем нормой для каждого показателя.
-
02 1–2 недели
Сбор метрик
Подключаем сбор метрик приложения, базы, очередей и внешних проверок. Настраиваем хранение с нужной глубиной и разумной стоимостью.
-
03 3–5 дней
Алерты и дежурство
Формулируем правила так, чтобы каждый алерт требовал действия. Настраиваем маршрутизацию в дежурный канал и порядок эскалации.
-
04 ежемесячно
Оптимизация и отчёт
Разбираем накопленные данные, устраняем найденные узкие места и подтверждаем эффект измерениями до и после.
Сопровождение и дежурство
Дальше — дежурство по регламенту
Наблюдаемость без дежурства отвечает только на вопрос «что случилось». Чтобы реагировать до клиента, нужен регламент реакции — пакеты и приоритеты опубликованы на странице мониторинга безопасности.
Базовый
от 55 000 ₽/мес
Реакция до 4 часов
До 10 сервисов
Минимальный контур контроля: сбор событий, сканирование уязвимостей и ежемесячный отчёт для службы ИБ.
- До 10 сервисов
- Сбор и хранение логов
- Сканирование раз в месяц
- Аудит доступов раз в квартал
- Ежемесячный отчёт
- Реакция в рабочие часы
Бизнес
от 120 000 ₽/мес
Реакция до 30 минут
До 30 сервисов, 24/7
Постоянный контроль с круглосуточным дежурством, корреляцией событий и отслеживанием закрытия уязвимостей.
- До 30 сервисов
- Дежурство 24/7
- Правила корреляции под ваш стек
- Сканирование раз в неделю
- Контроль закрытия находок
- Разбор каждого инцидента
Критичный
от 220 000 ₽/мес
Реакция до 15 минут
Требования регуляторов, чувствительные данные
Для организаций с повышенными требованиями: расширенное покрытие, регламенты под проверки, работа с персональными данными.
- Объём без ограничений
- Реакция до 15 минут, 24/7
- Расширенное покрытие источников
- Регламенты под требования регуляторов
- Учения по реагированию
- Выделенный контакт для ИБ
Пакеты и цены ниже — из опубликованного описания услуги мониторинга. Точную стоимость называем после инвентаризации: она зависит от числа сервисов, объёма данных и режима реакции.
| Приоритет | Что произошло | Реакция | Восстановление |
|---|---|---|---|
| P1 — Атака или утечка | Признаки активной компрометации, доступа к данным или шифрования | 15 минут | локализация до 2 часов |
| P2 — Подозрительная активность | Аномальные входы, эскалация прав, необычные запросы к данным | 30 минут | разбор до 8 часов |
| P3 — Уязвимость высокой критичности | Найдена уязвимость, эксплуатация которой возможна | 4 часа | план закрытия до 3 дней |
| P4 — Замечания и рекомендации | Находки среднего и низкого риска, вопросы hardening | 1 рабочий день | по плану работ |
Стек
На чём это собирается
Работаем в вашем стеке, если он уже есть. Направление «Мониторинг и логирование» с техническими деталями — на отдельной странице раздела DevOps.
Метрики и дашборды
- Prometheus
- Grafana
- экспортёры приложения и базы
- пороги и SLO
Логи и трассировка
- Loki
- OpenTelemetry
- поиск по correlation id
- группировка ошибок
Приложение
- APM и трассировка запросов
- журнал медленных запросов
- очереди и воркеры
- эффективность кэша
Клиентская часть
- Core Web Vitals
- ошибки JavaScript
- вес ресурсов
- сторонние скрипты
Доступность извне
- HTTP-проверки с нескольких площадок
- проверка содержимого страницы
- TLS-сертификаты и домены
- внешние зависимости
Дежурство
- маршрутизация алертов
- эскалация по SLA
- подавление связанных уведомлений
- разбор инцидентов
Технические детали
Границы услуги
Что мы делаем и чего не делаем
Мониторинг не заменяет администрирование и не отменяет работу над продуктом. Ниже — честное разделение, чтобы ожидания совпали с результатом.
Что делаем мы
- Собираем метрики приложения, базы, очередей и внешние проверки доступности
- Настраиваем пороги и алерты так, чтобы каждый требовал действия
- Разбираем производительность: запросы в цикле, отсутствующие индексы, неэффективный кэш
- Готовим рекомендации и подтверждаем эффект измерениями до и после
- По желанию берём реакцию на алерты по доступности вместе с дежурством
Чего не делаем
- Не заменяем системного администратора: ОС, инфраструктура и повседневные задачи остаются за ним
- Не занимаемся развитием функциональности продукта — это задачи разработки
- Не обещаем ускорить систему без изменений в коде или схеме данных
- Не ставим «мониторинг всего»: шумные показатели не собираем сознательно
Первые находки обычно появляются в течение первых двух недель: как правило это запросы в цикле, отсутствующие индексы и неэффективное кэширование. Эффект измерим сразу, потому что базовые значения P95 сняты до изменений.
Частые вопросы о мониторинге
Нужно ли устанавливать агенты на серверы?
Зависит от уровня детализации. Внешние проверки доступности работают вообще без доступа к инфраструктуре. Метрики приложения, трассировка запросов и медленные SQL требуют либо агента, либо подключения библиотеки в код, либо чтения данных из уже существующих источников — журнала базы, веб-сервера. Мы подбираем минимально инвазивный вариант и согласуем его до начала работ.
Вы заменяете нашего системного администратора?
Нет, мы дополняем. Администратор занимается инфраструктурой, обновлениями операционной системы и повседневными задачами. Мы берём на себя наблюдаемость, разбор производительности приложения, анализ запросов к базе и подготовку рекомендаций. При этом часть рутины — реакция на алерты по доступности — может быть передана нам вместе с дежурством.
Как быстро видно эффект от оптимизации?
Первые находки обычно появляются в течение первых двух недель: как правило это запросы в цикле, отсутствующие индексы и неэффективное кэширование. Эффект от их устранения измерим сразу, потому что у нас уже есть базовые значения P95 до изменений. Более глубокие улучшения — переработка тяжёлых сценариев, вынос фоновых операций — планируются отдельными задачами.
Мониторинг потянет много ресурсов и денег?
Стоимость зависит от объёма данных и глубины хранения. Мы специально настраиваем хранение детальных метрик на недели, а агрегированных — на месяцы, и ограничиваем сбор шумных показателей. На практике для среднего проекта расходы на хранение данных мониторинга оказываются ниже стоимости одного часа простоя, а часть находок снижает нагрузку и тем самым расходы на инфраструктуру.
С чего начать, если мониторинга нет вообще?
С инвентаризации: списка сервисов, их владельцев и критичных сценариев. За 3–5 дней мы фиксируем, что считаем нормой для каждого показателя, и только после этого подключаем сбор метрик. Порядок именно такой, потому что метрика без порога не даёт ответа на вопрос «нужно ли что-то делать».
Сколько времени занимает настройка?
Инвентаризация — 3–5 дней, сбор метрик приложения, базы, очередей и внешних проверок — 1–2 недели, алерты и дежурство — ещё 3–5 дней. То есть уже на второй неделе у вас не графики, а работающие алерты и первые найденные узкие места. Оптимизация дальше идёт ежемесячно по накопленным данным.
Мы уже платим за APM-сервис. Зачем вы?
Если сервис установлен и им пользуются, половина задачи решена — мы работаем с тем, что есть, и не предлагаем менять инструмент ради инструмента. Обычно не хватает другого: порогов, привязанных к критичным сценариям, алертов, которые требуют действия, и регулярного разбора находок. Инструмент без регламента показывает графики, но не отвечает на вопрос, что делать.
Как вы отчитываетесь о работе?
Ежемесячно: что найдено, что устранено, как изменились показатели до и после, какие узкие места остаются и что предлагаем делать дальше. Отдельно — разбор каждого инцидента: что произошло, почему, что меняем, чтобы не повторилось.
Как мы думаем о наблюдаемости
Какие метрики действительно стоит отслеживать
Начинать нужно не с технических показателей, а с пользовательских сценариев. Если для бизнеса критично оформление заказа, то метрика номер один — доля успешных оформлений и время этого сценария, а не загрузка процессора. Технические метрики нужны для объяснения причины, но сигналом должен быть показатель, связанный с выручкой или обслуживанием клиентов.
Второй принцип — ограничить число метрик на дашборде. Мы выносим на главный экран не более десяти показателей и добавляем к каждому порог, при котором дежурный обязан действовать. Всё остальное живёт в детальных панелях и используется в разборе, а не в постоянном наблюдении.
Другие направления поддержки
Настроим наблюдение за вашей системой
Расскажите, из каких сервисов состоит продукт, — предложим набор метрик и алертов под ваши критичные сценарии.
- Телефон
- +7 (495) 368-39-51
- Что будет после заявки
- Свяжемся, соберём список сервисов и критичных сценариев, после чего предложим набор метрик, порогов и алертов со сроками. Инвентаризация занимает 3–5 дней.
- Если APM уже стоит
- Работаем с тем, что есть, и не предлагаем менять инструмент ради инструмента: обычно не хватает порогов под критичные сценарии, алертов с действием и регулярного разбора находок.
Полезное рядом: поддержка и обслуживание, управляемые услуги, мониторинг и логирование, контакты.
Заявка на настройку мониторинга
Опишите, из каких сервисов состоит продукт и что уже вызывает тревогу, — вернёмся с набором метрик, порогов и алертов.