Loki 429: too many outstanding requests при ingestion — причины и пошаговое исправление

Что означает «429: too many outstanding requests / ingestion» в Loki

Ошибка 429 с контекстом ingestion чаще всего видна на стороне отправителя (Promtail, Grafana Agent, приложение) и означает, что Loki начал ограничивать приём логов. Важно: это не «веб‑API перегружен» в классическом смысле, а сигнал о backpressure внутри пишущего контура (distributor/ingester). У Loki копится слишком много незавершённых операций, и он отдаёт 429, чтобы не уйти в неконтролируемый рост памяти и CPU.

Практически всегда корень проблемы в одном из сценариев:

• слишком много уникальных streams из‑за высокой label cardinality;
• упёрлись в ingestion rate limit или другие tenant limits;
• инфраструктурная деградация (CPU/сеть/диск/объектное хранилище), из‑за которой нормальный поток превращается в «долги».

Дальше — практичный план: как быстро подтвердить причину, где именно «затык», и что менять, чтобы не лечить симптом повышением лимитов до падения по OOM.

Как выглядит проблема: симптомы на отправителе и внутри Loki

На стороне Promtail / Grafana Agent

Типичная картина — ретраи при отправке батчей и рост очередей. Обычно видно:

• регулярные ошибки push с кодом 429;
• рост буфера/очереди у шиппера;
• увеличение задержки доставки (логи «догоняют» через минуты).

Если шиппер настроен агрессивно (мелкие батчи, много параллельных отправок), он способен усилить инцидент: Loki не успевает, шиппер «давит» сильнее, outstanding‑очередь растёт, и 429 становится постоянным состоянием.

Внутри Loki

Перегруз ingestion внутри Loki чаще проявляется как комбинация:

• высокий CPU у distributor и ingester;
• рост памяти у ingester из‑за большого числа активных streams и незакрытых чанков;
• замедление flush чанков и запись в storage;
• ошибки/таймауты при доступе к объектному хранилищу (особенно на схемах с активной компакцией/индексом).

Экспресс-диагностика за 15 минут: лимит или деградация

Цель — понять, Loki «умышленно режет» поток лимитами или физически не справляется (ресурсы/хранилище).

1) Убедитесь, что 429 отдаёт именно Loki

Соберите несколько примеров с отправителя: время, tenant (если используете multi-tenant), куда шёл push. Если Loki стоит за reverse‑proxy, проверьте, не прокси ли возвращает 429. Это важно, чтобы не искать лимиты Loki там, где виноват балансировщик.

2) Локализуйте «плохой» источник

Почти всегда есть один сервис или job, который создаёт основную нагрузку: слишком болтливый компонент, внезапно включившиеся подробные логи, или пайплайн, который превратил динамические поля в метки. Упростите поиск: используйте стабильные лейблы job, namespace, app, cluster, чтобы быстро выделить источник.

Быстрый (хоть и грубый) приём в момент инцидента: временно отключить отправку от подозрительного job или снизить verbosity и посмотреть, исчезают ли 429. Если исчезают — вы нашли «центр тяжести».

3) Проверьте label cardinality (самый частый корень)

Если внезапно выросло число streams, ingester начинает тратить ресурсы на обслуживание огромного количества активных рядов логов: держит состояние, крутит маленькие чанки, чаще флашит в storage. Это очень быстро приводит к «too many outstanding requests».

Правило для Loki: метки — это индекс. Всё, что часто меняется (request id, user id, IP, путь с параметрами, pod UID), почти никогда нельзя класть в labels.

Если тема с метками у вас «болит» регулярно, удобно держать короткую памятку для команды и общий подход к пайплайнам. По этой части пригодится материал: как проектировать labels и pipelines в Loki без кардинальности.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Почему label cardinality вызывает Loki 429 быстрее всего

В Loki уникальная комбинация меток — это отдельный stream. Добавили метку request_id или trace_id — получили почти бесконечное количество streams. То же происходит, если в лейблы попал полный URL с query‑параметрами, динамический путь, имя файла с хэшем, номер билда и т.д.

Технические последствия высокой кардинальности:

• ingester хранит состояние по большому числу активных streams (рост памяти и CPU);
• чанки становятся маленькими, чаще флашатся (рост накладных расходов на запись);
• индексация/компакция начинают занимать заметно больше ресурсов;
• увеличивается число незавершённых операций — и Loki включает backpressure через 429.

Как быстро выявить «опасные» метки

Самый практичный путь — корреляция с изменениями:

• что поменяли в promtail/agent pipelines за последние деплои;
• не изменился ли формат логов приложения (JSON‑поля, новые атрибуты);
• не стали ли вы вытаскивать в labels значения, которые раньше были в тексте.

Если нужно «потушить» инцидент и параллельно собрать фактуру, временно ограничьте поток от подозрительного источника и зафиксируйте, как меняется количество 429. Это ускоряет поиск в разы.

Tenant limits и ingestion rate limit: где Loki реально режет поток

В Loki лимиты чаще всего применяются per-tenant (даже если tenant один). Ошибка 429 может означать, что вы достигли одного из порогов:

• ingestion rate limit — лимит входящего объёма (байт/сек);
• лимит на количество streams (защита от взрыва кардинальности);
• лимиты на размеры (строка/батч/чанк) — иногда проявляются иначе, но тоже ломают ingestion.

Опасная стратегия — «просто поднять лимиты». Если первопричина в метках, вы обычно заканчиваете OOM на ingester или резким ростом расходов на storage. Рабочая последовательность такая:

1. сначала уменьшить cardinality и стабилизировать пайплайны;
2. потом убедиться, что ресурсы и storage выдерживают нагрузку;
3. только затем аккуратно расширять лимиты под реальные пики.

Минимальный набор проверок по лимитам

Когда видите 429, полезно ответить на три вопроса:

• это стабильно на всех источниках или только у одного job;
• есть ли совпадение с пиковыми нагрузками (релизы, бэкапы, крон‑задачи);
• не было ли недавно изменений в limits_config/runtime overrides.

Promtail: как настроить отправку, чтобы не добивать Loki

Даже если Loki «на грани», корректная отправка снижает шанс получить «too many outstanding requests» при кратковременных сбоях:

• батчи должны быть достаточно крупными, чтобы не тратить ресурсы на слишком частые запросы;
• ретраи должны быть с backoff, а не «в лоб»;
• параллелизм отправки — ограниченный;
• если ваш агент это поддерживает — используйте буферизацию на диске как страховку на пики.

Критичный момент: извлекать поля из логов можно и нужно, но далеко не всё должно становиться label. Большинство динамических атрибутов лучше оставить в JSON/тексте и искать уже на запросе.

Практическое правило: что оставлять в labels

• статические признаки источника: job, service, namespace, cluster, env;
• низкая кардинальность: level (если значений 4–6), component;
• редко меняющиеся значения (условно: меняются несколько раз в день, а не на каждый запрос).

Кандидаты на проблему: user_id, ip, request_id, session, полный url, pod (если постоянно пересоздаётся) и любые значения, которые «почти всегда уникальны».

Хранилище и схема (в т.ч. boltdb-shipper): когда 429 — следствие медленного storage

Даже при нормальной кардинальности ingestion может «упираться» в storage: если запись чанков/индекса тормозит, растёт время внутренних операций, увеличиваются очереди и Loki начинает ограничивать вход.

Типовые узкие места:

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

Если Loki крутится на вашей инфраструктуре, часто самый простой путь стабилизировать ingestion — вынести компоненты на предсказуемые ресурсы и не экономить на диске/CPU. Для таких задач обычно выбирают VDS, чтобы гарантировать лимиты по ресурсам и избежать «шумных соседей».

Retention: как срок хранения косвенно влияет на ingestion

Retention напрямую про стоимость и объёмы, но на стабильность ingestion он тоже влияет: чем больше данных и индексов обслуживается постоянно, тем выше фоновые затраты на компакцию и обслуживание. На пиках это может «съедать» ресурсы, которые вы ожидаете видеть у ingestion.

Рабочая стратегия retention обычно такая:

• короткий срок хранения для шумных логов (debug/trace‑подобные);
• дольше — только для важных аудиторных событий, ошибок, безопасности;
• если нужен долгий срок — храните более структурированные события и следите за метками.

Если вы как раз планируете пересобрать схему хранения логов под свои сроки и бюджеты, может быть полезен материал: retention в Loki/Promtail и выбор инфраструктуры.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Пошаговый план устранения Loki 429 без «выключить лимиты»

Шаг 1. Остановите рост нагрузки (оперативные меры)

Если инцидент активный, сначала снизьте давление: временно уменьшите verbosity (например, DEBUG → INFO) у проблемного сервиса или отключите отправку конкретного job. Это создаст «окно», чтобы спокойно исправлять конфиги.

Шаг 2. Приведите labels к безопасному виду

Проверьте pipelines promtail/agent и уберите динамические поля из labels. Если поле важно для расследований — оставьте его в JSON/тексте и используйте парсинг/фильтрацию на запросе.

Шаг 3. Проверьте limits и увеличивайте их только после нормализации меток

Если кардинальность нормальная, поток предсказуемый, а лимиты срабатывают на честных пиках — увеличивать их можно. Делайте это вместе с мониторингом CPU/памяти ingester и скоростью записи в storage.

Шаг 4. Нормализуйте ретраи и параллельность отправителя

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

Шаг 5. Проверьте storage и компакцию

Если по меткам всё хорошо, но 429 появляется на пиках, ищите задержки работы со storage и конкуренцию за ресурсы. Частая ловушка: проблема выглядит как ingestion, а фактически это медленная запись/компакция.

Шаг 6. Пересмотрите retention

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

Типовые анти‑паттерны, из-за которых 429 возвращается

• сделали label из уникального идентификатора (request_id, trace_id) «чтобы фильтровать»;
• добавили в labels полный URL с параметрами;
• подняли лимиты и забыли: потом рост нагрузки заканчивается OOM вместо 429;
• ретраи без backoff и без ограничений по параллельности;
• всё в одном tenant без изоляции: один шумный сервис «кладёт» приём для всех.

Мини‑чеклист стабильного ingestion в Loki

• labels — только низкая кардинальность, динамика остаётся в тексте/JSON;
• tenant limits настроены осмысленно (rate, streams) и соответствуют вашему профилю нагрузки;
• promtail/agent отправляет адекватные батчи, ретраи с backoff;
• storage и сеть до него выдерживают пиковый ingestion rate;
• retention соответствует реальным требованиям, а не «по умолчанию 90 дней».

Если нужно быстро масштабироваться без сюрпризов

Когда вы устранили проблемы с label cardinality, стабилизировали отправку и упёрлись в честный рост, остаются два направления: масштабирование компонентов Loki (ingester/distributor/compactor) и обеспечение предсказуемого storage, либо пересмотр объёма и retention. Ориентируйтесь на пики: пиковая скорость логов и число активных streams важнее средних значений.

Если хотите, подготовлю шаблон диагностики под ваш сетап: какие метрики снять, какие логи собрать и как по ним отличить лимит от деградации CPU/storage.