Предсказание отказов HDD/SSD: как мониторить диски и избегать аварий

Жесткие диски и SSD рано или поздно выходят из строя, но их отказ редко бывает внезапным. 

Зная, какие параметры мониторить, можно заранее выявить проблемы и заменить диск за недели до его полной поломки. В этом разберемся сегодня.

Какие параметры критичны?

Самый простой способ оценить состояние диска — анализ S.M.A.R.T.-атрибутов. Вот ключевые показатели, на которые стоит обратить внимание:

⏺Reallocated Sectors Count – количество переназначенных секторов. Рост этого значения — первый тревожный сигнал.
⏺Pending Sectors – секторы, ожидающие перераспределения. Если диск не может их исправить, он может скоро выйти из строя.
⏺Uncorrectable Sectors – необратимо поврежденные сектора, которые диск не может ни исправить, ни перенести.
⏺CRC Errors – ошибки интерфейса SATA/NVMe, указывают на проблемы с кабелем или контроллером.
⏺Power-On Hours – возраст диска. HDD редко живут больше 5-7 лет, SSD – до 3-5 лет при высокой нагрузке.
⏺SSD Wear Leveling Count – степень износа ячеек памяти у SSD. Если значение приближается к 100%, диск скоро выйдет из строя.

Эти параметры можно отслеживать вручную, но лучше автоматизировать процесс.

Мониторинг S.M.A.R.T. в Linux

Чтобы проверить диск вручную, можно использовать smartmontools:

smartctl -a /dev/sda

Но вручную это делать неудобно, поэтому подключаем мониторинг в Zabbix и Prometheus.

Автоматический мониторинг дисков в Zabbix

В Zabbix есть готовые шаблоны для S.M.A.R.T. Чтобы подключить мониторинг:
1️⃣Устанавливаем Zabbix Agent (если он еще не установлен):

sudo apt install zabbix-agent

Для CentOS/RHEL:

sudo yum install zabbix-agent

2️⃣ Добавляем модуль для работы с S.M.A.R.T.

sudo apt install smartmontools

3️⃣ Настраиваем Zabbix Agent для сбора данных о дисках. Добавляем в /etc/zabbix/zabbix_agentd.conf:

UserParameter=smartctl.discovery, sudo /usr/local/bin/smartctl_discovery.sh
UserParameter=smartctl.info[*], sudo smartctl -A /dev/$1 | grep "$2" | awk '{print $10}'

4️⃣ Перезапускаем агент:

sudo systemctl restart zabbix-agent

5️⃣ Импортируем шаблон “SMART Monitoring” в Zabbix и привязываем к хосту.

Теперь Zabbix будет автоматически отслеживать состояние дисков и присылать алерты при критических изменениях.

В следующем посте продолжим!

Релиз открытой утилиты GNU patch 2.8

В конце марта 2025 года состоялся релиз открытой утилиты GNU Patch 2.8. 

Решение позволяет применить к файлам патчи, включающие списки изменений, созданные программой diff. Исходный код проекта написан на языке C и распространяется под лицензией GPLv3+. Версия GNU patch 2.7 вышла в сентябре 2012 года.

В новую версию проекта вносили изменения одиннадцать разработчиков в ходе подготовки релиза.

По информации OpenNET, основные изменения и доработки в GNU patch 2.8:

⏺решена проблема 2038 года — утилита теперь корректно обрабатывает данные о времени файлов, созданных после 2038 года, даже на платформах с 32-разрядным типом time_t;
⏺опция «‑follow‑symlinks» теперь распространяется не только на входные файлы, но и на создаваемые файлы;
⏺в соответствии с требованиями стандарта POSIX.1–2024 запрещено использование символа перевода строки в именах файлов;
⏺запрещено использование нулевых байтов ('\0') в строках с директивами diff;
⏺разрешено указание пробелов и табуляций перед значениями с номерами строк и после них;
⏺проведена работа по исключению неопределённого или некорректного поведения в нештатных ситуациях, например при обработке очень больших размеров полей, ошибках ввода/вывода, нехватке памяти, состояниях гонки и отправке сигналов в неподходящие моменты;
⏺удалён старый код «Plan B», созданный для систем с 16-разрядными указателями;
⏺повышены требования к компилятору, который теперь должен поддерживать стандарт C99 (ранее требовался C89);
⏺добавлена поддержка новых версий GCC, Autoconf и Gnulib.

