У клиента есть свои особенности, поэтому лучшим вариантом было именно добавление новых серверов. Наверное "только" стоит убрать, чтобы не вводить в заблуждение :)
Код выложим в ближайшее время.
Дополнение: если делать автотест для шаблонов, то наливается хост, проверяем через API что данные пошли, далее меняем состояние того, что хотим проверить. Скажем, если это доступность SSH, то отключаем ее или просто блокируем на уровне Firewall и проверяем через API что изменения попали в Zabbix и триггер сработал. Идея в том, что нам известно состояние в котором находится система и то, в котором она должна оказаться и эти изменения должны попасть в систему мониторинга. В случае Zabbix, все изменения можно отслеживать через API.
Тут все достаточно просто, нам известен конечный результат выполнения скрипта. В git сделан простой pipeline. К примеру, возьмём скрипт который создаёт веб проверку. Запускается pipeline, в котором запускается скрипт с набором тестовых данных и создается веб проверка, а потом запускается скрипт, который проверяет наличие верного item и trriger. Если все на месте и с нужными данными, то тестовая проверка удаляется. И тест считается пройденным. Для тестов на zabbix сервер установлен gitlab-runner. Если интересен код, пишите, выложим.
Можно, конечно. Только это логически независимые вещи. Вот тут https://habrahabr.ru/post/261391/, к примеру, имена хранятся в MySQL, и остаются через ODBC. Так что вы изначально можете получить имя звонящего, а потом отправить его в телеграм.
Т.е. менеджер должен услышать сообщение телеграма ДО того как ему поступит входящий звонок (во время звонка >не все айфоны даже держат сессию 3G)?
Не обязательно, он просто должен знать номер звонящего, суть в этом.
Рекомендую «резолвить» CALLERID в название контрагента по базе CRM (если номер неизвестный — принявший >звонок менеджер д.б. по приходу в офис внести его в БД.
Согласен, отличное дополнение. Данная статья — это, так сказать, "каркас" для оповещения, какие аргументы передавать нужно в каждой конкретной реализации — решается по месту:)
В этом примере все будет корректно: пусть у нас на одном asterisk 1000 агентов в очереди и на втором тоже 1000 агентов в очереди, причем, это разные агенты. Пришел вызов, направился на первый asterisk, попал в очередь из 1000 агентов. Его позиция будет считаться для заданной очереди.
Sip proxy можно и для отказоустойчивости, и для сокрытия топологии использовать, но и для распределения нагрузки вполне подходит. FreeSwitch по синтетическим тестам — да, вроде показывает себя лучше. Когда перейдете с Asterisk на FreeSwitch, обязательно напишите статью, думаю, многим будет интересно прочесть о сравнении под реальной нагрузкой
Количество звонков в сутки без указания средней длительности — не всегда показательно. Вот пиковое число одновременных вызовов — более интересная метрика
Да, вы правы, можно сделать и на ami, логика отличаться не будет. На bash проще выделить нужный канал — 2 grep и все, а в случае с ami все будет чуть сложнее, и потребуется минимальное знание хотя бы php
Пишут, что буквально вчера выкатили исправление, и скоро зальют в Stable. Хотя, конечно, несколько месяцев править то, что сами же и сломали — это своеобразно
В крайнем случае, конечно, стоит попытаться. Но все-таки, думаю, лучше постараться предотвратить взлом, чем потом ходить по судам. Кстати, думаю, будет интересно, если Вы расскажете, как именно взломали станцию
Это в минуту. Спасибо что обратили внимание, поправим в статье.
У клиента есть свои особенности, поэтому лучшим вариантом было именно добавление новых серверов. Наверное "только" стоит убрать, чтобы не вводить в заблуждение :)
Дополнение: если делать автотест для шаблонов, то наливается хост, проверяем через API что данные пошли, далее меняем состояние того, что хотим проверить. Скажем, если это доступность SSH, то отключаем ее или просто блокируем на уровне Firewall и проверяем через API что изменения попали в Zabbix и триггер сработал. Идея в том, что нам известно состояние в котором находится система и то, в котором она должна оказаться и эти изменения должны попасть в систему мониторинга. В случае Zabbix, все изменения можно отслеживать через API.
Добрый день, спасибо за ваш интерес к статье.
Не обязательно, он просто должен знать номер звонящего, суть в этом.
Согласен, отличное дополнение. Данная статья — это, так сказать, "каркас" для оповещения, какие аргументы передавать нужно в каждой конкретной реализации — решается по месту:)
Рассмотрим обращение из dialplan, работу с AstDB и расскажем зачем все это нужно.
Пишут, что буквально вчера выкатили исправление, и скоро зальют в Stable. Хотя, конечно, несколько месяцев править то, что сами же и сломали — это своеобразно