Ключевые метрики производительности компьютерных систем для администраторов

Короткий ответ: какие метрики смотреть в первую очередь

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

В первые минуты инцидента проверьте request latency и error rate, затем перейдите к CPU utilization, load average, memory pressure, swap activity, IOPS, throughput, дисковой и сетевой latency. Сравнивайте текущие значения с базовой линией, а не с универсальным порогом.

Практическая схема выглядит так: рост p95 или p99 latency при высокой run queue указывает на конкуренцию за CPU, рост PSI и swap in/out, на нехватку памяти, увеличение disk await и queue depth, на насыщение хранилища, а retransmits и packet loss, на проблемы сети. Подробный рабочий набор для Linux, виртуальных машин, Docker, Kubernetes, NAS и ZFS собран в отдельной шпаргалке по метрикам производительности.

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

• Сервис: request rate, error rate, p50, p95 и p99 latency, таймауты, размер очереди запросов.
• CPU: user, system, iowait, steal, загрузка каждого ядра, run queue, частота и CPU throttling.
• Память: доступная RAM, memory PSI, reclaim, major page faults, swap in/out, OOM events.
• Диск: read/write IOPS, throughput, await, latency чтения и записи, utilization устройства, queue depth.
• Сеть: RTT, packet loss, jitter, retransmits, ошибки интерфейса, drops, throughput и состояние TCP-соединений.

Снимок одной минуты редко объясняет причину. Смотрите временной ряд, длительность пика, затронутые узлы и совпадение с релизом, резервным копированием, изменением трафика или отказом зависимости.

Почему одна метрика не описывает состояние системы

У любого ресурса есть как минимум четыре разных характеристики: спрос на ресурс, фактическая занятость, очередь и время ожидания. CPU может быть занят на 60 процентов, но запросы будут ждать диск или блокировку. Сетевой интерфейс может передавать данные на 30 процентов от номинальной скорости, но потери пакетов уже вызовут повторные передачи.

Низкая CPU utilization не доказывает исправность системы. Причиной задержки могут быть медленные записи в базу, memory pressure, сетевой RTT, зависший внешний API или процессы в состоянии D. В распределенной системе проверьте весь путь: клиент, балансировщик, приложение, базу, хранилище, OpenTelemetry Collector и Prometheus. Метрики могут пропадать из-за сетевого ограничения между компонентами, ошибок scrape или переполненной очереди доставки.

Первичный вывод формулируйте как гипотезу: «p99 вырос одновременно с disk await и queue depth». Затем подтвердите ее на уровне процесса, контейнера, устройства или конкретного запроса.

CPU utilization: что это и как интерпретировать загрузку процессора

CPU utilization показывает долю времени, когда логические процессоры заняты обработкой работы. В Linux общий процент складывается из нескольких режимов, поэтому цифра 80 процентов без расшифровки мало что говорит. На многопроцессорном хосте среднее значение может скрыть одно полностью занятое ядро и несколько почти бездействующих.

User, system, iowait и steal: из чего складывается CPU utilization

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

Высокий iowait не означает, что процессор выполняет полезную работу. Это сигнал ожидания I/O, который нужно сопоставить с дисковой latency, очередью устройства и процессами в состоянии D. В виртуальной машине высокий steal указывает на конкуренцию за физические CPU. Добавление vCPU не устранит проблему, если хост перегружен или виртуальная машина попала на шумного соседа.

Для быстрой проверки используйте mpstat -P ALL 1, top или htop, а для привязки нагрузки к процессам, pidstat -u 1. На серверах с Prometheus полезны метрики node_exporter, а в контейнерах, значения cgroup CPU usage, quota, period и throttling.

Как отличить CPU-bound нагрузку от ожидания

CPU-bound сценарий ограничен вычислениями. Обычно при нем растет user или system time, нужные ядра заняты, run queue держится выше обычного уровня, а latency увеличивается вместе с объемом работы. Disk latency, swap activity и memory PSI при этом не объясняют рост задержки.

Для подтверждения сравните:

• загрузку отдельных ядер, а не только общий процент;
• run queue и число runnable-задач;
• частоту CPU и признаки thermal или power throttling;
• CPU quota и throttling контейнера;
• request latency и throughput приложения.