Предсказание отказов HDD/SSD: как мониторить диски и избегать аварий
Часть 2

Продолжим обсуждение мониторинга жестких дисков

Мониторинг дисков в Prometheus + Grafana

Если в инфраструктуре уже есть Prometheus, можно использовать node_exporter с поддержкой S.M.A.R.T.:

1️⃣Устанавливаем node_exporter:

wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-linux-amd64.tar.gz
tar xvf node_exporter-linux-amd64.tar.gz
cd node_exporter-linux-amd64
sudo ./node_exporter --collector.smartmon

2️⃣ Добавляем в конфиг Prometheus новый таргет (prometheus.yml):

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

3️⃣ Настраиваем Grafana для визуализации
В Grafana импортируем готовый Dashboard 12430 “SMART Monitoring”.

Теперь мы видим наглядную динамику параметров S.M.A.R.T. и можем заранее предсказать сбои.

Использование AI для предсказания отказов

Если нужно автоматически анализировать аномалии, можно использовать AI-модель для предсказания отказов.
1. Собираем данные за 6-12 месяцев с проблемных и рабочих дисков.
2. Обучаем ML-модель на основе реальных данных.
3. Настраиваем прогнозирование аномалий через TensorFlow/Scikit-Learn и уведомления в Telegram/Slack.

Пример простого скрипта на Python, который анализирует S.M.A.R.T. и ищет аномалии:

import pandas as pd  
from sklearn.ensemble import IsolationForest  

# Загружаем данные S.M.A.R.T.
df = pd.read_csv("smart_data.csv")

# Выбираем критичные параметры
features = ["Reallocated_Sectors", "Pending_Sectors", "Uncorrectable_Sectors"]

# Обучаем модель аномалий
model = IsolationForest(contamination=0.01)
model.fit(df[features])

# Предсказываем аномалии
df["anomaly"] = model.predict(df[features])

# Выводим проблемные диски
print(df[df["anomaly"] == -1])

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм FUSE в Linux и зачем он нужен?

✅Ответ: FUSE (Filesystem in Userspace) — это интерфейс, позволяющий создавать файловые системы в пространстве пользователя без необходимости писать код в ядре. Он применяется для реализации виртуальных файловых систем, шифрования, работы с удаленными хранилищами.

Основные возможности:
— Изоляция: FUSE работает в user-space, снижая риски сбоев и уязвимостей в ядре.
— Гибкость: можно монтировать файлы из облака, архивов или даже из базы данных.
— Применение: SSHFS (удаленная файловая система через SSH), EncFS (шифрованные каталоги), rclone (доступ к облачным хранилищам).

Policy-Based Routing (PBR) в Linux: Как разделять трафик по приложениям и протоколам

Обычно маршрутизация в Linux строится по таблице маршрутов, но что если нужно разделять трафик не просто по IP-адресу, а по приложению, порту или протоколу?

Здесь на помощь приходит Policy-Based Routing (PBR) – механизм, позволяющий задавать гибкие правила маршрутизации.

Когда это нужно?
⏺Выводить разный трафик через разные каналы – например, HTTP/S через VPN, а SSH и RDP напрямую.
⏺Разграничивать нагрузку между несколькими провайдерами – балансировка трафика между двумя интернет-каналами.
⏺Ограничивать взаимодействие сервисов – запрет доступа контейнеров в интернет, но разрешение выхода в локальную сеть.

Настройка PBR в Linux

Создаём дополнительные таблицы маршрутов

