Метрики производительности системы: что отслеживать DevOps-инженеру и администратору

Для ежедневного контроля системы достаточно начать с нескольких групп показателей: загрузка ресурсов, насыщение, ошибки, объем работы и доступность. На сервере отслеживайте CPU и load average, доступную память и активность swap, задержку и заполнение дисков, сетевой трафик и ошибки. На уровне приложения добавьте throughput, latency, error rate и availability.

Высокая загрузка ресурса сама по себе не доказывает наличие проблемы. Процессор может быть занят полезной работой, а низкий CPU не исключает задержки диска, нехватку памяти, сетевые потери или медленный ответ базы данных. Метрику нужно связывать с типом сервиса, объемом нагрузки, временным периодом и пользовательским симптомом.

Для виртуальных машин понадобятся CPU ready, steal time и показатели overcommit. Для Docker-контейнеров важны лимиты cgroups, CPU throttling, рестарты и OOMKilled. В Kubernetes проверяйте состояние node и pod, pressure, readiness, доступность реплик и ошибки планирования. Для NAS и ZFS добавьте latency хранилища, очередь, IOPS, заполнение pool, checksum errors, scrub, SMART и состояние vdev.

Быстрый алгоритм диагностики Linux-сервера с командами top, vmstat, iostat и ss собран в практическом руководстве по метрикам CPU, памяти, диска и сети. Ниже приведена расширенная схема для постоянного мониторинга, инцидентов и планирования ресурсов.

Короткий ответ: какие метрики производительности системы нужны в первую очередь

Минимальный набор должен отвечать на четыре вопроса: сколько работы выполняет система, насколько заняты ресурсы, где образовалась очередь и видит ли пользователь результат этой работы. Поэтому мониторинг строят вокруг четырех групп: utilization, saturation, errors и traffic. К ним добавляют доступность и задержку сервиса.

Четыре группы показателей: utilization, saturation, errors и traffic

• Utilization, уровень использования ресурса. Примеры: CPU usage, занятый объем памяти, busy time диска, загрузка сетевого интерфейса.
• Saturation, признаки насыщения и ожидания. Примеры: run queue, disk queue depth, длина очереди запросов, memory pressure, CPU throttling.
• Errors, ошибки и отказы. Примеры: HTTP 5xx, timeout, packet drops, retransmits, read errors, checksum errors, OOMKilled.
• Traffic, объем выполняемой работы. Примеры: requests per second, количество операций чтения и записи, сетевой throughput, число активных соединений.

Эти категории помогают оценивать новую систему без запоминания сотен имен метрик. Например, CPU utilization показывает занятость процессора, но run queue показывает конкуренцию процессов за вычислительное время. Throughput показывает объем трафика, а retransmits помогают понять, насколько надежно передаются пакеты. Для диска IOPS описывает количество операций, latency показывает цену каждой операции, а queue depth отражает накопившееся ожидание.

К utilization добавляйте пользовательский эффект. Запросы могут выполняться быстро при высокой загрузке CPU, если сервис выдерживает свой SLO. И наоборот, latency может расти при загрузке CPU 30%, когда приложение ждет диск, базу данных, DNS или внешний API.

Минимальный набор для ежедневного контроля

Для дежурного специалиста нужен короткий baseline, который помещается на одном обзорном экране. Такой набор подходит как стартовая точка для Linux-сервера, виртуальной машины или узла Kubernetes:

• CPU usage, user, system, iowait, steal time и load average.
• Memory available, swap in, swap out, major page faults, OOM events и memory pressure.
• Disk read/write latency, IOPS, throughput, queue depth, filesystem usage и inode usage.
• Network throughput, errors, drops, retransmits, connection failures и сетевую latency.
• Availability сервиса, request rate, p95 или p99 latency и error rate.
• Для контейнеров и Kubernetes, restart count, readiness, OOMKilled, CPU throttling и доступность реплик.
• Для хранилищ, состояние pool, ошибки чтения и записи, checksum errors, scrub и прогноз заполнения.

Универсальных порогов для всех систем нет. В качестве стартовых значений можно проверять устойчивую загрузку CPU выше 85%, memory pressure вместе с активным swap, рост disk latency в течение нескольких минут, заполнение файловой системы выше 80-90% и p95 выше SLO. Эти значения нужно сверить с базовой линией, типом нагрузки и допустимым временем ответа.

Базовый мониторинг производительности сервера

Проверку физического или виртуального сервера удобно вести в порядке CPU, памяти, дисков и сети. Для каждой области нужно сопоставлять загрузку, насыщение, ошибки и объем работы. Метрики можно получать через node_exporter, пакеты sysstat, команды iostat, vmstat, sar, системные журналы и данные приложения.

CPU: загрузка, load average, run queue и iowait

Загрузка CPU состоит из нескольких частей. Значение user показывает время пользовательских процессов, system связано с работой ядра, idle отражает свободное время, iowait показывает ожидание завершения операций ввода-вывода. В виртуальной машине отдельное внимание нужно уделять steal time, когда гипервизор забирает виртуальный процессор для другой нагрузки.

Load average учитывает задачи, готовые выполняться, и процессы, ожидающие некоторые операции ядра. Число нельзя сравнивать с фиксированным порогом без учета количества vCPU. Load 4 на машине с 4 vCPU может означать полную занятость процессоров, а на машине с 16 vCPU такая нагрузка выглядит иначе. Для вывода о насыщении смотрите load average, run queue, CPU usage и latency приложения в одном временном окне.

Высокий run queue при user CPU выше 85% указывает на конкуренцию процессов за вычислительное время. Высокий iowait при умеренном user CPU направляет проверку к диску, сетевому хранилищу или зависимому блочному устройству. Высокий system CPU может быть связан с большим количеством системных вызовов, сетевыми пакетами, шифрованием, драйверами или частыми операциями файловой системы.

vmstat 1 5
iostat -xz 1 5
sar -q 1 5

Команды дают быстрый снимок состояния, но для инцидента полезнее сравнить графики за 15-30 минут до жалобы и после ее появления. Краткий пик CPU редко объясняет устойчивую деградацию, если latency и error rate остались в норме.

Память: available, page faults, swap и давление на память

Поле free не описывает весь объем памяти, доступный процессам. Linux использует RAM для page cache и может быстро освободить часть этого кэша. Для первичной оценки берите MemAvailable, а затем проверяйте swap, page faults, PSI memory pressure и события OOM.

Сам факт занятого swap не доказывает аварию. Система может хранить там редко используемые страницы и продолжать работать без заметной задержки. Проблема начинается при активном обмене страницами, росте swap in и swap out, увеличении major page faults и одновременном росте времени ответа.

Memory pressure в PSI показывает, сколько времени задачи проводили в ожидании доступной памяти. Этот показатель полезнее простого процента занятой RAM, когда на сервере работают контейнеры, базы данных и файловый кэш. Событие OOM нужно сопоставить с процессом, cgroup, лимитом контейнера и моментом роста нагрузки.

Для Linux-сервера полезно хранить отдельно:

• объем MemAvailable в байтах и процентах;
• скорость swap in и swap out;
• major page faults в секунду;
• memory PSI за короткое окно;
• число OOM events и завершенных процессов;
• потребление памяти по процессам и cgroups.

В контейнере 50% занятой памяти узла не отменяет лимит, установленный для самого контейнера. Процесс получит OOMKilled, если достигнет своего cgroup limit, даже при свободной RAM на node.

Диски и файловые системы: latency, IOPS, throughput и заполнение

Производительность дисковой подсистемы описывают несколькими связанными показателями. IOPS показывают количество операций за секунду, throughput измеряет объем переданных данных, latency показывает время выполнения операции, а queue depth отражает накопившиеся запросы. Busy time помогает увидеть занятость устройства, но его нельзя читать отдельно от задержки.

Высокий throughput подходит для последовательного чтения больших файлов и резервного копирования. База данных может выполнять сравнительно небольшой объем данных, но генерировать большое количество случайных операций с высокой latency. Синхронные записи сильнее зависят от подтверждения операции накопителем и кэшем, поэтому их задержка заметно влияет на транзакционные системы.

Разделяйте задержку устройства и задержку файловой системы. Высокий iowait при большой latency устройства указывает на нижний уровень хранения. Нормальная latency устройства при медленной файловой операции требует проверки блокировок, заполнения тома, inode, журналирования, сетевой файловой системы и самого приложения.

