По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье мы рассмотрим работу такого функционала Elastix 4 как Agenda, и его сопутствующего модуля – Calendar.
Обзор
Данный функционал находится в общем меню слева, и называется, как я уже упоминал выше – Agenda:
Если кликнуть по нему, то откроется два модуля на выбор Calendar и Address Book:
Начнем с обзора возможностей Calendar.
Настройка и использование Calendar
Как видно на скриншоте ниже, это обычный календарь, но с не совсем обычным функционалом.
После нажатия на кнопку + Create New Event, откроется следующее окно, которое можно увидеть на скриншоте ниже, вместе с примером настройки. По факту, это будет автоматический звонок указанному абоненту с подключением механизма TTS (Text to Speech) – то есть озвучивания текста голосом:
Name - Название события
Description - Описание события, необязательное поле
Start and End dates - Дата начала и дата конца события
Color - Цвет, которым событие будет выделено в календаре
Configure a phone call reminder - включение возможности голосового напоминания участнику события
Call to - номер телефонаэкстеншена
Reminder - параметр, определяющий, за какое время будет произведено голосовое напоминание
Text to Speech - текст, который будет произнесен с помощью TTS абоненту
Кроме того можно прислать напоминание участниками по email:
Для завершения настройки необходимо кликнуть кнопку Save. После этого событие появится в вашем календаре и будет выделено указанным цветом.
Заключение
В заключение хочу сказать что скорее всего данный функционал будет не очень часто использоваться, по причине повсеместного развития облачных календарей и различных to-do приложений, но если при каком-то сценарии вам понадобится данный календарь – знайте, он есть :)
Для пользователей, которые обладают премиальной лицензии на Cisco Unified Contact Center Express (UCCX), одной из самых крутых фич является наличие возможной интеграции и отправки запросов в базу данных. Сами запросы могут строиться на базе введенной звонящим информации, его номера – чего угодно.
Безусловно важно сделать ¬¬изначальный дизайн скриптов правильным и учитывать нагрузку. Большие и тяжелые скрипты, которые имеют много «плеч» в БД (базу данных), значительно увеличивают нагрузку на ресурсы сервера. А если БД еще и удалена от сервера CCX и имеет место сетевая задержка, то может иметь место прямое воздействие на бизнес и лояльность звонящего вам клиента.
Обзор Cisco Unified CCX Script Editor
Для создания и управления IVR скриптами в UCCX используется специальный инструмент - Cisco Unified CCX Editor. Он позволяет визуально управлять некими блоками, которые отвечают за то, или иное действие. Выглядит эта палетта следующим образом:
Давайте рассмотрим раздел Database. Здесь мы видимо 4 пункта:
DB Get - сопоставление полученных данных из БД к переменным скрипта;
DB Read - подключение к серверу и запрос;
DB Release - закрываем подключение к БД;
DB Write - если нужно внести изменения в БД, используем Write метод;
На скриншоте выше видно, что каждый скрипт начинается с события Start и заканчивается событием End. Во время звонка, по ходу выполнения скрипта, мы можем запрашивать данные из БД сколько угодно раз. Каждый запрос имеет свой отдельный список шагов, которые указаны в списке из 4х пунктов выше.
Мы рекомендуем предварительно обкатать все SQL запросы, доступ системы и прочие рабочие факторы перед выгрузкой в продуктивную среду
Например, давайте посмотрим, что скрыто внутри блока DB Read:
Взглянем на поля, которые доступны для конфигурации:
DB Resource Name - метка запроса. Своего рода метка;
Data Source Name - источник данных (DSN), указанное в административной консоли UCCX (Cisco Unified CCX Administration Database);
Timeout (in sec) - пауза выполнения запроса. Этот интервал защитит вашу систему от, например, потери связи с БД. То есть, максимум 7 секунд ожидания. Кстати, если указано как 0, то запрос не будет ограничен по времени;
Теперь из вкладки General переходим во вкладку Field Selection:
Запрос - SQL – команда (запрос), который вы ходите выполнить. Например, SELECT fld1, fld2 from tbl where fld1 = $variable - выбираем два поля из таблицы, где одно из полей равно переменной, которую, мы ранее, присвоили в скрипте (DTMF от клиента, например);
Test (кнопка) - нажмите на эту кнопку, чтобы проверить синтаксис запроса и подключение к БД;
Number of rows returned - количество вернувшихся строк запроса, в случае, если была нажата кнопка Test;
Show all fields (select table/view) - показать все поля в таблице, к которой выполняется подключение;
Отлично, разобрались. Теперь давайте взглянем на блок DB Get:
DB Resource Name - лэйбл или имя для этого запроса;
Data Source Name - имя БД (настраивается на стороне Cisco Unified CCX Administration);
Refresh Database Schema (кнопка) - кнопка, которая отвечает за подтягивание данных БД и таблицы в CCX Editor;
Переходим во вкладку Field Selection:
Table/View - данное поле показывает имя таблицы из БД, которая выбрана во вкладке General, которую мы описывали выше;
Табличное поле:
Field Name - имя поля, в выбранной БД;
Data Type - типа данных (строка/число и так далее);
Local Variable - переменная скрипта, которая будет хранить соответствующее поле;
Add/Modify (кнопки) - кнопки, которые отвечают за модификацию полей (кроме типа данных, он read only);
Полученные данные можно использовать в скрипте, например, чтобы озвучивать клиенту (TTS) его данные по номеру телефона, или по введенным цифрам (номер заказа). Кстати, аналогичную фичу мы реализовали в связке Yandex.SpeechKit и Asterisk.
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.
Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев.
Проверка времени перезагрузки
Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last
Проверка системных журналов
Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями.
Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор.
Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину.
Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:
sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel'
/var/log/messages /var/log/syslog /var/log/apcupsd*
| grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'
Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.
Проверка журнала auditd
Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
Анализ журнала systemd
Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд:
$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald
После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется.
Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:
$ journalctl --list-boots
Вот его выходные данные на моем сервере:
Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:
$ journalctl -b {num} –n
Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце.
В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются.
Заключение
Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины.
Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.