Развёртывание централизованной системы логирования на VPS: Fluent Bit, OpenSearch и OpenSearch Dashboards

Что мы настраиваем и зачем

С ростом сложности современных IT-систем, количество генерируемых логов экспоненциально увеличивается. Каждый сервис, приложение, операционная система и сетевое устройство производит свои собственные журналы событий. Ручной просмотр этих логов на множестве серверов становится неэффективным, а часто и невозможным. Централизованная система логирования решает эту проблему, собирая все логи в одном месте для удобного поиска, анализа и мониторинга.

Мы будем развёртывать стек, состоящий из трёх ключевых компонентов:

• Fluent Bit: Легковесный и высокопроизводительный процессор логов, метрик и трассировок. Он будет установлен на сервере (или нескольких серверах), где генерируются логи, и будет отвечать за их сбор, фильтрацию, трансформацию и отправку в центральное хранилище. Fluent Bit известен своим низким потреблением ресурсов, что делает его идеальным для использования на VPS или в контейнеризованных средах.
• OpenSearch: Форк Elasticsearch, представляющий собой распределённую, масштабируемую поисковую и аналитическую СУБД, оптимизированную для работы с большими объёмами данных, такими как логи. OpenSearch обеспечивает быстрый индексацию и поиск, агрегацию данных и хранение исторических записей.
• OpenSearch Dashboards: Веб-интерфейс для OpenSearch, позволяющий визуализировать данные, создавать дашборды, выполнять интерактивный поиск и анализировать логи без прямого взаимодействия с API OpenSearch. Это основной инструмент для операторов и разработчиков.

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

Альтернативы: Cloud-managed vs Self-hosted

Существует два основных подхода к реализации систем логирования:

• Cloud-managed решения: Такие сервисы, как AWS CloudWatch, Google Cloud Logging, Azure Monitor, Datadog, Splunk Cloud, Logz.io и другие. Они предлагают полностью управляемые платформы, снимая с вас заботы по развёртыванию, масштабированию и обслуживанию инфраструктуры. Преимущества включают простоту использования, высокую доступность и мощные функции из коробки. Недостатки — высокая стоимость, особенно при больших объёмах логов, и потенциальная привязка к конкретному облачному провайдеру.
• Self-hosted решения на VPS/dedicated сервере: Это подход, который мы реализуем в данном руководстве. Вы самостоятельно устанавливаете и управляете всеми компонентами на собственном или арендованном сервере. Преимущества включают полный контроль над данными, значительно более низкие эксплуатационные расходы (особенно для средних и больших объёмов), возможность тонкой настройки под специфические нужды и отсутствие привязки к провайдеру. Недостатки — необходимость в технических знаниях для развёртывания и обслуживания, а также ответственность за обеспечение надёжности и масштабируемости системы.

Выбор self-hosted решения на VPS идеально подходит для владельцев VPS/dedicated серверов, стартапов, разработчиков и компаний, которые хотят сэкономить на облачных расходах, сохраняя при этом гибкость и контроль. Для объёмов логов до нескольких десятков гигабайт в день, этот подход оказывается наиболее экономически выгодным и позволяет эффективно использовать ресурсы сервера.

Какой VPS-конфиг нужен под эту задачу

Требования к VPS для централизованной системы логирования сильно зависят от объёма генерируемых логов, частоты их поступления, а также от периода хранения данных. Для начального развёртывания и средних нагрузок (до 10-20 ГБ логов в день) можно ориентироваться на следующие параметры:

Минимальные требования

• CPU: 2 ядра. OpenSearch достаточно требователен к процессору для индексации и выполнения запросов.
• RAM: 8 ГБ. OpenSearch активно использует оперативную память для кэширования индексов и буферов. Меньше 8 ГБ может привести к низкой производительности и частым сбоям.
• Диск: 100-200 ГБ SSD. SSD критически важен для производительности OpenSearch, поскольку операции ввода-вывода (чтение/запись логов) очень интенсивны. Объём диска должен быть достаточным для хранения логов за желаемый период. При 10 ГБ логов в день, 200 ГБ хватит на ~20 дней.
• Сеть: 100 Мбит/с. Для передачи логов и доступа к Dashboards.