Заполнение файловой системы контролируйте по байтам и inode. Том с большим количеством мелких файлов может исчерпать inode раньше свободного места. Отдельно учитывайте snapshots, quotas, reserved space и временные каталоги. Значение 90% сегодня может быть приемлемым, если данные растут на 0,1% в неделю, и критичным при росте на 5% в сутки.

iostat -xz 1 5
df -h
df -i
sar -d 1 5

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

Сеть: трафик, ошибки, drops, retransmits и соединения

Throughput интерфейса показывает, сколько данных проходит через порт. Он не говорит, теряются ли пакеты и сколько времени занимает передача. Для качества соединения нужны errors, drops, TCP retransmits, connection failures и latency между конкретными узлами.

Рост retransmits может быть связан с перегрузкой канала, ошибками физического интерфейса, проблемами duplex, перегруженным виртуальным коммутатором или потерями по пути. Увеличение connection refused чаще указывает на отсутствие слушающего процесса или достижение лимита, а timeout требует проверки маршрута, фильтрации, перегрузки и зависимого сервиса.

Число соединений нужно интерпретировать вместе с лимитами файловых дескрипторов, очередью accept, состояниями TCP и нагрузкой приложения. Большой объем трафика при нулевых потерях может быть штатным. Небольшой трафик с ростом retransmits и latency уже способен нарушить работу API.

ss -s
sar -n DEV 1 5
sar -n TCP,ETCP 1 5

Проверяйте показатели на сервере, узле виртуализации, node Kubernetes и сетевом оборудовании. Значения на одном интерфейсе не всегда показывают место потери пакетов.

Метрики виртуальных машин, контейнеров и Kubernetes

В многоуровневой инфраструктуре один и тот же ресурс имеет несколько представлений. CPU физического хоста распределяется между VM, vCPU попадает в планировщик гостевой ОС, а контейнер получает долю времени через cgroups. При диагностике сопоставляйте хост, VM, node, pod и приложение в одном временном диапазоне.

Гипервизор и виртуальные машины: CPU ready, steal и overcommit

CPU ready показывает, сколько времени виртуальная машина ждала физический процессор при готовности к выполнению. Высокое значение возникает при конкуренции VM за pCPU, слишком большом числе vCPU, overcommit или неравномерном распределении нагрузки.

Steal time виден внутри гостевой ОС и отражает время, которое гипервизор отдал другой виртуальной машине. Внутри VM CPU usage при этом может выглядеть умеренным, хотя реальное время ответа растет. Для подтверждения проверяйте CPU ready на гипервизоре и latency приложения.

Виртуализация памяти добавляет ballooning и hypervisor swapping. Если гипервизор вытесняет страницы VM на диск, гостевая ОС может показывать низкий memory pressure, но задержки операций резко вырастут. Метрики хоста и гостя должны иметь одинаковые timestamps, иначе причина и симптом окажутся смещены по времени.

Проверьте:

• соотношение vCPU к pCPU и фактический overcommit;
• CPU ready и steal time;
• ballooning и swap гипервизора;
• latency виртуального datastore;
• соседние VM с резкими всплесками нагрузки;
• изменения размера VM и политики размещения.

Контейнеры: лимиты, throttling, рестарты и OOMKilled

Контейнер нужно оценивать по потреблению и по установленному ограничению. CPU usage показывает фактическое использование, а CPU throttling показывает, что cgroup не получила процессорное время из-за лимита. Низкий CPU usage с высоким throttling возможен, если короткие пики упираются в слишком низкий limit.

Для памяти смотрите working set, RSS, limit, cache, OOMKilled и restart count. Растущий working set при стабильной нагрузке может указывать на утечку. Повторяющийся OOMKilled при свободной памяти на node чаще связан с лимитом контейнера, а не с дефицитом всего узла.

Рестарт сам по себе не объясняет причину. Сопоставьте его с exit code, событиями контейнера, liveness probe, readiness probe, OOMKilled, ошибками приложения и изменениями конфигурации. Для временных файлов отслеживайте filesystem usage контейнера и доступный ephemeral storage.

Минимальный набор для Docker:

• CPU usage и throttled periods;
• memory working set, RSS и memory limit;
• OOMKilled и restart count;
• статус healthcheck;
• filesystem usage и доступный ephemeral storage;
• network traffic, errors и connection failures.

Kubernetes: состояние node, pod и workload

