Мониторинг логов Mikrotik: Документация

1. Введение

Цель документа

Данная документация описывает решение для централизованного сбора, хранения и визуализации логов с сетевого оборудования Mikrotik. Документ предназначен для системных администраторов и инженеров, которые хотят понять архитектуру и принципы работы стека мониторинга.

Для кого предназначено

Системные администраторы, обслуживающие сетевую инфраструктуру
IT-специалисты, внедряющие системы мониторинга
Инженеры, работающие с Mikrotik и Proxmox

Общая схема решения

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│    Mikrotik     │     │    Mikrotik     │     │    Mikrotik     │
│    Router 1     │     │    Router 2     │     │    Router N     │
└────────┬────────┘     └────────┬────────┘     └────────┬────────┘
         │                       │                       │
         │ Syslog (UDP 514)      │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│                     Ubuntu Server VM                            │
│                    (Proxmox кластер)                            │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    Docker Compose                       │    │
│  │  ┌─────────┐     ┌─────────┐     ┌─────────────────┐    │    │
│  │  │  Alloy  │────▶│  Loki   │────▶│     Grafana     │    │    │
│  │  │ :514/udp│     │ :3100   │     │     :3000       │    │    │
│  │  └─────────┘     └─────────┘     └─────────────────┘    │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘

2. Инфраструктура

2.1 Proxmox кластер

Proxmox VE (Virtual Environment) — это платформа виртуализации с открытым исходным кодом, объединяющая технологии KVM (для виртуальных машин) и LXC (для контейнеров) под единым веб-интерфейсом управления.

Принцип работы кластера

Proxmox кластер состоит из нескольких физических серверов (нод), объединённых в единую систему управления. Ключевые принципы работы:

Кворум — механизм голосования, определяющий работоспособность кластера. Для принятия решений требуется большинство голосов (50% + 1). При потере кворума кластер блокирует операции записи для защиты данных от split-brain.
Corosync — отвечает за коммуникацию между нодами, отслеживает их состояние и обеспечивает синхронизацию конфигурации кластера.
Распределённое хранилище — кластер может использовать общие хранилища (Ceph, NFS, iSCSI), что позволяет мигрировать виртуальные машины между нодами без простоя.

Роль виртуализации в данном решении

Виртуальная машина с Ubuntu Server размещена на Proxmox кластере, что обеспечивает:

Изоляцию сервиса мониторинга от других систем
Возможность быстрого восстановления из снапшота
Гибкое распределение ресурсов (CPU, RAM, диск)
Высокую доступность при использовании HA-функций Proxmox

2.2 Ubuntu Server VM

В качестве операционной системы для стека мониторинга выбрана Ubuntu Server 24.04 LTS. Основные причины выбора:

Долгосрочная поддержка (LTS) — обновления безопасности на 5 лет
Широкая совместимость с Docker и современными инструментами
Минимальное потребление ресурсов в серверной редакции
Обширная документация и сообщество

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

3. Архитектура стека

3.1 Push-модель сбора логов

Существует два основных подхода к сбору логов:

Модель	Описание	Инициатор
Push	Источник сам отправляет логи на сервер	Клиент (Mikrotik)
Pull	Сервер периодически опрашивает источники	Сервер мониторинга

Почему Mikrotik использует Push

Mikrotik RouterOS поддерживает протокол Syslog для отправки логов. Это классический Push-подход, при котором роутер самостоятельно отправляет события на указанный syslog-сервер по протоколу UDP или TCP.

Настройка на стороне Mikrotik минимальна:

/system logging action
add name=remote remote=<IP сервера> remote-port=514 target=remote

/system logging
add action=remote topics=critical,error,warning,info

Преимущества Push-модели

Простота настройки — достаточно указать IP-адрес сервера
Мгновенная доставка — события отправляются сразу при возникновении
Независимость от сервера — роутер работает автономно, даже если сервер недоступен
Низкая нагрузка на роутер — не требуется агент или дополнительное ПО

Ограничения

UDP не гарантирует доставку — логи могут теряться при сетевых проблемах
Нет подтверждения получения — отправитель не знает, дошло ли сообщение
Безопасность — syslog по умолчанию передаётся в открытом виде

3.2 Компоненты стека

Grafana Alloy

Alloy — это сборщик телеметрии от Grafana Labs, пришедший на смену Promtail и Grafana Agent. В данном решении Alloy выполняет роль syslog-сервера:

Принимает syslog-сообщения по UDP (порт 514) и TCP (порт 1514)
Парсит сообщения формата RFC3164 (BSD Syslog)
Извлекает метаданные: hostname, severity, facility, app_name
Пересылает структурированные логи в Loki