По умолчанию в Linux есть таблица main, но для PBR нам нужны дополнительные. Добавим их в /etc/iproute2/rt_tables:

echo "100 vpn_table" >> /etc/iproute2/rt_tables
echo "200 direct_table" >> /etc/iproute2/rt_tables

Добавляем маршруты в новые таблицы

Предположим, что у нас два выхода:
• eth0 – основной интернет,
• tun0 – VPN-интерфейс.

Добавим маршруты:

ip route add default via 192.168.1.1 dev eth0 table direct_table
ip route add default via 10.8.0.1 dev tun0 table vpn_table

Создаём правила для выбора таблицы

Теперь направим трафик определённых приложений в нужные таблицы.

Например, весь трафик от процесса firefox через VPN:

iptables -t mangle -A OUTPUT -m owner --uid-owner firefox -j MARK --set-mark 1
ip rule add fwmark 1 table vpn_table

Или весь SSH-трафик (порт 22) напрямую:

iptables -t mangle -A OUTPUT -p tcp --dport 22 -j MARK --set-mark 2
ip rule add fwmark 2 table direct_table

Проверяем настройки

Убедимся, что правила работают:

ip rule show
ip route show table vpn_table
ip route show table direct_table

Вот кто смог😎

Тонкая настройка TCP-стека в Linux: уменьшаем RTT и ускоряем соединения

Linux по умолчанию настроен на универсальный сценарий работы с сетью, но если вам нужна максимальная скорость соединений и минимальная задержка (RTT), стоит детальнее поработать с параметрами TCP-стека через sysctl.

Что влияет на скорость TCP:
1️⃣Размер буферов – слишком маленькие буферы ограничивают скорость, а слишком большие приводят к задержкам.
2️⃣ Алгоритмы контроля перегрузок – некоторые из них более агрессивны и подходят для быстрой сети.
3️⃣ Обработка ACK – частота отправки подтверждений влияет на задержку.
4️⃣ Настройка SYN и TIME_WAIT – влияет на скорость установки и закрытия соединений.

Оптимизация через sysctl

Увеличиваем размеры буферов

sysctl -w net.core.rmem_max=67108864  # Макс. размер буфера приёма  
sysctl -w net.core.wmem_max=67108864  # Макс. размер буфера отправки  
sysctl -w net.ipv4.tcp_rmem="4096 87380 33554432"  # Буферы TCP для чтения  
sysctl -w net.ipv4.tcp_wmem="4096 65536 33554432"  # Буферы TCP для записи  

Это позволяет использовать больше памяти для TCP-соединений, снижая потери пакетов при высоких скоростях.

Отключаем медленные алгоритмы управления перегрузками

sysctl -w net.ipv4.tcp_congestion_control=bbr

BBR (Bottleneck Bandwidth and RTT) — алгоритм, который ускоряет TCP-соединения и минимизирует RTT, особенно в нестабильных сетях.

Оптимизируем обработку ACK

sysctl -w net.ipv4.tcp_delack_min=10  # Минимальная задержка перед ACK (в мс)  
sysctl -w net.ipv4.tcp_adv_win_scale=2  # Улучшение работы с окнами  

Это уменьшает задержки на медленных соединениях, но нужно тестировать для вашей сети.

Ускоряем установку соединений

sysctl -w net.ipv4.tcp_syncookies=1  # Включаем защиту от SYN-флуда  
sysctl -w net.ipv4.tcp_syn_retries=2  # Уменьшаем число повторных SYN-запросов  
sysctl -w net.ipv4.tcp_fin_timeout=10  # Быстро закрываем неактивные соединения  

Применение изменений

Чтобы сохранить настройки, добавьте их в /etc/sysctl.conf и примените командой:

sysctl -p

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает eBPF в Linux и зачем он нужен?

✅Ответ: eBPF (Extended Berkeley Packet Filter) — это механизм в ядре Linux, позволяющий безопасно выполнять код в пространстве ядра без изменения его исходников. Он используется для сетевого мониторинга, безопасности, трассировки и профилирования.