CPU-bound приложение может использовать процессор почти на 100 процентов при невысокой загрузке GPU, диска или сети. Такая картина сама по себе не означает инцидент. Если сервис выдерживает целевой throughput, p99 находится в базовой линии, а ошибок нет, высокий CPU может быть ожидаемым результатом эффективной обработки.

Высокий iowait меняет направление поиска. При нем проверьте iostat -xz 1, pidstat -d 1 и задержку конкретного устройства. При высоком steal проверьте показатели гипервизора и соседние виртуальные машины. Масштабирование CPU в обоих случаях может оставить исходную проблему без изменений.

Почему средняя загрузка CPU может скрывать проблему

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

Проверяйте per-core значения, частоту, cgroup limits и длительность пиков. Минутная агрегация подходит для трендов, но во время инцидента используйте интервал 1-5 секунд. Для Kubernetes сопоставьте CPU usage pod с request, limit, throttled seconds и загрузкой worker node.

Пример: хост с 16 логическими CPU показывает 35 процентов общей загрузки. Один поток базы занимает 100 процентов одного ядра, а задержка конкретного endpoint выросла в три раза. Средний показатель скрывает горячее ядро, поэтому решение нужно искать в распараллеливании, распределении запросов или изменении профиля работы.

Load average: что это и как читать очередь задач

Load average в Linux отражает среднее число задач, готовых выполняться, и задач в непрерываемом ожидании, чаще всего ожидании I/O. Значения обычно выводятся для интервалов 1, 5 и 15 минут. Это показатель давления на систему, а не процент загрузки CPU.

Что означают значения 1, 5 и 15 минут

Первое значение быстрее реагирует на событие. Второе помогает увидеть нагрузку за несколько минут. Третье показывает более устойчивый тренд.

• Растет только 1-minute load, затем быстро снижается, вероятен короткий всплеск.
• 1-minute load выше 5-minute, нагрузка недавно усилилась.
• Все три значения последовательно растут, очередь накапливается или система долго работает под высоким давлением.
• 15-minute load остается высокой после завершения пика, система еще не успела разгрузить накопившуюся работу.

Проверьте значения командами uptime, w и cat /proc/loadavg. Сопоставьте их с графиком deploy, изменением request rate и длительностью фоновых задач.

Как соотнести load average с количеством ядер

Нормализуйте load average на число доступных логических CPU. Значение 4 для хоста с четырьмя CPU и значение 4 для однопроцессорной виртуальной машины описывают разное давление. Приближение load к числу CPU означает, что runnable-задачи могут регулярно конкурировать за вычислительное время, но не задает универсальную границу аварии.

Смотрите вместе:

• load average и run queue;
• CPU utilization по ядрам;
• iowait и disk latency;
• memory PSI и swap activity;
• latency и error rate сервиса.

Для контейнера значение load может относиться к узлу, а CPU limit контейнера будет существенно меньше. Сравнивайте показатель с доступными CPU конкретного уровня: node, виртуальной машины, pod или контейнера.

Высокий load average при низкой загрузке CPU

Такое сочетание часто появляется при ожидании диска, сетевой файловой системы, блокировок или другого I/O. Задача не выполняет вычисления, поэтому CPU остается свободным, но попадает в load average и задерживает зависимые операции.

Порядок проверки:

1. Запустите vmstat 1 и посмотрите run queue, blocked processes, swap и I/O.
2. Проверьте iostat -xz 1, await, utilization и average queue size.
3. Найдите процессы в состоянии D через ps -eo state,pid,comm,wchan:32.
4. Сопоставьте процессные операции с pidstat -d 1.
5. Проверьте latency сетевого mount, если приложение работает с NAS или NFS.

Увеличение числа vCPU не убирает задержку, если очередь образовалась на storage или в сетевой файловой системе.

Память: memory pressure и swap activity

Подсистема памяти требует трех разных групп показателей: емкость RAM, давление на память и активность paging. Поле free в выводе free -h не описывает состояние целиком, потому что Linux использует свободные страницы под page cache и может быстро освободить их для приложений.

Memory pressure: когда памяти не хватает системе

