Мониторинг жестких дисков linux

Отслеживание производительности жестких дисков Linux сервера обычно производится при помощи систем, основанных на готовых решениях таких как Zabbix, но для собственной инфраструктуры можно написать свои скрипты, которые будут производить мониторинг дисков, затем обрабатывать эти данные и при необходимости визуализировать. Во второй части статьи приведен скрипт на основе которого можно построить собственную систему мониторинга.

Мониторинг дисков Linux сервера

Чаще всего применяются консольные утилиты vmstat, top, iotop, iostat и т.п. вывод некоторых из них — в частности, vmstat удобно парсится и и используется в bash скриптах.

vmstat

В выводе для отслеживания состояния дисков значение имеет блок io (характеризует операции ввода-вывода — их количество и затратность для системы )

bi — blocks in — сколько блоков записали в дисковую систему

bo — blocks out — сколько считали

top

Нажатие D покажет список процессов создающих самую большую нагрузку на диск

iotop

Интерес представляют параметры о количестве процессов записи на диск и чтения с диска

Total DISK READ
Total DISK WRITE

Total — показывает пропускную способность между ядром ОС и системой ввода-вывода

Actual DISK READ
Actual DISK WRITE

Actual — показывает как система ввода-вывода обращается к железу

ionice:
—idle — процесс может использовать диск только если он простаивает и другими процессами не используется
—be — best effort (классы 0-7) — средний приоритет
—rt — real time — наивысший приоритет (классы 0-7, 7-й будет означать максимальный приоритет)

В некоторых случаях приоритет потребления диска для процессов требуется понизить, делается это как раз при помощи ionice

iostat входит в пакет sysstat — если в системе его нет, пакет можно установить при помощи apt-get

Большое количество полезной информации выведет вызов команды с ключом -x

Утилита SAR обладает широким функционалом и применяется, среди прочего, и для мониторинга дисков

sar является частью пакета sysstat. Чтобы запустить 2 теста параметров с интервалом в 5 секунд нужно выполнить sar 5 2

Используя ключ -b можно получить информацию о подсистеме ввода-вывода и использовании буферов

Linux 4.4.0-97-generic (admin-Satellite-C660) 28.10.2017 _i686_ (4 CPU)

14:54:02 tps rtps wtps bread/s bwrtn/s
14:54:07 3,80 0,00 3,80 0,00 307,20
14:54:12 0,40 0,00 0,40 0,00 12,80
Average: 2,10 0,00 2,10 0,00 160,00

В выводе будут следующие параметры с актуальными значениями:

%busy (процент занятости),
avque (средня длина очереди),
r+w/s (число операций чтения и записи в секунду),
blks/s (число переданных блоков в секунду),
avwait (среднее время ожидания)
avserv (среднее время обслуживания).

Большие значения %busy и avque будут говорить о существовании проблем с дисковой подсистемой.

С опцией -d будет выводиться информация по системным устройствам, -p (pretty) сделает вывод более читабельным

Linux 4.4.0-97-generic (admin-Satellite-C660) 28.10.2017 _i686_ (4 CPU)

14:55:26 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
14:55:31 sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00

14:55:31 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
14:55:36 sda 2,80 0,00 238,40 85,14 0,01 2,29 2,29 0,64

Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
Average: sda 1,40 0,00 119,20 85,14 0,00 2,29 2,29 0,32

Скрипт, осуществляющий мониторинг дисков Linux сервера

Рассмотрим простейший скрипт, который будет контролировать количество операций ввода-вывода и в случае превышения установленного значения отправлять письма на адрес администратора сервера.

Скрипт будет контролировать только два параметра, это простейшая реализация. Однако добавив некоторый функционал и дополнительные параметры скрипт можно использовать для построения собственной системы мониторинга.

Будем парсить вывод vmstat, понадобятся значения bi и bo, которые показывают сколько операций ввода-вывода выполняется дисковой подсистемой.

procs ————memory———- —swap— ——io—- -system— ——cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 832180 189268 67288 649176 1 18 34 38 158 778 8 2 88 2 0

Оставим в выводе только интересующие нас колонки

bi bo
34 38

При помощи tail вырежем последнюю строку со значениями

43 45

Далее приведены строки скрипта, который будет использоваться для мониторинга

Значение первого параметра будем записывать в файл bytes_in.txt

vmstat | awk ‘‘ | tail -1 | cut -f 1 -d ‘ ‘ > bytes_in.txt

Значение второго таким же образом в bytes_out.txt

vmstat | awk ‘‘ | tail -1 | cut -f 2 -d ‘ ‘ > bytes_out.txt

Возьмем в качестве предельного значение 90, которое не является критичным даже для десктоп инсталяции и в настоящей системе может быть заменено на любое другое. Читаем значение из файла и сравниваем его с числом 90, если значение больше 90 — отправляем письмо на адрес электронной почты администратора

