Насыщение — один из четырёх сигналов. Весь набор также показывает задержку, трафик и ошибки; ресурсный график не заменяет пользовательский результат.
Почему это важно
Один график CPU не показывает успех запросов, а средняя задержка может скрыть медленный хвост. Набор сигналов помогает определить последствие и начать диагностику.
Что подтверждено
Google SRE выделяет четыре золотых сигнала: задержку, трафик, ошибки и насыщение. Трафик показывает объём обращений к системе, насыщение — приближение к её ограничениям.
Граница применимости: Подход к мониторингу распределённых систем; конкретные единицы и ресурс ограничения зависят от услуги.
При наблюдении задержки Google SRE рекомендует различать время успешных и неуспешных запросов: быстро вернувшаяся ошибка не доказывает быстрое выполнение полезной работы.
Граница применимости: Задержка запросов услуги. Классификация успеха задаётся явно и не сводится автоматически к одному коду протокола.
Для веб-службы трафиком могут быть запросы в секунду, для сетевого пути — биты в секунду на выбранном уровне. Единицу выбирают по работе услуги; эти два числа нельзя складывать или напрямую сравнивать.
Граница применимости: Редакторское сопоставление меры нагрузки и уровня измерения. Из интенсивности обращений не выводят автоматически долю успеха.
Высокая занятость ресурса — полезный контекст, но для насыщения проверяют его пределы, очереди и ожидание. Низкое среднее по серверу не исключает ограничение одного ресурса или части запросов.
Граница применимости: Редакторское объяснение диагностики по золотым сигналам и показателям ожидания. Конкретный универсальный процент CPU или памяти не назначается.
В учебной выборке было 100 успешных запросов по 200 мс; стало 50 успешных по 200 мс и 50 ошибок по 10 мс. Общее среднее снизилось с 200 до 105 мс, но доля ошибок выросла с 0% до 50%. Улучшившееся общее среднее не доказывает улучшение услуги.
Граница применимости: Закрытые выборки по 100 запросов с одинаковым правилом успеха. Приведено арифметическое среднее, а не перцентиль или прогноз.
Не путать
Задержка отвечает на вопрос о длительности, весь набор золотых сигналов также показывает трафик, ошибки и насыщение. Быстрые ошибки могут уменьшить общее среднее и одновременно ухудшить результат услуги.
Что проверить
- Выберите пользовательскую операцию и правило успеха.
- Измеряйте задержку и её распределение.
- Отделите задержку ошибок от успешных операций.
- Укажите единицу трафика и интервал измерения.
- Сопоставьте долю ошибок с теми же операциями.
- Назовите ресурс ограничения, очередь и признак ожидания.
- Проверьте, не улучшили ли среднее быстрые ошибки.
Первоисточники
Monitoring Distributed Systems
Google Site Reliability Engineering · Site Reliability Engineering, Chapter 6
Формулирует symptom-based paging, actionable pages и риск alert fatigue от частых незначимых notifications.
Открыть первоисточникRFC 5136: Defining Network Capacity
IETF · RFC 5136, February 2008
Разделяет nominal link capacity, available capacity и измерение результата на выбранном protocol layer.
Открыть первоисточникPressure Stall Information
Linux Kernel · Linux kernel documentation, проверено 29 августа 2026 года
Определяет CPU/memory/I/O pressure через долю времени stalled tasks и связывает contention с latency/throughput loss.
Открыть первоисточникImplementing SLOs
Google Site Reliability Engineering · The Site Reliability Workbook, Chapter 2
Описывает построение SLI/SLO от пользовательской цели, measurement window и error-budget policy.
Открыть первоисточник