Мониторинг и диагностика файлового сервиса: ключевые метрики, Prometheus, Grafana и Zabbix

Почему файловый сервис требует постоянного мониторинга

Общий файловый сервис на Samba или NFS держит на себе общие каталоги, профили пользователей, дистрибутивы, резервные копии и рабочие документы. Отказ длиной в 30 минут останавливает работу целых отделов: бухгалтерия не закрывает период, разработчики не собирают релиз, поддержка не открывает вложения из тикетов. Простой файлового сервиса редко бывает локальным.

Причины отказов обычно не выглядят катастрофично в момент появления. Раздел /srv/data заполняется до 100%, и ядро перестает создавать новые файлы, хотя место в других разделах есть. Samba открывает дескриптор на каждое подключение, упирается в fs.file-max и начинает отклонять новые сессии. Ретрансмиты в NFS растут из-за потери пакетов на коммутаторе, и пользователи жалуются на медленный сервер, тогда как диски отвечают за единицы миллисекунд.

Ручная проверка логов работает, пока у вас два сервера. На десяти хостах с разными версиями Samba и NFS такой подход дает пропущенные инциденты: сбой обнаруживают пользователи, а не дежурный. Метрики, собранные заранее, показывают деградацию до того, как она станет отказом: рост очереди I/O, растущий счетчик ретрансмитов, приближение к лимиту дескрипторов.

Сообщество «Сети для всех» публикует статьи и практические разборы по сетевому и системному администрированию, включая Cisco, MikroTik, Huawei, Zabbix, Grafana и Linux, а также реальные примеры конфигураций и типичных проблем: практические разборы по Zabbix, Grafana и Linux. Такой формат удобен как источник рабочих шаблонов, которые дальше адаптируют под свое окружение.

Ключевые метрики для контроля состояния файлового сервиса

Минимальный набор для эксплуатации: задержки ввода-вывода, пропускная способность и ошибки сети, свободное место и inode, открытые дескрипторы, ошибки протоколов NFS и Samba. Метрики снимают и с сервера, и с клиентов. Сервер показывает ресурсы, клиент показывает, что реально доходит до пользователя: сетевые потери и таймауты видны именно на стороне клиента.

Метрики ввода-вывода и их интерпретация

Основной инструмент - iostat -x 5, для истории подходит sar -d 1 10. Смотрите r/s и w/s (число операций), rkB/s и wkB/s (объем), r_await и w_await (средняя задержка обслуживания запроса в миллисекундах), aqu-sz (средняя длина очереди) и %util (доля времени, когда диск был занят).

Ориентиры для практики: await выше 20 мс на HDD уже повод присмотреться, для диска, отданного под NFS-экспорт, задержка выше 50 мс почти всегда превращается в жалобы на медленный доступ. Растущая aqu-sz при стабильном await означает, что запросов становится больше, чем диск успевает разгребать. Показатель %util выше 80% на HDD сигналит о насыщении, а вот на NVMe он часто близок к 100% и при нормальной работе, потому что устройство обслуживает несколько очередей параллельно. Для NVMe ориентируйтесь на await и длину очереди.

Пошаговый разбор узких мест по диску, памяти и сети с пороговыми значениями собран в материале мониторинг производительности сервера: метрики CPU, памяти, диска и сети.

Сетевые метрики и пропускная способность

Загрузку интерфейсов снимает sar -n DEV 1, ошибки и дропы показывает ip -s link show eth0 и ethtool -S eth0. Пропускная способность измеряется в мегабитах в секунду, и для файлового сервиса важнее не пиковая цифра, а доля ошибок и потерь: даже 0,1% потерь на гигабитном канале ощутимо тормозит SMB из-за повторных передач.

Для NFS ключевые счетчики лежат в nfsstat -r на клиенте: retrans (повторные передачи RPC-запросов) и timeouts. Рост retrans при нормальной загрузке дисков указывает на сеть: перегрузку аплинка, потери на коммутаторе, несовпадение duplex. Счетчики повторных передач TCP удобно смотреть через netstat -s | grep -i retrans.

Когда нужно найти конкретный процесс или соединение, которое съедает канал, помогают iftop и nethogs: инструменты для контроля загрузки файлов на сервере.

