Centralized logs, Loki и Graylog: когда нужен VPS, а когда Dedicated server

Централизованные логи часто начинают внедрять после первой серьёзной проблемы. Сайт упал, API отвечает нестабильно, сервер перегружен, клиент жалуется, а команда не может быстро понять, где причина. Логи есть на каждом сервере, но они разбросаны по разным машинам, контейнерам, приложениям и сервисам.

После этого появляется идея: собрать всё в одно место. Loki, Graylog, OpenSearch, Grafana, Promtail, Fluent Bit, syslog, Docker logs, nginx, application logs, firewall logs, auth logs. На старте кажется, что это простая задача. Поставили сервер, отправили туда логи, открыли красивый интерфейс. Но через несколько недель выясняется, что centralized logging - это не просто “ещё один сервис”. Это отдельная инфраструктурная нагрузка.

Логи постоянно пишутся, индексируются, ищутся, ротируются и хранятся. Если не считать disk, retention и CPU заранее, сервер с логами сам становится проблемой: диск забивается, поиск тормозит, ingestion отстаёт, а нужные события удаляются раньше, чем команда успевает их проверить.

Зачем вообще нужны централизованные логи

Централизованные логи нужны не для красоты. Они нужны, чтобы команда могла быстро отвечать на конкретные вопросы: что случилось, когда началось, какой сервис виноват, какие пользователи затронуты, была ли ошибка до релиза, есть ли подозрительная активность, почему выросла нагрузка.

Это особенно важно, если у проекта больше одного сервера. Например, есть backend, frontend, database, proxy, worker, billing, VPN, mail, monitoring, Docker containers и отдельные сервисы клиентов. Без централизованного сбора логов администратор вручную прыгает между машинами и теряет время.

Centralized logging полезен для:

• поиска ошибок в приложениях;
• анализа инцидентов;
• отладки API;
• контроля авторизаций и SSH-входов;
• анализа nginx/apache logs;
• аудита действий;
• поиска подозрительной активности;
• поддержки клиентов;
• проверки проблем после релиза;
• корреляции событий между несколькими серверами.

Но польза появляется только тогда, когда логи не просто собираются, а нормально хранятся, ищутся и удаляются по понятной политике.

Loki или Graylog: разный подход к логам

Loki и Graylog решают похожую задачу, но делают это по-разному. Loki часто выбирают там, где уже используется Grafana и нужен удобный поиск по логам рядом с метриками. Он хорошо подходит для Kubernetes, контейнеров, приложений и сценариев, где важно быстро смотреть логи по labels.

Graylog чаще выбирают как более классическую систему управления логами. Он удобен для syslog, сетевого оборудования, firewall, Linux/Windows-серверов, security-событий, потоков, алертов и более привычной лог-аналитики через интерфейс.

С точки зрения сервера оба варианта требуют ресурсов, но по-разному. Loki чувствителен к ingestion volume, labels, storage и retention. Graylog обычно требует ресурсов не только для самого Graylog, но и для backend-хранилища, индексации, поиска и retention-политик.

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

Почему диск становится главной проблемой

Логи почти всегда растут быстрее, чем ожидают. Один nginx access log кажется маленьким. Но если добавить application logs, database logs, auth logs, Docker logs, reverse proxy, firewall, monitoring, cron, mail и debug-вывод, объём быстро становится серьёзным.

Самая частая ошибка - включить сбор всего подряд и не настроить retention. В результате на сервер летят debug logs, успешные health checks, повторяющиеся события, шум от ботов, лишние access logs и мусорные сообщения, которые никто никогда не будет читать.

Для лог-сервера нужно заранее считать:

• сколько GB логов приходит в сутки;
• сколько дней нужно хранить данные;
• какой запас нужен на пики;
• есть ли индексы и metadata overhead;
• какой объём нужен под систему и временные файлы;
• будут ли архивы или только online search;
• что делать, когда диск заполнится.

Если проект генерирует 20 GB логов в сутки и хочет хранить их 30 дней, это уже не “немного места”. Даже без большого запаса это сотни гигабайт. Если хранить 90 или 180 дней, нужен совсем другой storage-план.

