Вводная


Понадобилось мне поставить на мониторинг станции Avaya. С версией Communication Manager выше R16.0.141 проблем не возникло — там в SNMP все очень хорошо и прозрачно видно, в том числе статусы транков и внутренних номеров. Но вот с более ранними версиями — засада. А если учесть, что таких станций было более 30 штук, да и транков на каждой не менее 10-20 (а на некоторых несколько сотен) — задача оказалась малость нетривиальной. Но так как сделать все же надо — пришлось решать). Итак…

Постановка задачи


Что нам надо:

  1. Отловить отказ транка в течение 1-2 часов после падения
  2. Отловить массовый отказ внутренних номеров (отключение 10-20% внутренних номеров в течение 10-20 минут)
  3. Отказ любого из кабинетов либо появление ошибок на них
  4. Поймать выход из строя ключевых внутренних номеров (входящие группы, випы и пр.)
  5. Следить за состоянием DECT-баз, подключенных к станциям
  6. Ну и хорошо бы получить актуальную информацию о версии ПО на станциях, серийных номерах и прочем.

Что имеем из оборудования


  • Более 30 станций Avaya Aura версий от R13 до R16;
  • 10-300 транков разных типов (CO, E1, H323, SIP и т.п.) на каждой станции, транки добавляются или удаляются крайне редко;
  • 100-3000 телефонов на каждой станции. Есть как IP-аппараты, так и аналоговые и цифровые;
  • С каждой DECT-станцией работают от 5 до 100 DECT-баз. По моделям: Avaya DECT R3, Avaya DECT R4, Spectralink IP-DECT Server 6500 и Spectralink IP-DECT Server 6500
  • Linux-сервер, на котором развернуть zabbix
  • Все объекты доступны по сети

Подготовительные работы


Настроим zabbix-сервер


  1. Условимся, что сервер уже настроен на работу с SNMP и SNMPtrap;
  2. Настроим разбивку rsyslog по разным файлам и разрешим принимать ему сообщения с других хостов. Для этого отредактируем конфиг rsyslog.conf

    $UDPServerRun 514
    $InputTCPServerRun 514
    $template FROMHOSTIP,"%fromhost-ip%"
    $template FILENAME,"/var/log/rsyslog/%fromhost-ip%/syslog.log"

    а затем перезапустим rsyslog;

  3. Положим файлы trunk2type.sh, trunk2ip.sh, и trunk2alive.sh из архива в каталог externalscripts;

  4. Положим файл convert_trunks.sh в любое место и настроим его выполнение через cron раз в 10 минут.

Не забудьте поменять этих скриптах переменную PATH_TXT на актуальную.

Настроим Avaya Aura Communication Manager


Включим SNMP


  1. Зайдем браузером на веб-интерфейс Communication Manager
  2. В меню Administration > Server Maintenance > Alarms > SNMP Agent установим следующие параметры:

    1. Access from IP-addressess: Any или укажем IP-адрес Zabbix-сервера
    2. Включим SNMP Community v2 и установим имя read-only community в public
    3. Сохраним настройки.

  3. Применим настройки, перезапустив агента (Alarms > Agent Status)
  4. В меню Security > Firewall разрешим snmp и snmptrap (надо поставить обе галки напротив соответствующих служб)

Включим сбор статистики по транкам


  1. Запустим Avaya Site Administration, подключимся к станции и выполним команду:

    ch mea tru

    А затем укажем все номера транков, по которым надо собирать статистику. На версиях R13 и ранее количеств наблюдаемых транков ограничено 20 транками.

Настроим DECT-станции


Avaya DECT R3


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

  1. При включении SNMP укажем IP-адрес сервера Zabbix и комюнити public.
  2. Его же укажем Syslog-сервере. Порт 514.

Avaya DECT R4


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

  1. При включении SNMP укажем IP-адрес сервера Zabbix и комюнити public.
  2. Его же укажем Syslog-сервере. Порт 514. уровень логирования 4 (Warnings) или 3 (Errors).

Spectralink IP-DECT Server 400/6500


Настройки надо производить только на главной базе. Остальные базы подхватят эти параметры автоматически. При применении настроек SNMP база потребует перезагрузки!!!

  1. При включении SNMP укажем IP-адрес сервера Zabbix, и комюнити public
  2. Его же укажем Syslog-сервере. Порт 514. уровень логирования 4 (Warnings) или 3 (Errors)

Настроим Медиа-шлюзы


После захода через telnet или ssh на медиашлюз введем следующие команды:

snmp-server community read-only public read-write <rw community>
set snmp trap <IP-адрес>
set snmp community trap public

Формируем список транков


Для мониторинга транка нам понадобится следующая информация по каждому из транков:

  1. Номер транка
  2. Название транка
  3. Тип транка
  4. Количесто линий в транке
  5. Количество линий out-of-service
  6. IP-адрес дальнего конца транка

Все эти данные можно получить через SNMP, но в этом случае не получится связать номер транка с адресом его дальней ноды. Поэтому придется это сделать в ручном режиме. Для облегчения этой задачи мной был создан в Excel`е файл, формирующий нужный нам список по результатам выполнения тех команд из Avaya Site Administration. Процедура следующая:

  1. В Avaya Site Administration нажимаем Ctrl+R и делаем отчеты в файлы csv по каждой из трех команд:

    • li tru
    • li sign
    • li node-n a (на станциях ранее R15 эта команда выглядит как li node-n)

  2. Результаты каждой из трех команд импортируем в соответствующие листы файла Excel
  3. На листе Zabbix в результате мы получим нужную нам таблицу. Экспортируем ее в текстовый файл с названием avaya_node-names_<IP-адрес станции>.txt

Заведение узлов в Zabbix


В Zabbix заводим хосты станций, шлюзов и основных DETC-баз, прикрепляя к ним следующие шаблоны:

  • Станция Avaya Aura версии младше R16.0.141:

    • Template_Device_SNMP
    • Template_ICMP
    • Template SNMP AVAYA AURA PBX TRUNKS
    • Template SNMP AVAYA AURA PBX MG
    • Template SNMP AVAYA AURA EXTENSIONS (Если надо отдельно мониторить внутренние номера) Использовать с осторожностью — параметры внутренних номеров станция отдает очень неспешно!!!

  • Медиашлюзы G4xx, G3xx, G7xx. Обратите внимание: мониторинг шлюзов G6xx не поддерживается!!!

    • Template_Device_SNMP
    • Template_ICMP
    • Template SNMP AVAYA G3xx-G4xx-G6xx MEDIAGATE

  • DECT-базы R3 и R4 (можно заводить все базы — как основные, так и работающие в slave-режиме)

    • Template_Device_SNMPv1 (Да, эти станции держат только SNMPv1)
    • Template_ICMP
    • Template SNMP AVAYA IP-DECT R4

  • DECT-базы Spectralink IP-DECT Server 6500 и 400 (можно заводить только master-базы)

    • Template_Device_SNMP
    • Template_ICMP
    • Template SNMP Spectralink IP-DECT Server 6500_400

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

Заключение


Есть несколько моментов, на которые хочу обратить внимание:

  • На станциях R15 и по непонятным причинам может зависать SNMP-агент при четырех или более параллельных обращениях.
  • Шаблон Template SNMP AVAYA AURA EXTENSIONS очень медленно работает при подключенных 100 и более телефонах. Советую включать его для первичного сканирования внутренних номеров, а затем отключить все группы датчиков не ключевых номеров (допустим кроме випов или входящих).
  • По DECT-базам Avaya R3 и R4 крайне мало мониторинговой информации.
  • При добавлении транка на станцию надо повторно сделать действия описанные в разделе «Заведение узлов в Zabbix».
  • Анализ логов из rSyslog в данных шаблонах пока не реализован

Ссылки


Поделиться с друзьями
-->

Комментарии (16)


  1. sHaggY_caT
    03.01.2017 03:53
    +3

    а почему на гиктаймс, а не на хабр?


  1. dedyshka
    08.01.2017 22:00
    +1

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


    1. ansealk
      08.01.2017 22:06

      Зачем? Статья рассчитана на тех, кто знает, что такое zabbix, definity и проч. Начав плотно работать с распределенной Avaya выяснил, что готового решения мониторинга состояния станций, кроме родного от Avaya, нет. Если же у вас возникли вопросы — пишите, отвечу. А вот смысла опускаться до «мониториг Avaya средствами Zabbix для чайников» не вижу.


      1. sHaggY_caT
        08.01.2017 22:53
        +1

        Так и разместили бы на Хабрахабр :) Тут для Вас нет аудитории, даже среди комментаторов — например, я работаю с Zabbix, но не с Avaya (я по Asterisk'ам больше).

        Советую Вам спросить модераторов о возможности перенести статью на параллельный ресурс.


        1. ansealk
          09.01.2017 06:44

          А вот за совет о переносе — огромное спасибо. Воспользуюсь.


        1. Antinomy
          09.01.2017 07:27
          +1

          А не думали ли вы написать что-то по данной теме? Имеется в виду Zabbix + Asterisk. По Заббиксу статей хватает, по Астериску — тоже немало, а вот по такой связке не встречал.
          Сам как раз подхожу к необходимости вести мониторинг Астериска.


          1. ansealk
            09.01.2017 16:20

            Там на статью не наберется — включаем SNMPv3, agentX и юзаем шаблон. Описание это еще три года назад у себя на сайте размещал: http://www.ansealk.ru/wiki/doku.php?id=pbx_asterisk_cherez_snmpv3


            1. sHaggY_caT
              09.01.2017 16:42

              SNMPv3


              Зачем? Этот протокол придумали неЛюди :) Всё и без него работает, с помощью скриптов через плагины для агента.


              1. ansealk
                09.01.2017 16:44

                Дело в том, что часть параметров в v2 не отдается. А так, да — полностью согласен, v3 это еще то извращение.


                1. sHaggY_caT
                  09.01.2017 18:07

                  мне все его версии не нравятся. Я просто запускаю через агент свои скрипты на питоне и bash


                  1. ansealk
                    09.01.2017 18:14

                    Хм… тогда ваш вариант мне точно не подойдет: прописывать ручками датчики для полусотни очередей и сотни транков — это занятие не по мне. Именно поэтому у меня реализовано все на snmp: дискавери в заббиксе -это наше все)
                    Но как раз для случая работы с агентом писал вот такие статейки: http://www.ansealk.ru/wiki/doku.php?id=monitoring_pbx — там как раз есть мониторинг средствами баша.
                    Кстати, а не поделителсь своим шаблоном и скриптами? Интрересно глянуть было бы


                    1. sHaggY_caT
                      09.01.2017 18:25
                      +1

                      Хм… тогда ваш вариант мне точно не подойдет: прописывать ручками датчики для полусотни очередей и сотни транков — это занятие не по мне.


                      Если у Вас есть такая штука, как Puppet или Ansible, то это удобнее SNMP, и более… человекочитаемо. Вообще инфраструктура-как-код, ИМХО, очень хорошая идея, которая всё упрощает. Конфиг агента, плагины, и пр, генерируются динамически. Да и в принципе и вообще все конфиги всех серверов.

                      Кстати, а не поделителсь своим шаблоном и скриптами? Интрересно глянуть было бы


                      У меня Asterisk под старую версию Puppet. Что бы его выкладывать в опенсурс, нужно рефракторить и портировать на четвёртый паппет.


                      1. sHaggY_caT
                        09.01.2017 18:30

                        И Вы знаете, что в Zabbix есть автодискавери не для SNMP, да?


                        1. ansealk
                          09.01.2017 18:49

                          Знать-то знаю, но инертность мышления — штука серьезная) Привык кучу оборудования через SNMP мониторить — вот его и юзаю.
                          Плюс еще один момент есть — у меня уже наработана куча шаблонов на базе snmp под разное оборудование. Так что при появлении нового класса оборудования мне проще старый шаблон переделать, чем переписывать все заново.
                          Про Puppet посмотрю, может что для себя и найду, спасибо.


                          1. sHaggY_caT
                            09.01.2017 19:05

                            Про Puppet посмотрю, может что для себя и найду, спасибо.


                            Под эту парадигму нужно сразу переписывать всю инфраструктуру.
                            И эта парадигма хорошо ложится, если в компании разработчики работают по AGILE, что бы разрабатывать в одном ритме инфраструктуру вместе с другим кодом.


  1. ansealk
    09.01.2017 18:12

    .