Memory pressure показывает, сколько времени задачи теряют из-за ожидания памяти. В Linux это видно через Pressure Stall Information, PSI, в файле /proc/pressure/memory. Поля some и full показывают долю времени, когда часть или все non-idle задачи испытывали задержку из-за подсистемы памяти.

Рост memory PSI вместе с reclaim, major page faults и увеличением latency приложения подтверждает, что системе трудно поддерживать рабочий набор страниц. Если появляются OOM events, ядро или cgroup уже принудительно завершает процессы.

Для диагностики соберите:

• free -h, чтобы увидеть available memory, cache и swap;
• vmstat 1, чтобы проверить reclaim, paging и blocked processes;
• cat /proc/pressure/memory, чтобы оценить PSI;
• major page faults процесса;
• OOMKilled, eviction и memory limit для контейнеров.

Свободная RAM может быть небольшой при здоровой системе, если available memory остается достаточной, PSI близок к базовой линии, swap не активен, а latency не растет.

Swap activity: использование swap не всегда означает аварию

Занятая swap-область и активный paging, разные признаки. Ядро может переместить редко используемые страницы в swap и не создавать заметной задержки. Постоянный рост swap in и swap out означает, что рабочий набор процессов не помещается в RAM или система агрессивно освобождает страницы.

В vmstat 1 смотрите поля si и so. Команда sar -W 1 дает отдельную статистику paging. Свяжите эти значения с memory PSI, major page faults, iowait и p95 latency. Если swap операции идут непрерывно, приложение может замедлиться из-за чтения страниц с диска.

Отключение swap вслепую повышает риск OOM. Сначала проверьте, кто потребляет память, какой лимит задан cgroup и есть ли запас по available memory. В Kubernetes учитывайте requests, limits, QoS-класс pod и события eviction.

Память контейнера и память хоста

Хост видит общую RAM и page cache, а cgroup показывает учет конкретного контейнера. Один pod может достигнуть memory limit и получить OOMKilled, пока на узле остается свободная память. Обратная ситуация тоже возможна: контейнеры находятся ниже своих лимитов, но node испытывает общее давление из-за page cache, системных процессов или соседних workload.

Сопоставляйте четыре уровня:

• процесс и его resident set;
• контейнер и memory cgroup;
• pod и его request или limit;
• worker node и общий memory PSI.

Page cache не нужно автоматически считать утечкой. Утечку подтверждают устойчивый рост рабочего набора, отсутствие возврата памяти после снижения нагрузки и ухудшение поведения приложения. Для Kubernetes дополнительно проверьте OOMKilled, eviction, node pressure и события планировщика.

Диск и хранилище: IOPS, throughput и latency

IOPS показывают число операций ввода-вывода в секунду. Throughput измеряет объем переданных данных в секунду, обычно в MB/s или GB/s. Storage latency показывает время выполнения операции. Три значения описывают разные стороны нагрузки и должны анализироваться вместе.

Чем отличаются IOPS, throughput и storage latency

Мелкие случайные операции обычно упираются в IOPS и latency. Поток последовательных операций крупными блоками чаще ограничен throughput. База данных, виртуальная машина и metadata-heavy файловая система могут испытывать задержку при сравнительно небольшом throughput, если запросы мелкие или очередь уже растет.

IOPS без размера блока не позволяют сравнить две нагрузки. 50 000 операций по 4 KiB и 50 000 операций по 1 MiB создают разный throughput и требуют разных ресурсов. На результат влияют чтение или запись, случайный или последовательный профиль, глубина очереди, кэш контроллера, тип RAID и синхронность записи.

Высокий throughput не гарантирует малую задержку. Устройство может передавать большой поток, пока отдельные интерактивные операции ждут в очереди.

Очередь диска и насыщение устройства

В iostat -xz 1 проверьте await, read/write latency, utilization и средний размер очереди. Рост await вместе с queue depth означает, что операции ждут обслуживания. Поле busy около 100 процентов показывает постоянную занятость устройства, но тяжесть проблемы определяют достигнутая latency и требования приложения.

Для SSD и HDD одинаковое значение busy может иметь разный смысл. SSD обычно обслуживает больше операций с меньшей задержкой, HDD чувствителен к случайному доступу и перемещениям головки. Сравнивайте устройство с его baseline и SLA приложения, а не с абстрактным порогом.