Свободное место и дескрипторы

Место контролируют двумя командами. df -h показывает занятость блоков, df -i показывает inode. На ext4 число inode фиксируется при создании файловой системы, и при миллионах мелких файлов (почта, кэш, логи) inode заканчиваются раньше места: запись падает с ошибкой «No space left on device», хотя df -h показывает свободные гигабайты. Рабочие пороги: 80% занятости как предупреждение, 90% как критичное событие, для inode те же границы.

Дескрипторы смотрят через cat /proc/sys/fs/file-nr (три числа: выделено, свободно, максимум), sysctl fs.file-max, ulimit -n и lsof | wc -l. Для конкретного демона полезнее ls /proc/$(pidof smbd)/fd | wc -l. Если выделенных дескрипторов больше 80% от максимума, новые подключения к Samba начнут отваливаться. В node_exporter ту же картину в графике дают метрики учета файловых дескрипторов; перед построением панели проверьте их наличие на эндпоинте /metrics вашей версии экспортера.

Ошибки протоколов NFS и Samba

Серверная статистика NFS собирается командой nfsstat -o all: badcalls (вызовы, отклоненные сервером), retrans и timeouts (сетевые проблемы), badxid (несовпадение идентификаторов), null. Рост badcalls говорит о том, что сервер не принимает часть запросов, а не о медленных дисках. На клиенте к этому добавляются nfsiostat и статистика по конкретному монтированию через mountstats.

Практическое правило интерпретации: если значения badxid и timeouts превышают пять процентов от общего числа запросов, стоит увеличить параметр timeo в опциях монтирования NFS (руководство по настройке производительности). Если badxid равно 0, а retrans и timeouts при этом велики, это тоже диагностический признак сетевых проблем, а не медленного хранилища. Учитывайте, что счетчики nfsstat накопительные: для алертов берите прирост за интервал, а не абсолютное значение.

Samba отдает состояние через smbstatus: smbstatus -p показывает процессы и подключения, smbstatus --locks показывает блокировки файлов, smbstatus -b показывает сессии. Косвенный признак проблем - рост числа «broken pipe» в логах и одновременное падение числа активных сессий. Часть таких инцидентов лечится не мониторингом, а настройками монтирования и передачи: параметры vers, wsize, rsize, timeo и nohide описаны в руководстве настройка NFS для максимальной скорости и стабильности.

Имена метрик, пути к логам и набор параметров зависят от версии Samba, ядра Linux и экспортеров. Перед тем как строить алерты на конкретный счетчик, проверьте его наличие в выводе nfsstat, smbstatus или на эндпоинте /metrics вашего экспортера. Расхождения между major-версиями Samba встречаются чаще, чем кажется.

Настройка мониторинга через Prometheus и Grafana

Prometheus забирает метрики по pull-модели: сам опрашивает HTTP-эндпоинты экспортеров по расписанию. Для файлового сервиса нужны два слоя: node_exporter на хосте (диски, сеть, файловые системы, дескрипторы) и протокольный экспортер или textfile-коллектор для специфики NFS и Samba.

Установка и настройка экспортеров

node_exporter ставится из релиза на GitHub, запускается под отдельным пользователем и по умолчанию слушает HTTP-порт 9100 (prometheus/node_exporter). Проверка занимает секунды: curl -s localhost:9100/metrics | head. Textfile-коллектор включается флагом --collector.textfile.directory=/var/lib/node_exporter/textfile: скрипт по cron раз в минуту пишет файл с метриками, а экспортер отдает их вместе с системными.

# TYPE nfs_badcalls_total counter
nfs_badcalls_total 3
# TYPE nfs_retrans_total counter
nfs_retrans_total 12
# TYPE samba_sessions gauge
samba_sessions 42

Для серверной статистики NFS в экосистеме Prometheus есть отдельные экспортеры, но подтвержденных данных о конкретном экспортере из организации prometheus-community, который читает счетчики ядра, и о его порте по умолчанию у нас нет. В официальном списке распределения портов Prometheus упоминается nfs-ganesha exporter (Default port allocations), однако это другой проект и другой охват метрик. Для Samba готовые экспортеры сторонние, и покрытие метрик зависит от версии, поэтому на практике чаще берут smbstatus через textfile-коллектор: это предсказуемо и не требует сборки. Экспортеры запускают на том же хосте, где работает сервис, иначе вы получите метрики другого узла.

scrape_configs:
  - job_name: 'file-server'
    scrape_interval: 30s
    static_configs:
      - targets: ['10.0.0.10:9100']

После перезагрузки конфигурации проверьте страницу /targets в интерфейсе Prometheus: цель должна быть в состоянии UP, а в /graph по имени метрики должны появляться точки.

Создание дашбордов в Grafana

Быстрый старт: подключите Prometheus как источник данных и импортируйте готовый дашборд Node Exporter Full (ID 1860) - это проверенный сообществом шаблон с более чем 20 панелями, импорт занимает пару минут (Node Exporter Full). Затем добавьте панели под свои метрики. Для файлового сервиса рабочий минимум на дашборде: задержка и очередь диска, ошибки и трафик интерфейса, свободное место и inode по всем точкам монтирования, процент использованных дескрипторов, счетчики NFS и число сессий Samba.

rate(node_disk_io_time_seconds_total[5m])
100 - (node_filesystem_avail_bytes{mountpoint="/srv/data"} / node_filesystem_size_bytes{mountpoint="/srv/data"} * 100)
rate(node_network_receive_errs_total[5m])

Имена метрик отличаются между версиями экспортеров, поэтому перед сохранением панели проверьте запрос в режиме Explore. Алерты удобнее держать в Grafana Alerting или в Alertmanager, если Prometheus уже связан с ним: контактные точки настраиваются на email, Telegram или webhook.

Мониторинг файлового сервиса в Zabbix

Zabbix собирает метрики агентом по расписанию и хранит историю в собственной базе. Путь короче для тех, у кого уже развернут сервер Zabbix: шаблон Linux by Zabbix agent закрывает процессор, память, диски, сеть и файловые системы, а специфику NFS и Samba добавляют через UserParameter.

В Zabbix 8.0 шаблоны Linux by Zabbix agent и Linux by Zabbix agent active обновлены: улучшены панели, расширен мониторинг сетевых интерфейсов и блочных устройств, а в агентах для Linux добавлен новый ключ элемента данных для обнаружения сетевых интерфейсов. Также в этой версии улучшены функции триггеров, основанные на подсчете (Что нового в Zabbix 8.0). Важно помнить: при обновлении Zabbix шаблоны и типы медиа не обновляются автоматически, чтобы не перезаписать ваши изменения, поэтому шаблоны обновляют или добавляют вручную по документации. Конкретный синтаксис триггеров и выражений сверяйте с документацией именно вашей версии: между релизами он меняется.

Сбор метрик NFS через Zabbix

Пользовательские параметры описываются в zabbix_agentd.conf и требуют перезапуска агента:

UserParameter=nfs.badcalls,nfsstat -o all | awk '/badcalls/ {print $2}'
UserParameter=nfs.retrans,nfsstat -o all | awk '/retrans/ {print $2}'
UserParameter=nfs.timeouts,nfsstat -o all | awk '/timeouts/ {print $2}'

В интерфейсе создайте элементы данных типа Zabbix agent с интервалом 60 секунд, типом «Числовой (целое положительное)», хранением истории 7 дней и трендов 90 дней. Триггер на рост ошибок выглядит так: min(/file-server/nfs.badcalls,5m)>10. Для ретрансмитов полезнее выражение на прирост, а не на абсолютное значение, потому что счетчик в nfsstat накопительный.

Сбор метрик Samba через Zabbix

UserParameter=samba.sessions,smbstatus -p | grep -c '^[0-9]'
UserParameter=samba.locks,smbstatus --locks | grep -c '^[0-9]'

Резкое падение числа сессий обычно означает обрыв на стороне сети или перезапуск демона, поэтому триггер строят на разнице между соседними значениями, а не на пороге. Ошибки аутентификации удобно ловить элементами журнала: активная проверка типа Zabbix agent (active) с ключом log[/var/log/samba/log.smbd,"STATUS_LOGON_FAILURE",,,skip] выдает строку в момент появления и не требует внешних скриптов.

