Логи в Grafana Loki на сервере: частые ошибки и решения

MAATRIX

Loki и Promtail подняты, но логи не появляются в Grafana, сыплются ошибки «entry out of order», Loki отвечает 429 или память сервера уходит в потолок. Все эти проблемы Loki типовые и почти всегда связаны с метками, временем или конфигом Promtail. Разберём частые ошибки логов в Grafana Loki на сервере с диагностикой и готовыми решениями.

Логи не доходят до Loki

Самая частая жалоба — в Grafana пусто, хотя Promtail запущен. Диагностику ведите с обоих концов: сначала проверьте, что Promtail жив и читает файлы, потом — что Loki их принимает.

Проверьте статус Promtail и его лог:

systemctl status promtail
journalctl -u promtail -n 50

Частые причины в логе Promtail. Первая — не тот URL Loki в конфиге: поле clients.url должно указывать на http://IP_LOKI:3100/loki/api/v1/push, с правильным IP и путём. Вторая — Loki недоступен по сети: firewall закрыл порт 3100. Откройте его на сервере Loki только для адресов источников:

ufw allow from IP_ИСТОЧНИКА to any port 3100

Третья — Promtail не имеет прав читать логи: файлы в /var/log часто закрыты, а Promtail работает не от root. Проверьте, доступен ли путь из __path__. Убедитесь, что сам Loki принимает данные, обратившись к его API:

curl -s "http://localhost:3100/ready"

Ответ ready означает, что Loki готов. Если нет — смотрите его собственный лог.

Метод «диагностики с обоих концов» стоит взять за правило: система сбора логов — это конвейер из трёх звеньев (Promtail читает, сеть передаёт, Loki принимает), и обрыв на любом звене даёт одинаковый симптом «в Grafana пусто». Поэтому не гадайте, а проверяйте по цепочке: видит ли Promtail файлы (его лог покажет, сколько строк прочитано), уходят ли они (в логе Promtail будут ошибки отправки, если Loki недоступен), принимает ли Loki (его /ready и лог). За пять минут такой проверки вы точно локализуете, где рвётся конвейер, вместо того чтобы наугад менять конфиги то на одном, то на другом конце.

Ошибка «entry out of order»

Классическая ошибка Loki: Promtail шлёт логи, а Loki их отвергает с «entry out of order» или «entry too far behind». Причина — Loki (в старых версиях и по умолчанию) требовал, чтобы записи одного потока приходили строго по возрастанию времени. Если в лог попадают строки с более ранним временем, чем уже принятые, — отказ.

Причин рассинхрона несколько. Часто это неверный часовой пояс на источнике: время сервера врёт, и метки времени скачут. Проверьте и синхронизируйте время:

timedatectl set-ntp true
timedatectl status

Вторая причина — вы объединили в один поток (одинаковый набор меток) логи из нескольких файлов с разным временем, и они перемешались. Решение — развести их разными метками, чтобы у каждого потока было своё монотонное время. В свежих версиях Loki приём непоследовательных записей ослаблен, но лучшая практика — чинить причину: точное время через NTP и аккуратные метки.

Ошибка 429: too many outstanding requests

Loki отвечает кодом 429 и «too many outstanding requests» или «rate limit exceeded» — вы упёрлись в лимиты приёма. Loki намеренно ограничивает поток, чтобы не захлебнуться, и при всплеске логов начинает отклонять.

Настраиваются лимиты в секции limits_config конфига Loki. Ключевые параметры — предельная скорость и размер всплеска на поток:

limits_config:
  ingestion_rate_mb: 8
  ingestion_burst_size_mb: 16
  per_stream_rate_limit: 5MB
  per_stream_rate_limit_burst: 20MB

Поднимите значения под свой объём и перезапустите Loki. Но прежде чем крутить лимиты вверх, задайте вопрос — почему логов столько. Часто причина в приложении, которое пишет гигабайты в цикле ошибок, или в слишком «болтливом» уровне логирования. Уменьшить поток на источнике (поднять уровень до warning, отфильтровать шум в Promtail) правильнее, чем бесконечно повышать лимиты.

Взрыв кардинальности меток

Коварнейшая проблема Loki — высокая кардинальность меток, из-за которой сервер жрёт память и тормозит. Loki индексирует метки, и каждая уникальная комбинация меток создаёт отдельный поток. Если вы положили в метку что-то с миллионом значений — ID запроса, IP клиента, путь URL с параметрами, — число потоков взрывается, и Loki задыхается.

Правило простое: метки — только для того, что имеет мало значений и по чему вы фильтруете (сервис, хост, уровень, окружение). Всё высококардинальное (ID, IP, конкретные URL) должно оставаться в теле лога и искаться фильтром |=, а не быть меткой. Если память Loki растёт необъяснимо, первым делом проверьте метки в конфиге Promtail:

grep -A5 labels /etc/loki/promtail-config.yml

Уберите из labels всё, что может принимать много значений. Это чинит большинство проблем с производительностью Loki раз и навсегда — кардинальность важнее, чем объём самих логов.

Чтобы понять масштаб проблемы, представьте арифметику. Если у вас есть метки host (10 значений) и job (5 значений), это 50 возможных потоков — Loki справляется играючи. Но стоит добавить в метки IP клиента, и при 100 000 уникальных адресов число потоков подскакивает до миллионов. Каждый поток — это отдельная структура в памяти, отдельная запись в индексе, отдельный набор файлов. Отсюда и внезапный рост памяти, и падение скорости запросов, и в тяжёлых случаях — крах сервера. Именно поэтому опытные администраторы относятся к добавлению новой метки как к архитектурному решению, а не как к мелочи: одна неудачная метка способна уронить весь сбор логов, и лечится это только удалением метки и переиндексацией.

Диск заполняется и Loki падает

Логи копятся, диск заполняется, Loki перестаёт принимать данные. Причина — не настроено или слишком длинное хранение. Loki хранит чанки на диске, и без ограничения они растут бесконечно.

Задайте срок хранения и включите его применение в конфиге:

limits_config:
  retention_period: 720h
compactor:
  retention_enabled: true
  delete_request_store: filesystem

retention_period: 720h — это 30 дней; компактор с retention_enabled: true действительно удаляет старые данные (без него параметр хранения не применяется — частая ошибка). Следите за диском:

du -sh /var/lib/loki
df -h

Если логов объективно много и 30 дней истории занимают слишком много места, честный вывод — нужен диск побольше. Переход на VPS с большим диском решает это без ежедневной чистки. У MAATRIX сервер с нужным объёмом поднимается за пару минут, с оплатой картой РФ, СБП или криптой — иностранная карта не требуется.

Частые вопросы