В новых версиях sysstat поле svctm может отсутствовать или не давать полезной картины для современных блочных стеков. Ориентируйтесь на await, queue depth, read/write latency и показатели нижнего уровня, если они доступны.

pidstat -d 1 помогает связать I/O с процессами. Если очередь устройства растет из-за backup, compaction или scrub, временное ограничение фоновой задачи может подтвердить гипотезу быстрее, чем смена конфигурации сервера.

Особенности RAID, ZFS и NAS

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

В ZFS проверьте состояние пула, ARC hit ratio, sync writes, latency vdev и активность scrub или resilver. SLOG помогает отдельным сценариям синхронной записи, но не превращает медленный пул в универсально быстрый storage. Вывод делайте по задержке приложения, профилю записи и состоянию всех vdev.

Для NAS к локальным метрикам добавьте RTT до сервера, retransmits, latency удаленного mount и загрузку интерфейсов. Если локальный диск NAS отвечает быстро, а NFS или SMB-запросы медленные, причину нужно искать на сетевом пути, в протоколе или в серверной очереди.

Почему среднее значение latency недостаточно

Среднее сглаживает редкие медленные операции. Используйте распределение:

• p50 показывает типичный запрос;
• p95 отражает опыт пяти процентов самых медленных запросов;
• p99 помогает увидеть хвост задержек, который часто связан с очередями, GC, журналом или внешними зависимостями;
• max полезен для поиска единичных выбросов, но нестабилен как основной SLO-показатель.

Разделяйте чтение и запись, размер блока, endpoint и тип клиента. Средняя latency 5 ms может скрывать p99 в 2 секунды, если редкие операции влияют на критичные запросы.

Сеть: network latency, throughput и потери пакетов

Network latency описывает время прохождения данных между узлами, но у прикладного запроса несколько составляющих. Измеряйте RTT, время установления TCP или TLS, ожидание в очереди, обработку на сервере, обращение к базе и передачу ответа.

RTT не равна полной задержке запроса

ping измеряет ICMP RTT. Реальный HTTP, gRPC или database-запрос может включать DNS, TCP handshake, TLS handshake, балансировщик, очередь worker-пула, обработку приложения и несколько обращений к зависимым сервисам.

Сопоставьте ping или mtr с request latency и трассировкой запроса. Нормальный ICMP RTT не исключает задержку в приложении. Высокий RTT до одной зависимости не означает, что весь сервис работает медленно, если запросы к ней редкие.

Для оценки сетевого вклада разбейте таймер на DNS, connect, TLS, time to first byte и получение ответа. В распределенной системе отдельные интервалы по этапам точнее общего времени.

Throughput, потери и retransmits

Проверьте загрузку интерфейса, ошибки, drops, TCP retransmits, MTU, duplex и ограничения виртуальной сети. Полезные команды: ss -ti, sar -n DEV 1, ip -s link, ethtool -S и mtr.

• Рост retransmits увеличивает latency из-за повторной передачи и ожидания таймеров TCP.
• Packet loss может ухудшить сервис при незагруженном канале.
• Ошибки и drops на интерфейсе указывают на проблемы порта, кабеля, драйвера, MTU или виртуального коммутатора.
• Насыщение throughput нужно оценивать с учетом full-duplex, burst-трафика и ограничений каждого участка пути.

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

Сетевые задержки в распределенных системах

Сервис может быть доступен, но цепочка telemetry уже деградирует. Например, источник метрик отправляет данные в OpenTelemetry Collector, collector накапливает очередь из-за backpressure, а Prometheus получает неполный поток. На графике сервиса появится пропуск данных, хотя приложение продолжит обрабатывать запросы.

Проверяйте каждый участок:

1. доступность и RTT между источником и collector;
2. размер очереди и скорость отправки collector;
3. ошибки scrape и доступность targets;
4. время ingestion и возраст последнего sample в Prometheus;
5. таймауты, лимиты, DNS и внешние зависимости.

Проблема часто возникает во взаимодействии EC2, collector и хранилища метрик. Состояние каждого компонента по отдельности может выглядеть нормальным.

Как искать узкое место по шагам

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

Шаг 1. Начать с пользовательского симптома

Зафиксируйте, что именно изменилось:

• p95 или p99 latency;
• error rate и таймауты;
• request rate и throughput;
• конкретный endpoint, tenant, pod, узел или регион;
• время начала и частоту повторения.

Снижение throughput при прежнем request rate может означать очередь или отказ части worker-пула. Рост ошибок только у одного endpoint направляет поиск к его зависимости, а деградация всех операций, к общей инфраструктурной причине.

Шаг 2. Сопоставить время и масштаб проблемы

Наложите временные ряды сервиса, хоста, storage и сети на одинаковый интервал. Проверьте deploy, изменение конфигурации, cron, backup, compaction, failover, рост трафика и появление новых процессов.

Корреляция дает направление, но не доказывает причинность. Если latency и CPU выросли одновременно, выясните, что произошло первым. Сравните затронутый узел с незатронутым, а текущий период, с таким же периодом baseline.

Шаг 3. Найти насыщенный ресурс

Ищите saturation, очередь и задержку:

После уровня узла перейдите к процессу, контейнеру, pod, диску, интерфейсу или endpoint. Иначе нагрузка нескольких независимых компонентов сольется в одну среднюю цифру.

Шаг 4. Проверить цепочку latency

Разбейте время ответа на ожидание очереди, CPU, память, storage, сеть и внешние зависимости. Для приложения используйте tracing или отдельные таймеры. Для базы измеряйте ожидание соединения, выполнение запроса, блокировки и запись журнала.

В input-sensitive системах latency можно разложить на этапы mouse, CPU, memory, GPU или PCIe и display scan-out. Такой подход показывает, на каком участке pipeline возникает задержка, даже если итоговая метрика выглядит как одно число.

Пример: API стал медленнее, но CPU не вырос

Сначала график показывает рост p99 latency при умеренной CPU utilization. Проверка памяти обнаруживает рост PSI и reclaim, затем vmstat 1 показывает paging. В другом случае CPU остается низким, но iostat -xz 1 фиксирует рост await и queue depth. Еще один вариант, retransmits на сетевом соединении с базой.

Во всех трех сценариях низкая CPU utilization не исключает ограничение по памяти, storage или сети. Измените один подтвержденный фактор: уменьшите paging, остановите конкурирующую I/O-задачу или устраните потери пакетов. Восстановление p99 вместе с исчезновением признака saturation подтверждает гипотезу.

Методика поиска узких мест с baseline, p95 и p99 подробно разобрана в руководстве по оценке производительности системы.

Мониторинг производительности серверов в продакшене

Production-мониторинг должен показывать влияние на сервис и состояние ресурсов на одной временной шкале. Дашборд без request latency превращается в набор графиков хоста, а алерт без длительности и контекста создает шум.

Какие графики должны быть на основном dashboard

В верхней части разместите сервисные показатели:

• request rate;
• error rate;
• p95 и p99 latency;
• таймауты и насыщение worker-пула;
• throughput ключевых операций.

Ниже расположите инфраструктурные показатели:

• CPU per core, user, system, iowait, steal и throttling;
• load average и run queue;
• memory PSI, available memory, reclaim и swap in/out;
• disk latency, IOPS, throughput, utilization и queue depth;
• network RTT, packet loss, retransmits, errors, drops и throughput.

Добавьте фильтры по host, container, pod, device и endpoint. Для Kubernetes рядом с pod-метриками показывайте состояние worker node. Для NAS и ZFS разделяйте сетевую latency, latency пула, ARC и операции физических дисков.

Как строить алерты без лишнего шума

Связывайте алерт с пользовательским эффектом и устойчивым признаком насыщения. Рост CPU в течение 10 секунд редко требует реакции, если latency и ошибки не меняются. Высокая p99 вместе с run queue или throttling дает более полезный сигнал.

• Используйте окна наблюдения, например 5-15 минут, для устойчивых условий.
• Разделяйте warning и critical.
• Указывайте затронутый host, pod, device или endpoint.
• Добавляйте baseline для будних дней, ночных периодов и сезонных пиков.
• В тексте алерта указывайте первую проверку: iostat -xz 1, PSI, retransmits или cgroup throttling.

Порог должен отражать SLA или SLO сервиса. Универсальное правило «CPU выше 80 процентов» дает слабый результат: для одного сервиса это штатная работа, для другого, признак потери запаса.

