Всем привет. В этой статье будет много текста, мало цифр с пруфами, пока что более поверхностный разбор, но я думаю тем кто упустил GrafanaCON 2026 это будет интересно.

Маленький спойлер для начала

Существует особый класс технических конференций, где за бодрыми слайдами прячутся по-настоящему серьёзные архитектурные решения. GrafanaCON 2026 в Барселоне оказался именно таким. Grafana Labs представила Grafana 13 и целую волну обновлений open source инструментов, но для всех, кто эксплуатирует логирование на промышленных масштабах, главной темой стала переработка архитектуры Loki под девизом "Architecture for the Next Wave of Log Workloads"

Мир логов изменился, а Loki - пока что нет

Рост популярности структурированных логов и OpenTelemetry фундаментально изменил паттерны работы с логами: от простого текстового поиска — к сложным аналитическим запросам с высокой кардинальностью. Это сделало критически важным переосмысление системного дизайна, чтобы устранить узкие места производительности и растущие расходы на инфраструктуру.
Проще говоря: инструмент, который строился как «дешёвый поиск по тексту», столкнулся с задачами, для которых не проектировался. (ну ладно я тут утрирую что это «дешевый поиск по тексту», но всё же).

По данным Grafana Labs 2026 Observability Survey, более 77% организаций опираются на open source и открытые стандарты для observability. Но однако более 38% команд по‑прежнему называют главной проблемой — сложность. Направление выбрано верное, но эксплуатировать инструменты по‑прежнему непросто. Именно в этот разрыв метит «Next Wave».

Проблема с репликацией: копии каждой строки лога

Чтобы понять ценность изменений, нужно сначала понять, что именно сломано в старой архитектуре.

Традиционная архитектура Loki достигала высокой доступности через репликацию: каждая входящая строка лога отправлялась трём ингесторам (replication factor = 3). Дедупликация при этом опиралась на именование файлов — если ингесторы покрывали один временной диапазон, они должны были генерировать идентичные имена файлов, и дубликаты «схлопывались».
Staff Software Engineer Тревор Уитни объяснил механику во время брифинга на GrafanaCON: в распределённой системе ингесторы немного расходятся по времени, и любой дрейф синхронизации приводит к тому, что файлы получают разные имена — дедупликация перестаёт работать корректно.

Результат? Каждая строка лога в среднем хранилась 2.3 раза — двойной перерасход CPU, памяти, сети и объектного хранилища. (значение 2.3 раза — это более империческая величина). Да это осознанная плата, ведь без репликации мы бы теряли данные при падении узла, но факт остается фактом мы получаем избыточное хранение и доп.нагрузку.

Три архитектурных изменения, которые изменят всё

Теперь переходим к самому интересному, а что же именно изменится в архитектуре Loki.

Kafka как durability layer: конец эпохи репликации на ингесторах.

Первое и самое фундаментальное изменение. Grafana Labs вводит Kafka-backed ingestion - более эффективные и надёжные пайплайны на уровне приёма логов.

Принципиальный сдвиг прост: вместо репликации между ингесторами - очередь сообщений как единственный источник истины. Лог попадает в Kafka один раз, а уже оттуда его забирают ингесторы. Эффективный фактор репликации падает до единицы. Данные перестают дублироваться.
Но тут есть важная оговорка: single-binary режим для разработки и домашних лабораторий не требует Kafka. Новая зависимость актуальна только для полноценных production-инсталляций с распределённым режимом работы. Для тех, кто уже использует Kafka в своём стеке, это означает более органичную интеграцию всего observability-пайплайна.

Новый планировщик запросов: data locality и параллелизм

Переработанный планировщик запросов распределяет работу по партициям и выполняет её параллельно, оптимизируя под локальность данных и максимизируя пропускную способность. Это позволяет Loki обрабатывать значительно меньше данных на каждый запрос при более быстром возврате результатов.

Две ключевые идеи нового планировщика:

Data locality - стараться обрабатывать данные там, где они физически находятся, а не тащить их через сеть. Особенно критично при работе с облачными хранилищами, где каждый байт передачи стоит денег.

Параллельное исполнение — позволяет разбивать один большой запрос на независимые подзапросы по патрициям и выполнять их одновременно, вместо последовательного сканирования потоков.

В совокупности эти изменения дают до 20-кратного сокращения сканируемых данных и 10-кратного ускорения на агрегирующих запросах. Но стоит понимать что эти цифры могут оказаться маркетинговым вбросом от Grafana. Вангую но на деле мы получим цифры немного другие. Но если Вы платите за S3, то Вы сильно заметите изменение в стоимости услуг.

Поглощение Logline: «иголка в стоге сена»

Grafana Labs объявила о поглощении Logline. Специализация Logline — эффективный поиск, точечные запросы типа «найди конкретный user ID или error code в петабайтах данных». Как везде пишут что это «поиск иголки в стоге сена».
Интеграция этой технологии в Loki должна значительно улучшить производительность точечного поиска при сохранении экономичной, index‑light архитектуры.
Исторически это была ахиллесова пята Loki. Инструмент намеренно избегал тяжёлых инвертированных индексов, делая ставку на дешёвое хранение и метки, что хорошо работало для широких поисков, но проигрывало при точечных запросах. В Loki 3.0 появились экспериментальные Bloom Filters как первый шаг в этом направлении. Поглощение Logline это следующий, значительно более серьёзный шаг.

Что это означает для вас в production среде

Если вы сейчас эксплуатируете Loki в распределённом режиме, основные практические последствия таковы:

Инфраструктурные зависимости. Переход на Kafka-backed ingestion означает либо наличие Kafka в стеке, либо решение о его добавлении. Это не бесплатно с точки зрения операционной сложности, зато вы получаете гарантии доставки и возможность переиграть логи при необходимости - чего в старой схеме попросту не было.

Экономика облачного хранилища. 20x сокращение сканируемых данных - прямое снижение расходов на операции чтения в объектном хранилище. Для высоконагруженных инсталляций это может кардинально изменить ежемесячный счёт.
(опять-таки, держим в голове что цифра 20x - это пока что заявленная цифра от GrafanaLabs).

Аналитика в реальном времени. Новый планировщик позволяет крутить сложные агрегаты по терабайтам логов там, где раньше приходилось ждать десятки секунд или минут. SRE-расследования после деплоя становятся значительно менее болезненными.

Точечный поиск. Если вы сейчас обходите ограничения Loki через параллельные индексы или Elasticsearch рядом с Loki - это направление теперь официально в roadmap. Когда именно технология Logline будет доступна в open source и Grafana Cloud, станет ясно позже.

Итог

«Next Wave“ для Loki — это признание того, что мир изменился. OpenTelemetry стало индустриальным стандартом инструментации. Структурированные логи стали нормой. Запросы с высокой кардинальностью — повседневностью. Старые архитектурные допущения Loki, заложенные ещё в эпоху простого текстового поиска, перестали соответствовать этим реалиям. 

Grafana Labs меняет три фундаментальных допущения разом: от репликации к Kafka, от линейного сканирования к параллельному партиционированию, от принципиального отказа от индексов к гибридному подходу.

Обновление Loki на GrafanaCON 2026 — одно из самых значительных архитектурных изменений проекта за последние годы. Посмотрим, как это будет работать в реальных production‑нагрузках: цифры на слайдах и цифры в боевой системе — далеко не всегда одно и то же. Но направление выглядит разумным и хорошо обоснованным.