На уровне node проверяйте conditions, CPU pressure, memory pressure, disk pressure, allocatable resources и ошибки kubelet. Pod в состоянии Running может оставаться недоступным для пользователей, если readiness не проходит или сервис не видит нужные endpoints.

Для pod и workload нужны pending pods, scheduling failures, restart count, readiness, liveness, replica availability, container limits и request-to-limit ratio. Рост pending означает проблему планирования, нехватку allocatable ресурсов, taints, affinity, topology constraints или невозможность скачать образ.

Состояние deployment оценивайте по доступным репликам и времени rollout. Число запущенных pod без данных о готовности, ошибках и latency сервиса не показывает доступность. События Kubernetes связывайте с метриками node, cgroup и приложения.

При диагностике Kubernetes удобно двигаться по цепочке: node, namespace, workload, pod, container, endpoint. Практические PromQL-запросы и алгоритм поиска проблем собраны в руководстве по диагностике pod и узлов Kubernetes через метрики.

Для облачной среды можно отдельно оценивать метрики виртуальных серверов, managed Kubernetes, баз данных и сетевых балансировщиков. Например, при выборе ресурсов для тестового кластера удобно сопоставлять доступную CPU, память, storage latency и стоимость часа на уровне конкретного окружения. Подходящие варианты инфраструктуры собраны на странице облачных серверов и Kubernetes.

Мониторинг систем хранения и NAS: производительность, емкость и целостность

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

Производительность: задержка, очередь, IOPS и пропускная способность

Для storage собирайте read latency, write latency, IOPS, throughput, queue depth и busy time. Отдельно разделяйте последовательную и случайную нагрузку, чтение и запись, синхронные и асинхронные операции. Один показатель IOPS без размера блока и типа операции мало пригоден для сравнения.

Сопоставляйте latency хранилища с iowait на сервере и временем ответа приложения. Если latency pool растет одновременно с iowait и p95 API, хранилище может быть первичной причиной. Если storage latency стабильна, а приложение медленное, проверяйте блокировки, базу данных, сеть и внешние зависимости.

При проектировании СХД полезно заранее считать IOPS, throughput и задержки для базы данных, виртуальных машин и VDI. Формулы и примеры таких расчетов приведены в руководстве по производительности СХД.

Емкость и состояние файловой системы

Для NAS и файловых систем отслеживайте pool usage, dataset usage, snapshots, quotas, reserved space, inode usage и скорость роста данных. Алерт только на текущий процент заполнения дает неполную картину. Свободные 2 ТБ могут закончиться за сутки при массовой загрузке, а 5% свободного места на архивном томе может сохраняться годами.

Рассчитывайте прогноз даты исчерпания свободного места по скорости роста за 7, 14 или 30 дней. Резкие изменения скорости нужно объяснять: создан новый snapshot, включено резервное копирование, выросли логи, изменился retention или появился крупный dataset.

Snapshots занимают место даже после удаления файлов из активного dataset, если старый snapshot удерживает блоки. Quota ограничивает отдельный dataset, а reserved space влияет на доступный резерв pool. Эти параметры нужно выводить на один диагностический экран вместе с фактическим usage.

Надежность ZFS и дисковых массивов

Для ZFS проверяйте состояние pool и vdev, checksum errors, read errors, write errors, scrub status, resilver progress и SMART-показатели дисков. Degraded state требует отдельного критического алерта, даже если приложения пока отвечают нормально.

Checksum errors показывают повреждение данных или проблемы передачи на уровне устройства и пути. Read и write errors помогают понять, какие операции уже завершались с ошибкой. Scrub проверяет блоки и исправляет повреждения, если доступна избыточность. Контролируйте факт запуска, длительность и результат scrub.

ARC hit ratio помогает оценивать эффективность кэша ZFS, но его нельзя читать без профиля нагрузки и объема RAM. Низкое значение может быть ожидаемым для потокового чтения больших файлов. Для базы данных важнее сопоставить ARC, latency, sync writes, нагрузку на диски и реальное время ответа запросов.

SMART-показатели полезны для раннего обнаружения деградации носителя: reallocated sectors, pending sectors, uncorrectable errors, температуры и результатов self-test. Единичное предупреждение не заменяет проверку pool, журнала и резервных копий. Повторяющийся рост ошибок требует плана замены диска и проверки целостности данных.

Как связать технические метрики с симптомами у пользователей