Применение eBPF:
— Сетевой фильтр: ускоряет обработку пакетов, применяется в XDP и Cilium.
— Мониторинг и трассировка: инструменты вроде BCC и bpftrace используют eBPF для анализа работы ядра в реальном времени.
— Безопасность: используется в системе защиты, такой как Falco, для обнаружения аномалий.

Автообновление контейнеров по Git push

Автоматизация деплоя — один из способов сэкономить часы жизни и избавиться от рутины.

Если вы используете GitLab и Docker, можно настроить простую, но эффективную схему: пушим код — запускается GitLab CI, собирается и пушится образ — Watchtower на проде обновляет контейнер. Всё это без единого ручного действия.

1️⃣GitLab CI собирает и пушит Docker-образ

Пример .gitlab-ci.yml:

stages:
  - build
  - deploy

variables:
  IMAGE_TAG: registry.gitlab.com/yourgroup/yourapp:latest

build:
  stage: build
  script:
    - docker build -t $IMAGE_TAG .
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin $CI_REGISTRY
    - docker push $IMAGE_TAG

Для продакшена рекомендуют использовать versioned теги:

IMAGE_TAG: registry.gitlab.com/yourgroup/yourapp:$CI_COMMIT_SHORT_SHA

2️⃣ Watchtower на сервере следит за обновлениями

Запускаем Watchtower с привязкой к сокету Docker:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e WATCHTOWER_CLEANUP=true \
  -e WATCHTOWER_POLL_INTERVAL=60 \
  containrrr/watchtower

Если у вас приватный реестр, авторизуйтесь на сервере:

docker login registry.gitlab.com

Можно указать конкретный контейнер, за которым следить:

containrrr/watchtower yourapp_container

3️⃣ Запускаем основной контейнер из latest

Контейнер должен быть собран из обновляемого тега:

docker run -d \
  --name yourapp_container \
  yourgroup/yourapp:latest

При обновлении latest Watchtower автоматически остановит и перезапустит контейнер с новым образом.

Ускорение cold-start для systemd-сервисов

Если при загрузке системы или запуске демонов вы замечаете задержки, systemd даёт немало рычагов, чтобы cold-start прошёл быстрее.

Особенно это критично для сервисов, чувствительных к времени реакции (например, прокси, VPN, API-шлюзы).

Вот основные параметры, с которыми стоит поиграться:

⏺IOSchedulingClass и IOSchedulingPriority
Позволяют задать класс и приоритет доступа к диску.

Пример:

[Service]
IOSchedulingClass=best-effort
IOSchedulingPriority=2

Если сервис работает с базами или логами — можно установить класс realtime или поднять приоритет ближе к 0 (чем ниже — тем выше приоритет).

⏺CPUSchedulingPolicy и CPUSchedulingPriority
Контроль приоритетов на уровне CPU-шедулера.
Для критичных задач — SCHED_FIFO или SCHED_RR.

[Service]
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=50

⏺StartLimitBurst и StartLimitInterval
Позволяют контролировать поведение при частых перезапусках. Иногда systemd из-за быстрых рестартов просто «глушит» сервис.

[Unit]
StartLimitBurst=10
StartLimitIntervalSec=30

Можно дать больше попыток на старте — особенно если сервис зависит от сети или сторонних демонов.

⏺TimeoutStartSec
Если cold-start занимает время, а systemd слишком рано считает запуск проваленным — увеличьте таймаут:

[Service]
TimeoutStartSec=60s

⏺ExecStartPre и ReadyNotify
Иногда лучше запускать предварительную инициализацию отдельно, чтобы основная служба стартовала уже с готовым окружением.

[Service]
ExecStartPre=/usr/local/bin/warmup.sh
Type=notify

⏺Nice и OOMScoreAdjust
Если нужно приоритетное планирование и защита от OOM killer’а:

[Service]
Nice=-5
OOMScoreAdjust=-500