Сообщество «Сети для всех» среди популярных публикаций отмечало материал о нововведениях в Zabbix 8.0 LTS (обзор нововведений Zabbix 8.0 LTS), поэтому перед обновлением мажорной ветки стоит сверить синтаксис триггеров и поведение шаблонов со своим релизом.

Анализ логов Samba и NFS для диагностики

Метрики отвечают на вопрос «что сломалось», логи отвечают на вопрос «почему». Для Samba основной источник - каталог /var/log/samba/, для NFS - journalctl -u nfs-server и системный журнал /var/log/syslog.

Что искать в логах Samba

Файлы называются log.smbd, log.nmbd и log.<адрес клиента>. Уровень детализации задается в секции [global] файла smb.conf: log level = 3 дает рабочую подробность, значение 10 включают временно для одного клиента. Постоянно держать уровень выше 3 не стоит: на активной шаре запись логов заметно нагружает диск и съедает место.

Ключевые строки для поиска: STATUS_LOGON_FAILURE, NT_STATUS_ACCESS_DENIED, broken pipe, read_fd_with_timeout failed, Too many open files. Интерпретация простая. Серия STATUS_LOGON_FAILURE от одного клиента чаще связана с устаревшим кэшем учетных данных или рассинхронизацией времени. Те же ошибки от всех клиентов сразу указывают на службу winbind или sssd и на доступность контроллера домена. Строка Too many open files подтверждает утечку дескрипторов.

grep -iE "error|fail|denied" /var/log/samba/log.smbd | tail -50
journalctl -u smbd --since "1 hour ago" | grep -i broken

Что искать в логах NFS

Ядро пишет про NFS в dmesg и syslog: dmesg -T | grep -i nfs, grep -i nfs /var/log/syslog, journalctl -u nfs-server --since "1 hour ago". Типовые сообщения: nfsd: too many open files (нужно поднимать лимиты для потоков nfsd), NFS: server not responding, still trying (клиент не получает ответ и продолжает попытки), NFS: server OK (связь восстановилась), rpc timeout.

Детальную отладку включает rpcdebug -m nfsd -s all, сброс делается флагом -c. Отладка пишет много записей и быстро забивает буфер и диск, поэтому включайте ее на минуты, а не на сутки. Полный набор приемов с nfsstat, nfsiostat, mountstats и разбором журналов ядра собран в материале диагностика NFS: nfsstat, nfsiostat, mountstats и журналы.

Практические сценарии диагностики типовых проблем

Медленный доступ к файлам

1. На сервере запустите iostat -x 5 и найдите диск, где лежит шара. Задержка await выше 100 мс и растущая очередь aqu-sz означают узкое место в хранилище.
2. Проверьте сеть: ping -c 100 до сервера, iperf3 -c на 30 секунд, на клиенте nfsstat -r и nfsiostat 10 по нужной точке монтирования.
3. Оцените процессор и память: топ по smbd, rpc.mountd и потоков nfsd, vmstat 1, число занятых ядер в сравнении с load average.
4. Просмотрите логи на ошибки и повторы.

Дальше решает интерпретация. Высокий await при чистой сети означает диски. Нормальные диски и растущие retrans означают сеть. Высокая доля системного времени процессора при чистых дисках и сети намекает на малый размер rsize и wsize. Разбор методики поиска узкого места без преждевременной закупки железа приведен в статье как найти узкое место в системе.

Обрывы сессий

1. Проверьте логи: broken pipe в Samba, NFS: server not responding у NFS.
2. Соберите сетевые ошибки: ip -s link show, ethtool -S eth0, sar -n EDEV 1. Ищите дропы и ошибки, а не только трафик.
3. Проверьте параметры монтирования NFS: timeo и retrans в /etc/fstab. Для NFS over TCP значение timeo по умолчанию составляет 600 (60 секунд), а если retrans не указан, клиент повторяет каждый TCP-запрос дважды. Сообщение «server not responding» генерируется после retrans повторов, после чего клиент продолжает восстановление в зависимости от того, действует ли опция hard-монтирования: при hard некэшированные операции повторяются до получения ответа. Учтите, что любое значение timeo больше значения по умолчанию будет приведено к значению по умолчанию, поэтому явное timeo=600,retrans=2 имеет смысл только как фиксация поведения, а не как увеличение таймаута (nfs(5)).
4. Сверьте лимиты дескрипторов: ulimit -n для пользователя Samba, LimitNOFILE в systemd-юните smbd, значение fs.file-max. Обрывы при большом числе открытых файлов лечатся поднятием лимитов и перезапуском демона.
5. Проверьте тайм-ауты простоя на межсетевом экране и балансировщике: разрыв соединения через час тишины часто объясняется именно ими, а не сервером.

