Мониторинг и APM для магазина на 1С-Битрикс

Магазин упал в субботу вечером, в разгар распродажи. Узнали об этом не из мониторинга, а из злого сообщения клиента в чате поддержки — через сорок минут после того, как оформление заказа перестало работать. За эти сорок минут ушли десятки покупателей, а команда даже не знала, где искать: сервер вроде «пингуется», но заказы не проходят. Знакомая история для любого интернет-магазина на 1С-Битрикс, у которого нет нормальной наблюдаемости.

Эта статья — практическое руководство, как выстроить мониторинг доступности и производительности магазина: какие метрики снимать, как настроить Zabbix и APM, как сделать алерты, которые будят человека по делу, а не каждую ночь, и как разбирать инциденты, чтобы они не повторялись. Материал основан на нашей практике технической поддержки и сопровождения магазинов на 1С-Битрикс — без абстрактной теории, только то, что реально работает в эксплуатации.

Зачем магазину мониторинг и APM

Интернет-магазин — это система, которая зарабатывает деньги в реальном времени. Каждая минута недоступности оформления заказа — это прямые потери выручки, а медленный отклик страниц — тихая утечка конверсии, которую по бухгалтерии не видно. Мониторинг нужен не «чтобы был», а чтобы отвечать на три вопроса эксплуатации: работает ли магазин прямо сейчас, стал ли он медленнее за последнее время и где именно узкое место, когда что-то пошло не так.

Без мониторинга команда живёт в режиме «узнаём о проблемах от клиентов». Это худший из возможных источников: клиент сообщает не сразу, сообщает не всё и уже раздражён. Мониторинг переворачивает ситуацию — команда узнаёт о проблеме первой, часто до того, как её заметит заметная доля покупателей, и чинит по горячим следам, а не по разрозненным жалобам постфактум.

Отдельно стоит развести два понятия, которые часто путают. Мониторинг — это сбор известных метрик и проверка их по порогам: «CPU выше 90% — тревога». Он отвечает на вопросы, которые вы заранее знаете, как задать. Наблюдаемость (observability) — свойство системы, при котором по её внешним сигналам (метрики, логи, трассы) можно понять внутреннее состояние, включая проблемы, которые вы заранее не предвидели. Хороший APM — это как раз про наблюдаемость: он даёт данные, чтобы разобраться в новой, ранее не встречавшейся деградации.

Для магазина на 1С-Битрикс это особенно актуально. Платформа сложная: ядро, десятки модулей, компоненты с кэшированием, обмен с 1С, интеграции с платёжными системами и службами доставки. Проблема может прийти с любого слоя — от переполненного диска до зависшего агента обмена или медленного внешнего API оплаты. Без слоистой наблюдаемости искать причину приходится вслепую, перебирая гипотезы под давлением падающей выручки.

Три уровня наблюдаемости: инфраструктура, приложение, бизнес

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

• Инфраструктурный уровень. Сервер, ОС, база данных, веб-сервер, PHP. Метрики: CPU, память, диск, сеть, число процессов и соединений. Инструмент — Zabbix (или Prometheus, Nagios). Отвечает на вопрос «хватает ли ресурсов и жив ли хост».
• Прикладной уровень (APM). Само приложение на Битриксе: время ответа страниц, разбивка запроса на фазы, медленные SQL, тяжёлые вызовы компонентов, ошибки PHP. Инструмент — APM-система с агентом. Отвечает на вопрос «почему конкретный сценарий работает медленно или падает».
• Бизнес-уровень. То, ради чего магазин существует: число заказов в минуту, конверсия в оформление, успешность оплат, объём обмена с 1С. Источник — данные самого магазина, выведенные в метрики. Отвечает на вопрос «зарабатывает ли магазин прямо сейчас».

Сила подхода — в пересечении слоёв. Инфраструктурный алерт «CPU 95%» сам по себе может быть безобиден: ночная переиндексация нагружает процессор, и это нормально. Но тот же алерт вместе с прикладным «время ответа каталога выросло вдвое» и бизнесовым «заказов в минуту стало вдвое меньше» — это уже картина инцидента, где ясно и что сломалось, и как это бьёт по деньгам. Отдельные метрики без связи между собой создают либо шум, либо ложное спокойствие.