Расследование начинайте с пользовательского симптома и времени его появления. Затем проверьте availability, latency, errors, traffic и saturation. Одна метрика редко доказывает причину, поэтому соединяйте графики приложения, инфраструктуры, логов и трассировок.

Сервис стал медленным: latency, очереди и внешние зависимости

Среднее время ответа может скрыть проблему у небольшой, но значимой доли запросов. Для пользовательского сервиса смотрите p50, p95 и p99. p50 описывает типичный запрос, p95 показывает хвост задержки для 5% запросов, p99 помогает увидеть редкие, но тяжелые случаи.

При росте latency проверьте:

• request rate и изменение объема трафика;
• p50, p95, p99 и максимальную latency;
• размер очереди приложения и базы данных;
• CPU user, system, iowait и run queue;
• disk read/write latency и queue depth;
• network latency и retransmits;
• latency downstream-сервисов, DNS и внешних API;
• изменения релиза, конфигурации и схемы базы данных.

Высокий p99 при нормальном p50 часто указывает на отдельный тяжелый маршрут, блокировку, холодный кэш или медленную зависимость. Если p50 и p99 растут вместе с очередью, ресурс или downstream-сервис уже насыщен.

Появились ошибки или тайм-ауты: error rate и доступность

Разделяйте HTTP 4xx и 5xx. 4xx могут отражать неверные запросы клиента, истекшую авторизацию или изменение контракта API. 5xx чаще связаны с ошибкой приложения, недоступной зависимостью, исчерпанием пула соединений или внутренним тайм-аутом.

Сопоставьте рост error rate с timeouts, connection refused, DNS failures, restart events, readiness и доступностью зависимых сервисов. Отдельно отметьте момент релиза, изменения конфигурации, роста нагрузки или отказа узла.

Проверка доступности через ping или TCP показывает только уровень сети и слушающий порт. Endpoint может отвечать, пока бизнес-операция завершается ошибкой. Для критичного сценария создайте synthetic check, который выполняет авторизацию, ключевой запрос и проверяет ожидаемый результат. Такой тест связывает техническую доступность с SLI и SLO.

Сервер доступен, но бизнес-операция не выполняется

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

Для каждой критичной операции фиксируйте:

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

Если сервер доступен, но timestamp последнего успешного результата не меняется, это отдельный инцидент. Алерт должен срабатывать по пользовательскому эффекту, даже когда инфраструктурные проверки проходят.

Матрица симптомов и вероятных причин

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

Как настроить алерты, которые действительно помогают

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

Порог по базовой линии, а не универсальное число

Соберите baseline за рабочие и пиковые периоды. Для каждого сервиса зафиксируйте обычный диапазон CPU, памяти, latency, error rate, throughput и очередей. Сравнивайте будни, выходные, ночные окна, сезонные пики и периоды резервного копирования.

CPU выше 80% может быть нормой для batch-задачи, если latency пользовательского API остается в SLO. Disk latency 20 миллисекунд может быть приемлемой для архива, но уже мешать транзакционной базе. Для емкости важны процент заполнения, абсолютный остаток и скорость роста.

Порог выбирайте по влиянию на сервис. Например, предупреждение можно отправлять при p95 выше SLO 5 минут, а критический алерт создавать при превышении в течение 10 минут вместе с ростом error rate. Для filesystem полезны пороги 80% и 90%, но критичность уточняйте прогнозом даты заполнения.

Условие длительности и повторяемость события

Краткий всплеск и устойчивое нарушение требуют разных правил. В Prometheus для этого используют условие for, функции rate и окна наблюдения. Для CPU обычно нужна длительность, для OOMKilled достаточно факта события, а для отсутствия heartbeat требуется отдельное окно с учетом задержки доставки.

Примеры логики:

• CPU выше baseline 10 минут и одновременно растет run queue.
• Memory pressure выше допустимого уровня 5 минут вместе с swap in или major faults.
• p95 выше SLO 10 минут при request rate выше минимального рабочего объема.
• Disk latency растет 5 минут и queue depth превышает обычный диапазон.
• Нет heartbeat или scrape больше двух интервалов сбора.
• Pool перешел в degraded state, событие отправляется сразу.

Условие отсутствия данных должно отличать падение объекта от остановки самого сборщика. Контролируйте scrape errors, exporter health, stale series и heartbeat мониторингового агента.

Комбинированные правила и привязка к симптому

