Ключевые слова:snmp, monitor, (найти похожие документы)
From: Max <max[nospam]asmi[dot]spb[dot]ru>
Newsgroups: email
Date: Mon, 22 Oct 2005 14:31:37 +0000 (UTC)
Subject: Основы работы с SNMP traps
Оригинал: http://www.asmi.spb.ru/faq/snmp-traps-i/
SNMP traps и с чем их едят
В этой статье я хочу осветить вопрос работы с SNMP traps. В то время,
когда я начинал разбираться с этой темой, при неплохом знании
принципов работы протокола SNMP, я был удивительным образом перепутан
результатами чтения документации по этому вопросу, всеми этими OID,
которые нужно писать как параметры для команды snmptrap. Поиски
внятной информации в интернет не дали результатов. Создавалось
впечатление, что я один такой непонятливый среди тех, кто считает это
элементарным.
В своей работе я использую пакет NetSNMP с открытым исходным кодом и
поэтому, примеры относятся именно к этому пакету.
Я не буду останавливаться на описании дерева SNMP (считаю это
действительно банальным), а начнем с пресловутого OID. OID это просто.
OID, это Object ID, уникальный идентификатор объекта в дереве значений
SNMP. OID может записываться в нескольких видах.
1. Числовой. Например, 1.3.6.1.4.1.2021. Самый простой вид, по
причине полного отсутствия каких либо трансформаций программным
обеспечением. Именно в таком виде SNMP "думает".
2. Текстовый, с использованием MIB файлов. Понятно, что дикие цифры
OID запомнить категорически невозможно, поэтому с помощью MIB
можно вводить текстовые мнемонические имена для более простого
вспоминания и использования идентификаторов. Кроме того, текстовая
запись позволяет избежать написания OID от корня дерева SNMP.
Уникальные мнемонические имена уже содержат путь до необходимого
узла дерева. Отсюда возможны записи вида enterprises.ucdavis.
Так как уникальность мнемонического имени в пределах всех возможных
MIB никто не гарантирует и не всегда сразу вспомнишь к чему относится
имя (например prTable), существует следующая, на мой взгляд самая
приятная форма записи: UCD-SNMP-MIB::prTable. В таком формате, кроме
самого имени указывается имя MIB (можно сказать, это пространство
имен)
Единственным ограничением использования MIB является то, что при
использовании программного обеспечения SNMP от разных производителей и
различного железа необходимо единое "понимание" этих волшебных
трансформаций. Поэтому на сайтах производителей управляемого
оборудования есть файлы описания MIB для конкретных устройств.
С представлением OID разобрались. Теперь про трапы. Сразу оговорюсь,
что все нижесказанное относится к версии 2с SNMP.
В протоколе SNMP есть трапы (traps) и есть информы (informs).
Отличаются они тем, что трапы посылаются на станцию менеджера без
гарантии их доставки, а информы гарантированно доставляются. Ну, или
не доставляться, но тогда отправитель об этом узнает. Для простоты, я
и то и другое называю трапом. Так нам будет проще.
Какая информация посылается менеджеру в трапе (информе)? А посылаются
следующие данные:
* Uptime устройства в виде пары: стандартный OID uptime, значение
* OID, который говорит о том, что за событие приключилось. В MIB
файлах есть специальные описания некоторого количества стандартных
событий, вроде запуска или остановки агента. Также, мы можем
определить собственные trap OIDs и даже описать их в собственном
MIB файле.
* Любые пары OID и его значение (там еще есть и третье поле "тип
значения", но это нам побоку), которые могут дать дополнительную
информацию. Например, когда свитч посылает трап "Падение линка",
дополнительное поле будет содержать информацию OID интерфейса, с
которым приключилась неприятность -- IF-MIB:ifIndex.2.
Теперь, наше повествование разделяется на направления. Первое
направление: "Как нам послать SNMP trap ручками из командной строки".
Второе направлении "Как нам заставить агента SNMP посылать трапы когда
что то идет не по плану".
Посылаем руками
Допустим, нам хочется послать сообщение менеджеру о том, что демон
net-snmpd запустился и передать дополнительную информацию о размере
swap файла и все это ручками ??? Ну пришла нам такая блажь. Допустим.
Пишем:
snmpinform -c public -v 2c host.sample.com "" ucdavis.ucdTraps.ucdStart memTotalSwap i 1024000
Что здесь что ?
* "" - брать uptime по дефолту
* ucdavis.ucdTraps.ucdStart - послать этот трап
* memTotalSwap i 1024000 - добавить в нагрузку OID memTotalSwap
равное целому 1024000
И если на целевом хосте запущен демон snmptrapd, то в логе появится
сообщение о приходе трапа.
Однако, иногда хочется странного, например послать трап о том, что
инопланетяне тырят SCSI винчестеры прямо из корзинки или о том, что
серверную заливает водой, о чем вас предупредительно оповестил
самодельный датчик, которые весит на COM порту. Понятное дело, в
стандартных MIB о таких странных ситуациях не упоминается. Поэтому,
можно использовать произвольную последовательность цифирек для
обозначения нового в мире события. Например:
snmptrap -c public -v 2c 127.0.0.1 "" 1.3.3.3.3.3.3.3 1.2.2.2.2.2.2 s "Aliens opened the door"
И что характерно, это будет работать. В логе появится такая
бредятинка:
Nov 22 14:08:24 snmptrapd[465]: localhost [127.0.0.1]: Trap ,
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (736247) 2:02:42.47,
SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::org.3.3.3.3.3.3,
iso.2.2.2.2.2.2 = STRING: " Aliens opened the door"
В то же время, крутые администраторы должны все делать правильно,
самодокументируемо, в соответствии с требованиями IETF и других
компетентных организаций. Поэтому, будем описывать наши новые OID в
своем собственном MIB файле.
ALLIENSATTACK-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY,
Integer32, Opaque, enterprises, Counter32
FROM SNMPv2-SMI
alliensattack MODULE-IDENTITY
LAST-UPDATED "200209050000Z"
ORGANIZATION "XCom"
CONTACT-INFO
"Planet Earth"
DESCRIPTION
"MIB for preventing aliens to stole our SCSI disks"
::= { enterprises 10050 }
attackTraps OBJECT IDENTIFIER ::= { alliensattack 1 }
attackStartTrap NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Notify about start of attack"
::= { attackTraps 1 }
attackStopTrap NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Notify about time to leave our hideouts"
::= { attackTraps 2 }
attackSource OBJECT IDENTIFIER ::= { aliensattack 2 }
attackFromDoors OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Sent to manager when attack starts from doors"
::= { attackSource 1 }
attackFromWindows OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"May be alliens are innocent? And SCSI drives disappeared in the Gates?"
::= { attackSource 2 }
END
Здесь определяется enterptise с номером 10050 и ему даеся имя
aliensattack. После этого вводятся две ветки: одна для трапов (начало
и конец атаки), другая для OID дополнительной информации (атака через
двери или это вовсе не инопланетяне).
Скажу честно, в формате MIB файла я понимаю мало. Поэтому внимательно
изучив MIB файлы из стандартной поставки net-snmp, я сделал этот
пример который работает, но кристальной ясности во всех его ключевых
словах я не достиг.
Дальше! Укладываем этот файл с именем ALLIENSATTACK-MIB.txt в какой
нибудь каталог поближе и запоминаем, что с этого момента все программы
имеющие отношения к SNMP (snmpd, snmptrapd, snmpinform) мы запускаем с
поддержкой этого MIB. Тоесть, к командной строке добавляем параметры
-М каталог/с_файлом -m +ALLIENSATTACK-MIB.
Знак "+" перед именем MIB (не файла с MIB, а именно имя MIB), значит,
что MIB будет добавлен к загружаемым по умолчанию.
Посылаем автоматически
Способ #2. Пишем скрипт, который проверяет системные параметры и
посылает трап на станцию менеджера. Пишется на shell, perl или на
любом известном языке.
Способ #1. Наиболее интересный. В 5-й версии net-snmp появиласть
поддержка модуля DISMAN-EVENT-MIB котрый умеет отсылать сообщения при
некоторых условиях. Но это уже другая история.
> Создавалось впечатление, что я один такой
> непонятливый среди тех, кто считает это
> элементарным.
У меня такое же ощущение. Передо мной стоит задача написать агента для нашего девайса, который бы реализовывал MIB. Так вот хоть убей не как не могу разобраться в каком месте и в какой момент нужно обновлять таблицы, что бы по запросу выдавались актуальные значения.
Огромная просьба к автору, что бы продолжил цикл статей об SNMP.
В версии net-snmp 5.6 строку импорта надо скорректировать на
IMPORTS
OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, Integer32, enterprises FROM SNMPv2-SMI;
иначе будет ошибка с получением OID непонятная.
