🆚 Битва мониторинга: 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 #сравнение

🧠 Skills: Усталость от алертов. Как Zabbix убивает вашу внимательность

Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).

В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.

Внедряем правило 3 вопросов для настройки любого триггера:

Это влияет на бизнес прямо сейчас?

Я должен бросить свой кофе и чинить это немедленно?

Если я проигнорирую это до завтрашнего утра, кто-то заметит?

Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.

Зачем это нужно:
Когда случится настоящий сбой (например, дропнется RAID-массив в проде), вы можете просто пропустить этот критический алерт между пятьюдесятью рядовыми сообщениями о высокой загрузке процессора на тестовом контуре. Тишина в канале мониторинга — это признак здоровой инфраструктуры и здоровой психики администратора.

#skills #monitoring #zabbix #management #sysadmin #admin_future

🧠 Skills: видит ли ваш сервер ошибки ECC-памяти? Повод проверить — из Linux 7.4 убирают старые EDAC-драйверы

Коллеги, навык про железо, о котором обычно вспоминают только после «необъяснимых» падений серверов и внезапных kernel panic.

📌 ФАКТЫ
В ветке Linux 7.4 окончательно удаляются устаревшие EDAC-драйверы для платформ: Intel 975X, X38, 3200/3210 и AppliedMicro X-Gene (Ampere eMAG)

Мейнтейнер подсистемы Borislav Petkov (AMD) объяснил причину прямо: на фоне «лихорадки сгенерированных ИИ патчей» legacy-код становится прямой угрозой стабильности — тестировать входящие правки для древнего кремния физически не на чем

EDAC (Error Detection and Correction) — ключевая подсистема ядра Linux, собирающая телеметрию контроллеров памяти об исправленных (CE) и неисправимых (UE) аппаратных сбоях RAM

🛠 ПРОВЕРКА В СИСТЕМЕ
Bash

# Проверяем, зарегистрированы ли контроллеры памяти в sysfs (пусто = ядро не видит EDAC)
ls /sys/devices/system/edac/mc/

# Быстрое чтение счётчиков ошибок по всем контроллерам:
grep -H . /sys/devices/system/edac/mc/mc*/{ce_count,ue_count} 2>/dev/null

# Современный вариант через демон RAS (Reliability, Availability, Serviceability):
apt install rasdaemon && systemctl enable --now rasdaemon
ras-mc-ctl --summary
ras-mc-ctl --errors

⚠️ КАК ИНТЕРПРЕТИРОВАТЬ ВЫВОД
Счётчик CE (Correctable Errors) стабильно растёт на конкретном канале/диме — ячейки модуля деградируют. Планка ещё жива за счёт ECC-коррекции, но модуль пора отправлять под замену по RMA

UE (Uncorrectable Errors) > 0 — случился фатальный битфлип, который алгоритм исправить не смог. Возможна тихая порча данных в памяти или падение хоста

Каталог /sys/.../edac/mc/ пуст — аппаратная коррекция на уровне BIOS/BMC может работать, но ОС о событиях «вслепую» не знает. В таком случае смотрим аппаратный SEL через IPMI:

Bash

ipmitool sel elist | grep -i -E 'memory|ecc'

💡 В ЧЁМ СУТЬ

Исправимые ошибки (CE) — это заблаговременный индикатор скорой смерти планки RAM: модуль может неделями тихо сыпать счётчиком, пока сервер не словит первый неисправимый краш посреди рабочего дня.

Заведите опрос

ce_count

или трапы

rasdaemon

в Zabbix/Prometheus — это копеечный по ресурсам мониторинг, спасающий от внезапных падений гипервизоров и СУБД.

#skills #linux #hardware #ecc #monitoring #zabbix #sysadmin #admin_future