Какие метрики снимать с магазина на Битриксе

Соблазн «мониторить всё» ведёт к дашбордам, на которые никто не смотрит. Правильнее начать с короткого набора метрик, каждая из которых отвечает на конкретный операционный вопрос, и расширять его по мере инцидентов. Ниже — базовый набор для магазина на 1С-Битрикс.

Обратите внимание на два принципа. Первый: смотрите на перцентили, а не только на среднее. Среднее время ответа может выглядеть приличным, пока 5% пользователей ждут по восемь секунд — именно они уходят и портят конверсию. Медиана и 95-й перцентиль расскажут правду там, где среднее приукрашивает. Второй: ключевая метрика магазина — не сервер, а деньги. Метрика «заказов в минуту» ловит целый класс проблем, невидимых для инфраструктуры: сломался JS в корзине, отвалился платёжный шлюз, ошибка в шаблоне оформления. Сервер здоров, диск свободен, а заказы не идут — и только бизнес-метрика это покажет.

Zabbix: мониторинг доступности и ресурсов

Zabbix — зрелая система мониторинга инфраструктуры с открытым кодом, которую удобно ставить рядом с магазином на 1С-Битрикс. Она собирает метрики с серверов, хранит историю, строит графики и рассылает уведомления по гибким правилам. Для магазина Zabbix закрывает нижний, инфраструктурный слой наблюдаемости.

Архитектурно Zabbix состоит из нескольких частей, и понимание их ролей помогает настраивать систему осознанно:

• Zabbix Server. Ядро, которое принимает метрики, проверяет их по триггерам и запускает действия (алерты). Ставится на отдельный хост, а не на боевой сервер магазина.
• Zabbix Agent. Демон на сервере магазина, который снимает локальные метрики: загрузку процессора, память, диск, процессы PHP-FPM, статус nginx и MySQL.
• Проверки без агента. HTTP-мониторинг доступности и времени ответа страниц выполняется сервером Zabbix «со стороны» — так он видит сайт как посетитель и не зависит от здоровья самого магазина.
• Веб-сценарии. Многошаговые проверки, которые проходят цепочку страниц (главная → каталог → корзина) и контролируют коды ответа, время и наличие нужного текста на странице.
• Триггеры и действия. Правила «если метрика вышла за порог — создать проблему» и «если проблема возникла — отправить уведомление в Telegram/почту/дежурному».

Ключевой набор триггеров для магазина: недоступность сайта (нет ответа или код 5xx), время ответа выше порога, высокая загрузка CPU дольше нескольких минут, исчерпание памяти или swap, мало места на диске, недоступность MySQL, рост числа процессов PHP-FPM до предела пула. Отдельно полезен триггер «нет свежих данных от агента» — он ловит ситуацию, когда сервер не упал целиком, но перестал отвечать, и молчание само по себе становится сигналом.

APM: разбор производительности приложения

Zabbix отвечает на вопрос «жив ли сервер», но не отвечает на вопрос «почему карточка товара стала грузиться две секунды вместо трёхсот миллисекунд». Здесь работает APM — Application Performance Monitoring. Это класс инструментов, которые встраиваются в приложение агентом и разбирают каждый (или выборочный) запрос на составляющие: сколько времени ушло на PHP, сколько на SQL, сколько на внешние вызовы, какой компонент оказался самым тяжёлым.

APM даёт то, чего нет у инфраструктурного мониторинга, — контекст внутри приложения. Вместо «сервер медленный» вы получаете «страница /catalog/ медленная, потому что компонент отдаёт 47 SQL-запросов, из которых один делает полный перебор таблицы на 200 мс». Это разница между гаданием и диагнозом. Основные возможности APM применительно к магазину на Битриксе:

• Разбивка времени ответа по фазам. Видно, где именно теряется время — в базе, в PHP-коде, в ожидании внешнего API оплаты или доставки.
• Медленные транзакции. Автоматический сбор самых медленных запросов с полной трассой, чтобы разбирать не «среднюю температуру», а конкретные худшие случаи.
• Анализ SQL. Список запросов страницы, их число и время — прямой путь к проблемам вроде N+1 и отсутствующих индексов.
• Ошибки и исключения. Сбор фатальных ошибок и предупреждений PHP с трассой стека и контекстом запроса.
• Внешние зависимости. Тайминги вызовов к платёжным шлюзам, службам доставки и API 1С — узкое место часто именно там.

