От Пингов к Инсайтам: Развертывание Стека Observability (Prometheus, Loki, Grafana)
Традиционный мониторинг отвечает на вопрос «Что сломалось?». Наблюдаемость (observability) отвечает на вопрос «Почему это сломалось?». Она строится на трех столпах: метриках (числа), логах (события) и трейсах (путь запроса).
Этот гайд проведет вас по полному циклу развертывания золотого стандарта open-source для связки метрик и логов.
1️⃣ Шаг 1: Установка Prometheus и Node Exporter (Метрики)
▪️ Prometheus: Это сервер, который будет опрашивать (scrape) источники метрик. Скачайте и запустите его.
▪️ Node Exporter: Это агент, который вы ставите на каждый наблюдаемый сервер. Он собирает системные метрики (CPU, RAM, диск, сеть) и отдает их Prometheus'у.
Существуют сотни других экспортеров для баз данных, веб-серверов и оборудования, что делает Prometheus универсальной платформой.
▪️ Конфигурация prometheus.yml: Добавьте Node Exporter как цель.
YAML
После запуска проверьте метрики в веб-интерфейсе Prometheus (http://<prometheus_ip>:9090).
2️⃣ Шаг 2: Установка Loki и Promtail (Логи)
▪️ Loki: Сервер, который принимает и хранит ваши логи.
▪️ Promtail: Агент, который ставится на серверы, "читает" лог-файлы (/var/log/*.log), добавляет к ним метки (labels) и отправляет в Loki.
Ключевое отличие Loki от ELK: он не индексирует всё содержимое логов, а только метки (например, job="nginx"). Это делает его чрезвычайно экономичным и быстрым.
▪️ Конфигурация promtail-config.yml:
YAML
3️⃣ Шаг 3: Установка Grafana и Интеграция
▪️ Установите и запустите Grafana — наш будущий центр управления.
▪️ В веб-интерфейсе (http://<grafana_ip>:3000) перейдите в Connections > Data sources.
▪️ Добавьте Prometheus, указав его URL.
▪️ Добавьте Loki, указав его URL.
4️⃣ Шаг 4: Магия Корреляции Данных
Теперь самое главное. На одном экране мы видим график метрик и связанные с ним логи.
Сценарий: Пользователи жалуются на тормоза сайта.
Вы открываете дашборд в Grafana и видите пик загрузки CPU (данные из Prometheus).
Прямо под этим графиком у вас панель с логами из Loki, отфильтрованными по job="nginx" и level="error".
Вы видите, что в момент пика CPU в логах Nginx появился шквал ошибок upstream timed out.
Вывод: Проблема не в сервере, а в бэкенд-приложении. Диагностика заняла минуты, а не часы.
План действий в Grafana:
▪️ Импортируйте готовый дашборд для Node Exporter (ID: 1860).
▪️ Добавьте на него новую панель с источником данных Loki.
▪️ Используйте LogQL-запрос для фильтрации, например: {host="$hostname"} |= "error".
#Observability #Monitoring #Prometheus #Loki #Grafana #DevOps
Традиционный мониторинг отвечает на вопрос «Что сломалось?». Наблюдаемость (observability) отвечает на вопрос «Почему это сломалось?». Она строится на трех столпах: метриках (числа), логах (события) и трейсах (путь запроса).
Этот гайд проведет вас по полному циклу развертывания золотого стандарта open-source для связки метрик и логов.
1️⃣ Шаг 1: Установка Prometheus и Node Exporter (Метрики)
▪️ Prometheus: Это сервер, который будет опрашивать (scrape) источники метрик. Скачайте и запустите его.
▪️ Node Exporter: Это агент, который вы ставите на каждый наблюдаемый сервер. Он собирает системные метрики (CPU, RAM, диск, сеть) и отдает их Prometheus'у.
Существуют сотни других экспортеров для баз данных, веб-серверов и оборудования, что делает Prometheus универсальной платформой.
▪️ Конфигурация prometheus.yml: Добавьте Node Exporter как цель.
YAML
scrape_configs:
- job_name: 'node_exporter_metrics'
static_configs:
- targets: ['your_server_ip:9100']
После запуска проверьте метрики в веб-интерфейсе Prometheus (http://<prometheus_ip>:9090).
2️⃣ Шаг 2: Установка Loki и Promtail (Логи)
▪️ Loki: Сервер, который принимает и хранит ваши логи.
▪️ Promtail: Агент, который ставится на серверы, "читает" лог-файлы (/var/log/*.log), добавляет к ним метки (labels) и отправляет в Loki.
Ключевое отличие Loki от ELK: он не индексирует всё содержимое логов, а только метки (например, job="nginx"). Это делает его чрезвычайно экономичным и быстрым.
▪️ Конфигурация promtail-config.yml:
YAML
server:
http_listen_port: 9080
clients:
- url: http://<loki_ip>:3100/loki/api/v1/push
scrape_configs:
- job_name: system
static_configs:
- targets:
- localhost
labels:
job: varlogs
host: your_server_hostname
__path__: /var/log/*.log
3️⃣ Шаг 3: Установка Grafana и Интеграция
▪️ Установите и запустите Grafana — наш будущий центр управления.
▪️ В веб-интерфейсе (http://<grafana_ip>:3000) перейдите в Connections > Data sources.
▪️ Добавьте Prometheus, указав его URL.
▪️ Добавьте Loki, указав его URL.
4️⃣ Шаг 4: Магия Корреляции Данных
Теперь самое главное. На одном экране мы видим график метрик и связанные с ним логи.
Сценарий: Пользователи жалуются на тормоза сайта.
Вы открываете дашборд в Grafana и видите пик загрузки CPU (данные из Prometheus).
Прямо под этим графиком у вас панель с логами из Loki, отфильтрованными по job="nginx" и level="error".
Вы видите, что в момент пика CPU в логах Nginx появился шквал ошибок upstream timed out.
Вывод: Проблема не в сервере, а в бэкенд-приложении. Диагностика заняла минуты, а не часы.
План действий в Grafana:
▪️ Импортируйте готовый дашборд для Node Exporter (ID: 1860).
▪️ Добавьте на него новую панель с источником данных Loki.
▪️ Используйте LogQL-запрос для фильтрации, например: {host="$hostname"} |= "error".
#Observability #Monitoring #Prometheus #Loki #Grafana #DevOps
Проект на выходные: top — мертв. Строим свой SRE-мониторинг на Prometheus + Grafana
htop — это отлично. Но он показывает, что происходит сейчас. Он не скажет вам, что "каждую ночь в 3:05 CPU подскакивает до 100%".
Путь архитектора — это Observability. Вам нужны данные во времени.
Prometheus + Grafana — это "золотой стандарт" SRE и DevOps.
Prometheus: Собирает и хранит метрики (CPU, RAM, I/O, кастомные метрики) в базе данных временных рядов.
Grafana: Визуализирует эти данные в красивые, живые дашборды.
Как запустить за 5 минут (в Docker): Вам нужен docker-compose.yml:
YAML
Дальнейшие шаги:
Запустите docker-compose up -d.
Настройте Grafana (порт 3000), добавив Prometheus (порт 9090) как DataSource.
Начните собирать метрики с хостов, установив на них node_exporter (для Linux) или windows_exporter (для Windows).
Взгляд архитектора: Вы переходите от реактивного ("сервер упал") к проактивному ("мы видим, что место на диске закончится через 3 дня") мониторингу.
#linux #devops #sre #prometheus #grafana #docker #monitoring #weekendproject
htop — это отлично. Но он показывает, что происходит сейчас. Он не скажет вам, что "каждую ночь в 3:05 CPU подскакивает до 100%".
Путь архитектора — это Observability. Вам нужны данные во времени.
Prometheus + Grafana — это "золотой стандарт" SRE и DevOps.
Prometheus: Собирает и хранит метрики (CPU, RAM, I/O, кастомные метрики) в базе данных временных рядов.
Grafana: Визуализирует эти данные в красивые, живые дашборды.
Как запустить за 5 минут (в Docker): Вам нужен docker-compose.yml:
YAML
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
grafana:
image: grafana/grafana:latest
container_name: grafana
ports:
- "3000:3000"
depends_on:
- prometheus
Дальнейшие шаги:
Запустите docker-compose up -d.
Настройте Grafana (порт 3000), добавив Prometheus (порт 9090) как DataSource.
Начните собирать метрики с хостов, установив на них node_exporter (для Linux) или windows_exporter (для Windows).
Взгляд архитектора: Вы переходите от реактивного ("сервер упал") к проактивному ("мы видим, что место на диске закончится через 3 дня") мониторингу.
#linux #devops #sre #prometheus #grafana #docker #monitoring #weekendproject
🤡3🔥2🤔2❤1
🆚 Битва мониторинга: Zabbix vs Prometheus
Выбор системы мониторинга — это архитектурное решение. Нет «плохого» инструмента, есть неподходящий под задачу. Разберем, когда и что выбирать.
1. Zabbix: Классический «Комбайн»
Модель: Push & Pull. Централизованный сервер, агенты на хостах.
Сила: «Все в одном». Графики, алерты, карты сети, инвентаризация — всё из коробки. Отлично мониторит "железо", OS, стандартные сервисы.
Слабость: Тяжеловесный. Сложнее масштабировать на тысячи микросервисов. Хранит данные в SQL (MySQL/PostgreSQL), что может стать узким местом.
Вердикт: Идеален для Enterprise, статической инфраструктуры (Pet-servers), мониторинга сетевого оборудования.
2. Prometheus: Герой Cloud-Native
Модель: Pull (в основном). Сервер сам ходит к сервисам и забирает метрики (scraping).
Сила: Работает с Time Series Database (TSDB) — невероятно быстр для метрик. Создан для динамических сред (Kubernetes, Docker), где контейнеры живут минуты. Язык запросов PromQL очень гибок.
Слабость: Сам по себе «голый». Для визуализации нужен Grafana, для алертов — Alertmanager. Не хранит долгие исторические данные без доп. настройки (Thanos/VictoriaMetrics).
Вердикт: Стандарт де-факто для DevOps, микросервисов и K8s.
🏆 Итог: Строите завод или офис с принтерами и свичами? Zabbix. Поднимаете HighLoad кластер в Kubernetes? Prometheus + Grafana. Умный админ часто использует связку: Zabbix для железа, Prometheus для приложений.
#monitoring #zabbix #prometheus #devops #architecture #сравнение
Выбор системы мониторинга — это архитектурное решение. Нет «плохого» инструмента, есть неподходящий под задачу. Разберем, когда и что выбирать.
1. Zabbix: Классический «Комбайн»
Модель: Push & Pull. Централизованный сервер, агенты на хостах.
Сила: «Все в одном». Графики, алерты, карты сети, инвентаризация — всё из коробки. Отлично мониторит "железо", OS, стандартные сервисы.
Слабость: Тяжеловесный. Сложнее масштабировать на тысячи микросервисов. Хранит данные в SQL (MySQL/PostgreSQL), что может стать узким местом.
Вердикт: Идеален для Enterprise, статической инфраструктуры (Pet-servers), мониторинга сетевого оборудования.
2. Prometheus: Герой Cloud-Native
Модель: Pull (в основном). Сервер сам ходит к сервисам и забирает метрики (scraping).
Сила: Работает с Time Series Database (TSDB) — невероятно быстр для метрик. Создан для динамических сред (Kubernetes, Docker), где контейнеры живут минуты. Язык запросов PromQL очень гибок.
Слабость: Сам по себе «голый». Для визуализации нужен Grafana, для алертов — Alertmanager. Не хранит долгие исторические данные без доп. настройки (Thanos/VictoriaMetrics).
Вердикт: Стандарт де-факто для DevOps, микросервисов и K8s.
🏆 Итог: Строите завод или офис с принтерами и свичами? Zabbix. Поднимаете HighLoad кластер в Kubernetes? Prometheus + Grafana. Умный админ часто использует связку: Zabbix для железа, Prometheus для приложений.
#monitoring #zabbix #prometheus #devops #architecture #сравнение
Зачем это важно для карьеры:
Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных.
Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер.
#skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future
Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных.
Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер.
#skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future