Multi-tenancy
Тема дорожной карты · Loki
Мультитенантность в Grafana Loki позволяет одному кластеру Loki обслуживать несколько изолированных арендаторов: данные логов каждого арендатора хранятся отдельно и доступны только для запросов, содержащих корректный HTTP-заголовок X-Scope-OrgID, идентифицирующий арендатора. Мультитенантность включается установкой auth_enabled: true в loki-config.yaml; при отключённой мультитенантности (по умолчанию) Loki рассматривает все запросы как принадлежащие единственному синтетическому арендатору с именем fake. В развёртывании с несколькими арендаторами такие ограничения на уровне арендатора, как ingestion_rate_mb, max_streams_per_user, retention_period и max_query_length, можно настраивать индивидуально через файл per_tenant_override_config, предоставляя операторам детальный контроль над использованием ресурсов и жизненным циклом данных для каждого арендатора. Distributor применяет ограничения скорости записи и количества потоков на уровне арендатора при записи, тогда как Compactor обеспечивает применение политики хранения при удалении устаревших чанков из объектного хранилища. Мультитенантность широко применяется в командах платформенной инженерии, развёртывающих единый кластер Grafana Loki для нескольких продуктовых команд: это обеспечивает изоляцию логов и справедливое распределение ресурсов без необходимости поддерживать отдельный экземпляр Loki для каждой команды.
Как это работает
Multi-tenancy: 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 заранее.
Типичные ошибки
Ловушки Multi-tenancy: прыжок в microservices без нужды (operational complexity); нет caching-слоя (каждый query бьёт object storage); multi-tenancy без tenant rate-limits (один плохой tenant деградирует всех); недопровизион ingester memory (chunks теряются на OOM).