Рекомендуемый VPS-план для начального развёртывания

Для более комфортной работы и возможности масштабирования в будущем, а также для хранения логов за больший период, рекомендуется следующий конфиг:

• CPU: 4 ядра.
• RAM: 16 ГБ.
• Диск: 500 ГБ NVMe SSD. NVMe обеспечит значительно более высокую скорость чтения/записи по сравнению с обычным SSD, что критически важно для OpenSearch.
• Сеть: 1 Гбит/с.

Для аренды VPS с такими характеристиками можно рассмотреть VPS с указанными характеристиками, предлагающие гибкие тарифы и высокую производительность.

Когда нужен dedicated, а не VPS

Dedicated сервер становится необходимым, когда объёмы логов превышают возможности одного мощного VPS, или когда требуется максимальная производительность и изоляция ресурсов. Это актуально для сценариев, где:

• Объём логов составляет сотни гигабайт или терабайты в день.
• Требуется длительное хранение логов (месяцы, годы) с быстрым доступом.
• Необходим кластер OpenSearch из нескольких узлов для обеспечения высокой доступности и распределения нагрузки.
• Важны специфические аппаратные конфигурации (например, очень быстрые NVMe RAID массивы, большое количество RAM).

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

Локация: на что влияет

Выбор локации VPS или dedicated сервера влияет на несколько факторов:

• Задержка (Latency): Чем ближе сервер к источникам логов (вашим приложениям) и к пользователям OpenSearch Dashboards, тем меньше задержка при передаче данных и работе с интерфейсом. Для критически важных систем выбирайте локации, максимально приближенные к вашим основным серверам.
• Законодательство: В разных странах действуют разные законы о хранении данных. Убедитесь, что выбранная локация соответствует требованиям конфиденциальности и регуляторам, если это применимо к вашим данным.
• Стоимость: Цены на серверы могут незначительно отличаться в разных регионах.

Оптимальным является размещение системы логирования в том же датацентре или регионе, где находятся основные сервера, генерирующие логи.

Подготовка сервера

Перед установкой основных компонентов необходимо выполнить базовую настройку безопасности и установить необходимые утилиты. Мы будем использовать Ubuntu Server 24.04 LTS как основу.

1. Подключение по SSH и создание пользователя

Подключитесь к вашему VPS как пользователь root (если это единственный доступ) и создайте нового пользователя с правами sudo. Замените youruser на желаемое имя пользователя.

ssh root@your_vps_ip # Подключение к серверу
adduser youruser # Создание нового пользователя
usermod -aG sudo youruser # Добавление пользователя в группу sudo

Выйдите из сессии root и войдите под новым пользователем:

exit # Выход из сессии root
ssh youruser@your_vps_ip # Вход под новым пользователем

2. Обновление системы

Всегда начинайте с обновления пакетной базы и установленных пакетов.

sudo apt update # Обновление списка пакетов
sudo apt upgrade -y # Обновление всех установленных пакетов
sudo apt autoremove -y # Удаление ненужных зависимостей

3. Настройка SSH-ключей (рекомендуется)

Для повышения безопасности рекомендуется использовать SSH-ключи вместо паролей. Если вы ещё не используете их, сгенерируйте пару ключей на локальной машине и скопируйте публичный ключ на VPS.

# На вашей локальной машине
ssh-keygen -t rsa -b 4096 # Генерируем SSH-ключи (если их нет)
ssh-copy-id youruser@your_vps_ip # Копируем публичный ключ на VPS

После этого отключите вход по паролю для SSH (рекомендуется, но будьте осторожны, чтобы не заблокировать себе доступ):

sudo nano /etc/ssh/sshd_config # Открываем конфигурацию SSH-сервера

Найдите и измените следующие строки:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Может потребоваться отключить, если используются другие методы аутентификации

Сохраните файл и перезапустите SSH-сервис:

sudo systemctl restart sshd # Перезапуск SSH-сервиса

4. Настройка брандмауэра (UFW)

Разрешите только необходимые порты: SSH (22), HTTP (80), HTTPS (443). Для OpenSearch Dashboards мы будем использовать HTTPS.

sudo ufw allow 22/tcp # Разрешаем SSH
sudo ufw allow 80/tcp # Разрешаем HTTP (для Caddy/Certbot)
sudo ufw allow 443/tcp # Разрешаем HTTPS (для Caddy/Dashboards)
sudo ufw enable # Включаем брандмауэр
sudo ufw status # Проверяем статус

5. Установка Fail2Ban

Fail2Ban помогает защититься от брутфорс-атак, блокируя IP-адреса, с которых происходят многочисленные неудачные попытки входа.

sudo apt install fail2ban -y # Установка Fail2Ban
sudo systemctl enable fail2ban # Включение автозапуска сервиса
sudo systemctl start fail2ban # Запуск сервиса

Создайте локальную конфигурацию для Fail2Ban, чтобы она не перезаписывалась при обновлениях:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Копирование базового конфига
sudo nano /etc/fail2ban/jail.local # Редактирование локального конфига

В файле jail.local убедитесь, что секция [sshd] активна (enabled = true) и настройте параметры по своему усмотрению (например, bantime, findtime, maxretry).

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Сохраните и перезапустите Fail2Ban:

sudo systemctl restart fail2ban # Перезапуск Fail2Ban для применения изменений

6. Установка Docker и Docker Compose

OpenSearch и OpenSearch Dashboards будут развёрнуты в Docker-контейнерах для упрощения управления и изоляции. Caddy также будет работать в Docker.

# Установка зависимостей для Docker
sudo apt install ca-certificates curl gnupg lsb-release -y

# Добавление GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавление репозитория Docker
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Установка Docker Engine
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

# Добавление текущего пользователя в группу docker для работы без sudo
sudo usermod -aG docker youruser

После добавления пользователя в группу docker, выйдите и снова войдите в систему, чтобы изменения вступили в силу:

exit
ssh youruser@your_vps_ip

Проверьте установку Docker:

docker run hello-world # Запуск тестового контейнера

Если вы видите приветственное сообщение, Docker установлен корректно.

Установка ПО — пошагово

Теперь, когда сервер подготовлен, приступим к установке Fluent Bit, OpenSearch и OpenSearch Dashboards. Мы будем использовать Docker Compose для OpenSearch/Dashboards и нативную установку Fluent Bit.

1. Подготовка каталогов для OpenSearch и Caddy

Создадим необходимые каталоги для хранения данных OpenSearch и конфигурации Caddy. Это позволит сохранять данные даже при пересоздании контейнеров.

mkdir -p ~/opensearch/data # Каталог для данных OpenSearch
mkdir -p ~/opensearch/dashboards/config # Каталог для конфигов OpenSearch Dashboards
mkdir -p ~/caddy/config # Каталог для конфигов Caddy
mkdir -p ~/caddy/data # Каталог для сертификатов Caddy

Установим правильные права доступа для каталога данных OpenSearch, так как контейнер OpenSearch запускается от непривилегированного пользователя.

sudo chown -R 1000:1000 ~/opensearch/data # Изменяем владельца на UID 1000

2. Создание файла Docker Compose для OpenSearch и OpenSearch Dashboards

Создадим файл docker-compose.yml в домашнем каталоге, который определит сервисы OpenSearch и OpenSearch Dashboards.

nano ~/docker-compose.yml

Вставьте следующее содержимое. Указанные версии (OpenSearch 2.12.0, OpenSearch Dashboards 2.12.0) актуальны на начало 2026 года и являются стабильными.

# docker-compose.yml
version: '3.8'
services:
  opensearch:
    image: opensearchproject/opensearch:2.12.0 # Актуальная версия OpenSearch на 2026 год
    container_name: opensearch
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node1
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g # Выделите половину RAM сервера, но не более 30 ГБ
      - DISABLE_SECURITY_PLUGIN=true # Отключаем плагин безопасности для простоты, для продакшена его нужно настроить
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - ~/opensearch/data:/usr/share/opensearch/data # Сохранение данных OpenSearch
    ports:
      - "9200:9200" # Порт для API OpenSearch
      - "9600:9600" # Порт для Transport Layer
    networks:
      - opensearch-net
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:9200/_cat/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:2.12.0 # Актуальная версия OpenSearch Dashboards
    container_name: opensearch-dashboards
    environment:
      - OPENSEARCH_HOSTS=["http://opensearch:9200"] # Подключение к OpenSearch
    volumes:
      - ~/opensearch/dashboards/config/opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml # Конфиг Dashboards
    ports:
      - "5601:5601" # Порт для OpenSearch Dashboards
    networks:
      - opensearch-net
    depends_on:
      opensearch:
        condition: service_healthy # Запускаем Dashboards только после OpenSearch
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:5601/api/status || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  caddy:
    image: caddy:2.7.6-alpine # Легковесная и актуальная версия Caddy на 2026 год
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80" # Для Let's Encrypt
      - "443:443" # Для HTTPS
    volumes:
      - ~/caddy/Caddyfile:/etc/caddy/Caddyfile # Конфигурация Caddy
      - ~/caddy/data:/data # Сертификаты Let's Encrypt
      - ~/caddy/config:/config # Прочие данные Caddy
    networks:
      - opensearch-net
    depends_on:
      opensearch-dashboards:
        condition: service_healthy # Caddy зависит от работоспособности Dashboards

networks:
  opensearch-net:
    driver: bridge

Важное примечание по безопасности: В данном примере мы отключили плагин безопасности OpenSearch (DISABLE_SECURITY_PLUGIN=true) для упрощения развёртывания. В продакшн-среде крайне рекомендуется включить и настроить плагин безопасности, создать пользователей и роли, а также использовать HTTPS для доступа к OpenSearch API. Для этого потребуется более сложная конфигурация.

Память для OpenSearch: Обязательно скорректируйте параметр OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g в соответствии с объёмом RAM вашего VPS. OpenSearch должен использовать около 50% доступной памяти, но не более 30-31 ГБ. Если у вас 8 ГБ RAM, установите -Xms4g -Xmx4g; если 16 ГБ, то -Xms8g -Xmx8g.

3. Создание конфигурационного файла OpenSearch Dashboards

Создайте файл opensearch_dashboards.yml в каталоге ~/opensearch/dashboards/config/:

nano ~/opensearch/dashboards/config/opensearch_dashboards.yml

Добавьте следующее содержимое:

# opensearch_dashboards.yml
server.host: "0.0.0.0"
server.name: "opensearch-dashboards"
opensearch.hosts: ["http://opensearch:9200"]
opensearch.requestHeadersWhitelist: [ "authorization", "osd-xsrf" ] # Для работы с безопасностью OpenSearch
opensearch.ssl.verificationMode: "none" # Отключаем проверку SSL между Dashboards и OpenSearch, т.к. используется HTTP

4. Создание конфигурационного файла Caddy

Создайте файл Caddyfile в каталоге ~/caddy/, заменив your_domain.com на ваш реальный домен:

nano ~/caddy/Caddyfile

Добавьте следующее содержимое:

# Caddyfile
your_domain.com { # Замените на ваш домен
  reverse_proxy opensearch-dashboards:5601 # Проксирование запросов к Dashboards
  handle_errors {
    respond "{err.status_code} {err.status_text}"
  }
  log {
    output file /var/log/caddy/access.log {
      roll_size 10mb
      roll_keep 5
    }
  }
}

Убедитесь, что ваш домен (например, your_domain.com) указывает на IP-адрес вашего VPS в DNS-записях (A-запись).

5. Запуск OpenSearch, OpenSearch Dashboards и Caddy

Перейдите в каталог, где находится docker-compose.yml, и запустите сервисы:

cd ~ # Переходим в домашний каталог
docker compose up -d # Запуск всех сервисов в фоновом режиме

Процесс запуска может занять несколько минут, особенно для OpenSearch при первой инициализации. Проверить статус контейнеров можно командой:

docker compose ps # Проверка статуса контейнеров

Убедитесь, что все контейнеры имеют статус running и их HEALTH находится в состоянии healthy.

6. Установка Fluent Bit

Fluent Bit будет установлен на том же сервере, что и OpenSearch/Dashboards, для сбора системных логов и логов Caddy. Если у вас есть другие сервера, на них также нужно будет установить Fluent Bit и настроить его на отправку логов на ваш OpenSearch сервер.

Добавим репозиторий Fluent Bit (версия 2.2.x актуальна на 2026 год, новые версии могут быть доступны):

# Добавление GPG-ключа Fluent Bit
curl https://packages.fluentbit.io/fluentbit.key | gpg --dearmor | sudo tee /usr/share/keyrings/fluentbit-keyring.gpg > /dev/null

# Добавление репозитория Fluent Bit для Ubuntu 24.04 (Noble Numbat)
echo "deb [signed-by=/usr/share/keyrings/fluentbit-keyring.gpg] https://packages.fluentbit.io/ubuntu/noble noble main" | sudo tee /etc/apt/sources.list.d/fluent-bit.list

# Обновление списка пакетов и установка Fluent Bit
sudo apt update
sudo apt install fluent-bit -y # Установка Fluent Bit версии 2.2.x

Проверим статус сервиса:

sudo systemctl status fluent-bit # Проверка статуса Fluent Bit

Сервис должен быть запущен и активен.

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

Теперь, когда все компоненты установлены, настроим Fluent Bit для сбора логов и отправки их в OpenSearch.

1. Настройка Fluent Bit

Основной конфигурационный файл Fluent Bit находится по адресу /etc/fluent-bit/fluent-bit.conf. Однако, для удобства, лучше использовать отдельные файлы для входных данных (inputs), фильтров (filters) и выходных данных (outputs).

sudo nano /etc/fluent-bit/fluent-bit.conf

Убедитесь, что в конце файла fluent-bit.conf есть строки для включения внешних конфигураций:

# fluent-bit.conf
...
@INCLUDE /etc/fluent-bit/parsers.conf
@INCLUDE /etc/fluent-bit/conf.d/.conf

sudo nano /etc/fluent-bit/conf.d/inputs.conf

# /etc/fluent-bit/conf.d/inputs.conf

[INPUT]
    Name              tail
    Tag               syslog
    Path              /var/log/syslog
    Parser            syslog
    DB                /var/log/flb_syslog.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

[INPUT]
    Name              tail
    Tag               auth.log
    Path              /var/log/auth.log
    Parser            syslog
    DB                /var/log/flb_auth.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

[INPUT]
    Name              tail
    Tag               caddy.access
    Path              /var/log/caddy/access.log # Путь к логам Caddy
    Parser            json # Логи Caddy по умолчанию в JSON
    DB                /var/log/flb_caddy.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

sudo nano /etc/fluent-bit/conf.d/output.conf

# /etc/fluent-bit/conf.d/output.conf

[OUTPUT]
    Name            opensearch
    Match           
    Host            opensearch # Имя сервиса OpenSearch в Docker Compose
    Port            9200
    Index           fluent-bit-logs-%Y.%m.%d # Индекс с датой
    Type            _doc
    Logstash_Format On
    Logstash_Prefix fluent-bit-logs
    Retry_Limit     False
    Suppress_Type_Name On # Для OpenSearch 7+

1.3. Перезапуск Fluent Bit

После изменения конфигурации Fluent Bit необходимо перезапустить сервис:

sudo systemctl restart fluent-bit # Перезапуск Fluent Bit
sudo systemctl status fluent-bit # Проверка статуса

Убедитесь, что сервис запущен без ошибок. Вы можете просмотреть логи Fluent Bit для отладки:

sudo journalctl -u fluent-bit -f # Просмотр логов Fluent Bit в реальном времени

2. Проверка работоспособности

2.1. Доступ к OpenSearch Dashboards