Связывайте алерт с наблюдаемым эффектом и первичной причиной. Рост latency плюс рост очереди сильнее указывает на насыщение, чем каждый показатель отдельно. Memory pressure плюс swap и OOM сокращают область поиска. Ошибки сервиса плюс падение readiness помогают отделить проблему приложения от общего сбоя мониторинга.

Примеры полезных комбинаций:

• p95 latency выше SLO и error rate выше baseline.
• CPU throttling выше нормы и контейнер регулярно достигает CPU limit.
• Memory pressure на node и рост pending pods.
• Заполнение pool выше 85% и скорость роста превышает расчетный запас.
• Ошибки API и рост latency downstream-сервиса.
• Сбой scrape и отсутствие heartbeat конкретного exporter.

Связывайте дочерние события с одним incident. Когда один отказ базы данных вызывает ошибки API, падение readiness и рост latency, дежурный должен получить единый контекст с первичной гипотезой, а не три независимых уведомления.

Severity, маршрутизация и runbook

Для severity задайте влияние, время реакции, канал и владельца. Критический алерт означает нарушение доступности или SLO с понятным воздействием. Warning показывает риск деградации или ограниченный запас ресурса. Информационное событие фиксирует изменение без немедленного действия.

Текст уведомления должен содержать:

• имя сервиса и конкретного объекта;
• текущее значение и порог;
• продолжительность нарушения;
• пользовательский эффект или затронутый SLO;
• ссылку на дашборд внутри системы мониторинга;
• первые диагностические команды или шаги;
• владельца, канал эскалации и условие восстановления.

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

Как собрать дашборд и систему сбора метрик

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

Четыре уровня дашбордов: сервис, узел, ресурс и компонент

Сервисный экран показывает availability, request rate, error rate, p95 или p99 latency, состояние ключевых операций и отметки релизов.

Экран узла содержит CPU, load average, memory available, swap, disk latency, filesystem usage, network errors и throughput.

Экран ресурса помогает изучить конкретный тип нагрузки: очереди CPU, page faults, IOPS, queue depth, retransmits, memory PSI или рост данных.

Экран компонента предназначен для VM, pod, database, volume, dataset, pool или vdev. На нем должны быть видны лимиты, состояние, ошибки и соседние показатели, которые подтверждают гипотезу.

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

Единицы измерения, лейблы и высокая кардинальность

Фиксируйте единицы в названии панели и легенде: bytes, seconds, requests per second, percent, operations per second. Ошибка в единицах приводит к неверным порогам и сравнению несопоставимых рядов.

Лейблы должны описывать стабильные измерения: service, environment, cluster, namespace, node, status. Лейблы user_id, request_id, полный URL с параметрами и случайный идентификатор создают высокую кардинальность. Число временных рядов быстро растет, хранилище метрик занимает больше места, а запросы становятся тяжелее.

Полный URL заменяйте нормализованным route template, например /orders/:id. Идентификаторы запроса оставляйте в логах и трассировках, где их проще искать по конкретному инциденту. Для метрик сохраняйте измерения, по которым принимаются эксплуатационные решения.

Частота сбора, хранение и пропуски данных

Оперативная диагностика требует более короткого интервала, чем анализ месячного тренда. Короткие пики CPU, throttling и latency можно пропустить при слишком редком сборе. Для долгого хранения используйте агрегаты, а исходную детализацию оставляйте на период, когда она нужна для расследований.

Для счетчиков применяйте корректные rate-агрегации. Проверяйте reset счетчика после рестарта процесса, дублирование series и пропуски scrape. Единое время на серверах, node, гипервизоре и системе мониторинга критично для корреляции. Разница даже в несколько минут может привести к неверной последовательности событий.

Контролируйте:

• scrape errors и время последнего успешного сбора;
• stale series и gaps на графиках;
• синхронизацию времени;
• совместимость exporter с версией ОС и компонента;
• retention и объем хранилища метрик;
• нагрузку от самих запросов к Prometheus или другому хранилищу.

Prometheus, Grafana, node_exporter и OpenTelemetry подходят как распространенные компоненты стека. Выбор конкретного инструмента зависит от архитектуры, требуемой детализации, числа объектов и срока хранения.

Какие метрики создают шум и вводят в заблуждение