Отказ аутентификации

1. В Samba сверьте smbstatus с логами: STATUS_LOGON_FAILURE против NT_STATUS_ACCESS_DENIED. Первое указывает на проверку подлинности, второе на права.
2. Проверьте время на сервере и клиенте: timedatectl, chronyc tracking. Расхождение больше нескольких минут ломает Kerberos, и вход перестает работать при верных паролях.
3. Просмотрите smb.conf: security, workgroup, параметры idmap config, список valid users и права на каталог через getfacl.
4. Для NFS проверьте /etc/exports и вывод exportfs -v: адрес клиента в списке, режимы root_squash и all_squash, тип безопасности sec.
5. После правки примените изменения без полного рестарта: smbcontrol smbd reload-config для Samba, exportfs -ra для NFS.

Сравнение Prometheus+Grafana и Zabbix для файлового сервиса

Выбор не обязан быть бинарным. На хосте с файловым сервисом часто уже стоит агент Zabbix, а Grafana умеет брать данные из Zabbix через плагин-источник, так что визуализацию можно оставить общей. Критерий простой: если серверов десятки и они меняются редко, Zabbix даст результат быстрее; если инфраструктура описана кодом и меняется еженедельно, Prometheus удобнее.

Настройка алертинга и пороговых значений

В Prometheus правила описываются в отдельном файле и подключаются к Alertmanager:

groups:
  - name: fileserver
    rules:
      - alert: FilesystemSpaceLow
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes) * 100 < 10
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Свободное место ниже 10% на {{ $labels.instance }}"
      - alert: FileDescriptorsHigh
        expr: node_filefd_allocated / node_filefd_maximum * 100 > 80
        for: 5m
        labels:
          severity: warning

В Zabbix те же условия записываются триггерами: last(/file-server/vfs.fs.size[/srv/data,pfree])<10 для места, min(/file-server/nfs.badcalls,5m)>10 для ошибок протокола, last(/file-server/samba.sessions) с функцией сравнения с предыдущим значением для обрывов. Условие for в Prometheus и параметр «Время срабатывания» в Zabbix гасят ложные срабатывания на коротких пиках.

Рабочие пороги, от которых удобно отталкиваться: свободное место ниже 10%, свободные inode ниже 5%, использованные дескрипторы выше 80% как предупреждение и выше 90% как критичное событие, ошибки NFS больше 5 в минуту, await выше 50 мс в течение 5 минут, доля потерянных пакетов на интерфейсе выше 0,1%. Подбирайте значения под свою нагрузку: порог, подобранный для тестового стенда, на проде будет срабатывать каждую ночь во время резервного копирования.

Заключение

Порядок действий для внедрения выглядит так. Включите node_exporter или агент Zabbix на каждом сервере с Samba и NFS. Добавьте textfile-коллектор или UserParameter для nfsstat и smbstatus, чтобы протокольные счетчики попали в общую систему. Соберите дашборд с четырьмя обязательными панелями: задержка и очередь диска, сетевые ошибки, свободное место и inode, дескрипторы. Настройте алерты на место, inode, дескрипторы, badcalls, retrans и await, с окном подавления не меньше 5 минут. Поднимите log level до 3 в smb.conf и убедитесь, что ротация логов настроена.

Раз в квартал пересматривайте пороги по фактической статистике: пик ночного бэкапа, сезонные нагрузки и рост числа файлов меняют картину. Сообщество «Сети для всех» собирает практические разборы и примеры конфигураций по Zabbix, Grafana и Linux (канал с разборами и примерами), где можно сверить свои шаблоны с чужим опытом и обсудить нетиповые инциденты.