Retention: самый важный параметр

Retention - это срок хранения логов. Он отвечает на простой вопрос: сколько дней команда может искать события в интерфейсе. Без retention централизованные логи превращаются в бесконечную яму для диска.

Для большинства проектов не нужно хранить все логи в горячем поиске годами. Часто достаточно 7-14 дней для оперативной отладки, 30-90 дней для production-инцидентов и отдельного архивного хранения для compliance или редких расследований.

Graylog в своих материалах указывает, что многие клиенты хранят 30-90 дней online searchable logs и более долгий срок в архивах. Это правильная логика: горячее хранение должно быть быстрым и дорогим, архивное - более дешёвым и не обязательно мгновенно searchable. [oai_citation:1‡go2docs.graylog.org](https://go2docs.graylog.org/1380099/planning_your_deployment/planning_your_log_collection.htm?TocPath=Planning+Your+Deployment%7C_____1&utm_source=chatgpt.com)

Для Loki retention нужно включать и настраивать осознанно. В официальной документации Grafana указано, что retention в Loki выполняется через Compactor, а если соответствующий флаг не включён, логи могут жить бессрочно. Это важный момент: нельзя просто поставить Loki и надеяться, что старые данные сами аккуратно удалятся. [oai_citation:2‡Grafana Labs](https://grafana.com/docs/loki/latest/operations/storage/retention/?utm_source=chatgpt.com)

CPU: когда логи начинают грузить процессор

CPU нужен не только для интерфейса. Он участвует в приёме логов, парсинге, обработке pipelines, сжатии, индексации, поиске, алертах и dashboard-запросах. Чем больше источников и сложнее обработка, тем выше нагрузка.

CPU становится важным, если:

• много логов приходит одновременно;
• используются сложные parsing rules;
• много regex-обработки;
• часто выполняются тяжёлые поисковые запросы;
• много пользователей смотрит dashboards;
• есть alerts по логам;
• идёт активная индексация;
• используются pipeline rules, extractors или enrichment.

Но покупать самый мощный CPU без расчёта тоже не нужно. Часто bottleneck находится не в CPU, а в диске, retention, количестве индексов, неправильных labels или слишком шумных логах.

Когда достаточно VPS

VPS подходит для небольшого centralized logging. Например, если нужно собрать логи с нескольких серверов, хранить их 7-14 дней, быстро смотреть ошибки и не строить тяжёлую security-аналитику.

VPS может быть нормальным выбором, если:

• источников логов немного;
• ingestion небольшой и предсказуемый;
• retention короткий;
• поиск выполняется редко;
• нет большого количества dashboard-запросов;
• логи уже фильтруются на стороне агентов;
• нет требований к долгому online-хранению;
• команда использует logging как инструмент отладки, а не как compliance-систему.

Например, для малого проекта можно начать с VPS на SSD/NVMe, 2-4 vCPU, 4-8 GB RAM и диском под фактический retention. Но даже в таком варианте нужно настроить очистку старых данных. Иначе через месяц сервер станет аварийной задачей.

Когда нужен Dedicated server

Dedicated server нужен, когда logging становится постоянной тяжёлой нагрузкой. Это особенно актуально для хостинг-провайдеров, SaaS, VPN-сервисов, e-commerce, API-платформ, security-monitoring, инфраструктуры с большим количеством серверов и проектов с высоким трафиком.

Dedicated стоит рассматривать, если:

• логи идут с десятков серверов или контейнеров;
• ingestion измеряется десятками или сотнями GB в сутки;
• нужно хранить 30-90 дней online;
• поиск по логам используется каждый день;
• логи нужны для расследования инцидентов;
• VPS регулярно упирается в disk I/O;
• сервер логов сам создаёт latency;
• нужен большой локальный storage;
• важна изоляция от соседей по I/O;
• нужен запас CPU под parsing, search и alerts.

Главное преимущество dedicated - предсказуемый disk I/O. Логи - это постоянная запись. Если storage общий и рядом кто-то делает тяжёлую запись, поиск и ingestion могут проседать. На выделенном сервере диск и ресурсы принадлежат только вашему logging stack.

Почему стабильный disk I/O важнее, чем кажется

Централизованные логи постоянно пишутся. Даже если никто не открывает интерфейс, агенты продолжают отправлять события. Когда администратор запускает поиск по большому периоду, storage получает дополнительную нагрузку. Когда retention удаляет старые данные, это тоже работа с диском.

Плохой storage проявляется так:

• логи приходят с задержкой;
• поиск выполняется слишком долго;
• интерфейс Graylog или Grafana тормозит;
• появляются очереди ingestion;
• retention-операции мешают текущей записи;
• сервер показывает высокий iowait;
• после пика нагрузки часть логов теряется или приходит поздно.

Для production-логов лучше использовать SSD/NVMe и не заполнять диск под 95-100%. Лог-серверу нужен свободный запас, иначе при пике он может остановиться именно тогда, когда логи больше всего нужны.

Что отправлять в centralized logs, а что отрезать

Самый дешёвый storage - тот, который не пришлось использовать. Перед тем как покупать большой сервер, нужно убрать мусорные логи.

Обычно стоит фильтровать:

• успешные health checks;
• повторяющиеся debug-события;
• слишком подробные access logs без пользы;
• шум от ботов;
• тестовые сообщения;
• однотипные low-value события;
• логи, которые уже есть в другом источнике;
• чувствительные данные, которые нельзя хранить в логах.

Логи должны помогать расследовать проблему, а не создавать видимость контроля. Если команда собирает всё подряд, она платит за диск, CPU и сложность, но не обязательно получает больше пользы.

Loki: на что обратить внимание

Loki часто выбирают за связку с Grafana и удобство работы с labels. Но labels нужно проектировать аккуратно. Если использовать слишком много высококардинальных labels, например user_id, request_id или уникальные значения, Loki может начать работать хуже и требовать больше ресурсов.

Для Loki важно заранее определить:

• источники логов;
• labels и их кардинальность;
• объём ingestion;
• retention через Compactor;
• storage backend;
• запас CPU/RAM;
• будет ли single-node или distributed mode;
• какие запросы реально будут использоваться.

Grafana в документации по sizing Loki прямо указывает, что базовый расчёт ресурсов зависит от expected ingestion volume. Это правильная отправная точка: сначала считаем поток логов, потом выбираем сервер. [oai_citation:3‡Grafana Labs](https://grafana.com/docs/loki/latest/setup/size/?utm_source=chatgpt.com)

Graylog: на что обратить внимание

Graylog удобен, когда нужно управлять потоками логов, алертами, search-интерфейсом, extractors, pipelines и retention-политиками. Но он требует внимательного отношения к storage и индексам.

Для Graylog нужно заранее определить:

• сколько данных приходит в сутки;
• сколько дней хранить online;
• какая rotation/retention strategy используется;
• какой backend используется для индексов;
• сколько CPU нужно под parsing и search;
• какие streams нужны;
• какие логи должны храниться дольше;
• нужен ли archive tier.

Graylog предлагает управлять index sets, rotation и retention через настройки индексов. В текущей документации также описывается Data Tiering как рекомендуемый вариант для index set configuration. [oai_citation:4‡go2docs.graylog.org](https://go2docs.graylog.org/current/setting_up_graylog/index_model.html?utm_source=chatgpt.com)

Как считать storage под логи

Простой расчёт выглядит так: daily ingest умножается на количество дней retention и добавляется запас. Например, если проект собирает 10 GB логов в сутки и хочет хранить их 30 дней online, базовый объём уже около 300 GB до учёта overhead, индексов, пиков и системного запаса.

Graylog даёт практическую оценку storage через daily ingest × total retention days × 120%. В старой документации также встречается правило daily ingestion × retention days × 1.3 для учёта metadata overhead. В реальном проекте лучше закладывать запас, потому что пики и ошибки конфигурации появляются регулярно. [oai_citation:5‡go2docs.graylog.org](https://go2docs.graylog.org/current/planning_your_deployment/graylog_system_architecture.htm?utm_source=chatgpt.com)

Пример:

• 5 GB/day × 30 дней × 1.2 = 180 GB;
• 20 GB/day × 60 дней × 1.2 = 1.44 TB;
• 100 GB/day × 30 дней × 1.2 = 3.6 TB.

Это только грубая оценка. Фактический объём зависит от формата логов, сжатия, индексов, количества metadata, replicas, retention-политик и того, насколько хорошо вы фильтруете шум.

Snapshots и backups для лог-сервера

Не все логи нужно бэкапить. Иногда centralized logs - это operational data, которые можно потерять без катастрофы. Но если логи нужны для аудита, безопасности, расследований, клиентов или compliance, backup становится обязательным.

Нужно разделять три вещи:

• retention - сколько дней логи доступны в поиске;
• archive - где логи лежат долго и дешевле;
• backup - как восстановить саму систему после сбоя.

Для Graylog/Loki важно бэкапить конфигурации, dashboards, rules, pipelines, alert settings, agent configs и документацию. Данные логов бэкапятся только если они действительно нужны после аварии. Иначе можно потратить огромные деньги на резервное копирование мусора.

Какая конфигурация нужна

Для небольшого Loki или Graylog можно начать с VPS на SSD/NVMe, 2-4 vCPU, 4-8 GB RAM и диском, рассчитанным по daily ingest и retention. Это подходит для нескольких серверов, короткого хранения и умеренного поиска.

Для production logging лучше смотреть на 4-8 vCPU, 16-32 GB RAM и быстрый SSD/NVMe с запасом места. Если ingestion высокий, retention 30-90 дней, много источников и поиск используется каждый день, dedicated server будет более надёжным вариантом.

Для тяжёлых сценариев с десятками серверов, большим количеством контейнеров, security logs, VPN/firewall logs, API logs и долгим online retention стоит планировать dedicated server или отдельный кластер. Один маленький VPS здесь будет не экономией, а будущей аварией.

Что спросить у провайдера до заказа

Перед заказом VPS или dedicated server под centralized logs стоит уточнить не только цену, но и параметры storage.

• какой тип диска используется - SSD или NVMe;
• есть ли ограничение по disk I/O;
• можно ли увеличить диск без миграции;
• какой included traffic;
• есть ли private network для сбора логов;
• можно ли подключить отдельный backup/storage server;
• есть ли snapshots;
• какая политика по sustained write load;
• можно ли перейти с VPS на dedicated;
• какая локация лучше для ваших серверов;
• есть ли мониторинг диска и алерты.

Для логов особенно важно понимать disk I/O. Дешёвый сервер с большим, но медленным диском может оказаться хуже, чем меньший NVMe с правильно настроенным retention.

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

Первая ошибка - собирать всё подряд. Вторая - не настраивать retention. Третья - держать debug logs в production месяцами. Четвёртая - хранить чувствительные данные в логах. Пятая - выбирать сервер по объёму диска, не учитывая CPU, I/O и поиск.

Ещё одна частая ошибка - ставить Loki или Graylog, но не мониторить сам logging stack. Если система логов падает, команда узнаёт об этом только тогда, когда ей срочно нужны данные по инциденту.

Logging stack тоже должен мониториться: ingestion rate, disk usage, CPU, RAM, queue size, query latency, retention jobs, errors, dropped logs и свободное место.

Главный вывод

Centralized logs на Loki или Graylog дают команде контроль над инфраструктурой, но сами требуют грамотной инфраструктуры. Главные параметры - disk, retention и CPU. Без расчёта daily ingest и срока хранения сервер логов быстро превращается в источник проблем.

Для небольшого проекта достаточно VPS с SSD/NVMe и коротким retention. Для production, большого количества серверов, long retention, security logs и активного поиска лучше выбирать dedicated server с быстрым диском, запасом CPU и понятной политикой хранения.

QCKL помогает подобрать VPS или dedicated server под Loki, Graylog, централизованный сбор логов, syslog, Docker logs, application logs и инфраструктурный monitoring. Можно начать с VPS для небольшой команды, а при росте перейти на dedicated server с большим storage, стабильным I/O и отдельным backup/archive-планом.

Запросить подбор конфигурации можно на qckl.net.