От Пингов к Инсайтам: Развертывание Стека 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
Логи без боли: Как поднять централизованный сбор логов за 15 минут с Loki
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
version: "3"
networks:
loki:
services:
loki:
image: grafana/loki:latest
ports:
- "3100:3100"
command: -config.file=/etc/loki/local-config.yaml
networks:
- loki
promtail:
image: grafana/promtail:latest
volumes:
- /var/log:/var/log
- ./promtail-config.yml:/etc/promtail/config.yml
command: -config.file=/etc/promtail/config.yml
networks:
- loki
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
networks:
- loki
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin
Linux: tcpdump и lsof — это прошлое. Заглядываем в ядро с eBPF
Когда top, iotop и lsof бессильны, продвинутый инженер использует eBPF (extended Berkeley Packet Filter). Это технология, которая позволяет выполнять ваш код (безопасные "скрипты") прямо внутри ядра Linux, не меняя его.
Это как strace или tcpdump, но без гигантских накладных расходов и с безграничными возможностями. bpftrace — это самый простой способ начать.
Три убойных bpftrace one-liner'а, которые заменят вам 5 утилит:
Какие файлы открывает каждый процесс в системе? (в реальном времени):
Bash
Кто сейчас создаёт TCP-соединения? (мощнее netstat):
Bash
Какие execve() вызовы происходят? (мониторинг запуска процессов):
Bash
Взгляд архитектора: eBPF — это будущее Observability (наблюдаемости). Это не просто "еще один инструмент", это платформа. На ней построены такие гиганты, как Cilium (сеть в Kubernetes) и Falco (runtime-безопасность). Понимание eBPF — это прямой путь к уровню SRE и архитектора распределенных систем.
#linux #ebpf #sre #observability #devops #bpftrace #команды #architect
Когда top, iotop и lsof бессильны, продвинутый инженер использует eBPF (extended Berkeley Packet Filter). Это технология, которая позволяет выполнять ваш код (безопасные "скрипты") прямо внутри ядра Linux, не меняя его.
Это как strace или tcpdump, но без гигантских накладных расходов и с безграничными возможностями. bpftrace — это самый простой способ начать.
Три убойных bpftrace one-liner'а, которые заменят вам 5 утилит:
Какие файлы открывает каждый процесс в системе? (в реальном времени):
Bash
# (Аналог `lsof` на стероидах)
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'
Кто сейчас создаёт TCP-соединения? (мощнее netstat):
Bash
# Показываем PID, имя процесса и целевой IP/порт
sudo bpftrace -e 'tracepoint:sock:inet_sock_set_state /args->newstate == TCP_SYN_SENT/ { @[pid, comm] = count(); }'
Какие execve() вызовы происходят? (мониторинг запуска процессов):
Bash
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s\n", str(args->argv[0])); }'
Взгляд архитектора: eBPF — это будущее Observability (наблюдаемости). Это не просто "еще один инструмент", это платформа. На ней построены такие гиганты, как Cilium (сеть в Kubernetes) и Falco (runtime-безопасность). Понимание eBPF — это прямой путь к уровню SRE и архитектора распределенных систем.
#linux #ebpf #sre #observability #devops #bpftrace #команды #architect
🔬 Linux (SRE): Ваш Prometheus — "слепой". Встречаем Parca
Боль: Ваш Prometheus + Grafana показывают: "CPU spike at 14:30". И что? Вы знаете, что был всплеск, но вы не знаете, ПОЧЕМУ. Какая функция в вашем Python/Go/Rust-коде "съела" CPU?
Реакция админа: "Перезапущу pod, наверное, 'глюк'".
Реакция SRE: "Мне нужен непрерывный профилировщик".
Parca — это "Prometheus для профилирования". Он построен на eBPF и непрерывно (с почти нулевым оверхедом) сканирует CPU и память всех ваших процессов в системе.
Киллер-фича: Вы можете выбрать "спайк" CPU на Grafana, а затем "провалиться" в Parca и увидеть "Flame Graph" (огненный граф) — точную карту, показывающую, что function: process_payment() заняла 45% CPU в этот момент.
Взгляд архитектора: Вы переходите от "Мониторинга" (знать, что сломалось) к "Observability" (понимать, почему сломалось). Parca — это ваш "микроскоп", который находит "раковую опухоль" в коде, а не просто измеряет "температуру".
#linux #sre #ebpf #parca #observability #performance #architect #гайд
Боль: Ваш Prometheus + Grafana показывают: "CPU spike at 14:30". И что? Вы знаете, что был всплеск, но вы не знаете, ПОЧЕМУ. Какая функция в вашем Python/Go/Rust-коде "съела" CPU?
Реакция админа: "Перезапущу pod, наверное, 'глюк'".
Реакция SRE: "Мне нужен непрерывный профилировщик".
Parca — это "Prometheus для профилирования". Он построен на eBPF и непрерывно (с почти нулевым оверхедом) сканирует CPU и память всех ваших процессов в системе.
Киллер-фича: Вы можете выбрать "спайк" CPU на Grafana, а затем "провалиться" в Parca и увидеть "Flame Graph" (огненный граф) — точную карту, показывающую, что function: process_payment() заняла 45% CPU в этот момент.
Взгляд архитектора: Вы переходите от "Мониторинга" (знать, что сломалось) к "Observability" (понимать, почему сломалось). Parca — это ваш "микроскоп", который находит "раковую опухоль" в коде, а не просто измеряет "температуру".
#linux #sre #ebpf #parca #observability #performance #architect #гайд
🚀 Skills: Инфраструктурный нигилизм. Почему «надежность» больше не цель
Помните, как мы гордились серверами с аптаймом в 500 дней? В 2026 году такой сервер — это позор и огромная дыра в безопасности. Если ваша система не перезагружалась полтора года, значит, она не видела патчей ядра, обновлений микрокода ARM и критических фиксов библиотек.
Техническая суть:
Практика:
Ваш рабочий день должен начинаться не с проверки мониторинга «всё ли зеленое», а с проверки «пройдет ли сегодня автоматический редеплой 10% инфраструктуры».
Зачем это нужно:
Вывод: Ваша ценность как инженера — в скорости восстановления системы с нуля, а не в умении годами латать дырявое корыто.
#skills #iac #observability #resilience #devops #admin_future
Помните, как мы гордились серверами с аптаймом в 500 дней? В 2026 году такой сервер — это позор и огромная дыра в безопасности. Если ваша система не перезагружалась полтора года, значит, она не видела патчей ядра, обновлений микрокода ARM и критических фиксов библиотек.
Техническая суть:
Главный навык админа сегодня — не «поддержать жизнь», а «уметь убить и воскресить». Мы переходим от концепции надежности железа к концепции Resilience (упругости). Инфраструктура должна быть эфемерной.
Под капотом: Мы внедряем **Immutability** (неизменяемость). Конфигурация сервера не правится руками через SSH. Если нужно изменить один параметр в `sysctl`, вы меняете его в коде (IaC), пересобираете образ и пересоздаете инстанс.
Практика:
Ваш рабочий день должен начинаться не с проверки мониторинга «всё ли зеленое», а с проверки «пройдет ли сегодня автоматический редеплой 10% инфраструктуры».
# Пример декларативного описания состояния (Inspec / Goss)
# Мы проверяем не "как долго оно работает", а "соответствует ли оно стандарту 2026 года"
file:
/etc/ssh/sshd_config:
exists: true
contains:
- "Protocol 2"
- "PermitRootLogin no"
- "PubkeyAuthentication yes"
- "KexAlgorithms curve25519-sha256@libssh.org" # Квантово-устойчивые алгоритмы
command:
check_kernel_version:
exec: "uname -r"
exit-status: 0
stdout:
- "6.12" # Мы не сидим на старье
Зачем это нужно:
Это избавляет вас от «дрейфа конфигураций» (configuration drift). Когда у вас 1000 серверов, вы не можете быть уверены, что на 734-м какой-то стажер не поправил конфиг руками в три часа ночи. Только полная пересборка гарантирует идентичность и предсказуемость.
Вывод: Ваша ценность как инженера — в скорости восстановления системы с нуля, а не в умении годами латать дырявое корыто.
#skills #iac #observability #resilience #devops #admin_future
Зачем это важно для карьеры:
Разрыв между "администратором который смотрит на 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