Глава 21

Системный мониторинг и журналирование

Хаос присущ всем сложным вещам.

Стремитесь с усердием.

– Будда

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

logger.conf

При устранении неполадок в системе Asterisk, вы найдете очень полезной возможность обратиться к записям истории о том, что происходило в системе в момент появления проблем. Параметры для хранения этой информации определяются в /etc/asterisk/logger.conf.

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

Файл /etc/asterisk/logger.conf позволяет вам определить различные уровни журналирования для многих файлов, если нужно. Он обладает великолепной гибкостью, но это может привести к запутанности.

Формат записей в файле logger.conf следующий:

filename => type[,type[,type[,…]]]

Это простой файл logger.conf, который идет с исходниками Asterisk, но не стоит просто копировать файл примера, мы рекомендуем использовать следующее в вашем начальном файле logger.conf:

[general]

[logfiles]

console => notice,warning,error,dtmf

messages => notice,warning,error

;verbose => notice,warning,error,verbose

После сохранения файла, вам нужно перезагрузить logger используя следующую команду из оболочки:

$ asterisk -rx ‘logger reload’

или из Asterisk CLI:

*CLI> logger reload

Детализация журналирования: полезна, но опасна

Мы боролись с желанием рекомендовать добавление следующей строки в ваш logger.conf:

verbose => notice,warning,error,verbose

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

Используйте это. Это фантастика. Но помните, что это нужно отключить после завершения!

Вы можете указать любое имя файла, но специальное имя файла console фактически будет производить вывод в Asterisk CLI, а не в любой файл на жестком диске. Все остальные имена будут храниться в файловой системе в каталоге /var/log/asterisk. Типы logger.conf описаны в Таблице 24-1.

Таблица 24-1. Типы logger.conf

Тип Описание
notice Вы увидите много сообщений во время перезагрузки, а также они будут приходить во время обычных вызовов. notice просто любое событие, о котором Asterisk хотел бы проинформировать вас.
warning Warning (предупреждение) представляет собой проблему, которая может быть достаточно серьезной чтобы повлиять на вызов (в том числе отключение вызова, потому что поток вызова не может продолжаться). Предупреждения нужно устранять.
error Errors (ошибки) представляют собой значительные проблемы в системе, которые должны быть решены немедленно.
debug Отладка полезна только если вы пытаетесь устранить проблемы с кодом Asterisk. Вы не будете использовать отладку для устранения проблем в диалплане, но вы должны использовать её если разработчики Asterisk попросили вас предоставить журнал для отчетности о проблеме. Не используйте отладку в продакшене, поскольку количество сохраненных записей может заполнить жесткий диск в течение нескольких дней.a
verbose Это один из самых полезных типов протоколирования, но он также является одним из наиболее рискованных; если его оставить без присмотра, то велика вероятность заполнения жесткого диска.b
dtmf Журналирование DTMF может быть полезно если вы получаете жалобы, что вызовы неправильно маршрутизируются от автосекретаря.
fax Этот тип протоколирования обрабатывает сообщения связанные с технологией факса (res_fax_spandsp или res_fax_digium) сохраняемые факс-регистратором.
* Будет протоколировать ВСЁ (EVERYTHING) (и мы подразумеваем всё). Не используйте это, если вы не представляете последствия хранения такого объема данных. Ничем хорошим это не закончится.

a Это не теория. Это произошло с нами и было невесело.

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

Существует особенность у системы логирования Asterisk, которая может вызвать у вас некоторое замешательство, если вы не знаете о ней. Уровень журналирования для типов verbose и debug связан с детализацией, установленной в консоли. Это означает, что если вы пишете лог в файл с типом verbose или debug, а кто-то зашел в консоль CLI и дает команду core set verbose 0, или core set debug 0 журналирование в ваш файл журнала будет остановлено.

Просмотр журналов Asterisk

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

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

В Asterisk 11 введена функция ведения журнала, которая помогает с отладкой конкретного вызова. Протоколирование записей связанных с вызовом в настоящее время включает идентификатор вызова (call ID) в записи журнала. Этот call ID может использоваться с grep, чтобы найти все записи, связанные с этим вызов. В следующем примере журнал с идентификатором вызова С-00000004.

[Dec 4 08:22:32] WARNING[14199][C-00000004]: app_voicemail.c:6286

leave_voicemail: No entry in voicemail config file for ‘234123452’

В более ранних версиях Asterisk, есть еще одна уловка, которую вы можете использовать. Если, например, вы делаете детальное ведение журнала следует отметить, что каждый отдельный вызов имеет идентификатор потока, который при использовании grep часто может помочь вам отфильтровать все, что не относится к вызову. Например, в следующем подробном журнале у нас есть несколько вызовов, и поскольку вызовы происходят одновременно, трассировка одного вызова может быть очень запутанной:

$ tail –1000 verbose

[Mar 11 …] VERBOSE[31362] logger.c: — IAX2/shifteight-4 answered Zap/1-1

[Mar 11 …] VERBOSE[2973] logger.c: — Starting simple switch on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: == Spawn extension (shifteight, s, 1)

exited non-zero on ‘Zap/1-1’

[Mar 11 …] VERBOSE[2973] logger.c: — Hungup ‘Zap/1-1’

[Mar 11 …] VERBOSE[3680] logger.c: — Starting simple switch on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: — Hungup ‘Zap/1-1’

Для фильтрации одного вызова, мы можем произвести grep в потоке ID. Например:

$ grep 31362 verbose

который дал бы нам следующее:

[Mar 11 …] VERBOSE[31362] logger.c: — IAX2/shifteight-4 answered Zap/1-1

[Mar 11 …] VERBOSE[31362] logger.c: == Spawn extension (shifteight, s, 1)

exited non-zero on ‘Zap/1-1’

[Mar 11 …] VERBOSE[31362] logger.c: — Hungup ‘Zap/1-1’

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

Логирование демоном Linux syslog

Linux содержит очень мощный движок логирования, которым Asterisk способен воспользоваться. Сейчас обсуждаются различные варианты syslog и описание всех возможных способов логирования Asterisk выходит за рамки этой книги, достаточно сказать, что если вы хотите вести протокол Asterisk демоном syslog, вам просто необходимо указать следующую строку в файле /etc/asterisk/logger.conf:

syslog.local0 => notice,warning,error ; или любые типы, которые хотите

; регистрировать

Вы должны иметь запись в вашем конфигурационном файле1 системного журнала (syslog) с именем local0, которая должна выглядеть примерно так:

local0.* /var/log/asterisk/syslog

Вы можете для этого использовать local0 до local7, но проверьте ваш syslog.conf чтобы убедиться что ничего другого не использует один из этих каналов syslog.

syslog2 это гораздо более мощный инструмент регистрации, но он требует больше знаний, чем логирование Asterisk напрямую в файлы.

Проверка логирования

Вы можете просмотреть статус всех ваших настроек logger.conf через консоль Asterisk CLI используя команду:

*CLI> logger show channels

Вы должны увидеть примерно следующее:

Channel Type Status Configuration

——- —- —— ————-

syslog.local0 Syslog Enabled – NOTICE WARNING ERROR VERBOSE

/var/log/asterisk/verbose File Enabled – NOTICE WARNING ERROR VERBOSE

/var/log/asterisk/messages File Enabled – NOTICE WARNING ERROR

Console Enabled – NOTICE WARNING ERROR DTMF=

Ротация логов

