Централизованные логи: Grafana Loki или ELK Stack
Практика3 минРедакция Innovialabs
Коротко
Loki индексирует только метки и хранит логи дёшево — подходит большинству команд с Grafana; ELK индексирует весь текст, ищет мощнее, но требует заметно больше ресурсов и внимания.
Короткий ответ
Если вам нужно просто собирать логи со всех серверов и быстро находить ошибки по сервису, окружению и времени — начните с Grafana Loki. Если нужен полнотекстовый поиск по любому слову, сложная аналитика и агрегации по полям на больших объёмах — смотрите на ELK (Elasticsearch, Logstash, Kibana) или его открытый форк OpenSearch.
Зачем логам уходить с сервера
- Сервер может умереть. Вместе с диском пропадут и логи, которые нужны для разбора аварии.
- Серверов больше одного. Искать ошибку через
sshиgrepна пяти машинах и в десяти контейнерах — долго. - Контейнеры эфемерны. После пересоздания контейнера его stdout исчезает.
- Доступ и безопасность. Разработчику не нужен root на продакшене, чтобы прочитать логи.
- Корреляция. В одном окне видно, что происходило во всех сервисах в одну и ту же секунду.
Как они устроены
ELK разбирает каждую запись и строит инвертированный индекс по содержимому. Поиск по любому слову и полю очень быстрый, но индекс занимает много места, а Elasticsearch требователен к памяти и диску.
Loki индексирует только метки (labels): app, env, host. Сам текст сжимается в чанки и лежит, например, в объектном хранилище. При запросе Loki сначала выбирает потоки по меткам, затем фильтрует текст «грубой силой».
Сравнение
| Критерий | Grafana Loki | ELK / OpenSearch |
|---|---|---|
| Что индексируется | Только метки | Весь текст и поля |
| Ресурсы | Скромные | Высокие (RAM, быстрые диски) |
| Хранилище | Объектное (S3-совместимое) или диск | Диски кластера |
| Поиск по произвольному слову | Медленнее на больших диапазонах | Быстро |
| Аналитика по полям | Базовая (LogQL) | Мощная |
| Интерфейс | Grafana | Kibana / OpenSearch Dashboards |
| Сложность эксплуатации | Ниже | Выше: шарды, реплики, ретеншн индексов |
Стоимость в обоих случаях зависит не от названия продукта, а от объёма логов в день, срока хранения и требований к скорости поиска. Чем меньше вы индексируете, тем дешевле хранение — в этом главное преимущество Loki.
Минимальная доставка логов
Универсальный сборщик — Fluent Bit: он читает файлы или логи контейнеров и умеет отправлять их и в Loki, и в Elasticsearch. Это удобно: можно начать с одного бэкенда и сменить его, не трогая приложения.
Отправка в Loki:
[INPUT]
Name tail
Path /var/log/app/*.log
Tag app
[OUTPUT]
Name loki
Match app
Host loki
Port 3100
Labels job=app, env=prod
Отправка в Elasticsearch:
[OUTPUT]
Name es
Match app
Host elasticsearch
Port 9200
Index app-logs
Suppress_Type_Name On
У Grafana есть и собственный агент — Grafana Alloy, он пришёл на смену Promtail. Для ELK классический вариант — Filebeat. Выбирайте один агент на всю инфраструктуру.
Пример запроса в Loki (LogQL): все ошибки сервиса за выбранный период.
{app="api", env="prod"} |= "error" | json | level="error"
Как не ошибиться
- Мало меток в Loki. Используйте 3–6 стабильных меток. Не делайте метками
user_idилиrequest_id— это взорвёт количество потоков. Такие значения оставляйте в теле лога. - Логи без структуры. JSON-логи гораздо проще фильтровать в обеих системах.
- Нет ретеншна. Определите срок хранения заранее, иначе диск закончится неожиданно.
- Секреты в логах. Пароли, токены и персональные данные не должны попадать в централизованное хранилище.
- Сборщик без буфера. Настройте буферизацию на диск, чтобы не терять логи при недоступности бэкенда.