Откройте в браузере ваш домен (например, https://your_domain.com), который вы указали в Caddyfile. Вы должны увидеть интерфейс OpenSearch Dashboards.

2.2. Создание Index Pattern в Dashboards

После первого входа в Dashboards вам нужно будет создать "Index Pattern" для просмотра логов.

1. В левом навигационном меню перейдите в Stack Management (иконка шестерёнки).
2. Выберите Index Patterns в разделе Kibana.
3. Нажмите Create index pattern.
4. В поле Index pattern name введите fluent-bit-logs- (или другой префикс, который вы указали в fluent-bit/conf.d/output.conf). Нажмите Next step.
5. Для Time field выберите @timestamp. Нажмите Create index pattern.

curl http://localhost:9200 # Проверка доступности OpenSearch
curl http://localhost:9200/_cat/indices?v # Просмотр созданных индексов

Бэкапы и обслуживание

Система логирования накапливает критически важные данные, поэтому регулярное резервное копирование и правильное обслуживание являются обязательными.

Что бэкапить

• Данные OpenSearch: Это самое важное. Содержат все собранные логи. Рекомендуется использовать встроенные средства OpenSearch для создания снапшотов.
• Конфигурационные файлы:
  • docker-compose.yml
  • ~/opensearch/dashboards/config/opensearch_dashboards.yml
  • ~/caddy/Caddyfile
  • /etc/fluent-bit/fluent-bit.conf и /etc/fluent-bit/conf.d/.conf
• Сертификаты Caddy: Хотя Caddy автоматически их обновляет, иметь копию не помешает (~/caddy/data).

Простой скрипт автобэкапа (OpenSearch + конфиги)

Для OpenSearch рекомендуется использовать API для создания снапшотов в удалённое хранилище (например, S3-совместимое хранилище). Для конфигурационных файлов можно использовать rsync или tar.

Пример скрипта для бэкапа конфигурационных файлов:

#!/bin/bash

# Каталог для бэкапов
BACKUP_DIR="/var/backups/logging_system"
CONFIGS_DIR="$BACKUP_DIR/configs"
DATE=$(date +%Y%m%d%H%M%S)

# Создание каталогов, если их нет
mkdir -p "$CONFIGS_DIR"

echo "--- Начинаем бэкап конфигураций ($DATE) ---"

# Бэкап Docker Compose файла
cp ~/docker-compose.yml "$CONFIGS_DIR/docker-compose-$DATE.yml"
echo "docker-compose.yml забэкаплен."

# Бэкап конфига OpenSearch Dashboards
cp ~/opensearch/dashboards/config/opensearch_dashboards.yml "$CONFIGS_DIR/opensearch_dashboards-$DATE.yml"
echo "opensearch_dashboards.yml забэкаплен."

# Бэкап конфига Caddy
cp ~/caddy/Caddyfile "$CONFIGS_DIR/Caddyfile-$DATE"
echo "Caddyfile забэкаплен."

# Бэкап конфигов Fluent Bit
tar -czf "$CONFIGS_DIR/fluent-bit-configs-$DATE.tar.gz" /etc/fluent-bit
echo "Конфигурации Fluent Bit забэкаплены."

# Очистка старых бэкапов (оставляем последние 7 дней)
find "$CONFIGS_DIR" -type f -name "-$DATE.yml" -o -name "-$DATE.tar.gz" -mtime +7 -delete
echo "Старые бэкапы конфигураций удалены."

echo "--- Бэкап конфигураций завершен ---"

Сохраните этот скрипт как ~/backup_configs.sh, сделайте его исполняемым:

chmod +x ~/backup_configs.sh

И добавьте в cron для ежедневного выполнения (например, в 3:00 ночи):

crontab -e

Добавьте строку:

0 3    /home/youruser/backup_configs.sh > /dev/null 2>&1

1. Статус Fluent Bit: Убедитесь, что Fluent Bit запущен и активен: sudo systemctl status fluent-bit.
2. Логи Fluent Bit: Проверьте логи Fluent Bit на наличие ошибок отправки или парсинга: sudo journalctl -u fluent-bit -f. Ищите сообщения об ошибках подключения к OpenSearch или проблемах с файлами логов.
3. Доступность OpenSearch: С сервера, где работает Fluent Bit, попробуйте curl http://localhost:9200 (если OpenSearch на том же сервере). Убедитесь, что OpenSearch API доступен.
4. Index Pattern: Проверьте, что Index Pattern в Dashboards (fluent-bit-logs-) создан корректно и выбран правильный Time Field (@timestamp).
5. Конфиг Fluent Bit: Проверьте пути к логам в inputs.conf и правильность Host/Port в output.conf.

Как фиксить: Исправьте ошибки в конфигах Fluent Bit, перезапустите его (sudo systemctl restart fluent-bit). Убедитесь, что OpenSearch работает. Проверьте права доступа Fluent Bit к файлам логов (хотя обычно fluent-bit запускается от root или имеет необходимые права).

OpenSearch падает или работает медленно

Что проверить:

1. Память (RAM): OpenSearch очень требователен к памяти. Проверьте использование RAM на VPS: free -h. Если RAM постоянно заполнена, это проблема.
2. Логи OpenSearch: Проверьте логи контейнера OpenSearch на наличие ошибок OutOfMemoryError или проблем с диском: docker compose logs opensearch.
3. Дисковое пространство: Убедитесь, что на диске достаточно свободного места: df -h. OpenSearch требует много места для индексов.
4. Ulimits: Проверьте, что ulimits для memlock установлены правильно в docker-compose.yml.

Как фиксить: Увеличьте RAM на VPS. Увеличьте размер диска. Оптимизируйте параметр OPENSEARCH_JAVA_OPTS, выделяя больше памяти для JVM (но не более 50% от общей RAM). Настройте политику ротации индексов в OpenSearch (ILM - Index Lifecycle Management) для автоматического удаления старых логов, чтобы освободить место.

Какой VPS-конфиг минимально подойдёт?

Для минимального развёртывания, способного обрабатывать до 5-10 ГБ логов в день и хранить их в течение недели-двух, потребуется VPS с 2 ядрами CPU, 8 ГБ RAM и 100-200 ГБ SSD. Критически важно, чтобы это был SSD-диск, так как производительность ввода-вывода является узким местом для OpenSearch. Меньшие параметры приведут к нестабильной работе и частым сбоям, особенно при индексации.

Что выбрать — VPS или dedicated для этой задачи?

Для большинства индивидуальных проектов, стартапов и малого бизнеса, где объём логов не превышает 50-100 ГБ в день, мощного VPS (например, с 4-8 ядрами CPU, 16-32 ГБ RAM и 500 ГБ - 1 ТБ NVMe SSD) будет вполне достаточно. Dedicated сервер становится предпочтительным выбором, если вы планируете обрабатывать сотни гигабайт или терабайты логов ежедневно, требуете максимальной производительности, полного контроля над оборудованием, или если вам нужен кластер OpenSearch из нескольких узлов для обеспечения высокой доступности и масштабируемости.

Стоит ли включать плагин безопасности OpenSearch?

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

• Создать пользователей и роли с минимальными привилегиями.
• Настроить HTTPS для доступа к OpenSearch API.
• Использовать аутентификацию для OpenSearch Dashboards.

Это предотвратит несанкционированный доступ к вашим логам и данным.

Как ротировать логи, чтобы не заполнить диск?

Для OpenSearch используйте Index Lifecycle Management (ILM). Это встроенная функция, позволяющая автоматически управлять жизненным циклом индексов: переносить их на более медленные диски, создавать снапшоты, а затем удалять по истечении заданного срока. Настройте ILM через OpenSearch Dashboards в разделе Stack Management -> Index Management -> Index Policies. Например, можно настроить удаление индексов старше 30 дней.

Выводы и следующие шаги

Поздравляем! Вы успешно развернули полноценную централизованную систему логирования на вашем VPS, используя Fluent Bit для сбора, OpenSearch для хранения и OpenSearch Dashboards для визуализации. Теперь у вас есть мощный инструмент для мониторинга и анализа событий в вашей инфраструктуре, который позволит быстро реагировать на проблемы и принимать обоснованные решения на основе данных.

Следующие шаги для развития вашей системы:

1. Расширение источников логов: Настройте Fluent Bit на других ваших серверах, в контейнерах или приложениях для централизованного сбора всех релевантных логов.
2. Настройка безопасности OpenSearch: Включите и настройте плагин безопасности OpenSearch, создайте пользователей, роли и используйте HTTPS для защиты ваших данных.
3. Оптимизация и масштабирование: Изучите Index Lifecycle Management (ILM) для автоматической ротации и удаления старых логов. При росте объёмов рассмотрите возможность перехода на кластер OpenSearch из нескольких узлов или более мощный dedicated сервер.