if [ `cat /home/admin/bytes_in.txt` -gt 90 ]; then echo ‘Value of bytes_in is greater then 90. Take a look’ | mail -s ‘ WARNING’ admin@example.com; fi

if [ `cat /home/admin/bytes_out.txt` -gt 90 ]; then echo ‘Value of bytes_out is greater then 90. Take a look’ | mail -s ‘WARNING’ admin@example.com; fi

Получили скрипт в 4 строки, который будет контролировать самые важные параметры работы дисковой подсистемы сервера.

Последние 2 можно выполнять с небольшой задержкой, которая реализуется через sleep

Получившиеся пять строк нужно добавить в CRON, если задание будет выполняться раз в минуту — администратор всегда будет в курсе возникающих проблем с вводом-выводом. Таким же образом можно контролировать значение других параметров. Можно включать в письмо актуальное значение на которое среагировал мониторинг. Нужно ли это следует решать каждый раз индивидуально.

Источник

Мониторинг и проверка состояния SSD в Linux

И снова здравствуйте. Перевод следующей статьи подготовлен специально для студентов курса «Администратор Linux». Поехали!

Что такое S.M.A.R.T.?

S.M.A.R.T. (расшифровывается как Self-Monitoring, Analysis, and Reporting Technology) – это технология, вшитая в накопители, такие как жесткие диски или SSD. Ее основная задача – это мониторинг состояния.

На деле, S.M.A.R.T. контролирует несколько параметров во время обычной работы с диском. Он мониторит такие параметры как количество ошибок чтения, время запуска диска и даже состояние окружающей среды. Помимо этого, S.M.A.R.T. также может проводить тесты с использованием накопителя.

В идеале, S.M.A.R.T. позволит прогнозировать предсказуемые отказы, такие как отказы, вызванные механическим износом или ухудшением состояния поверхности диска, а также непредсказуемые отказы, вызванные каким-либо неожиданным дефектом. Поскольку обычно диски не выходят из строя внезапно, S.M.A.R.T. помогает операционной системе или системному администратору идентифицировать те диски, которые скоро выйдут из строя, чтобы их можно было заменить и избежать потери данных.

Что не относится к S.M.A.R.T.?

Все это, конечно, круто. Однако S.M.A.R.T. – это не хрустальный шар. Он не может спрогнозировать отказ со стопроцентной вероятностью и не может гарантировать, что накопитель не выйдет из строя без предупреждения. В лучшем случае S.M.A.R.T. стоит использовать для оценки вероятности поломки.

Учитывая статистический характер прогнозирования отказов, технология S.M.A.R.T. особенно интересует компании, использующие большое количество устройств для хранения данных. Чтобы выяснить, насколько точно S.M.A.R.T. может прогнозировать отказы и сообщать о необходимости замены дисков в центрах обработки данных или серверных мейнфреймах, даже проводились специальные исследования.

В 2016 году Microsoft и университет штата Пенсильвания провели исследование, связанное с SSD.

Согласно этому исследованию, некоторые атрибуты S.M.A.R.T. считаются хорошими индикаторами неизбежности отказа. В особенности в статье упоминаются:

Счетчик переназначенных (Realloc) секторов:

Несмотря на то, что основополагающие технологии радикально отличаются, этот показатель остается востребованным как в мире SSD, так и в мире жестких дисков. Стоит отметить, что из-за особенностей алгоритмов балансировки износа, используемых в SSD, когда несколько секторов выходят из строя, то с большой вероятностью можно предположить, что скоро выйдут из строя еще больше.

Ошибки в цикле Program/Erase (P/E):

Это признак проблем с основным оборудованием флеш-памяти, связанных с тем, что диск не может удалить данные из блока или сохранить их там. Дело в том, что процесс производства несовершенен, поэтому появление таких ошибок вполне можно ожидать. Однако флеш-память имеет ограниченное число циклов записи/удаления. По этой причине внезапное увеличение числа событий может сигнализировать о том, что диск достигает своего предела, и вполне ожидаемо, что другие ячейки памяти также начнут выходить из строя.

CRC и неисправимые ошибки («Data Error ”):

События такого типа могут быть вызваны ошибками хранения, либо проблемами с внутренним каналом связи накопителя. Этот индикатор учитывает как исправленные ошибки (без проблем сообщенные хост-системе), так и неисправленные ошибки (из-за которых происходит блокировка диска, сообщившего хост-системе о невозможности чтения). Другими словами, исправляемые ошибки невидимы для операционной системы, тем не менее они влияют на производительность накопителя, увеличивая вероятность переназначения сектора.

SATA downshift count:

Из-за временных помех, проблем с каналом связи между накопителем и хостом или из-за внутренних проблем с накопителем, интерфейс SATA может переключиться на более низкую скорость передачи сигналов. Снижение скорости соединения ниже номинального уровня оказывает очевидное влияние на производительность диска. Таким образом, этот показатель является наиболее значимым, в особенности, когда он коррелирует с наличием одного или нескольких предыдущих показателей.

Согласно исследованию, 62% вышедших из строя SSD показали наличие как минимум одного из вышеприведенных симптомов. С другой стороны можно сказать, что 38% изученных накопителей сломались без индикации этих симптомов. В исследованиях не упоминалось, были ли какие-то еще сообщения об отказах от S. M. A. R. T. по другим «симптомам». По этой причине нельзя напрямую сопоставить эти значения с отказом без предупреждения в 36% случаев из статьи от Google.

В исследовании Microsoft и университета штата Пенсильвания не раскрывались модели исследуемых дисков, однако, по словам авторов, большинство дисков поступают от одного и того же поставщика в течение уже нескольких поколений.

В ходе исследования также были отмечены значительные различия в надёжности между различными моделями. Например, «худшая» изученная модель показывает двадцатипроцентную частоту отказов через 9 месяцев после первой ошибки переназначения и до 36-ти процентов отказов в течение 9 месяцев после первого появления ошибок данных. «Худшей» моделью было названо более старое поколение дисков, рассматриваемых в статье.

С другой стороны, с теми же симптомами, что приведены выше, накопители нового поколения отказали в 3% и 20% в соответствии с теми же ошибками. Трудно сказать, можно ли объяснить эти цифры улучшением конструкции накопителя и производственного процесса, или здесь роль играет эффект устаревания накопителя.

Самое интересное, что упоминается в статье (я уже писал об этом ранее), так это то, что увеличение количества зарегистрированных ошибок может случить тревожным индикатором:

«Существует большая вероятность появления симптомов, предшествующих отказу SSD, которые активно себя проявляют и быстро прогрессируют, сильно сокращая время жизни накопителя до нескольких месяцев.»

Другими словами, одна случайная ошибка, о которой сообщил S.M.A.R.T., определенно не должна рассматриваться как сигнал о неизбежном отказе. Однако, когда исправный SSD начинает сообщать о все большем количестве ошибок, следует ждать краткосрочного или среднесрочного сбоя.

Но как узнать, в каком состоянии сейчас ваш SSD? Для удовлетворения своего любопытства, либо из желания начать внимательно следить за своими накопителями, вы можете использовать инструмент мониторинга smartctl .

Использование smartctl для мониторинга состояния вашего SSD в Linux

Чтобы следить за S.M.A.R.T статусом вашего диска, я предлагаю использовать инструмент smartctl , который является частью пакета smartmontool (по крайней мере на Debian/Ubuntu).

smartctl – это инструмент командной строки, но это особенно помогает в случаях, когда вам нужно автоматизировать сбор данных, например, с ваших серверов.

Первый шаг в использовании smartctl – это проверка того, есть ли на вашем диске S.M.A.R.T. и поддерживается ли он инструментом:

Как видите, мой внутренний жесткий диск ноутбука действительно поддерживает S.M.A.R.T. и он включен. Итак, как теперь получить S.M.A.R.T статус? Есть ли какие-то зафиксированные ошибки?

Выдача отчета «о всей S.M.A.R.T. информации о диске» — это опция -a :

Понимание выходных данных команд smartctl

На выходе получается много информации, которую не всегда легко понять. Наиболее интересной, вероятно, является та часть, которая помечена как “Vendor Specific SMART Attributes with Thresholds”. Она сообщает различные статистические данные, собранные S.M.A.R.T. устройством, и позволяет сравнить эти значения (текущие или худшие за все время) с некоторым порогом, определенным поставщиком.

Например, вот мои отчеты о переназначенных секторах на диске:

Вы можете заметить атрибут «Pre-fail». Он означает, что значение является аномальным. Таким образом, если значение превышает пороговое, велика вероятность сбоя. Другая категория »Old_age» используется для атрибутов, отвечающих значениям «нормального износа».

Последнее поле (здесь со значением «3») соответствует исходному значению атрибута, которое сообщает диск. Обычно это число имеет физическое значение. Здесь это фактическое количество переназначенных секторов. Для других атрибутов это может быть температура в градусах Цельсия, время в часах или минутах или количество раз, когда для диска было выполнено определенное условие.

В дополнение к исходному значению, диск с поддержкой S.M.A.R.T. должен сообщать «нормализованные значения» (значения полей, самые худшие и пороговые). Эти значения нормируются в диапазоне 1-254 (0-255 для пороговых значений). Прошивка диска выполняет эту нормализацию с помощью некоторого внутреннего алгоритма. Кроме того, разные производители могут нормализовать один и тот же атрибут по-разному. Большинство значений представлены в процентах, причем чем выше, тем лучше, но так бывает не всегда. Когда параметр ниже или равен пороговому значению, указанному производителем, диск считается неисправным в терминах этого атрибута. Помня о всех указаниях из первой части статьи, когда атрибут, показывающий ранее значение “pre-fail” все-таки дал сбой, наиболее вероятно, что скоро диск выйдет из строя.

