Как мы мониторинг SMART-данных дисков в оVirt экосистеме прикручивали

«Предупреждение болезни HDD или SDD может спасти вашу рабочую неделю», — учили старейшины DevOps. И они были правы!

Представьте: у вас целая когорта виртуальных машин, работающих на oVirt. Но что произойдет, если диск в одном из узлов начнет сбоить? Pandemonium!

И вот тут на сцену выходит наш герой — smartctl_exporter. Этот маленький, но мощный инструмент постоянно следит за S.M. A.R.T.-данными ваших дисков, словно врач с термометром и стетоскопом. Если он заметит проблемы, то немедленно отправит тревогу в Prometheus и Grafana, чтобы вы могли принять меры. Ниже краткая информация о нем и о его настройке.

Выделенные серверы с процессорами 4 поколения AMD EPYC 9354 / 9124 / 9554 / 9754 и Intel Xeon Silver 4416+

Арендуйте высокопроизводительный выделенный сервер на базе процессоров AMD EPYC и Intel Xeon последнего поколения, с оперативной памятью DDR5 и хранилищем NVME. Серверы доступны для заказа в ультрасовременном дата-центре в Москве и Амстердаме.

Без инсталляционного платежа со скидкой до 12% в зависимости от срока аренды и выдачей на следующий рабочий день.

Заказать

Как работает этот инструмент?

Вкратце это можно описать так:

  1. Smartctl_exporter проникает внутрь ваших дисков и собирает информацию о их состоянии с помощью Smartmontools.

  2. Все собранные данные отправляются по HTTP на порт 9633, где Prometheus с жадностью их «глотает».

  3. Prometheus, в свою очередь, преобразует эти данные в понятную форму, которую Grafana легко отображает в виде красивых графиков и диаграмм.

  4. Если smart_exporter обнаружит серьезную угрозу (например, диск может скоро вылететь), он тут же отправит вам уведомление, чтобы вы успели принять необходимые меры.

Минус — инструмент имеет ограничения по работе некоторыми SCSI/SAS- и NVMe-дисками, которые отсутствуют в базе smartctl/smartd.

В самом сердце smartctl_exporter, внутри функции main, определяется список устройств для мониторинга. Если задан флаг smartctl.device, экспортер использует указанные устройства. В противном случае он обращается к функции scanDevices, которая выполняет сканирование и подгружает список доступных устройств.

Smart_exporter устанавливается на каждый оVirt Node (компонент, установленный на каждом отдельном хосте, который управляет всеми ресурсами этого хоста и запущенными на нем виртуальными машинами) по пути /usr/bin/smartctl_exporter. В качестве ОС используется CentOS 8 Stream. Для бесперебойной работы необходимо убедиться, что на oVirt Engine (центральный сервер управления, который контролирует все хосты виртуализации, дисковые ресурсы и виртуальные сети) установлена версия GoLang, не ниже той, что использовалась для написания экспортера.

Создание сервиса

Для работы экспортера также необходимо создать сервис systemd. Для этого идем в каталог /usr/lib/systemd/system/ и создаем файл smartctl_exporter.service:

[Unit]
Description=smartctl exporter service
After=network-online.target

[Service]
Type=simple
PIDFile=/run/smartctl_exporter.pid
ExecStart=/usr/bin/smartctl_exporter
User=root
Group=root
SyslogIdentifier=smartctl_exporter
Restart=on-failure
RemainAfterExit=no
RestartSec=100ms
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

После необходимо активизировать сервис и запустить его командами:

systemctl daemon-reload

Проверяем статус работы командой:

systemctl status smartctl_exporter.service

Если все хорошо, увидим вывод, похожий на этот:  

3dde54b00028d66c840f2a9587ed1c0a.png

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

Для этого вводим команду:

netstat -na | grep 9633 

Смотрим вывод. Если порт открыт, результат будет следующим:  

38657cbc06335614b1b48ad0a6562980.png

Если порт закрыт, нужно открыть его вручную:  

firewall-cmd --add-port 9633/tcp

Далее следует проверить, «тянется» ли метрика. Для этого, находясь на ноде, вводим:

curl http://localhost:9633/metrics

Смотрим вывод:

5fda03135d3cc202719e0f0aeaaa11f2.png

Создание алерта Prometheus

Первым делом создаем алерт. У нас в HOSTKEY мы храним их в gitlab по пути /devops/ansible-playbooks/prometheus_playbook/ files/alerts.

e1d4e6dc7f3fc673fc40197d19a53a63.png

Создаем файл в формате .yml и пишем алерт, где указываем имя самого алерта, нужный для мониторинга атрибут и значение, на которое будет срабатывать алерт, время обновления, типа алерта (в нашем примере warning), а также описание. Формат алерта следующий:

groups:

- name: hdd_smartctl_check.rules

 rules:

#===================service is down========================

 — alert: Service is down

 expr: up{job="smart_exporter"} == 0

 for: 0m

 labels:

 severity: critical

 annotations:

 summary: Service is down ({{ $labels.instance }})

 description: "Service is not reachable."

