Вот вечером приходит алерт, что на виртуалке с VictoriaMetrics и Loki осталось <5% места. А я последний раз когда смотрел, там 160+ гигов было (из 300). Что-то явно пошло не так. Вряд ли это метрики, я давно не добавлял новые скрейп-таргеты, значит какие-то логи начали лететь.
Начинаю смотреть графики виртуалки:
- 22 декабря с 7 утра начал активно забиваться диск
Как понимаю, что это именно Loki жрет место. Аномально много места занимают два конкретных чанка данных. Смотрим в ncdu или du -sh на директории с данными VM и Loki:
--- /var/lib/loki/chunks/fake ---
/..
71.1 GiB [##########] /71a536873561d772
71.0 GiB [######### ] /4ed05483e3664242
9.9 GiB [# ] /47a1d97545945804
4.0 GiB [ ] /ab30104fb5a49027
3.4 GiB [ ] /1fb8841baeb3ef1
2.3 GiB [ ] /eaeec6ed138da0a2
1.4 GiB [ ] /f973cac99619b763
1.4 GiB [ ] /39aad22606baff2b
Причем видно, что файлы в них начали создаваться только после 22 декабря, значит ОНО:
find /var/lib/loki/chunks/fake/71a536873561d772/ -type f -printf '%TY-%Tm-%Td\\n' | sort | uniq -c
872 2025-12-22
1390 2025-12-23
1390 2025-12-24
1394 2025-12-25
....
Посмотрим количество логов с разбивкой по лейблу
job (тайм-рейндж выставляю на 1 час вокруг начала инцидента). Иду в Grafana Explore, выбираю Loki как data source:sum by (job) (count_over_time({job=~".+"}[5m]))Там вижу, что всплеск и дальнейшее плато выпадает на job-у
containerlogs. В этот лейбл я собираю логи с контейнеров со всех серверов. Значит надо посмотреть с какого хоста это летит и с какого compose-сервиса (или swarm-stack-а):topk(5, sum by (host) (count_over_time({job="containerlogs"}[5m])))Вижу на графике конкретный хост, добавляю его в фильтр. Так же меняю лейбл для суммирования, на stack_name (так как на этом сервере подняты сервисы Docker Swarm):
sum by (stack_name) (count_over_time({job="containerlogs", host="host.com"}[5m]))Теперь на графике видно сбойный сервис. Беру в охапку автора и идем смотреть конкретные логи этого сервиса в момент инцидента. Вижу, что сервис в определенный момент начал сыпать ошибками. Обычно, если ошибок нет, то нет и логов от сервиса. А тут он начал писать по ~300к строк в минуту. Анализирую ошибки, понимаю, что они в целом одинаковые.
Выясняем, что в сервис пришел кривой JSON, сервис не смог его обработать корректно, выдавал ошибку, возвращал JSON в очередь. А затем брал его же из очереди, выдавал ошибку... и так далее по кругу.
Теперь самое сложное: что сделать, чтобы избежать подобного в будущем?
- Более тщательный мониторинг занятого места на диске, лучше с predict-ом “с таким темпом место кончится через Х дней/часов”. Но расход был медленный, алерт пришел бы сильно не скоро.
- Rate Limit на количество логов в минуту на стороне Loki, повесить алерт на превышение.
- Ронять контейнер на каждый сбой? Норм, если есть алертинг на рестарты контейнеров. А что, если в очереди куча сбойных json-ов?
- Складывать сбойные json-ы не обратно в основную очередь, а в другую. И мониторить ее наполняемость? А если json был нормальным, просто сбой был временным - тогда валидный json улетит в мусорку…
- Настроить отправку exceptions в Sentry и сделать алерты?
- 👉 Стоит ли вообще что-то делать, если сервис - легаси и ломается примерно никогда и не сильно влияет на прод?
А можно ли удалить лишние логи? Я в свое время не нашел явного несложного способа дропнуть логи в Loki, например, за определенные даты. Только если настраивать новый ретеншен, либо грохать всё. В моем случае я просто оставлю, пока есть свободное место - в течение ретеншен-периода оно уйдет.