В качестве второго примера возьмем “seek error rate”:

На самом деле (и это основная проблема отчетности S.M.A.R.T.), точное значение полей каждого атрибута понимает только поставщик. В моем случае Seagate использует логарифмическую шкалу для нормализации значения. Таким образом, «71» означает примерно одну ошибку на 10 миллионов запросов (10 в степени 7,1). Забавно, что самым худшим показателем за все время была одна ошибка на 1 миллион запросов (10 в 6-й степени).

Если я правильно понимаю, то это значит, что головки моего диска сейчас расположены точнее, чем раньше. Я не следил за этим диском внимательно, поэтому анализирую полученные данные весьма субъективно. Возможно накопитель просто надо было немного «обкатать» с тех пор как он был введен в эксплуатацию? Или может быть это следствие механического износа деталей и, следовательно, теперь имеет место меньшая сила трения? В любом случае, какова бы ни была причина, это значение является скорее показателем производительности, чем ранним предупреждением об ошибке. Так что меня оно не сильно беспокоит.

Помимо вышеприведенного и трех крайне подозрительных ошибок, записанных около шести месяцев назад, этот диск находится в удивительно хорошем состоянии (по данным S.M.A.R.T.) для стокового диска ноутбука, проработавшего более 1100 дней (26423 часа).

Из любопытства я провел этот же тест на гораздо более новом ноутбуке, оснащенном SSD:

Первое, что бросается в глаза, так это то, что несмотря на наличие S.M.A.R.T., устройства нет в базе данных smartctl . Но это не помешает инструменту собирать данные с SSD, однако он не сможет сообщить точные значения различных атрибутов, специфичных для поставщика:

Выше вы видите выходные данные абсолютно нового SSD. Данные понятны даже в случае отсутствия нормализации или метаинформации для данных конкретного поставщика, как в моем случае с “Unknown_SSD_Attribute.” Я могу только надеяться, что в последующих версиях smartctl в базе данных появятся данные об этой модели диска, и я смогу лучше определять потенциальные проблемы.

Проверьте свой SSD в Linux с помощью smartctl

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

Автономное тестирование может проводиться во время обычных операций с диском, если не было указано иное. Поскольку тест и запросы ввода-вывода хоста будут конкурировать, производительность диска упадет на время теста. Спецификация S.M.A.R.T. определяет несколько видов автономного тестирования:

Короткое автономное тестирование ( -t short )
Такой тест проверит электрическую и механическую, производительность, а также производительность чтения диска. Короткое автономное тестирование обычно занимает всего несколько минут (обычно от 2 до 10).

Расширенное автономное тестирование ( -t long )
Этот тест занимает почти в два раза больше времени. Как правило, это просто более детальная версия короткого автономного тестирования. Кроме того, этот тест будет сканировать всю поверхность диска на наличие ошибок данных без ограничения по времени. Продолжительность теста будет пропорциональна размеру диска.

Транспортировочное автономное тестирование ( -t conveyance )
Этот тестовый набор предложен в качестве сравнительно быстрого способа проверки на возможные повреждения, возникшие во время транспортировки устройства.

Вот примеры, взятые с тех же дисков, что были выше. Я предлагаю вам угадать, где какой:

Сейчас производится проверка. Давайте дождемся завершения, чтобы посмотреть результат:

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

И еще раз, отправим в сон на две минуты и посмотрим результат:

Интересно, что в этом случае мы видим, что производители диска и компьютера, похоже, уже тестировали диск (на времени жизни в 0 часов и 12 часов). Я сам определенно был гораздо менее озабочен состоянием диска, чем они. Итак, поскольку я уже показал быстрые тесты, то и расширенный тоже запущу, чтобы посмотреть как это происходит.

Судя по всему на этот раз ждать придется гораздо дольше, чем при проведении короткого теста. Так что давайте посмотрим:

В последнем тесте обратите внимание на различие в результатах, полученных с помощью короткого и расширенного теста, даже если они были выполнены один за другим. Ну, возможно, этот диск не в таком уж и хорошем состоянии! Отмечу, что тест остановился после первой ошибки чтения. Поэтому, если вы хотите получить исчерпывающую информацию обо всех ошибках чтения, вам придется продолжать тест после каждой ошибки. Я призываю вас взглянуть на одну очень хорошо написанную страницу руководства smartctl(8) для получения дополнительной информации о параметрах -t select , N-max и -t select , чтобы уметь делать так:

Источник