Ответ
В DevOps-практике используются несколько основных моделей сбора данных, которые я применял в зависимости от задачи.
1. Pull-модель (Опрос) Сервер мониторинга сам запрашивает метрики с целевых систем. Классический пример — Prometheus.
- Как работает: Prometheus периодически отправляет HTTP-запрос (
scrape) на известные ему эндпоинты (targets), которые предоставляют метрики в текстовом формате. - Пример цели в
prometheus.yml:scrape_configs: - job_name: 'kubernetes-nodes' kubernetes_sd_configs: - role: node relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - Плюсы: Централизованное управление, проще контролировать нагрузку и безопасность.
2. Push-модель (Отправка) Агент на целевом сервере самостоятельно отправляет данные на сервер мониторинга. Примеры: StatsD, InfluxDB Telegraf, отправка логов.
- Как работает: Агент (например,
node_exporterв режиме pushgateway для batch-задач или Telegraf) собирает метрики и отправляет их по протоколу TCP/UDP/HTTP. - Пример отправки метрики в StatsD:
echo "app.login.count:1|c" | nc -u -w1 statsd-server 8125 - Плюсы: Подходит для кратковременных задач (jobs) или когда цели находятся за NAT/firewall.
3. Сбор логов (Log Shipping) Для логов используется модель push. Агент (Filebeat, Fluentd/Fluent Bit) следит за лог-файлами или журналами stdout контейнеров и пересылает их в центральное хранилище (Elasticsearch, Loki).
4. Экспортеры (Exporters)
Это специальные приложения, которые преобразуют метрики из внутреннего формата (например, MySQL статусы) в формат, понятный Prometheus. Я устанавливал mysql_exporter, nginx-prometheus-exporter и другие рядом с целевым приложением.
На практике в Kubernetes-кластере я использовал комбинацию: Prometheus (pull) для метрик, Fluent Bit (push) для логов и kube-state-metrics как экспортер состояния Kubernetes-объектов.