Большое количество графиков не гарантирует качественный мониторинг. Метрика нужна, если по ее изменению можно принять решение, подтвердить гипотезу или связать техническое состояние с пользовательским эффектом.

Почему один процент загрузки не объясняет проблему

CPU 90% при стабильном p99 и нормальном error rate может означать эффективную работу сервиса. CPU 30% при высокой disk latency уже сопровождается задержкой. Память 70% может быть page cache, а 50% внутри контейнера может закончиться OOMKilled из-за лимита cgroup.

Общий объем трафика без ошибок и latency не показывает качество сети. Число контейнеров без readiness и error rate не показывает доступность приложения. Заполненность pool без скорости роста не говорит, когда закончится место. Для каждого процента нужны абсолютное значение, временной ряд и соседние показатели.

Среднее значение против перцентилей и распределения

Среднее latency скрывает редкие долгие запросы. Например, 99 запросов по 50 миллисекунд и один запрос на 5 секунд дают среднее около 99,5 миллисекунды, хотя один пользователь ждет в сто раз дольше типичного времени.

Используйте p50 для типичного поведения, p95 для основной части пользователей и p99 для хвоста задержки. Всегда показывайте рядом request rate, потому что p99 при нескольких запросах в минуту может быть статистически нестабильным.

Не усредняйте уже агрегированные перцентили без учета количества запросов. Для общего p95 нужны исходные наблюдения или корректная гистограмма, например histogram buckets. Иначе маленький сервис может получить такой же вес, как крупный, а результат окажется искажен.

Метрики без владельца, действия и контекста

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

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

Практическая схема построения мониторинга за несколько этапов

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

Шаг 1. Описать сервисы, зависимости и критичные сценарии

Составьте карту сервисов, VM, физических узлов, Kubernetes node, pod, баз данных, сетевых компонентов, volume, dataset и storage pool. Для каждого сервиса укажите владельца, критичные зависимости и способ проверки результата.

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

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

Шаг 2. Собрать baseline и проверить качество данных

Наблюдайте рабочие и пиковые периоды. Зафиксируйте нормальные диапазоны CPU, памяти, диска, сети, latency, throughput и очередей. Отдельно отметьте фоновые задачи, резервное копирование, scrub, resilver, релизы и плановые окна обслуживания.

Проверьте единицы, timestamps, labels, пропуски, дублирование и соответствие метрик версиям компонентов. Убедитесь, что exporter видит нужные диски, filesystem, cgroups и интерфейсы. Для Kubernetes проверьте node, pod, container и workload. Для TrueNAS и ZFS сопоставьте pool, vdev, dataset, ARC, scrub и SMART.

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

Шаг 3. Создать обзорный экран и диагностические панели

На первом экране разместите availability, request rate, error rate и p95 или p99. Следующий уровень должен показывать CPU, memory pressure, disk latency, filesystem capacity и network errors. Еще глубже выводите pod, VM, database, volume, pool и vdev.

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

Шаг 4. Настроить алерты и проверить их на сценариях отказа

Смоделируйте перегрузку CPU, нехватку памяти, рост disk latency, отказ сетевой зависимости, OOM контейнера, pending pod и деградацию storage pool. Для каждого сценария проверьте появление первичного алерта, группировку вторичных событий, доставку уведомления и корректное восстановление.

Проверьте задержку доставки, маршрутизацию по severity, подавление повторов, эскалацию и отсутствие ложного восстановления. Тестируйте алерты в безопасной среде или на изолированном объекте с заранее определенным планом возврата.

Итоговый чек-лист для регулярного контроля

• Availability и соответствие SLO.
• Request rate, error rate, p95 или p99 latency.
• CPU usage, load average, run queue, iowait и steal time.
• Memory available, memory pressure, swap, major faults и OOM events.
• Disk latency, IOPS, throughput, queue depth и ошибки ввода-вывода.
• Filesystem usage, inode usage, quotas, snapshots и прогноз заполнения.
• Network throughput, errors, drops, retransmits и connection failures.
• Состояние VM, CPU ready, ballooning и latency datastore.
• Состояние pod и workload, readiness, liveness, restarts, OOMKilled и replica availability.
• Состояние storage pool, vdev, scrub, resilver, checksum errors и SMART.
• Scrape errors, gaps, stale series, heartbeat и синхронизация времени.
• Актуальность порогов, неиспользуемые метрики, новые зависимости и изменения архитектуры.

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