Grafana Loki

Loki — это система хранения логов, оптимизированная для работы с Grafana. Ключевые особенности:

Индексация только по меткам — в отличие от Elasticsearch, Loki не индексирует содержимое логов, что значительно снижает требования к ресурсам
Горизонтальное масштабирование — архитектура позволяет добавлять ноды по мере роста объёма данных
Совместимость с Prometheus — использует похожий язык запросов (LogQL)
Сжатие данных — эффективное хранение с настраиваемым retention

Grafana

Grafana — платформа визуализации и аналитики. Предоставляет:

Веб-интерфейс для просмотра и поиска логов
Конструктор dashboard-ов с разнообразными панелями
Систему алертинга на основе условий
Управление пользователями и правами доступа

3.3 Поток данных

Mikrotik Router
      │
      │          1. Syslog UDP/TCP (RFC3164)
      │          <134>Dec 26 15:00:00 RouterName topic: message
      ▼
┌─────────────┐
│    Alloy    │
│             │  2. Парсинг syslog:
│  - Приём    │    - Извлечение hostname
│  - Парсинг  │    - Определение severity  
│  - Relabel  │    - Извлечение app_name (topic)
└──────┬──────┘
       │
       │         3. HTTP POST /loki/api/v1/push
       │         Структурированные логи с метками
       ▼
┌─────────────┐
│    Loki     │
│             │  4. Хранение:
│  - Индекс   │    - Индексация по меткам
│  - Chunks   │    - Сжатие в chunks
│  - Retention│    - Применение retention policy
└──────┬──────┘
       │
       │         5. LogQL запросы
       │
       ▼
┌──────────────┐
│   Grafana    │ 6. Визуализация:
│              │    - Dashboard-ы
│  - Explore   │    - Панели и графики
│  - Dashboards│    - Поиск по логам
│  - Alerts    │    - Алерты
└──────────────┘

4. Docker Compose

Почему Docker

Контейнеризация через Docker выбрана по следующим причинам:

Изоляция — каждый компонент работает в своём окружении
Воспроизводимость — одинаковое поведение на любой системе
Простота обновления — смена версии сводится к изменению тега образа
Управление зависимостями — все зависимости упакованы в образ

Обзор сервисов

Стек состоит из трёх контейнеров, описанных в docker-compose.yml:

Сервис	Образ	Порты	Назначение
alloy	grafana/alloy:v1.5.1	514/udp, 1514/tcp, 12345	Приём syslog
loki	grafana/loki:3.3.2	3100	Хранение логов
grafana	grafana/grafana:11.4.0	3000	Веб-интерфейс

Сетевое взаимодействие контейнеров

                    ┌─────────────────────────────────┐
   Внешняя сеть     │      Docker Network (bridge)    │
                    │                                 │
   UDP 514 ─────────┼──▶ alloy:514                    │
   TCP 1514 ────────┼──▶ alloy:1514                   │
                    │         │                       │
                    │         │ http://loki:3100      │
                    │         ▼                       │
                    │       loki:3100                 │
                    │         ▲                       │
                    │         │ http://loki:3100      │
   HTTP 3000 ───────┼──▶ grafana:3000 ───────────────┘│
                    │                                 │
                    └─────────────────────────────────┘

Docker Compose автоматически создаёт внутреннюю сеть, в которой контейнеры обращаются друг к другу по имени сервиса (alloy, loki, grafana). Внешний доступ осуществляется только через опубликованные порты.

5. Заключение

Что получили

Развёрнутый стек обеспечивает:

Централизованный сбор логов со всех Mikrotik устройств в сети
Долгосрочное хранение с настраиваемым retention (по умолчанию 30 дней)
Удобный поиск по содержимому и фильтрация по меткам
Визуализацию через готовые dashboard-ы в Grafana
Мониторинг событий — отслеживание падений L2TP туннелей, firewall событий, ошибок авторизации

Веб-интерфейс Grafana

1. Введение​

Цель документа​

Для кого предназначено​

Общая схема решения​

2. Инфраструктура​

2.1 Proxmox кластер​

Принцип работы кластера​

Роль виртуализации в данном решении​

2.2 Ubuntu Server VM​

3. Архитектура стека​

3.1 Push-модель сбора логов​

Почему Mikrotik использует Push​

Преимущества Push-модели​

Ограничения​

3.2 Компоненты стека​

Grafana Alloy​

Grafana Loki​

Grafana​

3.3 Поток данных​

4. Docker Compose​

Почему Docker​

Обзор сервисов​

Сетевое взаимодействие контейнеров​

5. Заключение​

Что получили​