Мониторинг lsi megaraid на linux с помощью zabbix. узнать состояние raid с помощью megacli

Введение

У нас имеется любой сервер Linux с настроенным рейдом mdadm. Я специально не останавливаюсь на каком-то конкретном дистрибутиве, потому что этот рецепт универсален и будет актуален в любом дистрибутиве. Узнать состояние рейда можно командой в консоли:

Заглавные буквы U означают, что все жесткие диски на месте, с рейдом все в порядке. Если какой-то из них выйдет из строя, то вместо буквы будет стоять знак _ . По этому значению мы и будем определять статус рейд массива mdadm — если знака _ нет, то все в порядке.

Воспользуемся простой командой для определения символа _ в выводе mdstat:

Если символа _ нет, то на выходе получаем значение 0. Если же это значение больше 1, то рейд считается поврежденным, zabbix отправляет уведомление. Отправлять полученные значения на сервер мониторинга будем с помощью UserParameter.

Видео

Привожу видеоролик по установке и настройке предыдущей версии zabbix. Принципиально ничего не изменилось, кроме версий установленных программ.

Watch this video on YouTube

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

mdadm | Шпаргалки админа

ВАЖНО перед любыми операциями на хранилище убедитесь что бэкапы актуальны и исправны. Сначала смотрим состояние массива, важно чтоб не шла синхронизация либо пересборка..(я сделал ошибку, диск сбойнул и электричество выключили, я поменял физически диск и потом пытался собрать массив, что стоило мне немного нервов, надо было дождаться восстановления массива(а диск что вылетел пометить как сбойный), а уже потом идти менять диск.)

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

вот например

# cat /proc/mdstat Personalities : md0 : active raid6 sdc1 sde1 sdg1 sdf1 sdd1 5860147200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] resync = 88.6% (1732051884/1953382400) finish=38.6min speed=95562K/sec

unused devices:

если такого нет, то помечаем диск сбойным

mdadm –manage /dev/md0 –fail /dev/sda1

затем удаляем его из массива

mdadm –manage /dev/md0 –remove /dev/sda1

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

sfdisk -d /dev/sdb | sfdisk /dev/sda

И добавляем заменённый диск в массив

mdadm –manage /dev/md0 –add /dev/sda1

после чего автоматически начнётся пересборка массива.

Расширение массива Так получилось, что у меня массив состоял из дисков по 1.5ТБ но потом их перестали выпускать, и я менял диски на 2ТБ, но они не использовались по полной…

в итоге остался один диск на 1.5ТБ, решено его заменить на 2ТБ и расширить массив.

также перед началом смотрим что массив наш исправен, если всё ок то начинаем

mdadm –grow /dev/md0 –size=max

Автоматически начинается пересборка массива, у меня началась с 75%

вот что было до команды

# mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Mar 11 11:32:41 2013 Raid Level : raid6 Array Size : 4395018240 (4191.42 GiB 4500.50 GB) Used Dev Size : 1465006080 (1397.14 GiB 1500.17 GB) Raid Devices : 5

Total Devices : 5

вот что стало после

# mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Mar 11 11:32:41 2013 Raid Level : raid6 Array Size : 5860147200 (5588.67 GiB 6000.79 GB) Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB) Raid Devices : 5

Total Devices : 5

После синхронизации дисков, нужно расширить Файловую систему предварительно выполнив проверку текущей, но

перед проверкой надо отмонтировать фс

и проверяем

если всё ок, то расширяем ФС

Следить за процессом пересборки массива удобно вот такой командой

Просмотр состояния RAID-контроллера Adaptec на Debian5

Сентябрь 17th, 2014 Evgeniy Kamenev

1.Проверка наличия RAID-контроллера

# cat /var/log/dmesg | grep RAID

1	# cat /var/log/dmesg \| grep RAID

scsi 0:0:0:0: Direct-Access Adaptec RAID1 V1.0 PQ: 0 ANSI: 2

1	1.881318scsiDirect-Access Adaptec RAID1 V1.PQANSI2

2.Загрузка и установка утилиты arcconf

# cd /usr/src

1	# cd /usr/src

wget http://download.adaptec.com/tmp0001/adaptec/asmdeb/asm_debian_x86_x64_v6_50_18570.tgz

# tar xvfz asm_debian_x86_x64_v6_50_18570.tgz

1	# tar xvfz asm_debian_x86_x64_v6_50_18570.tgz

Для 64bit системы dpkg -i storman_6.50-18570_amd64.deb Для 32bit системы dpkg-i storman_6.50-18570_i386.deb Отключаем stor agent и выключаем его автозапуск:

# /etc/init.d/stor_agent stop

1	# /etc/init.d/stor_agent stop

# update-rc.d -f stor_agent remove

1	# update-rc.d -f stor_agent remove

3.Работ а с утилитой arcconf

