Архив метки: monitoring

Debian: Установка и настройка NET-SNMP

http://pro-voip.com.ua net-snmpЗдесь все манипуляции проводятся на Debian Wheezy.

Установка net-snmp

snmp — SNMP (Simple Network Management Protocol) applications
snmpd — SNMP (Simple Network Management Protocol) agents

snmpd.conf — конфигурационный файл для Net-SNMP SNMP агента.

Редактируем файл /etc/snmp/snmpd.conf:

Рестартуем демон snmpd:

Проверяем (например):

Контроль доступа к snmpd можно организовать двумя способами:

  • Traditional Access Control — традиционный контроль доступа
  • VACM Configuration — View-Based Access Control Model

 

SNMPv1 и SNMPv2c

 

Традиционный контроль доступа

Создание read-only и read-write community:

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, не ограничивая доступ к snmpd:

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, разрешив доступ к snmpd только localhost:

Создать read-only комьюнити public, разрешить доступ с localhost’а к ветке .1.3.6.1.2.1.1:

Если нам нужно объединить несколько разных веток дерева OID’ов для одного community, используем именованые «view»:

Если нужна более гибкое управление доступом к SNMP, следует использовать другую модель управления — VACM.

 

Контроль доступа VACM

Для того, чтобы настроить доступ к snmpd по модели VACM, необходимо определить 4 директивы:

  • com2sec
  • group
  • view
  • access

com2sec определяет некое имя (security name), к нему привязываются ip-адрес и комьюнити, с которыми можно получить доступ к snmpd:

com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

SECNAME — security name;
SOURCE — имя хоста, ip-адрес хоста, или подсеть в формате ip/mask, с которого разрешен доступ к snmpd;
COMMUNITY — строка community;
CONTEXT — используется в SNMPv3

group определяет группу, к которой привязываются ранее созданные secname:

group GROUP {v1|v2c|usm|tsm|ksm} SECNAME

view определяет ветки дерева MIB, к которым будем давать доступ:

view VNAME TYPE OID [MASK]

VNAME — произвольное имя вьюшки. Имена могут повторятся, таким образом создается вьюшка в набором «веток» дерева OID’ов;
TYPE — included или excluded — действие: включить или исключить ветку с view;
OID — определенный OID или ветка;

access даем ранее созданной группе права на доступ к просмотру/записи определенной вьюшки — связка group — view:

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY

GROUP — имя группы, определенное в шаге 2;
CONTEXT — default context —  «»

Пример:

«Пользователь» local — это пользователь локалхоста с комьюнити secret33, который входит в группу rwgroup. Пользователи группы rwgroup имеют read-write права на view с названием all. Вьюшке all соответствует дерево .1.

«Пользователь» rouser1 может получить доступ с сети 10.10.10.0/24, а «пользователь» rouser2 — с ip-адреса 11.11.11.11/32. Комьюнити — public. «Пользователи» rouser1 и rouser2 входят в группу rogroup. Группа rogroup имеет read-only права на view с названием systemview, в которую входят такие ветки дерева — 1.3.6.1.2.1.1, 1.3.6.1.2.1.2, 1.3.6.1.2.1.25:

 

SNMPv3

 

В SNMPv3 главным действующим «лицом» выступает не community, а user. Поэтому перед манипуляциями с контролем доступа, нужно сначала создать пользователя. При создании пользователя, мы также определяем уровень безопасности.

В SNMPv3 предусмотрено три уровня безопасности:

  • noAuthNoPriv — без аутентификации, без шифрования
  • authNoPriv — с аутентификацией (SHA|MD5), без шифрования
  • authPriv — с аутентификацией (SHA|MD5),с шифрованием (DES|AES)

Тип аутентификации — MD5 или SHA; Алгоритм шифрования — DES или AES;
SHA-аутентификация и DES/AES-шифрование используют OpenSSL — OpenSSL должен быть установлен, snmpd должен иметь поддержку OpenSSL.