В роли APM для магазина на 1С-Битрикс выступают как коммерческие решения с PHP-агентом, так и связки открытых инструментов (сбор метрик приложения плюс распределённая трассировка). Отдельно стоит помнить, что у самого Битрикса есть встроенный модуль «Монитор производительности» и панель отладки — они не заменяют полноценный APM, но полезны как быстрый первый взгляд и как источник данных о числе запросов, времени компонентов и хитах кэша. Глубже про сбор ошибок и трассировку в самом Битриксе мы писали в материале о логировании, отладке и мониторинге в Битрикс.

Логи, ошибки и трассировка запросов

Метрики говорят, что что-то не так; логи и трассы объясняют, что именно. Это третья опора наблюдаемости, и её часто недооценивают, пока не случается инцидент, который по графикам выглядит как «просто всплеск ошибок» без деталей.

Для магазина на Битриксе полезно централизованно собирать несколько потоков: журнал ошибок PHP (fatal и warning), лог веб-сервера с кодами ответа и временем, журнал медленных запросов MySQL и события ядра Битрикса (ошибки обмена, платежей, отправки почты). Ключевая идея — свести эти потоки в одно место, где по ним можно искать, фильтровать и строить графики частоты ошибок. Разрозненные логи на разных серверах, к которым надо ходить по SSH, во время инцидента бесполезны.

Трассировка запросов (tracing) — следующий шаг зрелости. Она присваивает каждому запросу идентификатор и прослеживает его через все слои: от веб-сервера через PHP к базе и внешним сервисам. Когда покупатель жалуется «оформление зависло в 14:32», по идентификатору запроса можно поднять полную картину именно этого обращения, а не гадать по агрегированным графикам. Для магазина трассировка особенно ценна на стыках — обмен с 1С, вызовы платёжного шлюза, — где время «утекает» в чужие системы.

Связка «метрики + логи + трассы» — это классические три столпа наблюдаемости. Метрики дешёвые и хороши для трендов и алертов, но не детальны. Логи детальны, но объёмны и дороги в хранении. Трассы дают сквозную картину одного запроса. Ни один из столпов не заменяет другие: в проде нужны все три, каждый со своей ролью.

Zabbix против APM: что и когда использует

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

Практический вывод: начинать почти всегда стоит с Zabbix и внешней проверки доступности — это дешёвый и быстрый способ перестать узнавать о падениях от клиентов. APM подключают вторым шагом, когда базовая доступность под контролем, а на повестке — скорость и разбор деградаций. Пытаться заменить один инструмент другим — типичная ошибка: без Zabbix вы не узнаете о падении диска, а без APM будете часами искать медленный запрос вручную.

Алерты без шума: пороги, важность, дежурства

Самая частая причина, по которой мониторинг перестаёт работать, — не техническая, а человеческая. Алертов становится слишком много, они срабатывают по пустякам, дежурный привыкает их игнорировать, и в итоге реальный инцидент тонет в шуме. Это называется усталостью от алертов (alert fatigue), и бороться с ней важнее, чем добавлять новые метрики.

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

1. Пороги с задержкой и гистерезисом. Алерт срабатывает, только если условие держится несколько минут, а гасится с запасом. Так метрика, «мигающая» на границе порога, не порождает поток уведомлений.
2. Уровни важности. Разделите события на «будит человека ночью» (упало оформление заказа), «смотрим в рабочее время» (растёт время ответа) и «в дайджест» (диск заполнен на 70%). Не всё заслуживает звонка в три часа ночи.
3. Подавление зависимостей. Если упал сам сервер, не нужно отдельно алертить о каждом сервисе на нём. Настройте зависимости триггеров, чтобы корневая проблема гасила производные.
4. Дедупликация и группировка. Сто одинаковых ошибок за минуту — это один алерт со счётчиком, а не сто сообщений.
5. Симптомы, а не причины. Алертите на то, что бьёт по пользователю («оформление не работает»), а не на каждую внутреннюю метрику. Причину найдёте по дашбордам и APM уже после того, как проснулись по делу.
6. Регулярная ревизия. Раз в месяц пересматривайте правила: всё, что ни разу не привело к действию, переписывают или выключают. Молчаливый мусор так же вреден, как и громкий.

Отдельно про каналы и дежурства. Критичные алерты должны идти туда, где их гарантированно увидят, — в дежурный мессенджер с уведомлением, а не только на почту, которую читают раз в день. Если магазин крупный и простой стоит дорого, вводят график дежурств с эскалацией: не отреагировал первый дежурный за N минут — уведомление уходит второму. Это превращает мониторинг из «кто-нибудь да заметит» в предсказуемый процесс с гарантией отклика.

SLI, SLO и бюджет ошибок для магазина

Чтобы мониторинг был не набором графиков, а инструментом управления, полезно опереться на три понятия из практики SRE (Site Reliability Engineering). Они переводят «сайт должен хорошо работать» в измеримые цели.

• SLI (Service Level Indicator) — метрика, которая измеряет качество сервиса с точки зрения пользователя. Для магазина это, например, доля успешных оформлений заказа или доля запросов каталога быстрее 1 секунды.
• SLO (Service Level Objective) — целевое значение SLI, к которому вы обязуетесь. Например: «99,9% доступности оформления в месяц» или «95% страниц каталога отвечают быстрее 800 мс».
• Бюджет ошибок (error budget) — допустимая доля нарушений SLO. Если цель 99,9%, то бюджет — 0,1% времени, которые можно «потратить» на сбои и рискованные релизы. Пока бюджет не исчерпан, команда двигается быстро; исчерпали — притормаживают и вкладываются в надёжность.

Ценность этого подхода в том, что он снимает вечный спор «релизить фичи или чинить стабильность» и переводит его в цифры. SLO задаёт понятную планку, а бюджет ошибок — объективный сигнал, когда пора остановить гонку за фичами и заняться устойчивостью. Для магазина не нужно перегибать с формализмом: достаточно двух-трёх ключевых SLO (доступность оформления, скорость каталога, успешность оплат), привязанных к конкретным метрикам мониторинга. Даже такой минимум переводит разговоры о надёжности из эмоций в факты.

SLO по скорости прямо смыкаются с пользовательскими метриками: доля быстрых страниц каталога и карточки — это фактически те же Core Web Vitals, только со стороны сервера. Как эти метрики влияют на конверсию и как их измерять со стороны пользователя, мы разбирали в статье про Core Web Vitals для интернет-магазина.

Реализация в 1С-Битрикс: что и как настроить

Перейдём от принципов к конкретике. Ниже — порядок внедрения наблюдаемости для магазина на 1С-Битрикс с нуля, от самого дешёвого и важного к более сложному.

1. Внешняя проверка доступности. Первым делом поднимите независимую проверку главной и страницы оформления заказа с внешней площадки: HTTP-код, время ответа, наличие ключевого текста. Это минимальный мониторинг, который сразу перестаёт давать вам узнавать о падениях от клиентов.
2. Zabbix на инфраструктуру. Установите Zabbix Server на отдельный хост, поставьте агент на сервер магазина, соберите базовые метрики: CPU, память, диск, swap, состояние nginx, PHP-FPM и MySQL. Настройте триггеры на исчерпание ресурсов и недоступность сервисов.
3. Веб-сценарий покупателя. Соберите в Zabbix многошаговый веб-сценарий, проходящий путь «главная → каталог → карточка → корзина». Он ловит поломки бизнес-логики, невидимые по коду главной страницы.
4. Мониторинг обмена с 1С. Добавьте проверку свежести обмена: когда последний раз проходил обмен товарами и заказами, нет ли зависших сессий. Устаревший каталог и непереданные заказы — частая тихая проблема магазинов.
5. APM на приложение. Подключите APM-агент к PHP, настройте семплирование (все медленные запросы плюс часть обычных), включите сбор медленных SQL и ошибок. Замерьте накладные расходы до и после — они должны остаться в единицах процентов.
6. Централизованные логи. Сведите журналы PHP, nginx, MySQL slow log и события ядра Битрикса в одно место с поиском и графиками частоты ошибок. Настройте алерт на всплеск 5xx и фатальных ошибок.
7. Бизнес-метрики. Выведите в мониторинг число оформленных заказов в минуту и успешность оплат. Настройте алерт на падение заказов к нулю в рабочее время — это ловит поломки, которые не видит ни один инфраструктурный триггер.
8. Дашборд и алерты. Соберите единый дашборд дежурного и настройте маршрутизацию алертов по важности с эскалацией. Проверьте всю цепочку учебной тревогой — от срабатывания триггера до сообщения дежурному.

