Thanos и Loki на отечественном S3: что получили после переезда у нескольких клиентов

В начале этого года мы наблюдали за несколькими клиентами, у которых метрики Prometheus хранились либо в зарубежном S3, либо вообще локально с retention в две недели. Первое стало неудобным по понятным причинам, второе - неудобным по причинам ещё более понятным: когда нужно разобраться в инциденте трёхнедельной давности, а данных нет, объяснять это заказчику неловко.

К декабрю мы переехали на отечественный S3 у четырёх клиентов - Thanos для метрик, Loki для логов. Пора зафиксировать, что получилось.

Почему именно Thanos, а не Mimir или Cortex

Вопрос регулярно задают. Ответ простой: Thanos у нас уже стоял у большинства клиентов как sidecar к Prometheus. Переезд на Mimir означал бы смену архитектуры, а не просто смену бэкенда хранения. Mimir объективно интереснее для multi-tenant-сценариев с большими объёмами, но у наших клиентов это не тот масштаб, где разница принципиальна. Thanos + object storage - понятная, эксплуатируемая нами уже не первый год схема.

Loki для логов появился как логичное продолжение: уже использовали Grafana-стек, и хранить логи в том же объектном хранилище рядом с метриками удобно с точки зрения единой политики retention и единого места оплаты.

Что с совместимостью S3 API

Это оказалось самой интересной частью. Отечественные провайдеры декларируют совместимость с AWS S3 API - и в целом это правда. Только всплыло несколько расхождений, которые проявились именно в контексте Thanos и Loki.

Thanos Store Gateway при первом запуске делает интенсивную работу с бакетом: листает все TSDB-блоки, читает meta.json, строит индекс. На одном из провайдеров мы поймали throttling на LIST-запросах при переносе большого количества исторических блоков. Thanos не особо обрабатывает 503 Slow Down от S3 - просто падает с ошибкой. Пришлось сделать поэтапный перенос блоков и добавить retry-логику через настройки objstore.bucket с увеличенными таймаутами. После этого работает нормально.

Loki оказался чуть нежнее в части multipart uploads. Loki при записи chunks использует multipart upload с довольно мелкими частями по умолчанию. У одного из провайдеров обнаружилась проблема: multipart uploads с частями меньше 5 МБ возвращали ошибку - это стандартное ограничение S3, но Loki с настройками по умолчанию периодически его нарушал при небольших объёмах записи. Фикс простой - chunk_target_size и max_chunk_age в конфиге Loki, но без понимания причины это ловится не сразу.

Presigned URLs - Thanos использует их для некоторых операций, и здесь у двух провайдеров из четырёх обнаружилось расхождение с AWS в части обработки заголовков. В итоге одному из них пришлось отключить presigned-операции и перейти на прямые запросы через service account - что немного медленнее, но работает.

Главный вывод по совместимости: API совместим примерно на 95%, и именно оставшиеся 5% требуют времени на отладку. Для Veeam, о котором мы писали раньше при тестировании иммутабельных бэкапов, картина похожая.

Производительность: что замерили

Делать вид, что у нас идеально контролируемый стенд, не будем - у каждого клиента своя нагрузка и своё железо. Но несколько наблюдений, которые повторяются.

• Compaction в Thanos. Thanos Compactor читает блоки из объектного хранилища, сжимает, пишет обратно. Это I/O-интенсивная операция, и скорость напрямую зависит от пропускной способности до S3. У двух клиентов compaction занимал существенно больше времени, чем на зарубежном S3 - примерно в полтора раза. Это не критично, если compaction запускается по расписанию в off-peak, но надо учитывать.

• Store Gateway query latency. Запросы к историческим данным через Store Gateway показали latency, сопоставимую с тем, что было на зарубежном S3. Это хорошая новость - именно на запросах нагрузка пользователя ощущается напрямую. Здесь провайдеры не разочаровали.

• Loki LogQL на больших интервалах. При запросах с большим временным диапазоном (несколько недель) и сложным фильтром Loki интенсивно читает chunks из S3. Здесь ощущается задержка относительно того, что было при хранении логов на локальных дисках. Это ожидаемо - зато retention теперь не ограничен размером диска.

Стоимость: что реально вышло

Здесь расчёт неочевидный. Стоимость гигабайта хранения у отечественных провайдеров сейчас заметно ниже, чем был зарубежный S3 по курсу. Но нужно считать полную картину.

Thanos и Loki генерируют транзакции. Много транзакций - LIST при индексировании, GET при запросах, PUT при записи, HEAD при проверках. На провайдерах, где транзакции тарифицируются отдельно, месячный счёт за транзакции оказался сопоставим со счётом за хранение. У одного клиента после первого месяца работы транзакционные расходы составили около 40% от общей суммы - мы этого не ожидали и теперь закладываем в расчёты заранее.

Если провайдер не тарифицирует LIST и HEAD - это реальная экономия именно для observability-стека, потому что Thanos Store Gateway делает очень много LIST-запросов.

Где сейчас

Все четыре клиента работают на отечественном S3 уже несколько месяцев. Критических проблем нет - все описанные выше нюансы обнаружены и закрыты в процессе внедрения. Managed-сопровождение наблюдает, как системы ведут себя под реальной нагрузкой.

Честный итог: отечественный S3 как long-term storage для Thanos и Loki - рабочий вариант, не экзотика. Нюансы совместимости API реальны, но решаемы при аккуратном внедрении. Стоимость хранения в пересчёте на рубли выгоднее зарубежных аналогов, но считать нужно с транзакциями, а не только гигабайты.

Что остаётся открытым вопросом - поведение провайдеров под экстремальной нагрузкой и долгосрочная надёжность хранения. Несколько месяцев эксплуатации - это не «проверено годами», и мы отдаём себе в этом отчёт.