Узнать, с какими опциями был собран net-snmp можно с помощью следующей команды:

Если —with-openssl в выводе есть, значит net-snmp собран с поддержкой openssl, если кто не догадался.

MD5 не использует OpenSSL.

 

Создание пользователя snmpv3

Для этого используется следующая команда:

net-snmp-config  —create-snmpv3-user [-ro] [-A authpass] [-X privpass] [-a MD5|SHA] [-x DES|AES] [username]

Минимальная длина authpass и privpass — 8 символов.

Сначала останавливаем демон snmpd:

Затем создаем пользователя, например, rouserv3:

При этом создается 2 записи в двух дефолтных конфигурационных файлах, о чем и пишет net-snmp-config в своем выводе. Если вы, не запуская snmpd, посмотрите на файл /var/lib/snmp/snmpd.conf, то в конце файла вы действительно увидите там строку «createUser rouserv3 MD5 «testtest» DES testtest». При запуске демона snmpd эта строка удаляется, появляется вместо нее ключ.

Запись «rouser rouserv3» в файле /usr/share/snmp/snmpd.conf — это настройка контроля доступа. Мало ведь создать пользователя, нужно дать ему какие-то права. Запись «rouser rouserv3» можно перенести в /etc/snmp/snmpd.conf (что я и делаю), а дальше использовать либо традиционный контроль доступа (оставив эту строку «rouser rouserv3»), либо VACM (по аналогии, как это настраивалось выше с SNMPv2c, только там были rocommunity и rwcommunity, а здесь rouser и rwuser).

 

Традиционный контроль доступа

Создание read-only и read-write-пользователя:

rouser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
rwuser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

noauth, auth, priv — помним про три уровня безопасности? было описано выше. Как по мне, так тут не хватает опции SOURCE, как в варианте в SNMP v1 и v2c с комьюнити. Для ограничения доступа с определенных ip-адресов нужно будет использовать фаервол. Ну и дальше примеры.

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, без аутентификации и без шифрования:

Проверка:

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией, но без шифрования:

Проверка:

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией и с шифрованием:

Проверка:

 

Контроль доступа VACM

В варианте с SNMP v1 и v2c для настройки VACM нужно было использовать 4 директивы: com2sec, group, view и access. В варианте с SNMP v3 — только три, com2sec использовать не нужно, у нас уже создан snmpv3-пользователь (он уже и есть «security name»), которого можно добавить в группу.

Отличие от настройки VACM в SNMP v1 и v2c — это указание securityModel — usm в директве group и указани sec.level в директиве access (sec.level может быть noauth, auth или priv)

 

Debian: Как узнать температуру процессора?

http://pro-voip.com.ua debianlm-sensors — набор утилит для считывания значений датчиков температуры, вольтажа и оборотов куллеров. С помощью этих утилит можно ответить себе на вопрос «Какая сейчас температура у моего процессора?» Итак, что мы делаем…

1.Устанавливаем lm-sensors:

apt-get install lm-sensors

2. Определяем наличие датчиков в системе:

sensors-detect

3. Догружаем недостающие драйвера:

modprobe <недостающие модули>

4. И все, смотрим значения датчиков:

sensors

 

Установка lm-sensors на Debian Wheezy

 

Определение датчиков в системе

Перед запуском команды sensors для считывания показаный с датчиков, нужно сначала определить, какие есть датчики в системе, и указать, показания каких из датчиков мы хотим увидеть в выводе команды sensors. С этим нам поможет утилита sensors-detect. Это интерактивная программа, запускаем ее на выполнение, читаем и отвечаем на вопросы. Рекомендуется оставить ответы по умолчанию (по умолчанию ответ Yes, просто нажимаем Enter)

Вывод дальнейший опущен, но, думаю, и так все понятно. Например, здесь был найден «Intel digital thermal sensor«, для которого необходимо будет догрузить драйвер coretemp.

В конце своей работы sensors-detect укажет, какие драйвера необходимы и предложит их добавить в /etc/modules, чтобы они автоматически подгружались при загрузке/перезагрузке системы. Соглашаемся. Но нужно проверить, есть ли у вас эти модули вообще.

Подгружаем недостающие модули

jc42 — не найден, скорее всего, нужно обновить ядро… jc42 нужен для считывания данных темературного сенсора ST STTS2002 DIMM. Обновиться я сейчас не могу, а какая температура памяти как-то не особо важно, поэтому просто уберу его с /etc/modules

Просмотр значений

Вывод всех значений:

Посмотреть значения датчиков в сыром неотформатированном виде:

 

Viel Spaß!

Monitord: Автоматический перезапуск демона

freebsd2В мире постоянно работающих систем с «слушающими» отзывчивыми демонами, бывает, случается неприятность — в силу каких-либо причин демон перестает быть отзывчивым и прекращает свою работу. В итоге получаем неработающий сервис. Неприятность может застать нас в любое время и в любом месте. И даже если предусмотрительно настроенная нами система мониторинга шлет  об этом тревожные письма и смс, побуждая к вполне закономерным действиям — сделать сервису start и разбираться, что случилось, — не всегда есть для того возможности. Банально, может не быть никаких «электронно-вычислительных машин» под рукой.

Делаем выводы с вышесказанного и решаем, что нужно «что-то», что будет следить за демонами и стартовать их автоматически, если те прикажут долго жить*. Кто-то для таких целей пишет свой скрипт и кидает его в cron, кто-то пользуется готовыми решениями, настраивая их под себя. Одним из таких решений и есть monitord — не самое лучшее, корявое, но, на мой взгляд, самое простое и лично мне подходящее.

 

Установка

На текущую дату — 07.04.2015 — порт monitord помечен как Broken:

Игнорируем этот факт и все-таки устанавливаем порт (запускаем make с ключом -D, устанавливая переменную NO_IGNORE):

 

После установки в системе появляются 3 файла:

  • /usr/local/etc/rc.d/monitord — стартовый скрипт;
  • /usr/local/sbin/monitord — бинарник;
  • /usr/local/etc/monitord.conf.sample — пример конфигурационного файла.

 

Структура конфигурационного файла

/usr/local/etc/monitord.conf.sample:

 

Одна строка в conf-файле отвечает за один сервис, и поделена на 6 столбцов:

  • user — от имени какого пользователя производить запуск;
  • options — как реагировать, если сервис потух:

auto —  запускать сервис автоматически;
alert — отсылать письмо на почту об инциденте (здесь у меня возникли проблемы, ниже опишу какие);
noauto — не запускать сервис автоматически (имеет смысл при указании этой опции вместе с опцией alert — т.е. просто для уведомлений);

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

  • delay — задержка запуска (секунды);
  • service — имя сервиса;
  • script — скрипт запуска сервиса;
  • parameters — аргументы, передаваемые скрипту запуска.

 

Настройка и запуск

Создаем или копируем с monitord.conf.sample конфигурацинный файл monitord.conf:

Например, для мониторинга apache24, по образу и подобию добавляем строку:

Добавляем monitord в автозагрузку и запускаем:

 

Проблемы с отправкой уведомлений

При использовании опции alert необходимо предварительно указать, через что эти алерты слать. Monitord предлагает указать только email получателя и MTA, который доставит alert-письмо этому получателю:

К сожалению, править какие-то другие заголовки для отправки уведомлений нельзя. И если уже с неменяемой темой и телом пиcьма смириться можно, то критично важно было бы отредактировать адрес отправителя, потому как сам Monitord туда подставляет следующее:

monitord-notification@www, где www — это у меня имя хоста.

А мой МТА настроен на проверку адреса-отправителя и получив от monitord такое вот письмо, отказывается его дальше передавать:

sender verify fail for <monitord-notification@www>: Unrouteable address

Лично для меня это не критично, поскольку уведомлениями занимается нагиос. Alert’ы я отключаю и пользуюсь только возможностью слежки за демонами и их автоматического старта/рестарта.

HDD: Smartmontools

! Работает с жесткими дисками, которые поддерживают технологию SMART !

smartmontools состоит из двух утилит:

  • smartctl — (Control and Monitor Utility for SMART Disks) — так сказать, интерактивная часть;
  • smartd — (SMART Disk Monitoring Daemon) — демон.

 

smartctl

Справка smartctl:

Сканировать и вывести список дисков и их тип:

Получить информацию о диске, такую как модель, серийный номер:

Краткая общая информация о здоровье диска:

Посмотреть всю информацию об устройстве:

Посмотреть всю SMART-информацию:

Посмотреть SMART-атрибуты диска:

 

SMART-тесты

Работа с тестами самодиагностики.

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

Запуск короткого теста (длится пару минут):

Запуск длинного теста (десятки минут, до часа):

Отменить тест:

Просмотр результата теста:

 

SMART-атрибуты

Поля атрибутов SMART

ID — идентификатор атрибута, однозначно определяет атрибут.
ATTRIBUTE_NAME — имя атрибута, расшифровка ID.
VALUE — текущее значение атрибута. Чем меньше — тем хуже. Измеряется в «попугаях». Сравнивается со значением TRESHOLD:

  • VALUE > TRESHOLD — диск считает, что он здоров;
  • VALUE < или = TRESHOLD  — бьем тревогу;
  • VALUE не достиг уровня TRESHOLD, но упорно уменьшается — атрибут деградирует — тоже пора задуматься о замене диска.

WORST — наихудшее значение VALUE атрибута за всю жизнь диска. Измеряется в «попугаях».
TRESHOLD — пороговое (критическое) значение VALUE для атрибута. Измеряется в «попугаях».
TYPE — тип атрибута:

  • Pre-fail — критичный
  • Old_age — некритичный

WHEN_FAILED — «когда выйдет из строя»:

  • «FAILED_NOW» — опасно;
  • » — » — с атрибутом все в порядке.

RAW_VALUE — реальное значение атрибута (не в «попугаях») — в зависимости от атрибута значение:

  • текущее (например, температура -Temperature_Celsius);
  • накапливающее (какой-либо счетчик, например, Power_Cycle_Count).

VALUE вычисляется исходя из RAW_VALUE по определенным алгоритмам, которые задает производитель.

Атрибуты SMART

* жирным шрифтом выделены атрибуты, требующие особого внимания

  • (1) Raw_Read_Error_Rate — содержит частоту возникновения ошибок при чтении с диска по вине аппаратной части накопителя;
  • (3) Spin_Up_Time — содержит время разгона шпинделя диска из состояния покоя до номинальной скорости (например, от 0 до 7200 об/мин);
  • (4) Start_Stop_Count — полное число запусков/остановов диска;
  • (5) Reallocated_Sector_Ct — содержит кол-во секторов, переназначенных диском в резервную область — операция Remapping — считаются только удачные попытки. Ключевой параметр в оценке состояния диска;
  • (7) Seek_Error_Rate — частота появления ошибок позиционирования БМГ; указывает на проблемы в механике диска;
  • (9) Power_On_Hours — число часов проведенных во включенном состоянии (накапливающий);
  • (10) Spin_Retry_Count — число попыток старта шпинделя диска, если первая попытка была неудачной;
  • (11) Calibration_Retry_Count — число попыток рекалибровки накопителя — сброс состояния диска и установка головок на нулевую дорожку;
  • (12) Power_Cycle_Count — число полных циклов включения-отключения диска;
  • (192) Power-Off_Retract_Count — для разных винчестеров либо суммарное кол-во парковок БМГ в аварийных ситуациях, либо суммарное кол-во включения-выключения питания диска (в WD, Hitachi);
  • (193) Load_Cycle_Count — кол-во полных циклов парковки БМГ;
  • (194) Temperature_Celsius — температура диска;
  • (196) Reallocated_Event_Count — кол-во операций переназначения — Remapping — учитываются удачные и неудачные попытки;
  • (197) Current_Pending_Sector — текущее кол-во нестабильных секторов — кандидаты на Remapping;
  • (198) Offline_Uncorrectable — параметр изменяется только при offline-тестировании, которое диск запускает при простое; содержит секторы-кандидаты на Remapping;
  • (199) UDMA_CRC_Error_Count — кол-во ошибок при передаче по интерфейсному кабелю в режиме UltraDMA от материнской платы контроллеру диска; Причины — некачественный шлейф, плохой контакт  в SATA-разъеме;
  • (200) Multi_Zone_Error_Rate — частота появления ошибок при записи данных;

 

smartd

Конфигурационный файл:

Автоматическое сканирование системы в поисках ATA и SCSI:

может запускаться с набором нужных директив, которые будут применены ко всем найденым дискам. Например:

Описание директив конфигурационного файла smartd можно найти в smartd.conf.sample и в ‘man smartd.conf’.

Многие люди предпочитают вручную указывать диски, которые хочется мониторить. Для этого необходимо закоментировать DEVICESCAN и указать диски.

Пример:

В данном примере указаны два жестких диска — ada0 и ada1. Используемые директивы:

-a Default: то же, что и набор директив «-H -f -t -l error -l selftest -C 197 -U 198»:

-H — мониторинг SMART Health Status, сообщает если статус FAILED;
-f  — мониторинг на ошибки (FAILED) любого из используемых атрибутов (поле SMART-атрибута WHEN_FAILED);
-t — то же, что и набор директив «-p -u»:

-p рассказывать об изменениях в «Pre-fail»-атрибутах;
-u рассказывать об изменениях в «Old_age»-атрибутах;

-l error — мониторить SMART-логи error;
-l selftest — мониторить SMART-логи selftest;

-C 197 — «197» — это ID атрибута — RAW_VALUE Current_Pending_Sector — сообщать при ненулевом значении;
-U 198 — «198» — это ID атрибута — RAW_VALUE Offline_Uncorrectable — сообщать при ненулевом значении;

-o on — enable автоматические offline-тесты;
-S on — enable attribute autosave;

-s (S/../.././02|L/../../6/03) — стартовать selftest’ы, когда выполняется регулярное выражение. В данном примере заданы несколько выражений, разделенных условием «или», поэтому ставим круглые скобки.

Регулярное выражение представляет собой следующую конструкцию:
T/MM/DD/d/HH
T — тип теста — Short, Long, Conveyance или Offline, MM — месяц, DD — день, d — день недели, HH — час.
S/../.././02 — запускать короткий (S) тест каждый день после 2-х часов ночи;
L/../../6/03 — запускать длинный (L) тест каждую субботу (день недели — 6) после 3-х часов ночи.

-I 194 — игнорировать изменения атрибута 194 — Temperature_Celsius;
-W 4,45,55 — мониторинг изменения температуры на 4 градуса, 45 — informal лимит, 55 — критический лимит;
-R 5 — отследить изменения в атрибуте 5 — Reallocated_Sector_Ct;

-m admin@provoip.in.ua — отправить warning email на admin@provoip.in.ua для -H, -l error, -l selftest, и -f

Другие директивы для smartd.conf:

* взято из /usr/local/etc/smartd.conf.sample

 

Sources:

man smartctl
man smartd.conf
http://www.ixbt.com/storage/hdd-smart-testing.shtml
http://rtfm.co.ua/s-m-a-r-t-proverka-hdd-opisanie-atributov-znachenie-atributov-utility-parametry/
http://www.wandmagic.ru/news/178.html
http://www.lexpr.ru/node/336