#===================Uncorrectable disk sectors============

 — alert: Uncorrectable disk sectors

 expr: smartctl_device_attribute{attribute_name="Offline_Uncorrectable",attribute_value_type="raw",job="smart_exporter"} > 10

 for: 0m

 labels:

 severity: warning

 annotations:

 summary: Uncorrectable disk sectors ({{ $labels.name }})

 description: "Value: {{ $value }}\nName: {{ $labels.name }}"

#===================DiskCurrentPendingSector========================

 — alert: DiskCurrentPendingSector

 expr: smartctl_device_attribute{attribute_name="Current_Pending_Sector",attribute_value_type="raw",job="smart_exporter"} > 10

 for: 0m

 labels:

 severity: warning

 annotations:

 summary: DiskCurrentPendingSector ({{ $labels.name }})

 description: "Value: {{ $value }}\nName: {{ $labels.name }}"

#===================Disk reallocated sectors=====================

 — alert: Disk reallocated sectors

 expr: smartctl_device_attribute{attribute_name="Reallocated_Sector_Ct",attribute_value_type="raw",job="smart_exporter"} > 10

 for: 0m

 labels:

 severity: warning

 annotations:

 summary: Disk reallocated sectors ({{ $labels.name }})

 description: "Value: {{ $value }}\nName: {{ $labels.name }}"

Сохраняем файл hdd_smartctl_check.yml и переходим в каталог /devops/ansible-playbooks/prometheus_playbook/group_vars

Открываем файл federation_ru.yaml. В верхней части документа, рядом с остальными таргетами, ниже создаем свой:

3db4742911958f5cd32fc9cb4207a10c.png

В таргете прописываем имя таргета, путь на каталог на HTTP, поднятый ранее на 9633 порту. Далее после labels указываем название сервиса и компонент virtualization:

e4f1cd1cd8480c68de0802ce72c1a601.png

Обращаем внимание, что вместо списка адресов присутствует вызов __address__. Файл с адресами всех нод генерируется при каждом прогоне плейбука, так что вводить огромное количество адресов не придется.

В самом начале документа после поля rule_files нужно указать имя написанного алерта:

0f2cdbdd83ec223b83b1f4d3ce06938d.png

Далее переходим к нашей внутренней Jenkins-задаче conf_prometheus.dsl и запускаем обновление мониторинга для всех серверов:

b7dd43e55bee34daf077e3484f7bf2a0.pngb2b7c8913f721d7cf065f89f37fc2c18.png

После успешного обновления следует перейти в веб-интерфейс Prometeus и проверить отработку таргета, введя имя искомого атрибута, например up{job=«smart_exporter»} == 0. Если проблем не возникло, то вывод будет примерно таким:  

646da9cfd7f953ad2eb8d524e56f1828.png

Вывод алерта на дэшборд Grafana

Алерты из Prometheus далее идут в Grafana, где выводятся на общий дэшборд. В нашем случае необходимо вывести алерты на отдельный дэшборд приложения с метриками, связанными с oVirt.

Делается это следующем образом: открываем дэшборд oVirt в Grafana, выбираем Edit и вписываем название алерта в формате job!=«cert_cheker». Обязательно после должна быть запятая, а если вписывается в середине поля, то с обоих сторон:

92bf6006375a5064e5545c2e8c8d524c.pngde7508fa6a7d47a94d8f5a3c3280870e.png

Далее идем в дэшборд Prometheus AlertManager — Ovirt checks:  

718ee4ea77b4f5747838e7138dde5898.png

Снова заходим в настройки панели:

be26922d6ade23ed09fc0cbc19cd4663.png

Жмем на добавление запроса (+ Query):

87719e13d42f554a12e4bcb1b25f7e83.png

И в появившемся поле вписываем имя алерта в формате job=«smart_exporter», после чего нажимаем Save в верхней части страницы:

ffc5ed1bec1e0c4708392c61876bcfb3.pnge3bfb65e2d63c6f5d856e3806bfaefea.png

После выполненных действий алерт будет выводиться на дэшборд oVirt — настройку можно считать оконченной.

Что можно сказать по итогу: инструмент хороший, позволяет извлекать значительное количество информации, но в текущей реализации работает преимущественно с HDD-дисками, а для SSD метрики по большей части выводятся не по классическому SMART-ATA-стандарту. И часть NVME-дисков вообще не видит (у нас таких, к счастью, не попалось).

Поэтому для SSD-дисков пришлось разбирать «простыню» вывода и вычленять из нее нужные атрибуты и переписывать алерты. Также инструмент хорошо интегрируется только с Prometheus, но для нас это не критично.

А вы чем мониторите ваши диски на серверах?

Выделенные серверы с процессорами 4 поколения AMD EPYC 9354 / 9124 / 9554 / 9754 и Intel Xeon Silver 4416+

Арендуйте высокопроизводительный выделенный сервер на базе процессоров AMD EPYC и Intel Xeon последнего поколения, с оперативной памятью DDR5 и хранилищем NVME. Серверы доступны для заказа в ультрасовременном дата-центре в Москве и Амстердаме.

Без инсталляционного платежа со скидкой до 12% в зависимости от срока аренды и выдачей на следующий рабочий день.

Заказать

© Habrahabr.ru