Масштабирование

Grafana Loki разработан для горизонтального масштабирования путём распределения нагрузки между несколькими экземплярами ключевых компонентов — Distributor, Ingester, Querier и Query Frontend, — а не за счёт вертикального масштабирования единого монолитного процесса. Пропускная способность записи масштабируется путём добавления Distributor-ов и Ingester-ов в хеш-кольцо, тогда как пропускная способность чтения повышается за счёт добавления реплик Querier и Query Frontend, способных распараллеливать и шардировать LogQL-запросы по сохранённым чанкам. Loki предлагает три режима развёртывания, соответствующих разным точкам на шкале масштабирования: монолитный режим (все компоненты в одном бинарном файле, для разработки), простой масштабируемый режим (разделение на чтение/запись для средних нагрузок) и полный режим микросервисов (каждый компонент развёртывается независимо для крупного продакшена). Объектное хранилище (S3, GCS или Azure Blob) — это общий уровень персистентности, обеспечивающий горизонтальное масштабирование без сохранения состояния, поскольку как Ingester-ы, так и Querier-ы можно заменять или масштабировать без потери данных. При планировании стратегии масштабирования Grafana Loki важно также пропорционально масштабировать Compactor, Ruler и уровни кэширования (Memcached или Redis), чтобы уплотнение индекса, оповещения и кэширование запросов успевали за ростом нагрузки на запись и чтение.

Как это работает

Масштабирование: Loki имеет три deployment режима. Monolithic (один бинарь, проще) — ок для < 100GB/день. Simple Scalable (read/write/backend сервисы в 3 tier-ах) — рекомендуется для большинства prod до TB/день. Microservices (каждый компонент scaled независимо) — для экстремального масштаба + multi-tenancy. Multi-tenancy через X-Scope-OrgID header. Cache (Memcached или Redis) ускоряет chunk + query result retrieval — essential на масштабе. Stateless сервисы + object storage = scale через добавление replicas.

Когда применять

Старт monolithic, переход на simple-scalable когда один бинарь упирается в лимиты, microservices только при нужде в true component-level autoscaling. Memcached / Redis cache — force-multiplier — включайте рано. Для multi-tenancy — design tenant ID propagation + per-tenant rate limits заранее.

Типичные ошибки

Ловушки Масштабирование: прыжок в microservices без нужды (operational complexity); нет caching-слоя (каждый query бьёт object storage); multi-tenancy без tenant rate-limits (один плохой tenant деградирует всех); недопровизион ingester memory (chunks теряются на OOM).

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы