trapmgr hp что это
Описание SNMP TRAP сообщений возникающих в процессе эксплуатации GPON
Сообщение об ошибке
Описание возникновения
Пользователем запущена команда на выполнение
Не удается связаться с ntp сервером
Пользователем запущено количество команд превышающих заданный порог
Изменилось состояние слота шасси.
Изменилось состояние слота шасси.
Состояние интерфейса изменено администратором
Напряжение питание вышло за допустимые границы
Индикатор LED error изменил состояние
Среднее кол-во пакетов приходящих на CPU превышает установленный порог
Закончена загрузка конфигурации. Наиболее часто возникает после перезагрузки системы
Конфигурация активного и запасного SFU отличается
Активация ONU не удалась
Попытка активации ONU с существующим номером
Обновление прошивки для ONU закончена
Деактивация ONU выполнена
ONU передает оптический сигнал дольше отведенного ей времени(скорее всего она не получает от OLT отведенного ей временного интервала)
Для моделей ONU оснащенных батареей
Возникновение на OLT аварии LOS(пропадание оптического линка)
Исчезновение аварии LOS
Источник питания пропал.
RX сигнал не обнаружен на SFU
Температура на ONU превышает заданный верхний предел
Температура на ONU ниже заданного нижнего предела
Загрузка процессора на ONU превышает заданный предел
Использование памяти на ONU превышает заданный предел
Zabbix snmp trap настройка
Сегодня расскажу о том, как настроить Zabbix для реакции на важные для нас snmp трапы. Если вы не знакомы с протоколом SNMP, с чем его едят можно узнать здесь. Что такое Zabbix можно почитать здесь. Ну а в двух словах, SNMP протокол служит для мониторинга и управления устройствами по сети. А Zabbix — программный комплекс для сетевого мониторинга.
Принцип работы SNMP следующий: в сети имеется устройство/хост (например cisco 2811), параметры которого мы хотим мониторить, и присутствует компьютер/сервер, с которого мы хотим мониторить. Возможны следующие действия: сервер отправляет SNMP запрос на cisco 2811 и получает SNMP ответ с интересующими его параметрами. Или можно настроить cisco 2811 так, что если на ней случается какое-либо событие (например интерфейс перешел shutdown, или кто-то изменил конфиг или ещё что-то (список возможных событий довольно велик)) то хост (cisco 2811) посылает серверу сообщение (SNMP trap) в котором говорится о наступившем событии.
Первый вариант удобен для мониторинга не критичных, постоянно меняющихся параметров, например, загрузка сетевых интерфейсов, температура и т.п. Для этого достаточно периодически, например раз в минуту, запрашивать эти параметры у хоста. А вот запрашивать каждую минуту состояние интерфейса, или BGP сессии, которая пожет упасть раз в месяц — решение не рациональное. В данной ситуации нам помогут SNMP трапы. Будем считать что Zabbix у вас установлен. Итак, приступаем к настройке.
Настройка SNMP на Cisco 2811
На циске выполняем следующее:
где:
Loopback 0 — интерфейс с которого доступен SNMP сервер,
10.1.1.10 ip адрес SNMP сервера,
нужный_вам_трап — например: snmp-server enable traps snmp authentication linkdown linkup,
или просто: snmp-server enable traps — включаются все доступные трапы.
MyCommunity — комьюнити (а-ля пароль) к SNMP серверу (если используется snmp v1).
Настраиваем SNMP сервер.
Смотрим, нет ли ошибок в /var/log/snmptrap.log, если нет, идём на циску и пытаемся инициировать событие, например погасить интерфейс. Смотрим, что появилось в /var/log/snmptrap.log и snmptrapmy.log.
У меня в snmptrapmy.log появилось следующее:
CISCO_HOST_NAME 10.1.1.5 linkDown Vlan10 «administratively down».
Vlan 10 — это имя интерфейса, который мы хотим мониторить.
Отлично! Трапы приходят! (Если ничего не пришло, проверьте свой файервол). Теперь настроим Zabbix.
Настройка Zabbix
В заббиксе создайте новый хост с ip-адресом 0.0.0.0 и с именем snmptraps. Добавьте его в любую группу, например Zabbix Servers.
Теперь создайте Item с такими параметрами:
Description: GetTraps,
Type: Zabbix trapper,
Key: snmptraps,
Type of information: Text,
Сохраните.
В разделе Item, хоста snmptraps, перед столбцом Description, появится столбец Log и маленькая иконка.
Щёлкните на ней, и выберите «Create Log Trigger».
Создайте триггер с такими параметрами:
Description: LinkStatus,
Item: GetTrap,
Expression: 10.1.1.5 linkDown Vlan10 (не забудьте нажать кнопочку add)
Severity: по_вкусу
Сохраните.
Теперь в Configuration->Actions создайте новый экшен на только что созданный триггер. Настройте его так:
Всё, можно проверять, погасите на циске интерфейс, и через некоторое время должен сработать ваш только что настроенный экшен.
Чтобы добавить реакцию zabbix на любой другой трап, воспроизведите это событие на хосте, посмотрите, что запишется в snmptrapmy.log на SNMP сервере, и укажите полученный OID в триггере zabbix. Как только zabix получит трап (который ему передаёт скрипт snmptrap.sh), он проверяет, есть ли в полученной строке указанный в триггере шаблон, и, если есть, то триггер срабатывает. Сработанный триггер вызывает привязанный к нему Action, который отправляет уведомление администратору о случившемся событии.
Если не работает:
Если трапы на SNMP сервере не логируются, выяснить в чём проблема можно отправив трапы вручную, с помощью программы snmptrap: на другом компьютере, установите программу snmptrap и выполните следующее:
Отправленный трап должен записаться в /var/log/snmptrap.log на SNMP сервере. Если его там нет, проверьте, запущен ли snmptrapd и как там дела с правилам вашего файервола и пингуется ли ваш SNMP сервер 🙂
Более подробно про настройку Zabbix можно почитать здесь.
для того чтобы, правильно светился hostname:
127.0.0.1 localhost
192.168.1.1 zabbix.local
10.10.10.1 Router-1
10.10.10.2 Router-2
10.10.10.3 Router-3
Спасибо kbish за дополнения.
User Tools
Site Tools
Table of Contents
3 SNMP трапы
Обзор
Получение SNMP трапов является полной противоположностью запросам к SNMP устройствам.
В этом случае информация отправляется с SNMP устройства и собирается или “ловится” Zabbix’ом.
Обычно трапы отправляются при наступлении некоторых условий и агент подключается на 162 порт сервера (в отличии от 161 порта на стороне агента, который используется для запросов). Использование трапов может помочь обнаружить некоторые кратковременные проблемы, которые происходят между интервалами опроса и могут быть пропущены при запросах данных.
Получение SNMP трапов в Zabbix рассчитано на работу с snmptrapd и с одним из встроенных механизмов передачи трапов в Zabbix – либо perl скрипт, либо SNMPTT.
Последовательность действий при получении трапа:
3.1 Настройка SNMP трапов
Настройка следующих полей в веб-интерфейсе является специфичной для этого типа элементов данных:
В поле Ключ используйте один из ключей SNMP трапов:
Укажите Тип информации равным ‘Журнал (лог)’ для обработки штампов времени. Обратите внимание, что другие форматы, такие как ‘Числовой’ также приемлемы, но для этого может потребоваться пользовательский обработчик трапов.
3.2 Настройка мониторинга SNMP трапов
Настройка Zabbix сервера/прокси
Для чтения трапов, Zabbix сервер или прокси должны быть настроены на запуск процесса SNMP траппера и должны знать абсолютный путь к файлу с трапами, который заполняется при помощи SNMPTT или получателя трапов Perl. Чтобы это сделать, измените файл конфигурации (zabbix_server.conf или zabbix_proxy.conf):
Настройка SNMPTT
Для начала, snmptrapd необходимо настроить на использование SNMPTT.
При конфигурировании SNMPTT на получение трапов, настройте SNMPTT на журналирование этих трапов:
Теперь отформатируйте трапы, чтобы они распознавались Zabbix’ом (измените snmptt.conf):
Настройка получателя Perl трапов
Требования: Perl, Net-SNMP скомпилированный с –enable-embedded-perl (компилируется по умолчанию начиная с Net-SNMP 5.4)
Получатель трапов Perl (ищите в misc/snmptrap/zabbix_trap_receiver.pl) можно использовать для передачи трапов в Zabbix сервер напрямую с snmptrapd. Для его настройки:
Формат SNMP трапа
Все пользовательские получатели трапов perl и конфигурация SNMPTT трапов должны форматировать трап следующим образом: [штамп времени] [трап, часть 1] ZBXTRAP [адрес] [трап, часть 2], где
Обратите внимание, что “ZBXTRAP” и “[адрес]” при обработке отрезаются из сообщения. Если трап форматируется как-то иначе, Zabbix может разобрать такие трапы неожиданным образом.
3.3 Требования к системе
Ротация журнала
Zabbix не предоставляет какую-либо систему ротации журналов – должно быть обработано пользователем. Ротация журналов должна начинаться с переименовывания старого файла и только после этого удалять его, чтобы никакие трапы не пропали:
Файловая система
Из-за реализации файла с трапами, Zabbix’у требуется файловая система с поддержкой inode для того чтобы различать файлы (эта информация берется из вызова stat()).
3.4 Пример установки
Этот пример использует snmptrapd + SNMPTT для передачи трапов Zabbix серверу. Установка:
Настройка WindowsUnix систем CISCO MIKROTIK VMWARE
Trap сервер позволяют информировать о состоянии сети – состояния интерфейсов, наличия проблем с ними или попытках подлома оборудования. Так же бывает полезен при разборе полетов. Обработку трапов будет осуществлять Zabbix и сигнализировать о наступлении события
Инсталляция Trap сервера
Настройка
Создадим файл /etc/snmp/cisco.conf со следующим содержимым
Правим файл /etc/snmp/snmptt.ini
После внесения изменений я перезапускаю все демоны
Подключение MIB файлов
Далее необходимо добавить расшифровку OID
Выяснять где хранятся MIB файлы
Просматриваем лог трап сервера и находим OID s, который не поддерживаются. Например, в логе такая запись
Осуществляем поиск необходимого MIB файла на сайте Cisco.com Можно воспользоваться другим источником или скачать с моего сайта одним архивом.
На сайте находим необходимый MIB по данному OID.
Загружаем все необходимые зависимости из таблицы
Таблица 1
| MIB Name |  | Version 1 | | Version 2 | | Dependencies |
| 1. SNMPv2-SMI | | Download | | | Download | | | View Dependencies |
| 2. SNMPv2-TC | | Download | | | Download | | | View Dependencies |
| 3. SNMPv2-CONF | | Not Required | | | Download | | | View Dependencies |
| 4. SNMPv2-MIB | | Download | | | Download | | | View Dependencies |
| 5. CISCO-SMI | | Download | | | Download | | | View Dependencies |
| 6. IANAifType-MIB | | Download | | | Download | | | View Dependencies |
| 7. IF-MIB | | Download | | | Download | | | View Dependencies |
| 8. CISCO-TC | | Download | | | Download | | | View Dependencies |
| 9. INET-ADDRESS-MIB | | Download | | | Download | | | View Dependencies |
| 10. SNMP-FRAMEWORK-MIB | | Download | | | Download | | | View Dependencies |
| 11. RFC1155-SMI | Non-Cisco MIB | | | Non-Cisco MIB | | | – | |
| 12. RFC-1212 | Non-Cisco MIB | | | Non-Cisco MIB | | | – | |
| 13. RFC-1215 | Non-Cisco MIB | | | Non-Cisco MIB | | | – | |
| 14. SNMPv2-TC-v1 | Non-Cisco MIB | | | Non-Cisco MIB | | | – | |
| 15. RMON-MIB | | Download | | | Download | | | View Dependencies |
| 16. CISCO-VTP-MIB | | Download | | | Download | | |
Далее необходимо подключить данные файлы в конфигурационный файл – /etc/snmp/cisco.conf, в том же порядке, каком скачивали, следующим способом
Все прикрепленые MIB фалы прописаны в /etc/snmp/cisco.conf. Можно скачать его или добавлять вручную
Весть каталог /etc/snmp/
MIB файлы одним архивом для Cisco
По отдельности
MIB файлы одним архивом для HP
По отдельности
MIB файл контроллера WLC
Cisco WLC MIB можно загрузить на странице Wireless Downloads (только для зарегистрированных заказчиков).
Чтобы загрузить MIB WLC, выполните следующие действия:
Настройка Zabbix на обработку трапов
Необходимо дописать данный материал
Настроим Zabbix на обработку трапов. Для этого включим ее в конфигурационном файле /etc/zabbix/zabbix_server.conf и укажем путь до файлов логов трап сервера
Дополнительная настройка требуется только триггеров, так как в шаблоне Template Net Cisco IOS SNMPv2
По умолчанию данная настройка принимает все трапы и привязывает их к узлу. В шаблоне необходимо скорректировать дату и привести ее к виду – hh:mm:ss yyyy/MM/dd
После этих настроек появляются данные в разделе General – SNMP traps (fallback). Данное условия собирается все трапы. Если необходимо ловить конкретные записис, то в скобках указываем искомое значение.
Создание триггера
Создание триггераОткрываем шаблон Template Net Cisco IOS SNMPv2 и создаем новый триггер
Добавим поиск строки, которую необходимо искать в логе. В данном примере указана ошибка авторизации
И сброс аварии по прошествии 600 секунд
Объединив их оператором AND. Должно получиться примерно следующее
Можно воспользоваться шаблоном zbx_export_templates
Настройка Cisco на отдачу трапов
snmp-server trap-source Vlan1
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps vrrp
snmp-server enable traps tty
snmp-server enable traps license
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
snmp-server enable traps flash insertion removal
snmp-server enable traps adslline
snmp-server enable traps adsl2line
snmp-server enable traps vdsl2line
snmp-server enable traps envmon
snmp-server enable traps c3g
snmp-server enable traps isdn call-information
snmp-server enable traps isdn layer2
snmp-server enable traps isdn chan-not-avail
snmp-server enable traps isdn ietf
snmp-server enable traps energywise
snmp-server enable traps cef resource-failure peer-state-change peer-fib-state-change inconsistency
snmp-server enable traps aaa_server
snmp-server enable traps atm subif
snmp-server enable traps memory bufferpeak
snmp-server enable traps config-copy
snmp-server enable traps config
snmp-server enable traps config-ctid
snmp-server enable traps entity
snmp-server enable traps fru-ctrl
snmp-server enable traps resource-policy
snmp-server enable traps event-manager
snmp-server enable traps hsrp
snmp-server enable traps ipmulticast
snmp-server enable traps msdp
snmp-server enable traps mvpn
snmp-server enable traps cpu threshold
snmp-server enable traps ipsla
snmp-server enable traps syslog
snmp-server enable traps l2tun session
snmp-server enable traps l2tun pseudowire status
snmp-server enable traps vtp
snmp-server enable traps pw vc
snmp-server enable traps firewall serverstatus
snmp-server enable traps nhrp nhs
snmp-server enable traps nhrp nhc
snmp-server enable traps nhrp nhp
snmp-server enable traps nhrp quota-exceeded
snmp-server enable traps isakmp policy add
snmp-server enable traps isakmp policy delete
snmp-server enable traps isakmp tunnel start
snmp-server enable traps isakmp tunnel stop
snmp-server enable traps ipsec cryptomap add
snmp-server enable traps ipsec cryptomap delete
snmp-server enable traps ipsec cryptomap attach
snmp-server enable traps ipsec cryptomap detach
snmp-server enable traps ipsec tunnel start
snmp-server enable traps ipsec tunnel stop
snmp-server enable traps ipsec too-many-sas
snmp-server host 192.168.1.251 informs version ВАШ_COMMUNITY
snmp-server host 192.168.1.251 version 2c ВАШ_COMMUNITY
HP Software — современный подход к построению системы мониторинга ИТ и бизнес-сервисов
Решения НР software позволяют увидеть редкие проблемы сети, те сетевые баги, которые чреваты последствиями. Мы можем увидеть все события, куда они могут вести, какими изменениями вызваны и т.д., — программа сама сопоставляет эти события и показывает слабые и проблемные места сети. С помощью этих инструментов мы можем увидеть сетевую проблему, еще до ее перехода в критическую фазу.
О том, как решение НР Software по аналитике позволяет выявить скрытые проблемы сети и бизнес-приложений и многом другом, под катом
Программные решения, как IT-менеджмент, представляют собой широкий спектр продуктов, который включает много интересных решений для автоматизации управления ИТ, автоматизации процессов, решения задач мониторинга, управления дата центрами.
Сегодня мы поговорим о решениях, предназначенных для мониторинга: мониторинга не только ИТ ‘железа’, а и бизнес-сервисов, то, что, собственно говоря, интересует бизнес.
Сейчас ни для кого не секрет, много компаний строят свой бизнес опираясь на IT. Руководителей мало интересует, что происходит с отдельным сервером, с отдельной ‘железкой’. Интересует, в первую очередь, качество предоставляемых сервисов, удовлетворенность клиентов, и возможность работы бизнес-сервисов на высоком уровне и таким образом обеспечивать непрерывную работу компании.
Соответственно, когда ухудшается наш сервис, (одно дело, если это внутренний клиент или внутренний пользователь, он может потерпеть немного), если же это клиент банка, телекома, или неважно какой компании, когда он сталкивается с плохим сервисом, что он делает? Он идет к конкуренту.
Таким образом, одна из основных задач такого рода мониторинга — это дать гибкий инструмент, который позволит связать те события, которые происходят в IT с состоянием бизнес-сервисов, возможность предсказать проблемы, возможность автоматизировать устранения проблемы для восстановления сервиса как можно быстрее и как можно качественнее. Следовательно, когда мы гарантируем нашим клиентам и заказчикам качественный сервис, они продолжают с нами работать, прибыли растут, мы захватываем все больше рынка, и выглядим красиво по сравнению с нашими конкурентами.
Что компания Hewlett-Packard предлагает для решения подобных задач? В общем, у НР достаточно широкий портфель, НР занимается решениями для мониторинга уже более 25 лет, начали с сетевого мониторинга, Network Node Manager, может быть кто-то об этом знает, потом был разработан целый ряд интереснейших решений, некоторые решения попали в НР за счет их покупки у других компаний, которые являлись лидерами в той или иной отрасли.
Решения НР Software
Если обобщить, то можно разбить предлагаемые решения на 4 категории:
Первый самый простой и понятный – инфраструктурный мониторинг (инфраструктурный менеджмент), здесь речь идет о мониторинге сетей, серверов, программного обеспечения, т.е. ИТ-ресурсов. В принципе, у многих компаний эти задачи уже решены коммерческими или бесплатными средствами. Например, Nagios, Zabbix используют Microsoft, поэтому мы не будем сейчас на этом останавливаться.
Речь пойдет больше о таких вещах, как Application Performance Management – это возможность выполнять комплексный мониторинг доступности приложений, и соответственно все, что под ним находится, мониторинг с точки зрения конечного пользователя, возможность диагностики проблем, которые находятся внутри application.
Далее Operations Bridge — непривычное название, Зонтик, зонтичная система мониторинга, которая позволяет объединить в себе данные мониторинга и самых разнообразных средств из имеющихся или новых, и создать единую консоль. Служба мониторинга – это консоль, которая предоставляет единое представление о том, как себя чувствуют сервисы, рассчитывается QPI, туда сваливаются все события, метрики производительности.
И Operations Analytics — это новейшая разработка HP, которая вышла на рынок чуть больше года назад, это решение, которое позволяет находить малоизвестные проблемы.
Когда мы говорим про традиционный мониторинг, мы знаем что мы хотим измерять, чаще всего знаем, каким должно быть пороговое значение, т.е. мы ищем те вещи, которые уже знаем, те сбои, которые ожидаемы. Например, известные события в логах, контролируем важные для нас параметры производительности или доступности сервисов, для которых тоже задаем пороговые значения.
На самом деле, в ИТ-инфраструктуре крупного предприятия происходит множество событий, которые не можем контролировать все. Когда мы говорим, допустим, о телефон-операторах, у которых количество логов растет гигабайтами в день, предусмотреть все возможные сценарии развития событий сложно, Operations Analytics использует методы обработки BigData, методы искусственного интеллекта для выявления нестандартных проблем, для поиска тех сбоев, которых не было раньше, нестандартных решений.
Платформа uCMDB
Прежде чем мы перейдем к рассмотрению этих продуктов, нужно сделать небольшое лирическое отступление, упомяну uCMDB — универсальная конфигурационная база данных, она является одним из ключевых компонентов не только для решений мониторинга, но и в других решениях для управления ИТ производимостью.
Итак, что она из себя представляет: это единая конфигурационная база данных, которая позволяет выстроить модели сервисов, объединив все компоненты, взаимосвязи, взаимные влияния, т.е. создать единую точку предоставления сервиса: из чего он состоит. uCMDB является связующим звеном между решениями мониторинга, если мы говорим про мониторинг, то на uCMDB, на отдельный объект мы можем «повесить» данные мониторинга и понять, как себя «чувствует» тот или иной сервис, понять взаимосвязь между компонентами. Когда мы строим интеграцию, например, с сервис-деском, у вас появляются дополнительные сущности, например, инциденты, проблемы, мы должны их «прицепить» к тем же самым объектам, когда мы говорим об управлении активами, с этими же элементами могут ассоциироваться финансовые составляющие, контракты, договора, стоимость этих активов и т.д.
Таким образом, uCMDB является одним из важных центров. И что важно, мы имеем возможность наполнять uCMDB автоматически, есть отличный метод безагентского дискаверинга, безагентского обнаружения отдельных компонентов инфраструктуры, связей между компонентами, например, мы можем подключиться к базе данных, посмотреть по логам, кто к ней обращался, и таким образом отстроить взаимосвязи между базой данных и ее клиентами. Или, например, когда мы говорим о стандартных приложениях: Active Diary, Microsoft Exchange, заложенный шаблон, мы уже знаем из чего состоит этот сервис, и нам остается обнаружить эти компоненты и простроить все необходимые взаимосвязи. Если есть какой-то сервис нестандартный, внутренней разработки, мы можем создать его модель, и он тоже будет дискавериться автоматически. Автоматический дискаверинг еще важен с той точки зрения, что, обычно, ИТ-инфраструктура современного предприятия очень динамическая, быстро меняется, и, если происходят какие-то изменения, нам нужно их тоже найти, обнаружить, чтобы uCMDB постоянно была up-to-date.
Например, в задачах мониторинга одной из важнейших вещей, которые мы решаем с помощью uCMDB — это корреляция событий. Topology Based Event Correlation — получая массу событий от различных объектов, мы понимаем, как компоненты инфраструктуры влияют на сервисы, соответственно, когда мы получаем поток событий, мы можем определить, какие инфраструктурные события влияют на какие сервисы, выявить причину и следствие этих событий.
Одно из представлений uCMDB: от уровней инфраструктуры, приложения до уровня бизнес-сервиса.
Давайте теперь перейдем более предметно к рассмотрению продуктов, и начнем с группы Application Performance Management. Это те продукты, которые позволяют настроить мониторинг сервисов в целом, понять насколько качественно он работает, работает ли, насколько быстро отвечает, насколько быстро выполняет те или иные функции.
По мнению Gartner, это те вещи, которые должны быть реализованы для решения задач мониторинга производительности приложений. В первую очередь нам нужно иметь возможность мониторинга с точки зрения конечного пользователя. Мы должны понимать, доступен ли сервис для пользователя, как качественно он работает, как быстро работает и работают ли все необходимые функции?
Мы должны иметь возможность отследить прохождение транзакций, когда пользователь выполняет какое-то действие, например, клиент-банк: проверка баланса, ушла транзакция, мы должны понять, куда она пошла, и какие процессы происходят внутри аппликейшин-сервера, и, если возникают какие-либо затруднения, мы сразу можем понять, где возникли эти затруднения. Это могут быть проблемы с приложением, может быть проблема с сетью или базой данных и т.д.
Если же проблема возникает с приложением, нам нужно иметь возможность выполнить глубокую диагностику, понять, что же внутри этого приложения происходит, где происходят задержки, где происходят потери транзакций. Снова же, нам нужно понимать, из чего состоят сервисы, это дискаверинг, автоматическое построение моделей. И конечно же, неплохо иметь возможность прогнозирования, выполнять аналитические задачи для того, чтобы решать нестандартные проблемы и понимать, чего нам ожидать в будущем, как наш сервис будет вести себя завтра или через неделю. Все эти задачи прекрасно решаются с помощью инструментов Hewlett-Packard. Здесь перечислены модули, которые покрывают эти задачи, мы сейчас их и рассмотрим.
User Monitoring
Начнем с мониторинга с точки зрения конечного пользователя. Это решение позволяет получить наиболее быстрый результат при небольших усилиях. Здесь у нас есть два подхода, лучше всего, конечно, их использовать вместе, но возможно и по-отдельности. 1-й вариант – это эмуляция действий пользователя, когда мы под видом реального человека подключаемся к системе, выполняем типичные действия, и смотрим, как они отрабатываются. 2-й вариант – мониторинг активности реальных пользователей, когда мы берем, допустим, систему трафик, содержащий элементы транзакций, как правило, данные берутся из коммутатора, который ближе всего находится к аппликейшн-серверу. Мы копируем трафик и настраиваем его разбор и видим запросы пользователя и видим ответ аппликейшна так мы мониторим доступность сервис-приложений для конечных пользователей.
Давайте посмотрим, как это работает. 1-й вариант – это эмуляция действий и активности пользователя. Здесь используется инструмент View Jam, возможно, знаком, способ создания эмуляции действий пользователя. Когда берем, например, консоль, говорим View Jam, что сейчас мы с этой консолью будем подключаться к таким приложениям по таким протоколам. Он перехватывает все наши запросы, все ответы приложения, превращает эти данные в скрипт. Потом мы это параметризуем, допустим, чтобы он соединялся под разными пользователями или выполнял разные типы запросов. Дальше используем этот скрипт, нам уже не нужна консоль приложения, все эмулируется на сетевом уровне, мы можем расставить пробы в любом количестве офисов, внутри нашей сети, и даже вне, и выполнять из этих проб с заданной периодичностью заданные действия. Выбираем необходимые локации, задаем перечень тех действий и транзакций, которые мы хотим проверять, и на выходе имеем консолидированное представление, где показывается из каких локаций происходит подключение, как быстро отрабатываются те или иные транзакции, в одном офисе, другом, третьем, четвертом…
Таким образом, мы видим, как наши системы и сервисы работают в тех точках, где они наиболее важные. В принципе, этот механизм наиболее оптимален для расчёта сулей, поскольку здесь мы сравниваем подобное с подобным. Мы имеем постоянно замеры доступности и производительности приложений по однотипным транзакциям, таким образом легко рассчитать качественный сулей. Этот механизм очень хорош для контроля доступности сервиса, допустим, в нерабочее время, когда реальных пользователей нет, а мы хотим быть уверенны, что наш сервис все так же доступен, например, начался рабочий день в банке, человек пришел, посмотрел, что все необходимые типы транзакций отрабатываются, может спокойно идти пить кофе и не бояться, что сейчас начнут звонить пользователи и что-то у них будет работать не так.
Вопрос: Сколько пользователей может эмулировать максимально?
Неограниченно, как настроите. Тот же механизм используется и для нагрузочного тестирования – weblearn скрипты, у нас есть инструмент LoadRunner. Если нужно сделать нагрузку, можно использовать LoadRunner, а он будет генерировать хоть десятки тысяч одновременных пользователей, поскольку это все делается на сетевом уровне, на уровне протоколов обмена данными, нам не нужна консоль, это очень легкое решение. BPM (Business Process Monitor) хорош тем, что простой в настройке, его можно поставить как stand alone решение, быстро настроить типовые транзакции и, даже не ставя под мониторинг компоненты инфраструктуры, уже понимать, как чувствуют себя наши сервисы, например, показать бизнесу реальное состояние и качество работы наших сервисов.
Он поддерживает огромное количество протоколов, базы данных, аппликейшн-сервера, веб-интерфейсы, толстый и тонкий клиенты, даже для DOS-приложений можно использовать, такого рода мониторинг, для очень устаревших. В Белоруссии в одном из банков пилотировали, у них старое приложение, не проблема даже для этого настроить.
Второй метод, о котором мы говорили – это мониторинг реальных действий пользователей, Real User Monitor, когда мы берем из сетевого трафика или из браузера, из аппликейшн-сервера необходимый сетевой трафик, здесь настраивать не так просто, поскольку нужно поработать с парсинг-трафиком, чтобы выявить элементы тех или иных транзакций, многие вещи делаются автоматически, недавно был пилот в одном из банков: запустили в рум трафик, настроили автоматическое выявление разных типов запросов, и он начал сразу же показывать, что одни запросы обрабатываются быстро, другие обрабатываются полторы минуты. Дальше уже более глубокая настройка,
Что здесь интересно: здесь можно понять, например, для какого конкретно пользователя существует проблема? Если в запросе выявляем пользователей, можем посмотреть, что у какого-то пользователя начались проблемы, можем ему позвонить, сказать ему: “Здравствуйте, мы знаем, что у вас есть проблема, мы над этим работаем, не беспокойтесь, через полчаса все заработает!”
Даже такой уровень сервиса можно сделать с подобными решениями. Здесь же можно делать снепшоты запросов. Когда мы видим, например, информацию об ошибке, какой-то сбой, мы можем снять снепшот, и можем знать, что видит пользователь, конкретную ошибку он видел, и нам не нужно с ним долго общаться по телефону, выяснять, какая проблема у него возникла, собственно, она уже у нас перед глазами.
Средствами диагностики мы можем заглянуть внутрь и понять, что конкретно происходит: пошла транзакция, мы понимаем, какие методы используются, какие функции используются в этом приложении, и можем понять сколько времени занимает обработка того или иного запроса, видим внешние вызовы, вызовы базы данных, видим утечки памяти, можем вплоть до места в коде указать, где кроется проблема, если это внутренняя разработка, если вы тесно сотрудничаете с поставщиком ПО, можно показать ему record ткнуть ему пальцем и сказать: «Вот здесь у вас проблема, решайте».
Если это Oracle, с Oracle мы не так глубоко копаем, но с Oracle тоже можем снимать данные коллектора, коллектор позволяет снять безагентским способом данные и смотреть, что происходит с базами, то есть, Oracle тоже подключается прекрасно.
Сопоставление работы пользователей и компонентов сети
Еще один аспект, который мы не упомянули – это влияние сети. Если мы хотим контролировать то, как влияет работа сети, сетевого оборудования, загрузка канала связи на наши сервисы, то можем использовать Network Node Manager, он также тесно интегрируется в нашу платформу, позволяет понять, чем грузятся каналы, как работа сети или состояние того или иного оборудования и даже изменение конфигурации этого оборудования влияет на работу и доступность наших сервисов.
Таким образом, BSM (Business Service Manager) позволяет создать единое консолидированное представление содержащее информацию о том, какие у нас сервисы используются, как они себя чувствуют, как себя чувствуют отдельные компоненты. Этот портал хорошо кастомизируется, в принципе, под каждую конкретную роль можно создать одно или несколько представлений. Пользователи, конечно, ограничиваются теми сервисами, за которые они отвечают и теми инструментами, которые для них доступны, даже рядовой пользователь сам для себя, используя простой графический конструктор, может набросать то представление, которое ему интересно. Или же можем для наших пользователей создать ряд представлений, которые будут использоваться для решения тех или иных задач.
Operations Bridge
Следующая тема, о которой мы поговорим – это Operations Bridge/Зонтик. Представим, что у нас уже теми или иными способами решена задача мониторинга, мы мониторим сеть, мониторим системы хранения и передачи данных, программное обеспечение, и делаем это все разными инструментами. HP не HP – не важно.
Но у нас нет единой консоли, которая показывает работу всех сервисов в одном окошке. Для того, чтобы решить эту задачу, предлагаем использовать Operations Bridge, которая берет события, берет информацию о топологии приложений из самых разнообразных систем, объединяет это все в единой консоли и позволяет коррелировать все эти события для того чтобы выявить причины, симптомы.
Например, пользователь заходит на интернет-банкинг, пытается выполнить какую-то транзакцию – у него не получается. Не получается потому, что база данных сбоит, а сбоит потому что не удалось расширить дисковые пространства на дисковых массивах. Т.е. проблема, которая нас беспокоит – это недоступность или некачественная работа интернет-банкинга, а причина кроется где-то далеко в СХД. Operations Bridge как раз позволяет объединить, скоррелировать все эти события, используя интересные методы корреляции: во-первых – это Topology Based Event Correlation, когда мы имеем uCMDB топологию сервисов, и в зависимости от того, с какими компонентами связан тот или иной сервис, можем понять как влияют те или иные события на его доступность. Поскольку модель uCMDB у нас динамичная, что-то поменялось – изменяя дискаверинг, автоматически перестраиваются правила корреляции. И второй метод — Stream Based Event Correlation, когда по времени возникновения тех или иных событий, мы можем предположить, что они связаны между собой, а также выявить, что является причиной и следствием.
Таким образом можем объединить в единой консоли все события, объединить все QPI, которые нас интересуют, и сделать эту консоль центральной системой мониторинга. Когда нам уже нужна более детальная информация, можем углубиться в ту систему, из которой мы получили эти данные мониторинга.
Что еще интересного позволяет делать Operations Bridge – автоматизировать настройки мониторинга при помощи средства Monitoring Automation, встроенного в Operations Bridge. Он позволяет, например, создавать типовые настройки мониторинга для тех или иных сервисов.
Например, добавилась у нас БД Oracle, можем автоматически направить, поставить под мониторинг с использованием типовых и стандартных шаблонов. Или же изменилась топология сервисов, переехал он на другую платформу, другой гипервизор – изменить правила мониторинга, чтобы система мониторила именно то, что сейчас происходит, не что происходило неделю назад.
И, конечно же, отчетность. В Operations Bridge входит Service Health Reporter, который позволяет объединить метрики из различных систем и строить консолидированные отчеты, снова же, с привязкой к бизнес-сервисам, к дежурным сервисным моделям. Что-то поменялось – отчеты, следовательно, тоже будут автоматически перестраиваться. В коробке большое количество, около тысячи, различных отчетов, и соответственно, можно создавать свои.
Operations Analytics
И третья вещь, о которой хотели поговорить: Operations Analytics. Как я уже говорил, когда мы используем традиционные средства мониторинга, мы знаем, что хотим мониторить, самих событий происходит значительно больше, чем мы можем предугадать, на гигабайты логов, которые у нас хранятся, или на огромное количество данных производительности было бы неплохо иметь возможность их всех объединить, нам нужно интеллектуальное и умное средство для работы со всей этой информацией, чтобы выявлять нестандартные ситуации. Operations Analytics использует технологию BigData, так, например, в качестве базы данных используется вертика (слышали про вертику?). Расскажем в двух словах.
Что Operations Analytics делает? Мы на него направляем все логи, все данные производительности. Все эти данные приводятся к единому формату. Operations Analytics позволяет хранить все логи, данные производительности и позволяет строить временную корреляцию между событиями, позволяет посмотреть на то, как чувствовал себя сервис в любой момент времени.
Механизм машины времени позволяет перемотаться в тот момент, когда происходил сбой и посмотреть, какие события происходили в этот момент, какие, например, были показатели производительности, загрузки каналов, и т.д. и определять тенденции, строить прогнозы по состоянию наших сервисов.
Архитектура: Vertica
Если посмотреть на архитектуру решения, она состоит из следующих вещей: для хранения данных используется Vertica – это БД, предназначенная для работы с большими данными, позволяет загружать огромное количество информации, обладает колоссальной масштабируемостью. Vertica интересна тем, что она создана для того, чтобы работать на дешевом оборудовании, она работает на х86-серверах, данные хранит на встроенных дисках и позволяет получать, практически, линейный прирост производительности при масштабировании. Было у нас, допустим, 3 сервера, мы их увеличили до 6, производительность вырастает вдвое и так, в общем, без ограничений. Например, Вертику использует Facebook c их колоссальными объемами данных,
Для сбора данных, работы с логами мы предлагаем с OpsAnalytics использовать ArcSight Logger. Это решение родом из информационной безопасности. ArcSight Logger хорош тем, что уже имеет массу коннекторов к самым разнообразным системам, уже умеет изначально собирать самые разнообразные логи и позволяет писать коннекторы для тех систем, к которым у нас их нет. Построена аналитическая настройка и есть связь с data sources, т.е. это система мониторинга НР или не НР, которая позволяет грузить туда события, метрики и т.д. Таким образом, мы в одной системе объединяем данные мониторинга, из систем мониторинга объединяем логи, и можем делать интересный анализ при помощи этого инструмента. Простая, понятная и очень производительная система.
Изначально Vertica лицензируется по объемам загружаемых в нее данных. Не важно сколько серверов. В комплекте с OpsAnalytics Vertica на 4Тб. Если этого объёма мало, тогда нужно дополнительно покупать лицензию Вертики.
Когда мы говорим про мониторинг логов тем же самым Conection Manager, агентом системы мониторинга, который выискивает заданные события, обработка логов может производится на самом объекте мониторинга. Мы периодически смотрим лог-файлы, когда видим нужное событие, отсылаем в систему. А здесь он работает по-другому. Здесь мы забираем полностью все логи в онлайн режиме и их разбор уже происходит уже на стороне OpsAnalytics. Т.е. здесь немного другого рода нагрузка. Если система мониторинга, тот же BPM, будет мониторить транзакции, то в сторону OpsAnalytics уйдет конкретная информация по транзакциям. Для того, чтобы объединить все это с информацией в логах, и посмотреть, какие события в логах могли вызвать сбой или ухудшение качества сервиса.
ArcSight Logger – это хороший выбор с точки зрения сбора логов, поскольку это решение уже не один год на рынке, уже существует масса коннекторов к разнообразным системам, есть удобный инструмент разработки своих коннекторов, чтобы два раза не изобретать велосипед, логи как раз и используются для сбора данных. Если вам нужно, можно использовать спланк.
Таким образом, что мы получаем? Получаем возможность выявления событий в логах, которые влияют на работу и производительность наших сервисов. Например, мы увидели ухудшение времени доступности сервиса, автоматическая система позволяет выявить те события в логах, которые могут быть причиной этого. Система выявляет новые, нестандартные события, предоставляет удобный инструмент для работы с логами, т.е. по контекстному поиску, — хороший механизм поиска, когда набираем отдельные элементы, поиск похож на человеческий язык. Она позволяет прогнозировать поведение наших сервисов в зависимости от того, как ведут себя те или иные компоненты, и позволяет, например, объединить данные ИТ-мониторинга с “неайтишным” мониторингом.
Как один из примеров, банк в одной из Европейских стран имел широкую сеть, в том числе и в горной местности, и у них периодически наблюдались непонятные ухудшения работы их сервисов в определенных регионах, они не могли определить причины возникновения. Кто-то додумался прикрутить в аналитику еще данные о погоде, и выявили стойкую взаимосвязь между состоянием окружающей среды, ветром, осадками и сбоем. Соответственно, нашли те места, которые и страдали от плохой погоды.
Интересный инструмент в аналитике – это машина времени. Вы видите вверху временную консоль. Система позволяет перемотаться в любой момент времени на временной консоли, а внизу будет отображаться то, как себя чувствовал сервис в данный момент времени, какова была производительность по определенным его функциям и какие события происходили в логах в тот момент времени, который нас интересует. Таким образом можем перематывать фактически в реальном времени, видеть, как изменялось состояние сервисов, какие события происходили, как менялись те или иные параметры производительности. Все эти данные хранятся в вертике и мы в реальном времени получаем из нее интересующие нас данные.
Одна из основных задач – это работа с большим количеством логов и выявление тех событий, которые либо являются причинами, либо потенциальными причинами сбоя. Мы выгрузили туда гигабайты логов, а на выходе имеем лишь несколько событий, которые система посчитала потенциально важными или потенциально важными для работы сервиса.
Небольшое демо (из доклада)
Оператор получил информацию по определенным транзакциям, есть у нас ненормально большой респонс-тайм. Открылась консоль, где показывается респонс-тайм, соответственно, красный – традиционно плохой. Общее состояние сервиса и метрики по определенному компоненту, например, Application Performance Overtime, и финансовые метрики, не имеющие прямого отношения к ИТ.
Такой вот флешбек позволяет управлять воспроизведением, и мы можем управлять воспроизведением, перемотаться в прошлое, посмотреть, как изменялись эти показатели, как менялись респонс-тайм транзакций и как чувствовал себя сервис и информацию по другим метрикам. Нашли момент, когда все работало хорошо, с этого момента стало плохо, нажали паузу, перематываемся, и можем смотреть влияние системных ресурсов на этот сбой, а также события логов, при этом, конечно, отображаются не все события, а только те, которые система посчитала важными. Из 93 тысяч логов событий у нас осталось 20, которые потенциально могут влиять на появление этой проблемы. Смотрим на этот лог, видим, это событие, можем нажать ок, чтобы в следующий раз это событие конкретно выискивалось.
Проблема оказалась в неправильной конфигурации лоджика. Это оператор догадался по типу ошибки. Можем добавить информацию о Transaction Performance Overtime к финансовым метрикам, которые здесь отслеживаются для того, чтобы выявить взаимосвязь. и предлагает нам скоррелировать эти события. Вот, нагрузили ему несколько метрик и предлагает скоррелировать. Здесь мы видим связь между показателями. Очень видимая связь наблюдается между Application Transaction Response Time и количеством отдельных пользователей, количеством пользовательских подключений.
В общем, мы видим, что конфигурация веблоджика влияет на те или иные показатели.
Вернулись снова в текущее положение, теперь на предлагает нажать на Predict и посмотреть, как мы ожидаем развитие событий.
Это настроенный дашборд для мониторинга Advent Rebanking – онлайн-банкинг, данные берутся оттуда. Изначально это предконфигурированный дашборд, мы набросали те метрики, за которыми следим, и те объекты, которые нам интересны.
Мы смотрим на нетипичные события, если что-то стало проявляться нетипично, нестандартно, значит нам это потенциально интересно. Если же написан error, тоже наверняка интересно.
Запись доклада