Важный нюанс именно для Битрикса — кэширование и композит. Мониторинг должен различать «холодный» и «тёплый» отклик: страница из композитного кэша отдаётся мгновенно, а та же страница с полной генерацией — в разы дольше. Если это не учитывать, метрики времени ответа будут «прыгать» и порождать ложные алерты. Правильно — мерить перцентили на реальном трафике и отдельно контролировать долю хитов кэша, потому что её падение почти всегда предшествует росту нагрузки на базу. Проблемы с базой при этом часто лечатся не мониторингом, а оптимизацией: как разгонять MySQL под Битрикс, мы подробно разбирали в статье про оптимизацию базы данных MySQL для 1С-Битрикс.

Как это выглядит в связке с админкой Битрикса

Внешний мониторинг не отменяет встроенных инструментов Битрикса — они дают данные, которые снаружи не видны: число SQL-запросов на хит, время компонентов, эффективность кэша. Схематично панель производительности и её связь с внешним мониторингом выглядит так:

Практический сценарий использования связки такой. APM непрерывно следит и поднимает алерт: «время ответа /catalog/ выросло, растёт число медленных SQL». Дежурный открывает медленную транзакцию в APM, видит конкретный тяжёлый запрос и компонент. Дальше он воспроизводит хит с включённой панелью производительности Битрикса на этой странице и получает детальную разбивку по компонентам и запросам — уже адресно, зная, куда смотреть. Внешний мониторинг задаёт направление, встроенный дожимает диагностику до строки кода. Ни один из инструментов по отдельности не даёт такой скорости разбора.

Разбор инцидентов: дежурство и постмортем

Мониторинг ловит проблему, но ценность он приносит только вместе с процессом реагирования. Инцидент — это не просто «что-то сломалось», а событие с жизненным циклом: обнаружение, реагирование, устранение, разбор. Провал на любом этапе обесценивает остальные: бесполезно быстро узнать о падении, если непонятно, кто и как чинит.

Базовый процесс реагирования на инцидент в магазине выглядит так:

1. Обнаружение. Алерт срабатывает и доходит до дежурного по гарантированному каналу. Время от начала проблемы до уведомления — метрика, которую стоит сокращать.
2. Оценка и коммуникация. Дежурный подтверждает инцидент, оценивает влияние (что не работает, сколько это стоит) и сообщает команде. Для крупных сбоев назначается координатор.
3. Смягчение. Первая цель — не найти причину, а вернуть сервис: откатить релиз, перезапустить сервис, включить деградированный режим. Причину ищут после того, как оформление снова работает.
4. Устранение и проверка. Находят и устраняют корневую причину, убеждаются по метрикам, что всё вернулось в норму, а не просто «стало тише».
5. Постмортем. После восстановления — письменный разбор без поиска виноватых, с планом действий, чтобы это не повторилось.

Отдельно про постмортем (разбор инцидента) — это самый недооценённый и самый ценный артефакт. Хороший постмортем содержит: точную хронологию (когда началось, когда заметили, когда починили), влияние на бизнес в измеримых величинах, непосредственную и корневую причины, разбор что помогло и что мешало при устранении, и конкретный список действий с ответственными и сроками. Ключевое правило — культура без обвинений (blameless): цель не найти виноватого, а понять, как система позволила ошибке привести к сбою. Люди честно рассказывают, что произошло, только когда не боятся наказания, а без честного рассказа корневую причину не найти.

Дашборды: что выводить на экран дежурного

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

Работает принцип пирамиды. Верхний уровень — несколько ключевых индикаторов здоровья магазина, видных с одного взгляда: доступность оформления, время ответа каталога, заказов в минуту, ошибки в минуту. Их должно быть достаточно, чтобы за две секунды ответить «магазин в порядке или нет». Ниже — детализирующие панели по слоям (инфраструктура, база, приложение, обмен), к которым дежурный спускается, когда верхний уровень показал проблему.