# /usr/StorMan/arcconf

1	# /usr/StorMan/arcconf

– просмотр справки

# /usr/StorMan/arcconf GETVERSION

1	# /usr/StorMan/arcconf GETVERSION

— просмотр информации о всех существующих контроллерах

Опубликовано в рубрике Debian/Ubuntu, Other Метки: Adaptec, arcconf, Debian, RAID Комментарии к записи Просмотр состояния RAID-контроллера Adaptec на Debian5 отключены

Мониторинг веб-сервера Nginx c помощью zabbix trapper

Рассмотрим случай, когда требуется настроить мониторинг сервера по множеству однотипных или динамических метрик, которые отсутствуют в zabbix-агенте.

В такой ситуации в zabbix-агенте можно создавать ключи для проверки с помощью параметра конфигурации – UserParameter. Для каждого параметра в zabbix_agentd.conf создаётся строка вида:

Однако, если значений слишком много, такой способ может оказаться не удобным.

Второй способ заключается в использовании элемента данных zabbix типа trapper (zabbix-ловушки). Принцип очень простой: в zabbix-сервере создаются элементы данных этого типа с произвольным именем ключа.

Если параметров много, то можно сформировать файл в формате zabbix_sender и отправить все значения из файла за одно соединение с сервером.

Строки в файле должны быть оформлены в таком виде:

или

Рассмотрим, как использовать эту возможность на примере мониторинга популярного веб-сервера Nginx. Для этого веб-сервера есть возможнось использовать модуль stub_status, который показывает в цифрах текущую нагрузку на Nginx примерно в таком виде:

Из этих данных мы можем получить, например, такие метрики для мониторинга:

nginx_status.active – количество всех открытых соединений
nginx_status.reading – количество запросов, у которых nginx читает заголовки запроса
nginx_status.writing – количество запросов, у которых в данный момент сервер читает тело запроса, обрабатывает запрос или пишет ответ клиенту
nginx_status.waiting – количество неактивных(keep-alive) соединений
nginx_status.accepts – количество принятых запросов в секунду
nginx_status.handled – количество обрабатываемых запросов в секунду
nginx_status.requests – количество запросов в секунду

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

Скрипт, формирующий файл для zabbix_sender-а и запускающий zabbix_sender, может запускаться zabbix-агентом.

Для этого в конфигурационном файле агента zabbix_agentd.conf создадим ключ nginx_status:

Содержимое /home/zabbix/nginx.sh примерно такое:

При запросе сервером zabbix ключа nginx_status, скрипт вышлет данные серверу.

Создаем в zabbix-сервере шаблон – Template App Nginx.

Создаём в шаблоне элемент данных типа zabbix agent, запускающий скрипт /home/zabbix/nginx.sh (Рис. 1).

Рисунок. 1 Элемент данных, запускающий скрипт /home/zabbix/nginx.sh

Скрипт в случае успешного получения страницы nginx-status возвращает 1 и 0 – в противном случае. Полезно создать триггер отслеживающий эту ситуацию (Рис. 2).

Рисунок 2. Тригер, отслеживаюший возможность получения статуса с Nginx.

Далее для каждого параметра создаем элемент данных типа zabbix trapper. На Рис.2 пример для метритки nginx active connections.

Рисунок 3. Создание элемента данных для метрики nginx active connections.

После объединения графиков в группы получаются графики как на Рис. 4 и Рис. 5.

Рисунок 4. Статус соединений.

Рисунок 5. Нагрузка на сервер.

Шаблон для мониторинга nginx можно скачать отсюда: http://forum.itrm.ru/t/94/

Оповещение о недоступности сайта

Давайте настроим уведомления о проблемах на сайте. Я предлагаю 2 типа оповещения:

О низкой скорости доступа к сайту.
О недоступности сайта вообще.

Идем, как обычно в исходный шаблон, на вкладку Triggers и добавляем новый.

Я предлагаю вот такое условие срабатывания для определения недоступности сайта. Если среднее значение 3-х последних проверок больше, либо равно единице, то срабатывает оповещение о недоступности сайта.

Когда идет 0 во всех проверках, все в порядке. Триггер сработает только если все 3 последних проверки не равны нулю. В моем примере Failed step может принимать значение либо 0, либо 1, где 1 это номер сбойного шага. Если у вас шагов несколько, то сбойным может оказаться второй шаг или третий шаг. То есть значение может быть больше 1. Но в любом случае, если последние 3 значения подряд строго не 0, то идет срабатывание триггера. Операция восстановления очень простая. Если последняя проверка без ошибки, то есть код равен 0, то считаем, что сайт уже работает.

Чтобы проверить работу триггера, достаточно на zabbix server в файл /etc/hosts добавить строку:

127.0.0.1 github.com

и подождать 3 минуты, чтобы получились 3 неудачных проверки. После этого вам должно было отправиться уведомление о недоступности сайта. Я получил вот такое:

Дальше делаем проверку времени ответа сервера. Тут каждый волен настраивать так, как ему кажется более правильным и удобным. Я использую такую схему. Беру среднее время отклика сайта и умножаю его на 3. Далее смотрю последние 7 проверок. Если в 5 проверках среди этих семи были значения выше, чем утроенное среднее время отклика, то считаю, что сайт тормозит и надо слать уведомление. Немного замороченно, но на практике такая схема у меня себя хорошо зарекомендовала без ложных срабатываний. При этом, если возникают реальные проблемы, я их вижу. Рисуем триггер.

Условие восстановления — в последних трех запросах два и более были быстрее, чем утроенное среднее время доступа. Текст выражений для копирования:

{Sites Monitoring:web.test.time.count(#7,1.5,"ge")}>4
{Sites Monitoring:web.test.time.count(#3,1.5,"lt")}>1

В выражении 1.5 это время отклика в секундах. Именно в таком виде оно попадает в zabbix сервер. Проверить можно в Latest Data.

В завершении оставляю свой шаблон, который создал для написания статьи. Можете копированием и редактированием приспособить его для своих сайтов. Это быстрее, чем составлять с нуля. Шаблон экспортирован с версии zabbix 4.0 — sites_monitoring.xml

Вот и все, мониторинг веб сайта работает, авторизация проверяется, оповещение о недоступности сайта настроено. Для полноты картины можно создать Screen или Dashboard с выводом всех необходимых параметров на один экран. Его настройки уже будут зависеть от конкретной ситуации и тех данных, которыми вы располагаете. К примеру, если у вас настроен мониторинг веб сервера, то можно разместить рядом графики его загрузки и параметры доступа к сайту. Туда же можно добавить загрузку самого сервера по процессору и памяти и вывести график использования сетевого интерфейса.

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

Более подробно о мониторинге за временем отклика сайта читайте в отдельной статье на этот счет. Там описана теория процесса и практические рекомендации, вместе с готовым триггером.

Дополнительные материалы по Zabbix

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Настройки системы
Рекомендую полезные материалы по Zabbix:
Установка 4.0 Обновление 3.0 -> 3.2 Обновление 3.4 -> 4.0 Установка Zabbix Proxy Работа на NGINX Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm.
Мониторинг служб и сервисов
Температура процессора Nginx и php-fpm Mysql репликация Службы Linux Рейд mdadm Транки Asterisk Synology Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix.
Мониторинг различных значений
Мониторинг сайта Мониторинг бэкапов Размер бэкапа Делегирование домена Значения из текстового файла Мониторинг логов Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога.

Скрипты по сбору информации о размере бэкапов

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

# mkdir /etc/zabbix/scripts
# mcedit /etc/zabbix/scripts/size-backup-dir.sh

#!/bin/bash

# Файл с информацией о размере папок
logfile=/etc/zabbix/scripts/size-log.txt

# Удаляем файл предыдущей работы скрипта
rm $logfile

# Определяем размер папки
size_1c=`du -s /mnt/data/backup/1c | awk '{print $1}'`

# Записываем результат в текстовый файл
echo 1c $size_1c >> $logfile

Если у вас несколько папок с бэкапами, добавляете их все в скрипт. Можно автоматизировать этот процесс, задать переменные с названиями папок с бэкапами и в цикле их перебирать, но у меня это не получилось, так как пути сильно разные. Пришлось все в ручную добавлять. Я привожу пример с одной папкой. Остальные по аналогии добавляете, не забывая изменять имена переменных, в которые передается размер директории.

Результатом работы скрипта будет файл следующего содержания:

# cat size-log.txt
1c 41374052

1с	имя бэкапа
41374052	размер бэкапа в байтах

Необходимо добавить этот скрипт в крон и выполнять раз в сутки. Находите конфиг крона в вашей системе и добавляете туда:

30      15       *       *       *      /etc/zabbix/scripts/size-backup-dir.sh

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

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

# mcedit /etc/zabbix/scripts/send-zabbix-size.sh

#!/bin/bash
cat /etc/zabbix/scripts/size-log.txt | grep $1 | cut -d " " -f 2

Проверяем его работу следующим образом:

# ./send-zabbix-size.sh 1c
41374052

На выходе просто цифра с размером, которая уходит на сервер заббикса. То, что нужно

Важно не забыть один момент, иначе ничего не зааработает. Скрипту нужно назначить владельца zabbix, чтобы агент мог его запускать:

# chown zabbix. /etc/zabbix/scripts/send-zabbix-size.sh

Если этого не сделать, получите ошибку в логе агента:

sh: 1: /etc/zabbix/scripts/send-zabbix-size.sh: Permission denied

Заключение

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