Как поставить мониторинг на сервер с которого запрещены исходящие соединения

Архитектура мониторинга при блокированных исходящих соединениях

Проблематика и подходы к решению

При запрещённых исходящих соединениях с сервера стандартный push-подход (когда агенты сами отправляют метрики) становится невозможным. В этом случае необходимо использовать pull-модель с промежуточным прокси или агент с локенным буфером. Я реализовывал подобные системы в банковских и государственных учреждениях со строгими сетевыми политиками.

Основные архитектурные решения

1. Prometheus с Reverse Proxy (наиболее надёжный вариант)

В этой схеме Prometheus Server находится в сегменте, откуда разрешены входящие соединения к мониторируемому серверу. На самом сервере запускается Node Exporter или другой экспортёр, который слушает localhost или внутренний интерфейс.

# Конфигурация nginx как reverse proxy для Prometheus
server {
    listen 9090;
    server_name monitoring-proxy;
    
    location /metrics {
        proxy_pass http://target-server:9100/metrics;
        proxy_set_header Host $host;
        proxy_connect_timeout 10s;
        proxy_read_timeout 30s;
    }
    
    # Дополнительная безопасность
    allow 192.168.100.50; # IP Prometheus сервера
    deny all;
}

# Конфигурация Prometheus для сбора через прокси
scrape_configs:
  - job_name: 'isolated-server'
    static_configs:
      - targets: ['monitoring-proxy:9090']
    metrics_path: '/metrics'
    # Важные параметры для ненадёжных соединений
    scrape_interval: 1m
    scrape_timeout: 30s

2. Pushgateway с локальным буфером

Prometheus Pushgateway можно развернуть в демилитаризованной зоне (DMZ), а агенты на изолированных серверах будут отправлять метрики при помощи curl или скриптов.

#!/bin/bash
# Пример отправки метрик через cron на изолированном сервере
METRICS=$(node_exporter --collector.textfile.directory=/var/lib/node_exporter/textfile_collector)

# Сохраняем метрики во временный файл
echo "$METRICS" > /tmp/last_metrics.prom

# Пытаемся отправить при наличии подключения к шлюзу
if ping -c 1 -W 2 pushgateway.example.com &> /dev/null; then
    cat /tmp/last_metrics.prom | \
    curl -X POST --data-binary @- \
    http://pushgateway.example.com:9091/metrics/job/isolated_server/instance/$(hostname)
fi

3. Агенты с локенным хранением и синхронизацией

Использование агентов типа Telegraf или Fluentd с буферизацией на диске и периодической синхронизацией через разрешённый промежуточный хост.

# Конфигурация Telegraf (telegraf.conf)
[agent]
  interval = "60s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "5s"
  precision = ""

# Локальное хранение при недоступности выхода
[[outputs.file]]
  files = ["/var/lib/telegraf/metrics.out"]
  data_format = "influx"

# При наличии подключения - отправляем дальше
[[outputs.http]]
  url = "http://gateway.example.com:8086/write"
  data_format = "influx"
  timeout = "10s"
  [outputs.http.proxy]
    url = "http://proxy.example.com:3128"

Критически важные аспекты реализации

Безопасность соединений:

• Использование VPN или SSH туннелей для создания защищённых каналов
• Mutual TLS аутентификация между компонентами
• Регулярная ротация ключей и сертификатов

Надёжность и отказоустойчивость:

• Локальное кольцевое буферизирование метрик на диске
• Механизмы повторной отправки при восстановлении соединения
• Мониторинг заполненности буфера и своевременное оповещение

Пример SSH туннеля для доступа:

# Создание туннеля с мониторингового сервера
ssh -f -N -L 9100:localhost:9100 \
    -o ServerAliveInterval=60 \
    -o ServerAliveCountMax=3 \
    user@isolated-server.example.com

Рекомендуемый стек технологий

1. Сбор метрик: Node Exporter, custom exporters
2. Транспорт: SSH tunnels, VPN, HTTP через разрешённые прокси
3. База данных метрик: Prometheus с долгосрочным хранением в Thanos или VictoriaMetrics
4. Визуализация: Grafana с дашбордами
5. Алертинг: Alertmanager с дублированием уведомлений

Практические рекомендации из опыта

• Всегда настраивайте локальное хранение метрик минимум на 7 дней
• Реализуйте health-check механизмы для контроля состояния каналов передачи
• Используйте textfile collector для кастомных метрик через cron-задачи
• Настройте мониторинг самого мониторинга - проверяйте актуальность данных
• Регулярно проводите учения по восстановлению каналов мониторинга

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