Latency (задержка) — это время ожидания между началом операции и получением результата, но точный смысл зависит от контекста измерения. В мониторинге сервисов Google SRE под latency понимают время, нужное на обслуживание запроса, а в сетевом контексте AWS — время, за которое пакет проходит от источника к назначению.
На практике главное не смешивать разные виды задержки: задержку запроса, сетевую задержку, RTT и tail latency. Для наблюдаемости это обычно означает две вещи: отдельно учитывать latency успешных и неуспешных запросов и смотреть не только на «типичное» значение, но и на распределение.
Английский термин: latency. Также встречается: задержка, request latency (задержка запроса), network latency (сетевая задержка), tail latency (задержка в «хвосте» распределения). Не путайте: RTT (round-trip time) — смежный термин, а не синоним latency во всех контекстах.
Простыми словами
Грубо говоря, latency — это то, сколько вы ждёте. Нажали кнопку, отправили запрос, послали пакет — и считаете время до ответа или до прибытия.
Проблема в том, что «задержка» кажется одним числом, хотя в реальной системе секундомер можно поставить в разных местах. Если вы смотрите на сеть, вас интересует путь пакета. Если вы смотрите на API, вас интересует время обслуживания запроса. Если вы анализируете качество пользовательского опыта, вас особенно волнуют редкие, но очень долгие ответы — то есть tail latency.
Как это работает
Latency зависит от того, где именно вы начали и закончили измерение. Поэтому сначала выбирают контекст, а уже потом инструмент и тип метрики.
Контекст 1: сервис
клиент -> запрос -> сервис обрабатывает -> ответ
|--------------------------|
latency обслуживания запроса
Контекст 2: сеть
источник -> пакет -> назначение
|------------------|
network latency
Контекст 3: диагностика RTT
хост A -> ICMP Echo -> хост B -> ответ -> хост A
|--------------------------------------|
RTT
Наблюдаемость
много измерений -> histogram -> buckets -> распределение -> median/tail- Выберите объект измерения. Для сервиса это время обслуживания запроса; для сети — время прохождения пакета между точками.
- Собирайте много наблюдений, а не одно число. Prometheus рекомендует использовать histograms для распределений latency, потому что summary quantiles нельзя пересчитать или агрегировать после сбора.
- Соблюдайте формат метрики. В OpenMetrics histogram часто используется для HTTP request latency; buckets там кумулятивные и обязаны включать bucket
+Inf. - Инструментируйте приложение стандартным способом. В OpenTelemetry инструмент
Histogramпредназначен для статистик вроде request duration; записываемые числовые значения ожидаются неотрицательными. - Смотрите на «хвост» распределения. В работе Google Tales of the Tail прямо сказано, что интерактивным сервисам нужны и низкая медианная latency, и низкая tail latency.
Для HTTP в OpenTelemetry описаны стабильные histogram-метрики длительности запросов в секундах с рекомендуемыми явными границами buckets. В документации SDK также указано, что стандартный 160-bucket histogram может поддерживать long-tail распределения примерно от 1 мс до 100 с при относительной ошибке менее 5% — это полезно именно там, где редкие долгие ответы важны не меньше, чем средние.
Отдельная практическая деталь из Google SRE: latency успешных и неуспешных запросов лучше разделять. Иначе один агрегат может скрыть картину: быстрые ошибки и медленные успешные ответы смешаются в одну метрику, и вы потеряете диагностическую ценность.
Где применяется
- Мониторинг HTTP-сервисов. Histogram-метрики request duration используют, чтобы видеть распределение задержек, а не только одно среднее число.
- Агрегация latency в системах наблюдаемости. Prometheus и OpenMetrics ориентируют практику на histograms, особенно когда нужны распределения и последующая агрегация.
- Диагностика сети.
pingиз iputils измеряет round-trip delays и packet loss через ICMP Echo. - Диагностика маршрута.
mtrсочетает traceroute и ping, поэтому помогает увидеть поведение задержек по пути, но не заменяет измерение one-way latency.
Для интерактивных систем важен не только «обычный» ответ, но и редкие долгие ответы. Именно поэтому tail latency выделяют отдельно: пользователь замечает не абстрактное среднее, а конкретный долгий запрос.
Практический пример
Допустим, пользователи жалуются: «сервис стал медленным». Полезный минимальный сценарий — не смешивать сетевую диагностику с сервисной latency.
# 1) Проверка RTT и потерь пакетов
ping api.example.com
# 2) Просмотр пути и задержек по маршруту
mtr api.example.com- Запустите ping. Он показывает round-trip delays и packet loss, то есть поведение пути «туда-обратно», а не one-way latency.
- Запустите mtr. Он совмещает traceroute и ping и помогает увидеть, как ведут себя ответы по hops.
- Сверьте это с service latency. Если у вас уже есть histogram длительности HTTP-запросов, сравнивайте распределение задержек сервиса с сетевой диагностикой, а не подменяйте одно другим.
- Не делайте поспешных выводов по промежуточным узлам. В репозитории mtr прямо оговорено, что ICMP-ответы могут rate-limitиться или отсутствовать, поэтому кажущаяся потеря на промежуточном hop не обязательно означает потерю пересылаемого трафика именно там.
Практический вывод: ping и mtr хороши для RTT и поведения маршрута, но не отвечают на вопрос о one-way latency и не заменяют метрики самого сервиса. Для приложений их лучше использовать как диагностическое дополнение к histogram-метрикам request duration.
Если вы разбираете задержки в ИИ-системах, рядом часто всплывают смежные темы: Batching (пакетная обработка), AI Agent (ИИ-агент), Self-attention и AI Safety (безопасность ИИ).
Чем отличается от RTT, сетевой задержки и tail latency
| Термин | Что измеряет | Чем отличается от latency в общем смысле |
|---|---|---|
| Service/request latency | Время обслуживания запроса сервисом | Это частный случай latency из практики SRE; успешные и неуспешные запросы лучше разделять. |
| Network latency | Время прохождения пакета от источника к назначению | Это сетевой контекст; он не равен автоматически времени ответа всего приложения. |
| RTT | Время пути туда и обратно | ping измеряет именно RTT, а не one-way latency. |
| Tail latency | Задержки в «хвосте» распределения | Это не отдельный вид транспорта или протокола, а фокус на редких долгих ответах, критичных для интерактивных сервисов. |
Ограничения и заблуждения
- Заблуждение: latency — всегда одно и то же. На самом деле термин контекстный: request latency, network latency, queueing delay, storage latency и RTT отвечают на разные вопросы.
- Заблуждение: ping показывает «задержку сети» в полном смысле. По данным iputils это измерение round-trip delays через ICMP Echo; это не прямое измерение one-way latency.
- Заблуждение: достаточно одного среднего значения. Для интерактивных сервисов важны и медианная latency, и tail latency.
- Заблуждение: любые quantiles можно удобно агрегировать после сбора. В практике Prometheus summaries для этого неудобны: summary quantiles нельзя пересчитать или агрегировать после collection, поэтому для latency-распределений обычно предпочитают histograms.
- Ограничение диагностики mtr. Потери на промежуточном hop могут быть ложным сигналом, если устройство ограничивает или не отправляет ICMP-ответы.
Редакционное ограничение: по открытым источникам в этом материале нельзя честно назвать «нормальную latency» без конкретного сервиса, сети и точки измерения. Практический вердикт простой: сначала определите контекст, затем измеряйте распределение, а не спорьте об одном числе.
Источники
- Monitoring Distributed Systems
- Performance – Hybrid Connectivity
- Histograms and summaries
- OpenMetrics Specification 1.0
- Metrics API
- HTTP semantic conventions for metrics
- Metrics SDK
- Tales of the Tail: Hardware, OS, and Application-level Sources of Tail Latency
- iputils/iputils
- traviscross/mtr
Вопросы и ответы
Latency и RTT — это одно и то же?
Нет. RTT — это время пути туда и обратно, которое показывает ping. Latency в более широком смысле может означать и задержку обслуживания запроса, и one-way задержку пакета.
Почему нельзя мерить всё только ping?
Потому что ping показывает ICMP round-trip delays и packet loss. Он не заменяет метрики request duration внутри сервиса и не даёт прямой one-way latency.
Зачем разделять latency успешных и неуспешных запросов?
Так рекомендует Google SRE: смешивание скрывает картину. Быстрые ошибки и медленные успешные ответы могут дать «красивый» агрегат, который ничего не объясняет.
Почему для latency часто выбирают histogram, а не summary?
Потому что в практике Prometheus summary quantiles нельзя пересчитать или агрегировать после сбора. Histograms удобнее для распределений latency и последующей агрегации.
Можно ли по mtr точно понять, где теряются пакеты?
Не всегда. Репозиторий mtr предупреждает, что промежуточные устройства могут ограничивать или не посылать ICMP-ответы, поэтому видимая потеря на hop не обязательно означает потерю пересылаемого трафика именно там.