Существует некоторая поддержка ротации, встроенная в Asterisk, когда Asterisk протоколирует в файлы. Ротация журналов будет выполнена в следующих случаях:

  • Если вы запустили ротацию журналов в Asterisk CLI командой.
    • Во время перезагрузки конфигурации, если существующие файлы журнала больше 1 Гб.
    • Если Asterisk получает сигнал SIGXFSZ, указывающий что файл для записи слишком велик.

    Call Detail Records (CDR) — детальная запись вызовов

    Система CDR в Asterisk используется для логирования истории вызовов в системе. В некоторых решениях эти записи используются для биллинга. В других — запись вызовов используется для анализа количества вызовов во времени. Её можно также использовать как инструмент отладки администратора Asterisk.

    Содержание CDR

    CDR имеет несколько полей, которые включены по умолчанию. Таблица 24-2 приводит их список.

    Таблица 24-2. Поля CDR по умолчанию

    Опция Значение/Пример Примечание
    accountcode 12345 Идентификатор учетной записи. Это поле определяется пользователем и пустое по умолчанию.
    src 12565551212 ID вызывающего абонента. Он устанавливается автоматически и доступен только для чтения.
    dst 102 Добавочный номер назначения для вызова. Это поле устанавливается автоматически и доступно только для чтения.
    dcontext PublicExtensions Контекст назначения для вызова. Это поле устанавливается автоматически и доступно только для чтения.
    clid “Big Bird” <12565551212> Полный идентификатор вызывающего абонента, включая имя вызывающего абонента. Это поле устанавливается автоматически и доступно только для чтения.
    channel SIP/0004F2040808-a1bc23ef Канал вызывающей стороны. Это поле устанавливается автоматически и доступно только для чтения.
    dstchannel SIP/0004F2046969-9786b0b0 Канал вызываемой стороны. Это поле устанавливается автоматически и доступно только для чтения.
    lastapp Dial Последнее приложение диалплана, которое было выполнено. Это поле устанавливается автоматически и доступно только для чтения.
    lastdata SIP/0004F2046969,30,tT Аргументы переданные в lastapp. Это поле устанавливается автоматически и доступно только для чтения.
    start 2010-10-26 12:00:00 Время начала вызова. Это поле устанавливается автоматически и доступно только для чтения.
    answer 2010-10-26 12:00:15 Время ответа на вызов. Это поле устанавливается автоматически и доступно только для чтения.
    end 2010-10-26 12:03:15 Время окончания вызова. Это поле устанавливается автоматически и доступно только для чтения.
    duration 195 Количество секунд между началом вызова и окончанием. Это поле устанавливается автоматически и доступно только для чтения.
    billsec 180 Количество секунд между ответом на вызов и окончанием вызова. Это поле устанавливается автоматически и доступно только для чтения.
    disposition ANSWERED Индикатор того, что случилось с вызовом. Это может быть NO ANSWER, FAILED, BUSY, ANSWERED или UNKNOWN.
    amaflags DOCUMENTATION Automatic Message Accounting (AMA) флаг связанный с этим вызовом. Он может быть одним из следующего: OMIT, BILLING, DOCUMENTATION или Unknown.
    userfield PerMinuteCharge:0.02 Поле пользователя общего назначения. По умолчанию это поле пусто и может быть задано в виде пользовательской строки.a
    uniqueid 1288112400.1 Уникальный ID канала src. Это поле устанавливается автоматически и доступно только для чтения.

    a userfield не так актуально в настоящее время, как это было раньше. Пользовательские переменные CDR являются более гибким способом получить пользовательские данные в CDR.

    Все поля записи CDR можно получить в диалплане Asterisk с помощью функции CDR(). Функция CDR() также используется для установки полей CDR, которые определяются для пользователя.

    exten => 115,1,Verbose(Call start time: ${CDR(start)})

    same => n,Set(CDR(userfield)=zombie pancakes)

    В дополнение к полям, которые всегда включены в CDR, можно добавлять пользовательские поля. Это делается в диалплане с помощью приложения Set() функцией CDR():

    exten => 115,1,NoOp()

    same => n,Set(CDR(mycustomfield)=coffee)

    same => n,Verbose(I need some more ${CDR(mycustomfield)})

    Если вы решите использовать пользовательские переменные CDR убедитесь что реализация CDR способна их регистрировать.

    Для просмотра встроенной документации по функции CDR(), выполните следующую команду в консоли Asterisk:

    *CLI> core show function CDR

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

    Приложения диалплана

    Есть несколько приложений диалплана, которые могут обрабатывать CDR для текущего вызова. Для получения списка приложений CDR, которые загружаются в текущую версию Asterisk, мы можем использовать следующую команду CLI:

    *CLI> core show applications like CDR

    -= Matching Asterisk Applications =-

    ForkCDR: Forks the Call Data Record.

    NoCDR: Tell Asterisk to not maintain a CDR for the current call

    ResetCDR: Resets the Call Data Record.

    -= 3 Applications Matching =-

    Каждое приложение имеет встроенную в Asterisk документацию, которую можно просмотреть с помощью следующей команды:

    *CLI> core show application <application name>

    cdr.conf

    Файл cdr.conf имеет раздел [general], который содержит параметры, применяемые ко всей системе CDR. Дополнительные необязательные разделы могут существовать в этом файле, они применяются к конкретному логированию CDR модулей. Таблица 24-3 приводит список доступных опций раздела [general].

    Таблица 24-3. Раздел cdr.conf [general]

    Опция Значение/Пример Примечание
    enable yes Включает логирование CDR. По умолчанию — yes.
    unanswered no Протоколирует неотвеченные вызовы. Обычно только отвеченные вызовы попадают в CDR. Протоколирование всех попыток вызова может привести к большому числу дополнительных записей о вызовах, а в большинстве своем они не нужны. По умолчанию – no.
    end before hexten no Закрывает вывод CDR до запуска расширения h в диалплане Asterisk. Обычно CDR не прекращается пока диалплан полностью не завершит работу. По умолчанию – no.
    initiated seconds no При вычислении поля billsec всегда округляется вверх. Например, если разница между ответом и завершением составляет 1 секунду и 1 микросекунду, billsec будет установлен на 2 секунды. Это помогает гарантировать поведение CDR Asterisk аналогичному поведению телекоммуникационных компаний. По умолчанию – no.
    batch no Очередь записей CDR будет протоколирована в пакетах, а не синхронизирована по завершению каждого вызова. Это предотвращает протоколирование CDR блокированных завершенных вызовов с разрушенным процессом Asterisk. Использование режима batch может быть невероятно полезно при работе с базой данных, которая может быть медленной для обработки запросов. Значение по умолчанию – no, но мы рекомендуем его включить.a
    size 100 Устанавливает число записей CDR, находящихся в очереди прежде чем они запишутся в пакетном режиме. По умолчанию значение – 100.
    time 300 Устанавливает максимальное количество секунд, которое CDR записи будут ждать в очереди, прежде чем пакет будет сохранен. Процесс регистрации пакета CDR будет выполнен по завершению этого периода времени, даже если размер не был достигнут. Значение по умолчанию составляет 300 секунд.
    scheduler only no Устанавливает когда процесс пакетной обработки CDR должен порождать новый поток или запланировано новое содержимое пакета CDR. Значение по умолчанию – no и мы рекомендуем не менять его.
    safe shutdown yes Блокирует выключение Asterisk, чтобы убедиться, что все в очереди записей CDR сохранены в журнал. По умолчанию – yes и мы рекомендуем оставить его таким, так как эта опция предотвращает потери важных данных.

    a Недостатком включения этой опции есть то, что если Asterisk слетит или умреть по какой-либо причине, записи CDR будут потеряны, так как они хранятся только в памяти, а процесса Asterisk уже не существует. См. safeshutdown для получения дополнительной информации.

    Конечные решения (Backends)

    Модули конечных решений Asterisk CDR реализуют различные пути логирования CDR. Большинство конечных решений CDR требуют определенной конфигурации для своего запуска.

    cdr_adaptive_odbc

    Как следует из названия модуль cdr_adaptive_odbc позволяет сохранять CDR в базе данных через ODBC. Часть имени “adaptive” указывает на то, что он приспосабливается к структуре таблицы: нет статической структуры таблицы, которая должна быть использована с этим модулем. При загрузке модуля (или перезагрузке) он читает структуру таблицы. При логировании CDR, он ищет переменную CDR, которая соответствует каждому имени столбца. Это относится как к встроенным CDR переменным, так и пользовательским. Если вы хотите логировать CDR переменные канала, просто создайте столбец с названием channel.

    Добавление содержания пользовательских CDR это так просто, как установить их в диалплане. Например, если мы хотим логировать User-Agent предоставляемый устройством SIP, мы можем добавит пользовательскую переменную CDR:

    exten => 105,n,Set(CDR(useragent)=${CHANNEL(useragent)})

    Для того, чтобы эта переменная CDR записывалась в базу данных cdr_adaptive_odbc, все, что нужно сделать – это создать столбец с именем useragent.

    Несколько таблиц могут быть настроены в файле конфигурации cdr_adaptive_ odbc. Каждая имеет в свой собственный раздел конфигурации. Название раздела может быть каким угодно, модуль не использует его. Вот пример простой таблицы конфигурации:

    [mytable]

    connection = asterisk

    table = asterisk_cdr

    Более подробный пример установок базы данных для логирования CDR может быть найден в «Хранение записей деталей вызовов (CDR)».

    Таблица 24-4, содержит список опций, которые можно определить для таблицы в разделе конфигурационного файла cdr_adaptive_odbc.conf.

    Таблица 24-4. Таблица конфигурационных опций cdr_adaptive_odbc.conf

    Опция Значение/Пример Примечание
    connection pgsql1 Соединение с базой данных, которая будет использоваться. Это ссылка на настроеное соединение в res_odbc.conf. Поле является обязательным.
    table asterisk_cdr Имя таблицы. Это поле является обязательным.
    usegmtime no Указывает, следует ли временные метки логирования использовать по GMT, а не местному времени. По умолчанию значение этой опции – no.

    В дополнение к паре полей ключ/значение (key/value), которые показаны в предыдущей таблице, cdr_adaptive_odbc.conf позволяет использовать несколько других элементов конфигурации. Во-первых, это псевдоним столбца. Обычно, переменные CDR записываются в столбцах с одноименным названием. Псевдоним позволяет изменять имя, которое будет отображаться в колонке с другим именем. Синтаксис такой:

    alias <CDR variable> => <column name>

    Вот пример отображение колонки, используя параметр alias:

    alias src => source

    Кроме того, можно задать фильтр контента. Это позволяет определить критерии, которым должны соответствовать записи, вставленные в таблицу. Синтаксис:

    filter <CDR variable> => <content>

    Вот пример фильтра содержания:

    filter accountcode => 123

    Наконец, cdr_adaptive_odbc.conf позволяет определять статическое содержание для столбцов. Это может быть полезно когда используется вместе с набором filters. Статический контент может помочь дифференцировать записи, которые были вставлены в одну таблицу по различным разделам конфигурации. Синтаксис для статического содержимого:

    static <“Static Content Goes Here”> => <column name>

    Это пример определения статического содержания для вставки с CDR:

    static “My Content” => my_identifier

    cdr_csv

    cdr_csv – это очень простой модуль CDR, который протоколирует CDR в CSV файл (значения разделены запятыми). Файл /var/log/asterisk/cdr-csv/Master.csv. Пока логирование CDR включено в cdr.conf и этот модуль загружен, CDR будет логироваться в файл Master.csv.

    Таблица 24-5. Параметры раздела cdr.conf [csv]

    Опция Значение/Пример Примечание
    usegmtime no Записывает временные метки по GMT, а не по локальному времени. По умолчанию – no.
    loguniqueid no Записывает переменную CDR uniqueid. По умолчанию – no.
    loguserfield no Записывает переменную CDR userfield. По умолчанию – no.
    accountlogs yes Создает отдельный файл CSV для каждого значения переменной CDR accountcode. По умолчанию – yes.

    Порядок переменных CDR в CSV-файлах создаваемых модулем cdr_csv:

    <accountcode>,<src>,<dst>,<dcontext>,<clid>,<channel>,<dstchannel>,<lastapp>, \

    <lastadata>,<start>,<answer>,<end>,<duration>,<billsec>,<disposition>, \

    <amaflags>[,<uniqueid>][,<userfield>]

    cdr_custom

    Этот модуль CDR позволяет задавать пользовательский формат CDR записей в файле протоколирования. Этот модуль наиболее часто используется для индивидуальных выводов CSV. Файл конфигурации для этого модуля /etc/asterisk/cdr_custom.conf. В этом файле должен быть один раздел под названием [mappings]. Этот раздел содержит соответствия между именем файла и шаблоном для CDR. Шаблон задается с помощью функций диалплана Asterisk.

    В следующем примере показана конфигурация для cdr_custom, она включает логирование в файл CDR – Master.csv. Этот файл будет создан в /var/log/asterisk/cdr-custom/Master.csv. Шаблон, который был определен, использует две функции диалплана CDR() и CSV_QUOTE(). CDR() извлекает значения из сохраненого CDR. Функция CSV_QUOTE() гарантирует, что значения экранируются для формата файла CSV:

    [mappings]

    Master.csv => ${CSV_QUOTE(${CDR(clid)})},${CSV_QUOTE(${CDR(src)})},

    ${CSV_QUOTE(${CDR(dst)})},${CSV_QUOTE(${CDR(dcontext)})},

    ${CSV_QUOTE(${CDR(channel)})},${CSV_QUOTE(${CDR(dstchannel)})},

    ${CSV_QUOTE(${CDR(lastapp)})},${CSV_QUOTE(${CDR(lastdata)})},

    ${CSV_QUOTE(${CDR(start)})},${CSV_QUOTE(${CDR(answer)})},

    ${CSV_QUOTE(${CDR(end)})},${CSV_QUOTE(${CDR(duration)})},

    ${CSV_QUOTE(${CDR(billsec)})},${CSV_QUOTE(${CDR(disposition)})},

    ${CSV_QUOTE(${CDR(amaflags)})},${CSV_QUOTE(${CDR(accountcode)})},

    ${CSV_QUOTE(${CDR(uniqueid)})},${CSV_QUOTE(${CDR(userfield)})}

    В реальном файле конфигурации значение в Master.csv должно быть в одной строке.

    cdr_manager

    Модуль cdr_manager записывает в CDR события Asterisk Manager Interface (AMI), которые мы детально обсуждали в Главе 20. Этот модуль настраивается в файле /etc/asterisk/cdr_manager.conf. Первый раздел в этом файле [general], который содержит простой параметр для включения этого модуля (по умолчанию значение — no):

    [general]

    enabled = yes

    Другой раздел в cdr_manager.conf – это раздел [mappings]. Он позволяет добавлять пользовательские переменные CDR для событий менеджера. Синтаксис такой:

    <CDR variable> => <Header name>

    Это пример добавления двух пользовательских переменных CDR:

    [mappings]

    rate => Rate

    carrier => Carrier

    При такой конфигурации, записи CDR будут отображаться как события в интерфейсе менеджера. Чтобы создать пример события менеджера, мы используем следующий пример диалплана:

    exten => 110,1,Answer()

    same => n,Set(CDR(rate)=0.02)

    same => n,Set(CDR(carrier)=BS&S)

    same => n,Hangup()

    Эта команда используется для выполнения этого расширения и генерирует образец события менеджера:

    *CLI> console dial 110@testing

    В итоге, вот пример события менеджера, образующегося в результате этого тестового вызова:

    Event: Cdr

    Privilege: cdr,all

    AccountCode:

    Source:

    Destination: 110

    DestinationContext: testing

    CallerID:

    Channel: Console/dsp

    DestinationChannel:

    LastApplication: Hangup

    LastData:

    StartTime: 2010-08-23 08:27:21

    AnswerTime: 2010-08-23 08:27:21

    EndTime: 2010-08-23 08:27:21

    Duration: 0

    BillableSeconds: 0

    Disposition: ANSWERED

    AMAFlags: DOCUMENTATION

    UniqueID: 1282570041.3

    UserField:

    Rate: 0.02

    Carrier: BS&S

    cdr_mysql

    Этот модуль позволяет размещать CDR в базе данных MySQL. Мы рекомендуем использовать в новой инсталляции cdr_adaptive_odbc вместо него.

    cdr_odbc

    Этот модуль обеспечивает старый интерфейс ODBC для логирования CDR. Новые установки должны использовать вместо него cdr_adaptive_odbc.

    cdr_pgsql

    Этот модуль позволяет размещать CDR в базе данных PostgreSQL. Мы рекомендуем использовать в новой инсталляции cdr_adaptive_odbc вместо него.

    cdr_radius

    Модуль cdr_radius позволяет размещать CDR на сервере RADIUS. Когда используется это модуль, каждая CDR сообщается RADIUS серверу как одно событие останова. Этот модуль настраивается в файле /etc/asterisk/cdr.conf. Опции для этого модуля размещены в разделе с именем [radius]. Доступные параметры перечислены в Таблице 24-6.

    Таблица 24-6. Параметры раздела cdr.conf [radius]

    Опция Значение/Пример Примечание
    usegmtime no Включает логирование с временными метками по GMT, а не по локальному времени. По умолчанию – yes.
    log unique id no Включает логирование переменной CDR uniqueid. По умолчанию – yes.
    loguserfield no Включает логирование переменной CDR userfield. По умолчанию – yes.
    radiuscfg /etc/radiusclient-ng/radiusclient .conf Задает расположение файла конфигурации radiusclient-ng. По умолчанию /etc/radiusclient-ng/radiusclient.conf

    cdr_sqlite

    Этот модуль позволяет размещать CDR в базе данных SQLite используя SQLite версии 2. Если у вас нет особой необходимости в SQLite версии 2 вместо 3, мы рекомендуем, чтобы все новые установки использовали cdr_sqlite3_custom.

    Этот модуль не требует настройки работы. Если модуль был скомпилирован и загружен в Asterisk, он будет вставлять CDR в таблицу называемую cdr в базе данных размещенной в /var/log/asterisk/cdr.db.

    cdr_sqlite3_custom

    Этот модуль CDR вставляет CDR в базу данных SQLite используя SQLite версии 3. База данных, созданная этим модулем находится в /var/log/asterisk/master.db. Этот модуль требует наличия конфигурационного файла /etc/asterisk/cdr_sqlite3_custom.conf. Конфигурационный файл определяет имя таблицы, а также настраивает какие переменные CDR будут вставлены в базу данных:

    [master]

    table = cdr

    ;

    ; Список имен столбцов, используемых при вставке CDRs.

    ;

    columns => calldate, clid, dcontext, channel, dstchannel, lastapp, lastdata,

    duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield,

    test

    ;

    ; Сопоставьте содержимое CDR с ранее указанными столбцами.

    ;

    values => ‘${CDR(start)}’,’${CDR(clid)}’,’${CDR(dcontext)}’,’${CDR(channel)}’,

    ‘${CDR(dstchannel)}’, ‘${CDR(lastapp)}’,’${CDR(lastdata)}’,’${CDR(duration)}’,

    ‘${CDR(billsec)}’,’${CDR(disposition)}’, ‘${CDR(amaflags)}’,

    ‘${CDR(accountcode)}’,’${CDR(uniqueid)}’,’${CDR(userfield)}’,’${CDR(test)}’

    В файле cdr_ sqlite3_custom.conf содержимое столбцов (columns) и значения каждой опции (values) должны быть в одной строке.

    cdr_syslog

    Этот модуль позволяет логировать CDR используя syslog. Для его включения сперва добавьте конфигурационный файл системы syslog – /etc/syslog.conf. Например:

    local4.* /var/log/asterisk/asterisk-cdr.log

    Asterisk модуль также имеет конфигурационный файл. Добавьте следующий раздел в /etc/asterisk/cdr_syslog.conf:

    [cdr]

    facility = local4

    priority = info

    template = “We received a call from ${CDR(src)}”

    Вот пример вывода syslog с помощью этой конфигурации:

    $ cat /var/log/asterisk/asterisk-cdr.log

    Aug 12 19:17:36 pbx cdr: “We received a call from 2565551212”

    cdr_tds

    Модуль cdr_tds использует библиотеку FreeTDS чтобы получить возможность отправлять CDR в Microsoft SQL Server и Sybase базу данных. Можно использовать FreeTDS с unixODBC поэтому мы рекомендуем использовать cdr_adaptive_odbc вместо этого модуля.

    Пример Call Detail Records

    Мы будем использовать модуль cdr_custom для иллюстрации нескольких примеров CDR записей для различных сценариев вызова. Конфигурация для /etc/asterisk/cdr_custom.conf показана в разделе «cdr_custom».

    Односторонний вызов

    В этом примере мы покажем как CDR выглядит для простого одностороннего вызова. В частности, мы будем использовать пример пользовательского вызова и проверим свою голосовую почту. Вот расширение из /etc/asterisk/extensions.conf:

    exten => *98,1,VoiceMailMain(@${GLOBAL(VOICEMAIL_CONTEXT)})

    Эта запись CDR из /var/log/asterisk/cdr-custom/Master.csv была создана как результат вызова этого номера:

    “””Console”” <2565551212>”,”2565551212″,”*98″,”UserServices”,

    “Console/dsp”,””, “VoiceMailMain”,”@shifteight.org”,”2010-08-16 01:08:44″,

    “2010-08-16 01:08:44″,”2010-08-16 01:08:53″,”9″,”9″,”ANSWERED”,

    “DOCUMENTATION”,””,”1281935324.0″,””,0

    Двухсторонний вызов

    В следующем примере мы покажем как выглядит CDR для простого двухстороннего вызова. Мы имеем один SIP телефон, вызывающий другой SIP телефон. Ответ на вызов, а затем повешенную трубку после короткого периода времени. Вот расширение, которое было вызвано:

    exten => 101,1,Dial(SIP/0000FFFF0002)

    Вот CDR, который был запротоколирован в Master.csv в результате этого вызова:

    “””Console”” <2565551212>”,”2565551212″,”101″,”LocalSets”,”Console/dsp”,

    “SIP/0000FFFF0002-00000000″,”Dial”,”SIP/0000FFFF0002″,”2010-08-16 01:16:10″,

    “2010-08-16 01:16:16″,”2010-08-16 01:16:29″,”19″,”13″,”ANSWERED”,

    “DOCUMENTATION”,””,”1281935770.2″,””,2

    Предостережения

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

    В результате команда разработчиков Asterisk все меньше вносит дополнительные изменения в систему CDR. Вместо этого, была разработана новая система регистрации событий канала (CEL), которая предназначена помочь в адресном логировании более сложных сценариев обработки вызовов. Имейте в виду, что CDR проще и легче использовать и мы по-прежнему рекомендуем использовать CDR если они удовлетворяют вашим потребностям.

    CEL (Channel Event Logging)

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

    Типы событий канала

    Каждая запись CEL представляет событие, которое произошло для канала в системе Asterisk. Таблица 24-7 содержит список событий, которые генерирует Asterisk когда происходит вызов.

    Таблица 24-7. Типы событий CEL

    Типы событий CEL Описание
    CHAN_START Канал был создан.
    CHAN_END Канал был разрушен.
    LINKEDID_END Последний канал с заданным linkedid был уничтожен.
    ANSWER Канал ответил. Канал создан для исходящего вызова. Это событие будет создано, когда ответит удаленный конец.
    HANGUP Канал повесил трубку. Как правило, это событие будет следовать очень быстро за событием CHAN_END. Разница в том, что это событие происходит, как только получен запрос hangup, в то время как CHAN_END происходит после завершения Asterisk процедуры очистки вызова и все ресурсы, связанные с этим каналом были освобождены.
    APP_START Отслеживаемое приложение начало выполняться на канале. Отслеживаемые приложения задаются в файле конфигурации основной ячейки, который описан в разделе “cel.conf”.
    APP_END Отслеживаемое приложения прекратило выполнение на канале.
    PARK_START Канал был припаркован.
    PARK_END Канал снял парковку.
    BRIDGE_START Запущен соединения каналов. Это событие наступает, когда два канала соединяются с помощью приложений Dial() или Queue().
    BRIDGE_END Соединение каналов был закрыто.
    BRIDGE_UPDATE Произошло обновление соединения. Это событие быдет происходить если имя канала или другая информация были изменены во время соединения.
    BLINDTRANSFER Канал выполнил слепой трансфер.
    ATTENDEDTRANSFER Канал выполнил трансфер с уведомлением.
    USER_DEFINED Произошло пользовательское событие канала. Это событие создано с использованием приложения CELGenUserEvent().

    Есть еще несколько событий, которые были определены, но еще не используются в любом месте кода Asterisk. Предположительно, некоторые будущие версии будут генерировать эти события в нужном месте. Они перечислены в Таблице 24-8.3

    Таблица 24-8. Определённые, но не используемые типы событий CEL

    Тип события CEL Описание
    CONF_ENTER Канал, который подключается к комнате конференции.
    CONF_EXIT Канал, который отключился от комнаты конференции.
    CONF_START Конференция была начата. Это событие происходит, когда первый канал входит в комнату конференции.
    CONF_END Конференция была закончена. Это событие происходит, когда последний канал покидает комнату конференции.
    3WAY_START Старт трехстороннего вызова.
    3WAY_END Завершение трехстороннего вызова.
    TRANSFER Основной трансфер был выполнен.
    HOOKFLASH Канал сообщил о событии сигнал отбоя (hookflash).

    Содержание событий канала

    Каждое событие CEL содержит поля перечисленные в таблице Таблица 24-9:

    Таблица 24-9. Поля событий CEL:

    Имя поля Значение/Пример Примечания
    eventtype CHAN_START Имя события. Список событий, которые могут произойти можно найти в Таблице 24-7.
    eventtime 2010-08-19 07:27:19 Время когда произошло событие.
    cidname Julie Bryant Имя caller ID установленное на канале связанным с этим событием .
    cidnum 18435551212 Номер caller ID установленный на канале связанным с этим событием.
    cidani 18435551212 Номер Automatic Number Identification (ANI) установленный на канале связанным с этим событием.
    cidrdnis 18435551234 Перенаправление номера установленного на канале связанным с этим событием.
    ciddnid 18435550987 Вызываемый номер установленный на канале связанным с этим событием.
    exten 101 Расширение в диалплане, которое сейчас начало выполняться.
    context LocalSets Контекст для расширения в диалплане, которое сейчас начало выполняться.
    channame SIP/0004F2060EB4-00000010 Имя канала связанное с этим событием.
    appname Dial Имя приложения диалплана начавшее сейчас выполняться.
    appdata SIP/0004F2060E55 Аргументы, передаваемые приложению диалплана, которое сейчас начало выполняться.
    amaflags DOCUMENTATION Флаг Automatic Message Accounting (AMA) асоциируется с этим вызовом. Может принимать одно из следующих значений: OMIT, BILLING, DOCUMENTATION, или Unknown.
    accountcode 1234 account ID. Это поле определяется пользователем и по умолчанию пустое.
    uniqueid 1282218999.18 Уникальный ID для канала, который связан с этим событием.
    userfield I like waffles! Содержание пользовательского события.
    linkedid 1282218999.18 ID каждого вызова. Этот ID позволяет связать воедино несколько событий из нескольких каналов, которые являются частью одного и того же логического вызова. ID исходит от uniqueid первого канала в вызове.
    peer SIP/0004F2060E55-00000020 Название канала соединенного с каналом, определенным в channame.

    Некоторые содержания событий CEL определяются пользователем. Например, userfield определяется пользователем и будет пустым по умолчанию. Чтобы установить в него какое-то значение, используйте функцию диалплана CHANNEL(). Вот пример определения userfield для канала:

    exten => 101,1,Set(CHANNEL(userfield)=I like waffles!)

    Приложения диалплана

    Система CEL включает простые приложения диалплана, которые находятся в модуле app_celgenuserevent.so. Эти приложения используют созданные пользовательские события типа EV_USER_EVENT. Практический пример использования этого может быть логирование выбора звонящих в меню:

    exten => 7,1,CELGenUserEvent(MENU_CHOICE,Caller chose option 7)

    Для полной текущей информации о синтаксисе приложения CELGenUserEvent() используйте встроенную документацию в Asterisk CLI:

    *CLI> core show application CELGenUserEvent

    cel.conf

    Система CEL имеет простой конфигурационный файл /etc/asterisk/cel.conf. Все параметры, заданные здесь влияют на обработку CEL независимо от модуля логирования, находящегося в работе. Таблица 24-10 показывает параметры, которые существуют в этом файле. Все они должны быть установлены в разделе [general] конфигурационного файла.

    Таблица 24-10. cel.conf раздел параметров [general]

    Опция Значение/Пример Примечание
    enable yes Включает/Отключает CEL. По умолчанию — no.
    apps Dial,queue Устанавливает приложение диалплана для отслеживания. По умолчанию для отслеживания приложений нет. События EV_APP_START и EV_APP_END будут генерироваться когда каналы запустят и остановят выполнение любых отслеживаемых приложений.
    events CHAN_START,CHAN_END, ANSWER,HANGUP Списки генерируемых событий. Это полезно, если вы заинтересованы только в подмножестве событий, генерируемых CEL. Если же хотите увидеть все события, установите эту опцию в ALL. Значение по умолчанию не генерирует события.
    dateformat %F %T Указывает формат даты когда событие CEL содержит отметку времени. Сведения о синтаксисе см. в руководстве для strftime, запустив man strftime в командной строке. Формат по умолчанию для метки времени CEL second.microseconds с эпохи.

    Как минимум для начала использования CEL, вы должны установить параметры enable и events в /etc/asterisk/cel.conf.

    Конечные решения (Backends)

    Как и в системе CDR есть ряд модулей, доступных для регистрации CEL событий. На самом деле, все CEL модули были получены из модулей CDR, поэтому их конфигурация очень похожа. В дополнение к параметрам конфигурации для cel.conf, которые были описаны в предыдущем разделе, эти модули требуют настройки, чтобы заставить их работать.

    cel_odbc

    Модуль cel_odbc.so предоставляет возможность протоколировать события CEL в базу данных с помощью ODBC. Этот модуль является не совсем таким как CDR для ODBC. Для событий CEL нет пользовательских переменных. Тем не менее, этот модуль будет по-прежнему приспосабливаться к структуре базы данных в том, что он будет логировать поля событий CEL, для которых имеются соответствующие столбцы и не будет выдавать ошибки если нет столбца для каждого поля. Конфигурация для этого модуля находится в /etc/asterisk/cel_odbc.conf.

    Несколько таблиц могут быть настроены в файле конфигурации cel_odbc. Каждая имеет свой раздел конфигурации. Название раздела может быть каким угодно, модуль не использует его. Вот пример простой таблицы конфигурации:

    [mytable]

    connection = asterisk

    table = asterisk_cel

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

    • eventtype
    • eventtime
    • userdeftype
    • cid_name
    • cid_num
    • cid_ani
    • cid_rdnis
    • cid_dnid
    • exten
    • context
    • channame
    • appname
    • appdata
    • accountcode
    • peeraccount
    • uniqueid
    • linkedid
    • amaflags
    • userfield
    • peer

    Таблица 24-11 показывает сопоставление типов событий и их целых значения, которые будут вставлены в столбец eventtype базы данных.

    Таблица 24-11. Тип события отображаемое в целом значении для столбца eventtype

    Тип события Целочисленное значение
    CHANNEL_START 1
    CHANNEL_END 2
    HANGUP 3
    ANSWER 4
    APP_START 5
    APP_END 6
    BRIDGE_START 7
    BRIDGE_END 8
    CONF_START 9
    CONF_END 10
    PARK_START 11
    PARK_END 12
    BLINDTRANSFER 13
    ATTENDEDTRANSFER 14
    TRANSFER 15
    HOOKFLASH 16
    3WAY_START 17
    3WAY_END 18
    CONF_ENTER 19
    CONF_EXIT 20
    USER_DEFINED 21
    LINKEDID_END 22
    BRIDGE_UPDATE 23
    PICKUP 24
    FORWARD 25

    Таблица 24-12 показывает параметры, которые могут быть определены в разделе конфигурации таблицы в файле cel_odbc.conf.

    Таблица 24-12. Таблица конфигурации cel_odbc.conf

    Опция Значение/Пример Примечание
    connection pgsql1 Определяет, какая база данных будет использоваться. Это ссылка на настроенное соединение в res_odbc.conf. Это поле является обязательным.
    table asterisk_cdr Определяет имя таблицы. Это поле обязательно.
    usegmtime no Включает/выключает при логировании использование временных меток GMT, а не локального времени. По умолчанию значение этой опции – no.

    В дополнение к паре полей ключ/значение, которые показаны в предыдущей таблице, cel_odbc.conf позволяет несколько других элементов конфигурации. Во-первых, это псевдоним столбца. Как правило, поля CEL записываются в столбцах с одноименным названием. alias позволяет отображать переменную с другим именем. Синтаксис:

    alias <CEL field> => <column name>

    Вот пример отображение колонки, используя параметр alias:

    alias exten => extension

    Кроме того, можно задать фильтр контента. Это позволяет определить критерии, которым должны соответствовать записи, вставляемые в таблицу. Синтаксис такой:

    filter <CEL field> => <content>

    Вот пример фильтра содержания:

    filter appname => Dial

    Наконец, cel_odbc.conf позволяет указать статический контент для столбца. Это может быть полезно когда используется совместно с фильтром. Статический контент может помочь различить записи, которые были вставлены в одну таблицу по различным разделам конфигурации. Синтаксис для статического контента такой:

    static <“Static Content Goes Here”> => <column name>

    Вот пример определяющий статический контент для записи с CEL событием:

    static “My Content” => my_identifier

    cel_custom

    Этот модуль CEL позволяет логировать события CEL в пользовательском формате. Чаще всего он используется для настройки данных CSV. Файл конфигурации для этого модуля /etc/asterisk/cel_custom.conf. В файле должен быть один раздел с названием [mappings]. Этот раздел содержит сопоставления между именами файлов и пользовательскими шаблонами для событий CEL. Шаблоны задаются с помощью функций диалплана Asterisk и нескольких специальных переменных CEL.

    Следующий пример – это простая конфигурация для cel_custom, которая включает один файл протокола CEL – Master.csv. Этот файл будет создан в /var/log/asterisk/cel-custom/Master.csv. Шаблон, который будет определен, использует функции диалплана CHANNEL(), CALLERID() и CSV_QUOTE(). Функция CSV_QUOTE() проверяет что значения правильно подготовлены для формата CSV-файла. Этот пример также рассматривает некоторые специальные переменные CEL, которые перечислены в Таблице 24-13.

    Таблица 24-13. Переменные CEL, доступные для использования в [mappings]

    Переменная CEL Значение Описание
    ${eventtype} CHAN_START Имя события CEL.
    ${eventtime} 1281980238.660403 Временной штамп для событий CEL. В этом примере штамп времени приводится в формате по умолчанию.
    ${eventextra} Whiskey Tango Foxtrot Пользовательские данные, включаемые с событием CEL. Дополнительные данные включаются когда используется CELGenUserEvent().

    Это пример файла /etc/asterisk/cel_custom.conf:

    [mappings]

    Master.csv => ${CSV_QUOTE(${eventtype})},${CSV_QUOTE(${eventtime})},

    ${CSV_QUOTE(${CALLERID(name)})},${CSV_QUOTE(${CALLERID(num)})},

    ${CSV_QUOTE(${CALLERID(ANI)})},${CSV_QUOTE(${CALLERID(RDNIS)})},

    ${CSV_QUOTE(${CALLERID(DNID)})},${CSV_QUOTE(${CHANNEL(exten)})},

    ${CSV_QUOTE(${CHANNEL(context)})},${CSV_QUOTE(${CHANNEL(channame)})},

    ${CSV_QUOTE(${CHANNEL(appname)})},${CSV_QUOTE(${CHANNEL(appdata)})},

    ${CSV_QUOTE(${CHANNEL(amaflags)})},${CSV_QUOTE(${CHANNEL(accountcode)})},

    ${CSV_QUOTE(${CHANNEL(uniqueid)})},${CSV_QUOTE(${CHANNEL(linkedid)})},

    ${CSV_QUOTE(${CHANNEL(peer)})},${CSV_QUOTE(${CHANNEL(userfield)})},

    ${CSV_QUOTE(${eventextra})}

    В реальном файле конфигурации значения в Master.csv должны быть в одной строке.

    cel_manager

    Модуль cel_manager создает события CEL на Asterisk Manager Interface (мы подробно обсуждали AMI в Главе 20). Этот модуль настраивается в файле /etc/asterisk/cel.conf. Он должен содержать одну секцию, называемую [manager], которая содержит один параметр включения этого модуля. Значение по умолчанию – no, но вы вожете включить его вот так:

    [manager]

    enabled = yes

    При такой конфигурации события CEL будут выглядеть как события AMI. Для примера генерации событий менеджера, мы будем использовать следующий диалплан:

    exten => 111,1,Answer()

    same => n,CELGenUserEvent(Custom Event,Whiskey Tango Foxtrot)

    same => n,Hangup()

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

    *CLI> console dial 111@testing

    И наконец, это один из примеров менеджера событий созданный в результате этого тестового вызова:

    Event: CEL

    Privilege: call,all

    EventName: CHAN_START

    AccountCode:

    CallerIDnum:

    CallerIDname:

    CallerIDani:

    CallerIDrdnis:

    CallerIDdnid:

    Exten: 111

    Context: testing

    Channel: Console/dsp

    Application:

    AppData:

    EventTime: 2010-08-23 08:14:51

    AMAFlags: NONE

    UniqueID: 1282569291.1

    LinkedID: 1282569291.1

    Userfield:

    Peer:

    cel_pgsql

    Этот модуль позволяет сохранять события CEL в базе данных PostgreSQL. Мы рекомендуем использовать в новых установках cel_odbc.

    cel_radius

    Модуль cel_radius позволяет сохранять события CEL на сервере RADIUS. Когда используется этот модуль, каждое событие CEL заносится на сервер RADIUS как отдельное событие. Этот модуль настраивается в файле /etc/asterisk/cel.conf. Параметры для этого модуля перечислены в Таблице 24-14 и размещаются в разделе [radius].

    Таблица 24-14. Разрешенные параметры в разделе

    [radius]

    файла cel.conf

    Опция Значение/Пример Примечание
    usegmtime no Использует штамп времени GMT (гринвич меридиан тайм) вместо локального времени. По умолчанию – yes.
    radiuscfg /etc/radiusclient-ng/radiusclient.conf Устанавливает размещение конфигурационного файла radiusclient-ng. По умолчанию /etc/radiusclient-ng/radiusclient.conf.

    cel_sqlite3_custom

    Этот модуль CEL записывает события CEL в базу данных SQLite используя SQLite вирсии 3. База данных, созданная этим модулем, находится в /var/log/asterisk/master.db. Файл конфигурации для этого модуля /etc/asterisk/cel_sqlite3_custom.conf определяет имя таблицы, а также настраивает какие переменные CEL будут вставлены в базу данных. Выглядит это примерно так:

    [master]

    table = cel

    ;

    ; Список имен столбцов, используемых при вставке событий CEL.

    ;

    columns => eventtype, eventtime, cidname, cidnum, cidani, cidrdnis, ciddnid, context, exten, channame, appname, appdata, amaflags, accountcode, uniqueid, userfield, peer

    ;

    ; Сопоставьте содержимое события CEL с ранее указанными столбцами.

    ;

    values => ‘${eventtype}’,’${eventtime}’,’${CALLERID(name)}’,’${CALLERID(num)}’,

    ‘${CALLERID(ANI)}’,’${CALLERID(RDNIS)}’,’${CALLERID(DNID)}’,

    ‘${CHANNEL(context)}’,’${CHANNEL(exten)}’,’${CHANNEL(channame)}’,

    ‘${CHANNEL(appname)}’,’${CHANNEL(appdata)}’, ‘$CHANNEL(amaflags)}’,

    ‘${CHANNEL(accountcode)}’,’${CHANNEL(uniqueid)}’, ‘${CHANNEL(userfield)}’,

    ‘${CHANNEL(peer)}’

    В файле cel_ sqlite3_custom.conf содержимое столбцов и значения параметров должны находиться в одной строке.

    cel_tds

    Модуль cel_tds использует библиотеку FreeTDS для записи событий CEL в базу данных Microsoft SQL Server или Sybase. Это можно сделать используя FreeTDS с unixODBC, поэтому мы рекомендуем использовать cel_odbc вместо этого модуля.

    Примеры событий канала

    Сейчас мы покажем вам несколько примеров создания событий вызова из системы CEL. Модуль cel_custom будет использован из-за своей простоты. Используемая конфигурация /etc/asterisk/cel_custom.conf приведена в разделе «cel_custom». Кроме того, следующая конфигурация была использована для /etc/asterisk/cel.conf:

    [general]

    enable = yes

    apps = Dial,Playback

    events = ALL

    Односторонний вызов

    В этом примере показан одиночный телефонный вызов в расширение, которое проигрывает сообщение “Hello World.” Вот этот диалплан:

    exten => 200,1,Answer()

    same => n,Playback(hello-world)

    same => n,Hangup()

    Вот события CEL, которые регистрируются в результате принятия этого вызова:

    “CHAN_START”,”1282062437.436130″,”Julie Bryant”,”12565553333″,””,””,””,”200″,

    “LocalSets”, “SIP/0000FFFF0003-00000010″,””,””,”3″,””,”1282062437.17″,

    “1282062437.17”,””,””

    “ANSWER”,”1282062437.436513″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “200”,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,”Answer”,””,”3″,””,

    “1282062437.17”,”1282062437.17″,””,””

    “APP_START”,”1282062437.501868″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”200″,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,”Playback”,

    “hello-world”,”3″,””,”1282062437.17″, “1282062437.17”,””,””

    “APP_END”,”1282062439.008997″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “200”,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,”Playback”,

    “hello-world”,”3″,””,”1282062437.17″, “1282062437.17”,””,””

    “HANGUP”,”1282062439.009127″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “200”,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,””,””,”3″,””,

    “1282062437.17”,”1282062437.17″,””,””

    “CHAN_END”,”1282062439.009666″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”200″,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,””,””,”3″,””,

    “1282062437.17”,”1282062437.17″,””,””

    “LINKEDID_END”,”1282062439.009707″,”Julie Bryant”,”12565553333″,

    “12565553333”,””,”200″,”200″, “LocalSets”,”SIP/0000FFFF0003-00000010″,””,

    “”,”3″,””,”1282062437.17″,”1282062437.17″,””,””

    Двухсторонний вызов

    Для второго примера один телефон буде вызывать другой через расширение 101. В результате вызов имеет два канала, которые объединяются в мост. Вот расширение, которое будет вызываться в диалплане:

    exten => 101,1,Dial(SIP/0000FFFF0001)

    А это события CEL, которые генерируются в результате создания этого вызова:

    “CHAN_START”,”1282062455.574611″,”Julie Bryant”,”12565553333″,””,””,””,”101″,

    “LocalSets”, “SIP/0000FFFF0003-00000011″,””,””,”3″,””,”1282062455.18″,

    “1282062455.18”,””,””

    “APP_START”,”1282062455.574872″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “101”,”101″, “LocalSets”,”SIP/0000FFFF0003-00000011″,”Dial”,

    “SIP/0000FFFF0001″,”3″,””,”1282062455.18″,”1282062455.18″,””,””

    “CHAN_START”,”1282062455.575044″,”Candice Yant”,”12565551111″,””,””,””,”s”,

    “LocalSets”, “SIP/0000FFFF0001-00000012″,””,””,”3″,””,”1282062455.19″,

    “1282062455.18”,””,””

    “ANSWER”,”1282062458.068134″,””,”101″,”12565551111″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0001-00000012″,”AppDial”,”(Outgoing Line)”,”3″,””,

    “1282062455.19”,”1282062455.18″,””,””

    “ANSWER”,”1282062458.068361″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “101”,”101″, “LocalSets”,”SIP/0000FFFF0003-00000011″,”Dial”,

    “SIP/0000FFFF0001″,”3″,””,”1282062455.18″, “1282062455.18”,””,””

    “BRIDGE_START”,”1282062458.068388″,”Julie Bryant”,”12565553333″,

    “12565553333”,””,”101″,”101″, “LocalSets”,”SIP/0000FFFF0003-00000011″,

    “Dial”,”SIP/0000FFFF0001″,”3″,””,”1282062455.18″, “1282062455.18”,””,””

    “BRIDGE_END”,”1282062462.965704″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”101″,”101″, “LocalSets”,”SIP/0000FFFF0003-00000011″,”Dial”,

    “SIP/0000FFFF0001″,”3″,””,”1282062455.18″, “1282062455.18”,””,””

    “HANGUP”,”1282062462.966097″,””,”101″,”12565551111″,””,””,””,”LocalSets”,

    “SIP/0000FFFF0001-00000012″,”AppDial”,”(Outgoing Line)”,”3″,””,

    “1282062455.19”,”1282062455.18″,””,””

    “CHAN_END”,”1282062462.966119″,””,”101″,”12565551111″,””,””,””,”LocalSets”,

    “SIP/0000FFFF0001-00000012″,”AppDial”,”(Outgoing Line)”,”3″,””,

    “1282062455.19”,”1282062455.18″,””,””

    “APP_END”,”1282062462.966156″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “101”,”101″,”LocalSets”,”SIP/0000FFFF0003-00000011″,”Dial”,

    “SIP/0000FFFF0001″,”3″,””,”1282062455.18″,”1282062455.18″,””,””

    “HANGUP”,”1282062462.966215″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”101″,”101″,”LocalSets”,”SIP/0000FFFF0003-00000011″,””,””,”3″,””,

    “1282062455.18”,”1282062455.18″,””,””

    “CHAN_END”,”1282062462.966418″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”101″,”101″,”LocalSets”,”SIP/0000FFFF0003-00000011″,””,””,”3″,””,

    “1282062455.18”,”1282062455.18″,””,””

    “LINKEDID_END”,”1282062462.966441″,”Julie Bryant”,”12565553333″,

    “12565553333”,””,”101″,”101″,”LocalSets”,”SIP/0000FFFF0003-00000011″,

    “”,””,”3″,””,”1282062455.18″,”1282062455.18″,””,””

    Слепой трансфер

    В этом последнем примере будет выполнен трансфер. Вызов начнется вызовом телефона по добавочному номеру 102. Затем вызов будет переведен на другой телефон с номером 101. Вот соответствующий диалплан:

    exten => 101,1,Dial(SIP/0000FFFF0001)

    exten => 102,1,Dial(SIP/0000FFFF0002)

    Это запротоколированные события CEL в результате этого сценария вызова:

    “CHAN_START”,”1282062488.028200″,”Julie Bryant”,”12565553333″,””,””,””,

    “102”,”LocalSets”, “SIP/0000FFFF0003-00000013″,””,””,”3″,””,

    “1282062488.20”,”1282062488.20″,””,””

    “APP_START”,”1282062488.028464″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”102″,”102″, “LocalSets”,”SIP/0000FFFF0003-00000013″,”Dial”,

    “SIP/0000FFFF0002″,”3″,””,”1282062488.20″, “1282062488.20”,””,””

    “CHAN_START”,”1282062488.028762″,”Brooke Brown”,”12565552222″,””,””,””,

    “s”,”LocalSets”, “SIP/0000FFFF0002-00000014″,””,””,”3″,””,”1282062488.21″,

    “1282062488.20”,””,””

    “ANSWER”,”1282062492.565759″,””,”102″,”12565552222″,””,””,”102″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,”AppDial”,”(Outgoing Line)”,”3″,””,

    “1282062488.21”,”1282062488.20″,””,””

    “ANSWER”,”1282062492.565973″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “102”,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,”Dial”,

    “SIP/0000FFFF0002″,”3″,””,”1282062488.20″,”1282062488.20″,””,””

    “BRIDGE_START”,”1282062492.566001″,”Julie Bryant”,”12565553333″,

    “12565553333”,””,”102″,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,

    “Dial”,”SIP/0000FFFF0002″,”3″,””,”1282062488.20″,”1282062488.20″,””,””

    “CHAN_START”,”1282062497.940687″,””,””,””,””,””,”s”,”LocalSets”,

    “AsyncGoto/SIP/0000FFFF0002-00000014″,””,””,”3″,””,”1282062497.22″,

    “1282062488.20”,””,””

    “BLINDTRANSFER”,”1282062497.940925″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “102”,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,”Dial”,”SIP/0000FFFF0002″,

    “3”,””,”1282062488.20″,”1282062488.20″,

    “AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>”,””

    “BRIDGE_END”,”1282062497.940961″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “102”,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,”Dial”,

    “SIP/0000FFFF0002″,”3″,””,”1282062488.20″,”1282062488.20″,””,””

    “APP_START”,”1282062497.941021″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,”Dial”,”SIP/0000FFFF0001″,”3″,””,

    “1282062497.22”,”1282062488.20″,””,””

    “CHAN_START”,”1282062497.941207″,”Candice Yant”,”12565551111″,””,””,””,”s”,

    “LocalSets”,”SIP/0000FFFF0001-00000015″,””,””,”3″,””,”1282062497.23″,

    “1282062488.20”,””,””

    “HANGUP”,”1282062497.941361″,””,””,””,””,””,””,”LocalSets”,

    “AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>”,”AppDial”,

    “(Outgoing Line)”,”3″,””,”1282062488.21″,”1282062488.20″,””,””

    “CHAN_END”,”1282062497.941380″,””,””,””,””,””,””,”LocalSets”,

    “AsyncGoto/SIP/0000FFFF0002-00000014<ZOMBIE>”,”AppDial”,”(Outgoing Line)”,

    “3”,””,”1282062488.21″,”1282062488.20″,””,””

    “APP_END”,”1282062497.941415″,”Julie Bryant”,”12565553333″,”12565553333″,””,

    “102”,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,”Dial”,

    “SIP/0000FFFF0002″,”3″,””,”1282062488.20″,”1282062488.20″,””,””

    “HANGUP”,”1282062497.941453″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”102″,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,””,””,”3″,””,

    “1282062488.20”,”1282062488.20″,””,””

    “CHAN_END”,”1282062497.941474″,”Julie Bryant”,”12565553333″,”12565553333″,

    “”,”102″,”102″,”LocalSets”,”SIP/0000FFFF0003-00000013″,””,””,”3″,””,

    “1282062488.20”,”1282062488.20″,””,””

    “ANSWER”,”1282062500.559578″,””,”101″,”12565551111″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0001-00000015″,”AppDial”,”(Outgoing Line)”,”3″,””,

    “1282062497.23”,”1282062488.20″,””,””

    “BRIDGE_START”,”1282062500.559720″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,”Dial”,”SIP/0000FFFF0001″,”3″,””,”1282062497.22″,

    “1282062488.20”,””,””

    “BRIDGE_END”,”1282062512.742600″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,”Dial”,”SIP/0000FFFF0001″,”3″,””,”1282062497.22″,

    “1282062488.20”,””,””

    “HANGUP”,”1282062512.743006″,””,”101″,”12565551111″,””,””,””,”LocalSets”,

    “SIP/0000FFFF0001-00000015″,”AppDial”,”(Outgoing Line)”,”3″,””,”1282062497.23″,

    “1282062488.20”,””,””

    “CHAN_END”,”1282062512.743211″,””,”101″,”12565551111″,””,””,””,”LocalSets”,

    “SIP/0000FFFF0001-00000015″,”AppDial”,”(Outgoing Line)”,”3″,””,”1282062497.23″,

    “1282062488.20”,””,””

    “APP_END”,”1282062512.743286″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,”Dial”,”SIP/0000FFFF0001″,”3″,””,”1282062497.22″,

    “1282062488.20”,””,””

    “HANGUP”,”1282062512.743346″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,””,””,”3″,””,”1282062497.22″,”1282062488.20″,

    “”,””

    “CHAN_END”,”1282062512.743371″,””,”102″,”12565552222″,””,””,”101″,”LocalSets”,

    “SIP/0000FFFF0002-00000014″,””,””,”3″,””,”1282062497.22″,”1282062488.20″,

    “”,””

    “LINKEDID_END”,”1282062512.743391″,””,”102″,”12565552222″,””,””,”101″,

    “LocalSets”,”SIP/0000FFFF0002-00000014″,””,””,”3″,””,”1282062497.22″,

    “1282062488.20”,””,””

    SNMP

    Simple Network Management Protocol (SNMP) – это стандартизированный протокол для управления сетью. Он очень широко используется и реализован во многих приложениях и сетевых устройствах. Такая платформа как OpenNMS4 – это платформа управления сетью с открытым исходным кодом, использующая SNMP (а также другие вещи). Asterisk поддерживает SNMP через модуль res_snmp. Этот раздел описывает установку и настройку res_snmp и как мы можем использовать платформу подобную OpenNMS.

    Установка модуля SNMP для Asterisk

    По умолчанию Asterisk не компилирует модуль разработки SNMP, поскольку сначала нужно установить все необходимые (зависимые) пакеты.

    Зависимости в RHEL

    В RHEL вам просто нужно установить пакет net-snmp-devel:

    $ sudo yum install net-snmp-devel

    Смотри далее раздел под названием “Перекомпиляция Asterisk с модулем res_snmp” для обзора, как перекомпилировать Asterisk с поддержкой SNMP.

    Зависимости в Ubuntu

    Под Ubuntu, нужно установить следующий пакет:

    $ sudo apt-get install snmp libsnmp-dev snmpd

    На Ubuntu необходимо устанавливать оба пакета snmp и snmpd, поскольку они не разрешают зависимостей библиотек разработки SNMP наподобие RHEL. Пакет snmp устанавливает инструменты SNMP подобно snmpwalk, который нам нужен, а пакет snmpd устанавливает демон SNMP.

    Смотри следующий раздел для описания, как пере компилировать Asterisk с поддержкой SNMP.

    Перекомпиляция Asterisk с модулем res_snmp

    Как только вы установите все нужные пакеты для SNMP, то можете перекомпилировать Asterisk с поддержкой SNMP:

    $ cd ~/src/asterisk-complete/asterisk/11/

    $ ./configure

    $ make menuselect # verify that res_snmp is selected under Resource Modules

    $ make

    $ sudo make install

    Затем вам нужно скопировать пример конфигурационного файла в каталог /etc/asterisk:

    $ sudo cp ~/src/asterisk-complete/asterisk/11/configs/res_snmp.conf.sample \

    /etc/asterisk/res_snmp.conf

    Мы раскажем о настройке этого файла, для использования с OpenNMS, в следующем разделе.

    Настройка SNMP для использования OpenNMS в Asterisk

    Проект OpenNMS – это платформа с открытым исходным кодом управления сетью, поддержка которой встроена в Asterisk. Однако, нужно сделать несколько шагов, чтобы включить эту поддержку. В этом разделе мы рассмотрим необходимые действия, чтобы подружить ваш Asterisk сервер с OpenNMS.

    Установка OpenNMS

    Вики OpenNMS имеет детальную иструкцию по установке OpenNMS.

    OpenNMS можно не устанавливать на ваш сервер Asterisk. Вы можете выделить отдельную машину для сервера OpenNMS.

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

    Инструкции по установке OpenNMS в вики используют SNMPv2c, который не является безопасным методом абстрагирования данных протокола SNMP. Так как мы хотим построить безопасную систему, наши инструкции покажут вам как включить поддержку SNMPv3.5

    Однако, поскольку SNMPv3 может быть немного громоздким зверем или потому что вы не желаете включить SNMPv3 по каким-то причинам (например, если ваша версия SNMP не была собрана с поддержкой OpenSSL), мы предоставим вам инструкции по настройке демона SNMP для SNMPv2c и SNMPv3.

    Как правило, проще настроить систему для SNMPv2c, а затем обновить ее до SNMPv3, правильная настройка SNMPv3 более сложная.

    Редактирование /etc/asterisk/res_snmp.conf для работы с вашим сервером OpenNMS

    В файле /etc/asterisk/res_snmp.conf, который вы скопировали из каталога с исходными кодами, нужно раскоментировать две строки:

    [general]

    ;subagent=yes

    ;enabled=yes

    Изменим файл res_snmp.conf для обоих клиентов SNMP и включим subagent:

    [general]

    subagent=yes

    enabled=yes

    После изменения этого файла, вам нужно перезагрузить модуль res_snmp.so, чтобы изменения вступили в силу:

    *CLI> module unload res_snmp.so

    Unloaded res_snmp.so

    Unloading [Sub]Agent Module

    == Terminating SubAgent

    *CLI> module load res_snmp.so

    Loaded res_snmp.so

    == Parsing ‘/etc/asterisk/res_snmp.conf’: == Found

    Loading [Sub]Agent Module

    Loaded res_snmp.so => (SNMP [Sub]Agent for Asterisk)

    == Starting SubAgent

    Редактирование /etc/snmp/snmpd.conf для работы с вашим сервером OpenNMS

    Теперь мы можем изменить файл /etc/snmp/snmpd.conf для SNMP на хосте. Переименуем текущий пример конфигурационного файла и создадим новый файл snmpd.conf:

    $ cd /etc/snmp

    $ sudo mv snmpd.conf snmpd.sample

    Первое что нужно сделать – это добавить права доступа этому файлу. Мы предлагаем вам прочитать файл /etc/snmpd/snmp.sample, который вы переименовали для лучшего представления об установке прав доступа. Затем добавим следующее в ваш файл snmpd.conf:

    $ sudo sh -c cat > snmpd.conf

    com2sec notConfigUser default public

    group notConfigGroup v1 notConfigUser

    group notConfigGroup v2c notConfigUser

    view all included .1

    view system included .iso.org.dod.internet.mgmt.mib-2.system

    access notConfigGroup “” any noauth exact all none none

    syslocation Caledon, ON

    syscontact Leif Madsen lmadsen@shifteight.org

    Ctrl+D

    Строки syslocation и syscontact необязательны, но они могут облегчить идентификацию сервера, если вы мониторите несколько узлов.

    Теперь нам нужно включить поддержку субагента AgentX что бы мы могли найти информацию о нашей системе Asterisk:

    $ sudo cat >> snmpd.conf

    master agentx

    agentXSocket /var/agentx/master

    agentXPerms 0660 0775 nobody root

    sysObjectID .1.3.6.1.4.1.22736.1

    Ctrl+D

    В дополнении к строке master agentx и опции agentX, мы включаем на Asterisk демон SNMP для коммуникации. Опция agentXPerms говорит, что Asterisk запущен от root. Если ваш Asterisk запущен от другой группы замените root на группу от которой запущен Asterisk.

    Чуть ниже конфигурации AgentX, мы добавили параметр sysObjectID. Цель добавления строки sysObjectID указать OpenNMS на хост-систему Asterisk, что позволяет динамически захватить дополнительную информацию для графиков.

    После того, как вы выполните эти шаги по настройке, вам нужно перезапустить демон SNMP:

    $ sudo /etc/init.d/snmpd restart

    Чтобы убедиться что информация будет передаваться правильно, используйте приложение snmpwalk:

    $ snmpwalk -On -v2c -c public 127.0.0.1 .1.3.6.1.4.1.22736

    Если вы правильно все настроили, то должны получить несколько строк с информацией на вашем экране, подобно этим:

    .1.3.6.1.4.1.22736.1.5.4.1.4.3 = INTEGER: 2

    .1.3.6.1.4.1.22736.1.5.4.1.4.4 = INTEGER: 2

    .1.3.6.1.4.1.22736.1.5.4.1.4.5 = INTEGER: 1

    .1.3.6.1.4.1.22736.1.5.4.1.4.6 = INTEGER: 1

    .1.3.6.1.4.1.22736.1.5.4.1.5.1 = INTEGER: 1

    …etc

    На этом этапе ваша хост-система должна быть готова для подключения к OpenNMS и сбора необходимой информации. Далее добавьте узел в систему и заполните соответствующую информацию. Через некоторое время OpenNMS опросит хост-систему и получит доступ к статистике Asterisk. Вы должны иметь возможность кликнуть графики ресурсов ( Resource Graphs) после выбора созданного узла и просмотреть выбор доступных графиков, таких как SIP, DAHDI, Local и т.д.

    Наблюдение за Asterisk с OpenNMS

    После того, как вы установили OpenNMS и настроили модуль res_snmp в Asterisk, вы можете использовать OpenNMS для наблюдения за вашим сервером Asterisk. Вы можете настроить какие статистические данные отслеживать, а также какие уведомления хотели бы получать на основе этих статистических данных. Изучение возможностей OpenNMS остается в качестве упражнения для читателя. Тем не менее, мы приложили несколько графиков для демонстрации основной информации, которую вы можете получить от сервера Asterisk. Эти графики от сервера Asterisk, который не очень сильно загружен, но они дают хороший пример того, что вы можете увидеть.

    Рисунок 24-1 содержит график, показывающий количество активных каналов в Asterisk в различное время.

    Рисунок 24-1. График активности каналов Asterisk

    Рисунок 24-2 показывает график активности каналов определенного типа. В данном случае мы просматриваем количество активных каналов DAHDI в системе. Мониторинг каналов DAHDI интересен с практической стороны, поскольку каналы DAHDI взаимосвязаны с физическими ресурсами и доступное количество каналов предопределено. Это будет очень полезно для управления использования каналами DAHDI и получения уведомлений о занятости всех каналов, это может послужить сигналом для добавления дополнительных каналов.

    Рисунок 24-2. График активности каналов DAHDI

    В завершение, Рисунок 24-3 показывает использование сетевого интерфейса. Как вы можете видеть, были всплески трафика, следующего «в» и «из» системы, когда происходили SIP вызовы.

    Рисунок 24-3. График трафика на сетевом интерфейсе

    Заключение

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

    1Который обычно находится в /etc/syslog.conf.

    2И rsyslog, syslog-ng и все остальное.

    3Если вы представите патч для добавления любого из этих событий в код и опишите эту сноску, Рассел вышлет вам бесплатно футболку Asterisk. Сноска за взятку!

    4OpenNMS, конечно не единственная платформа, которая может быть использована с модулем res_snmp. Тем не менее, мы решили обсудить её здесь по ряду причин. Во-первых, OpenNMS очень хорошая платформа управления сетью, которая имеет специальную интеграцию с Asterisk. Во-вторых, это открытый исходный код и 100% бесплатный. Наконец, Джефф Гельбах из OpenNMS внесший свой вклад в развитие Asterisk, прилагает значительные усилия в поддержке SNMP. OpenNMS также был достаточно хорош, чтобы помочь нам получить описание как все это работает, что мы могли задокументировать это.

    5Дополнительно вы можете найти пост в блоге о включении SNMPv3 для OpenNMS.

    Остались вопросы?

    Я - Першин Артём, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

    VoIP оборудование

    ближайшие курсы

    ближайшие Вебинары

    ONLINE

    Why Choose HUGE?

    Unlimited pre-designed elements

    Each and every design element is designed for retina ready display on all kind of devices

    User friendly interface and design

    Each and every design element is designed for retina ready display on all kind of devices

    100% editable layered PSD files

    Each and every design element is designed for retina ready display on all kind of devices

    Created using shape layers

    Each and every design element is designed for retina ready display on all kind of devices