Prometheus: scrape, retention и объем хранилища

Размер хранилища Prometheus зависит от числа targets, exporters, scrape interval, cardinality и retention. Универсальная формула вида «X GB на Y месяцев» ненадежна: два окружения с одинаковым числом серверов могут создавать разный объем временных рядов из-за labels и набора exporters.

Сначала соберите реальные данные scraping несколько дней. Оцените фактическую скорость генерации данных, экстраполируйте ее на нужный retention и добавьте примерно 20 процентов на straddling blocks. Сверху заложите операционный запас для новых targets, временного роста cardinality и обслуживания.

Контролируйте scrape errors, target availability, ingestion lag и возраст последнего sample. Отсутствие ряда может означать проблему exporter, сети, collector или самого Prometheus. Внешний облачный сервер или Kubernetes-площадку можно подобрать через Timeweb Cloud, если текущим узлам не хватает ресурсов для хранения и обработки метрик. Перед переносом проверьте retention, сетевую latency и требования к доступности.

Метрики, которые часто создают ложное впечатление

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

CPU utilization 100 процентов, не всегда авария

Высокая загрузка CPU ожидаема для CPU-bound обработки. Проверьте request latency, error rate, run queue, throttling и фактический throughput. Если сервис выдерживает целевую нагрузку, задержка укладывается в SLO, а ошибок нет, высокий CPU показывает использование доступного ресурса.

Проблема подтверждается, когда загрузка нужных ядер сопровождается растущей очередью, p99 и снижением throughput. Для контейнера дополнительно нужен контроль CPU limit и throttled time.

Низкая CPU utilization, не гарантия здоровой системы

Умеренная загрузка процессора встречается при высокой disk latency, memory pressure, сетевых retransmits, D-state и блокировках. CPU простаивает, пока задача ждет другой ресурс.

• Память проверяйте через PSI, reclaim, page faults и swap activity.
• Storage проверяйте через await, queue depth и read/write latency.
• Сеть проверяйте через RTT, loss, retransmits и ошибки интерфейса.
• Блокировки проверяйте на уровне базы, файловой системы и приложения.

Свободная память, IOPS и throughput без контекста

Free memory не равна запасу производительности, потому что RAM используется под cache. Смотрите available memory и PSI.

IOPS без размера блока и профиля чтения или записи не описывают нагрузку. 10 000 случайных операций и 10 000 последовательных операций создают разные требования.

Throughput не показывает tail latency. Большой поток данных может сосуществовать с медленными интерактивными операциями, которые ждут в очереди.

Средняя latency скрывает медленные запросы

Average подходит для общей оценки, но не показывает распределение. Сравнивайте p50, p95, p99 и число таймаутов. Если average стабилен, а p99 растет, проблема уже затрагивает часть клиентов и может быть связана с редкими I/O, GC, блокировками или зависимостями.

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

Missing series и stale data могут появиться при недоступном exporter, ошибках scrape, переполненной очереди collector, сетевом ограничении или задержке ingestion. Отдельно мониторьте:

• scrape errors;
• доступность targets;
• возраст последнего sample;
• ingestion lag;
• размер очереди отправки и backpressure collector.

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

Дополнительный разбор Linux-метрик и команд для поиска I/O, виртуализации и горячего ядра приведен в практическом руководстве по метрикам Linux.

Итоговая шпаргалка администратора

Связка «симптом - метрика - проверка»

Какие метрики считать обязательными в продакшене

Минимальный стандарт наблюдаемости включает сервисные latency, traffic и errors, затем saturation ресурсов:

• CPU utilization с разбиением по ядрам и режимам user, system, iowait, steal;
• load average и run queue;
• memory pressure, available memory и swap activity;
• disk latency, IOPS, throughput и queue depth;
• network latency, packet loss, retransmits и throughput;
• здоровье telemetry pipeline: scrape errors, target availability и ingestion lag.

Пороговые значения берите из baseline и требований SLA или SLO. Во время инцидента сначала зафиксируйте влияние на сервис, затем найдите насыщенный ресурс, очередь и latency, после чего перейдите к процессам, контейнерам, зависимостям и последним изменениям инфраструктуры.

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