Elasticsearch

Довольно часто наши клиенты сталкиваются с необходимостью выгрузить информацию о звонках из раздела Call Detail Record к себе. Как вы уже знаете (даже если взять во внимание предыдущую запись в этом блоге, а именно Липкость звонка), вся историческая статистика хранится в базе elasticsearch. В документации вы так же могли увидеть пример получения данных с помощью нашего REST API. Но, что если звонков несколько сотен? Или несколько тысяч? Как правильно получить такой объем данных? Сегодня я расскажу как работать с большими объемами данных.

Scroll

Для получения большого количества данных, в elasticsearch предусмотрен функционал scroll, который мы повторили и в нашем REST API. Рассмотрим на примере:

Лет 7 тому назад, я уже писал на тему обработки входящего звонка от клиента, с поиском внутреннего номера сотрудника, который последним звонил на номер клиента. Теперь пришло время написать похожую статью, как такое реализовать в webitel, тем более, что начиная с версии 3.8.2 (UPD: как оказалось, нужна версия старше 3.8.2) у нас в маршрутизации появилось отдельное приложение для запросов в базу elasticsearch, где и хранится вся информация о звонках. Давайте рассмотрим пример, как научить webitel соединять клиентов с последним звонившим.

Предположим, что у нас уже имеется любая существующая схема с IVR и другими полезностями. Мы хотим добавить в начале проверку по номеру телефона, звонящего к нам в офис, кто из сотрудников последним звонил на данный номер. Дополнительно мы еще добавим ограничение в «за последние 30 минут». Все это мы можем сделать с помощью запроса в cdr:

Очень сильно раздражает, если для поиск нужного звонка в статистике любой АТС нужно ждать десятки секунд, а то и минуты. А теперь представьте, что Вы постоянно работаете со статистикой… Каждый поиск, каждый новый фильтр — потерянные минуты, которые собираются в часы 🙁 Вы можете увеличить вычислительные ресурсы сервера, можно удалить старые записи… А можно перейти на полнотекстовый поиск. Вот это последние мы и решили испытать в ожидающем нас новом релизе webitel.

Те, кто пользовался админкой в webitel 3.0 или 3.1, очень хорошо помнят ее ограничения при работе со статистикой — только фильтры по дате. Я сам неоднократно не мог найти нужный мне звонок:

Старая статистика звонков

В релизе 3.2 мы презентовали новый Webitel WebClient, который обзавелся не только новым видом, но и новым конструктором фильтров:

Конструктор фильтров

Вчера мы закончили основные работы с перехода на новую версию webitel. Лично для меня, самым долгожданным был новый WebClient (Игорь, привет!). Описание других новшеств Вы сможете прочитать на этой странице: тыц!

Недавно я рассказывал о нашем опыте подружить webitel с elasticsearch. И вот мы запустили в тестовом режиме сервис аналитики по звонкам для всех пользователей webitel on-demand. В основе все та же связка elasticsearch и kibana. Сегодня я хочу более подробней рассказать, что это такое.

Пройдя авторизацию (все данные можете запросить у поддержки), для Вас открывается простой Dashboard:

Dashboard

Вся статистика webitel хранится в хранилище MongoDB в виде JSON файлов с детальным описанием всего маршрута звонка и переменных канала. Но, до сегодня было довольно сложно быстро построить отчет (либо график) по истории звонков. И мы начали поиск решения… Но, решение оказалось ближе, чем мы предполагали 🙂

Уже несколько последних месяцев для сбора и анализа логов я использую связку Elasticsearch+Logstash+Kibana, которая успешно справляется с поставленной задачей. Возникла идея, что если синхронизировать MongoDB с Elasticsearch и с помощью Kibana строить отчеты. Так и решили сделать!