Несколько практических правил хорошего дашборда для магазина:

• Бизнес-метрики сверху. «Заказов в минуту» и «успешность оплат» важнее, чем CPU. Начинайте с денег, а не с железа.
• Всегда с базовой линией. График без нормы бесполезен. Показывайте текущее значение рядом с обычным для этого времени суток, чтобы аномалия бросалась в глаза.
• Перцентили, а не среднее. Для времени ответа выводите медиану и 95-й перцентиль — среднее прячет хвост медленных запросов.
• Единый временной диапазон. Все панели дашборда на одной временной оси, чтобы события на разных слоях можно было сопоставить по времени.
• Отдельный экран для инцидента. Соберите узкий дашборд «что смотреть при падении» — только метрики, нужные для быстрого диагноза, без украшательства.

Частые ошибки мониторинга

• Мониторят только «пинг сервера» — сервер отвечает, а оформление заказа сломано, и об этом никто не знает.
• Проверка доступности крутится на том же сервере, что и магазин, — падает вместе с ним и молчит именно тогда, когда нужна.
• Слишком много алертов без уровней важности — дежурный привыкает игнорировать, и реальный инцидент тонет в шуме.
• Смотрят только на среднее время ответа — оно приличное, пока 5% пользователей ждут по восемь секунд и уходят.
• Нет бизнес-метрик — падение заказов из-за сломанного JS в корзине видно только по выручке в конце дня.
• APM включён на 100% трассировки на нагруженном проде — накладные расходы съедают ту скорость, которую призваны измерять.
• Не мониторят обмен с 1С и очереди — каталог устаревает, заказы не передаются, а инфраструктура при этом «зелёная».
• Инциденты чинят и забывают, без постмортема — те же грабли повторяются раз за разом, и мониторинг не растёт.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность наблюдаемости магазина перед тем, как считать её настроенной:

1. Доступность снаружи. Внешняя проверка главной и оформления заказа работает с независимой площадки и шлёт алерт в гарантированный канал.
2. Инфраструктура под Zabbix. Собираются CPU, память, диск, swap, состояние nginx, PHP-FPM и MySQL; настроены триггеры на исчерпание ресурсов.
3. Сценарий покупателя. Веб-сценарий проходит путь «главная → каталог → корзина → оформление» и контролирует коды, время и текст.
4. APM на приложении. Агент собирает время ответа по сценариям, медленные SQL и ошибки; накладные расходы замерены и держатся в единицах процентов.
5. Логи централизованы. Журналы PHP, nginx, MySQL slow log и события ядра сведены в одно место с поиском и алертом на всплеск ошибок.
6. Бизнес-метрики. Заказов в минуту и успешность оплат выведены в мониторинг; настроен алерт на падение заказов в рабочее время.
7. Обмен с 1С под контролем. Мониторится свежесть обмена товарами и заказами, зависшие сессии поднимают тревогу.
8. Алерты без шума. Пороги с задержкой, уровни важности, подавление зависимостей и эскалация настроены и проверены учебной тревогой.
9. Процесс инцидентов. Определены дежурство, каналы, роли; после каждого инцидента пишется постмортем без обвинений с планом действий.
10. Дашборд дежурного. Есть верхнеуровневый экран здоровья магазина и узкий дашборд «что смотреть при падении».

Вывод

Наблюдаемость магазина на 1С-Битрикс — это не один инструмент, а система из трёх слоёв: Zabbix держит инфраструктуру, APM объясняет производительность приложения, бизнес-метрики показывают деньги. Их сила — в связке: проблему видно на пересечении слоёв, где отдельные метрики складываются в диагноз. Но даже идеальные метрики бесполезны без двух вещей — алертов, которые зовут к действию, а не шумят, и процесса разбора инцидентов, который после каждого сбоя делает мониторинг умнее. Начните с внешней проверки оформления заказа, добавьте Zabbix и APM, настройте алерты по важности и заведите привычку писать постмортемы — и магазин перестанет узнавать о своих проблемах от клиентов.