По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Какое будущее ждет нас в контакт центрах с точки зрения кастомер сервис (клиентского сервиса)? Как компании создают новые пространства для коммуникации со своими потребителями? Будем говорить про чат боты - будущее клиентского сервиса. На цифрах, кейсах, исследованиях, в том числе социальных, постараюсь рассказать о том, почему в контакт центрах будущего, живых операторов будет меньше, а VoIP (классические телефоны) и CTI (интеграция компьютерных приложений и телефонии) отойдет на второй план. Посмотреть доклад Чат - боты это определенно хайповая история, несмотря на то, что сам хайп сейчас немного поугас. Компании абсолютно разного уровня внедряют чат - ботов: от больших банков, где чат бот органично вписывается в ИТ экосистему и помогает сократить косты на операторов и снизить их загрузку на рутинные операции до маленьких компаний, e-commerce или туристических фирм, где смысл чат - бота скорее сводится к тому, чтобы показать уровень технологичности на ряду с более "аналоговыми" конкурентами. Посмотрим на крупных игроков IT рынка, которые уже бороздят просторы ML/AI в поиске способа доставить счастье своим пользователям, среди них как Zero UI решения, которые вовсе не имеют привычного интерфейса, так и уже вполне рабочие чат боты: Алиса - умный помощник от Яндекс. Это мозги, которые живут почти во многих приложениях Яндекса и в хардварных устройствах. Кстати, по данным Яндекса, в приложении поиска доля голосовых запросов на октябрь 2018 года была 20%. Помимо пользовательских сценариев, Алиса сможет решать конкретные бизнес задачи по клиентскому обслуживанию клиентов вашего контакт центра, как автоматизированном режиме, так и в режиме диалога с оператором. Это реализуется с помощью платформы Яндекс.Диалоги - легкий способ связать жителя экосистемы Яндекса с вашим бизнесом, так сказать, не отходя от кассы. Кстати, количество активных пользователей алисы в месяц (MAU) 35 млн. - подумайте, сколько из них ваших потенциальных или текущих клиентов. Про Amazon и их разработки. Вы наверное слышали про виртуальный ассистент Alexa. Внутри алексы используются алгоритмы Amazon Lex А так как Amazon научился монетизировать свои технологии как никто другой, то они продают Amazon Lex в видео фреймворка (интерфейса) для создания приложений - как голосовых так и текстовых, в которых используются алгоритмы понимания естественных языков (NLU), и распознавания речи ASR. О первых я расскажу подробнее в конце статьи. Фреймворк, как заявляют ребята с Амазона, в контексте контакт центров классно подходит для рутинных операций - смена пароля, баланс, встреча с представителем компании и некоторые другие. Бот помощник Олег от банка Тинькоф. Бот помогает управлять кредиткой или дебетовой картой или заказать финансовые документы, снижая нагрузку на живых операторов и помогает закрыть пользовательские сценарии, купить билеты в кино и забронировать столик в ресторане. Тут можно отметить 2 самых очевидных пункта, которые дает бот: Ретеншн (вовлеченность) пользователей. Экосистема с элементами фана повышает вовлеченность к бренду и втягивает пользователей в экосистему. Билеты в кино, скидки, столики, переводы, а еще и голосом с ботом, который может ответить что то смешное или даже грубое, что насмешит друзей и спровоцирует цепочку рассылки диалога друзьям. Из этого вытекает следующий пункт: Виральность - распространяемость контента. На старте бот Тинькоф отвечал пользователям весьма неоднозначно. Например, на старте, попросив "сотку" у банка вы рисковали получить неплохую ответочку: Этот ответ массово распространился по социальным сетям. Это и есть та самая виральность. Вообще много мнений и обсуждений, касаемо чат ботов: начиная от того, что рынок еще не готов и сама технология бесполезна, заканчивая тем, что люди не любят общаться с чат ботами. Если два первых барьера мы с вами обсудили, то про второй я хочу поговорить немного подробнее. Блок про поколение Z - почему он в соц. сетях и не любит голос Впервые в истории, в 2011 в UK заметили, что объем телефонных звонков упал на 10%. При более детальном анализе было обнаружено, что максимально влияющая на падение показателя когорта пользователей - это люди 16 - 24 лет, которые предпочитают текстовую коммуникацию. К обеспокоенности провайдеров, масла в огонь подлил государственный медиарегулятор Ofcom (управление по коммуникациям), отчитавшись - 96% британцев в возрасте 16 - 24 используют текстовые сообщения каждый день. Итак, кто эта группа - 16 -24? Условно говоря, это люди рожденные после 1995 по 2012 года, и поздние Z - рожденные после 2000. Частично, тенденции к цифровизации и ухода в онлайн начали проявляться и у Миллениалов или, как принято их называть Поколение Y. Это люди рожденные с 1981 и до 1996 года. Несколько факторов, которые характеризуют поколение Z: Поколение Z очень целеустремленны. как пишут в исследованиях, это, "most success oriented". Взросление в процессе рецессии, войны, террористических атак, трудные времена на территории РФ. Зачастую, им приходилось наблюдать за борьбой родителей в трудные времена. Масла в огонь подливали миллениалы, полностью зацикленные на карьере. Настроение на успех на выходе дает следующий пункт, пусть и сомнительный - многозадачность. Многозадачность. Поколение Z чувствует себя спокойнее, выполняя несколько задач одновременно. Запостить фотографию в инстаграм, написать друзьям, почитать новости на медузе, сделать фильтра в снэпчате, погонять слова в скаенге. Мы не говорим об эффективности подобных активностей (которая по моему мнению, околонулевая), мы говорим про сам посыл. Тут и возникает важный нюанс - в контексте решения многозадачности, Z, решая свои вопросы с компанией, у которой они берут услугу, предпочтут отправить сообщение в бот в телеграмме или в приложении и ждать ответа, чем висеть на телефоне, холде, ждать ответа оператора и просто говорить голосом. Но это не главная причина. Важнейшей является то, что поколение Z нативно вросло в digital. Нативно в digital. Z находятся в цифровом пространстве полностью. Мессаджинг (текстинг), мемы, фотографии, лайки, обсуждения, снэпчаты - среда, в которой они существуют. И в ней, телефонному звонку, да и голосовой коммуникации в целом остается все меньше и меньше места. Соответственно, Z ожидают, что диджитал будет окружать их везде - решить проблемы с банком, заказать услугу, купить товар или еду, путешествия и прочее. Не давая им возможности обратиться в диджитал, мы рискуем потерять эту аудиторию. Существует множество других характеристик, которые прямо или косвенно влияют на стремление Z к цифре: Конфиденциальность - Z очень ценят свою конфиденциальность. Представьте Z, который едет в полном автобусе, звонит в контакт центр, где его просят назвать кодовое слово? Кажется, он будет слегка сконфужен Z легко принимают новое Вот такие они, эти ребята в гучи, суприм и кроссовках на высокой платформе. Давайте закрепим и посмотрим, что об этом думают большие компании. Пруфы того, что это важно В феврале 2018 года в Токио консалтинговая компания Гартнер отчиталась - к 2020 году 25% всех клиентских итераций будут происходить через VCA (virtual customer assistant), если переводить дословно - виртуальных клиентских помощников, или чат ботов, в контексте моего доклада и контакт - центра. Джин Альварез, вице - президент в Гартнер отчитался, что более чем половина крупного энтерпрайза уже начали инвестировать и исследовать виртуальных помощников, в разрезе решения стандартных вопросов с последующей эскалацией сложных на агента. Вот цитата Джина (Gene Alvarez): "As more customers engage on digital channels, VCAs are being implemented for handling customer requests on websites, mobile apps, consumer messaging apps and social networks" Перевод: С погружением клиентов в цифровые каналы коммуникации, все больше VCA (виртуальные клиентские помощники) внедряются для обработки клиентских запросов на сайтах, мобильных приложениях, мессенджерах и соц. сетях" Это важно, так как мы обсудили ранее, для подрастающего платежеспособного поколения Z - цифровые каналы это нативные вещи. Помимо прочего, важная цифра: организации, использующие VCA, в среднем, смогли сократить количество звонков, операторских чатов и писем на 70% и срезали косты на телефонию в среднем на 33%. В отчете так же было отмечено увеличение общего уровня удовлетворенности клиентов. Я не стану добавлять это в статью, так как Гартнер поленился рассказать, какие метрики для этого они посчитали и как измерили. Дальше. Ребята из Juniper Research еще в 2017 году говорили, что чат - боты - гейм чейнджер для банков и здравоохранения. Джунипер прогнозирует, что количество клиентских взаимодействий с чат-ботами в здравоохранении увеличится с 12% до 75% к 2022 году, а в банковском секторе достигнет 90% к этому времени. Автор исследования Лоурен Фои (Lauren Foye) объясняет: "We believe that healthcare and banking providers using bots can expect average time savings of just over 4 minutes per enquiry, equating to average cost savings in the range of $0.50-$0.70 per interaction. As Artificial Intelligence advances, reducing reliance on human representatives undoubtedly spells job losses." Перевод: Мы считаем, что банки и компании в области здравоохранения, используя чат- боты могут сэкономить более 4 минут на один клиентский запрос. Это примерно 50 - 70 центов за одну итерацию. 4 минуты на обращении что примерно ровняется $0.5 - $0.7. Лоурен пугает нас тем, что развитие AI (искусственного интеллекта) так или иначе приведет к потере работы многими людьми. Спасибо Лоурен, тебя это тоже коснется. Кстати, про искусственный интеллект. А точнее про одно из его направлений NLP (Natural Language Processing), или говоря по русски, обработку естественного языка. Про natural language processing (NLP). Обработка естественного языка Кратко пробежимся по технологии, которая драйвит эту отрасль. NLP - обработка естественного языка. Это направление породила одна проблема: компьютеры прекрасно справляются со структурированными данными, таблицами, приведенными к единообразию датасетами, но мы с вами общаемся не методами структурами, а словами. Тут и появилась идея научить машины понимать живой человеческий язык. В рамках решения этой задачи, как и в любой другой задаче машинного обучения, принято разбивать задачу на последовательность подзадач. Это называется пайплайн, он же конвейер процессов, которые необходимо выполнить. Давайте попробуем кратко разобраться на примере текста, взятого из википедии про Лондон: London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium. Тут есть несколько сегментов полезной информации про Лондон, где он находится и кем основан. 1. Дробим на предложения Первый этап пайплайна - дробим текст на предложения. Самое простое - по знакам препинания. Но современные алгоритмы используют более хитрые способы. Вот что у нас получилось: London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium. Три отдельных смысловых блока. Отлично. 2. Токенизация Оно же выделение слов. Так как мы уже разбили текст на предложения, берем первое и дробим - алгоритм прост - разбиение по пробелам или знакам препинания "London", "is", "the", "capital", "and", "most", "populous", "city", "of", "England", "and", "the", "United", "Kingdom", "." 3. Части речи Теперь смотрим на каждое слово отдельно и понимаем, что это - существительное, глагол, прилагательное или еще что то. Готовые фреймоврки обучены на на миллионах слов и учитывают слова стоящие рядом, для повышения точности определения. Получаем: London - имя собственное is - глагол the - артикль capital - существительное and - союз most - наречие populous - прилагательное 4. Лемматизация Лемматизация (англ. lemmatization) - приведение словоформы к ее первоначальной словарной форме (лемме). По факту, это отсечение окончаний и использование основой формы. Например, в русском языке словарной формой считается: существительные - именительный падеж, единственное число (руками - рука) глаголы - инфинитивная форма (искали - искать) прилагательные - единственное число, именительный падеж, мужской род (телекоммуникационными - телекоммуникационный) В NLP лемматизация обычно выполняется простым поиском форм в таблице. Вот что мы получаем: London - имя собственное (уже начальная форма) is - глагол (превращается в be) the - артикль (уже начальная форма) capital - существительное (уже начальная форма) and - союз (уже начальная форма) most - наречие (уже начальная форма) populous - прилагательное (уже начальная форма) 5. Стоп слова В нашем примере мы рассматриваем англоязычный фрагмент текста. Поэтому, из него нужно убрать слова, которые создают избыточный шум - артикли, например "and", "the", "a". Обычно, это делается по готовым таблицам. Снова смотрим на наше предложение: London - имя собственное (уже начальная форма) is - глагол (превращается в be) the - артикль (уже начальная форма) capital - существительное (уже начальная форма) and - союз (уже начальная форма) most - наречие (уже начальная форма) populous - прилагательное (уже начальная форма) 6. Парсинг зависимостей Следующим шагом нам важно понять взаимосвязь слов в предложении. Нужно понять, кто является родителем для каждого из токенов (слов) и установить тип взаимосвязи: субъект предложения, свойство, логическая связь, определение и так далее. В результате мы получаем уже почти готовое дерево связей. Логическим продолжением этого шага является группировка токенов по признакам взаимосвязи. Было: London - имя собственное (уже начальная форма) is - глагол (превращается в be) the - артикль (уже начальная форма) capital - существительное (уже начальная форма) and - союз (уже начальная форма) most - наречие (уже начальная форма) populous - прилагательное (уже начальная форма) Стало: London is the capital and most populous city 7. Распознавание именованных сущностей (Named Entity Recognition, NER) Двигаясь по пайплайну мы подходим к самому интересному, на мой взгляд, шагу - распознавание смысла слов. Вы уже заметили, что в нашем предложении встречаются географические сущности, такие как "London", "England" и "United Kingdom". На этом этапе пайплайна мы пониманием что это географический объект и определяем это, наполняя наш текст смыслом. NER алгоритмы хорошо работают с такими объектами как: имена людей; названия компаний; географические обозначения (и физические, и политические); продукты; даты и время; денежные суммы; события. Тут важно отметить, что хорошая NER система это не только словари. Они так же просматривают контекст предложения и окружение каждого конкретного токена. Адекватный NER должен уметь отличить американскую актрису Дакоту Фаннинг от штата Дакота на севере США 8. Разрешение кореференции Если быть кратким, то это решение вопроса с местоимениями, которые во всем тексте означают тот или иной объект. Вернемся к нашему изначальному тексту, который мы разбивали на предложения London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium. Обратите внимание на "It was founded by the Romans, who named it Londinium." Это было основано римлянами. Это? Что это? Вот и задача для для алгоритмов связать, что Это в данном контексте - это = Лондон. 9. Итог. Полный пайплайн NLP Итак, подытожим. Чтобы получать смыслы из речи человека текст проходит мощную обработку в конвейере NLP. Помимо прочего, NLP можно юзать и в голосовых технологиях, преобразуя речь в текст в рамках ASR механизмов и снова пропуская через пайплайн NLP. Суммарно, чтобы читать между строк и получать смысла информация перемалывается через эти 9 шагов (где то их может быть меньше, а где то в другом порядке, например): Дробим на предложения Токенизация Части речи Лемматизация Стоп слова Парсинг зависимостей Группировка токенов (существительных) Распознавание именованных сущностей (Named Entity Recognition, NER) Разрешение кореференции Кто делает? Продуктов много. Есть как тривиальные инструменты создания блок - схем (статичных алгоритмов обработки запросов), так и интерфейсы с продвинутым NLP, о котором мы поговорили ранее, есть энтерпрайзные решения, есть и решения для SMB. Не делая рекламы, поговорим про бесплатные решения. Rasa.com RASA.com Ребята дают бесплатный фреймворк для быстрого старта. Есть энтерпрайз коммерческие тарифы, которые дадут SLA и не комьюнити бэйзд гарантии. У ребят 0.5 млн загрузок по миру, 3.5 активных участников комьюнити. Схематично парни из раса.ком обозначили принципы работы их чат бота как на картинке: Можно попробовать абсолютно бесплатно, дав плечо фреймворку в свои данные. Итоги С развитием машинного обучения цифровое будущее становится все ближе и ближе. На руку прогрессу и развитию роботизации в клиентском сервисе играют поколенческие факторы, общие характеристики нового поколения, тренды и даже политическая обстановка. Будьте первыми, будьте актуальными, будьте технологичными и свежими.
img
Привет, сегодня расскажем что такое база данных и SQL. У современных баз данных куча нюансов - погнали разбираться. Представь - собираешь ты деньги на подарок корешу, и записываешь на бумажке, кто сколько скинул. Табличка с денежками организована, разделена по именам и сумме долга, и имеет удобную структуру - ну вот оно, это и есть база данных! Ага, теперь, перемещаемся в цифровое пространство и заводим целый эксель файл для этого дела. Стало удобнее, можно редактировать, сортировать и даже данные удалять! Круто! Но достаточно ли этого для роста этой базы данных? Нет. Со временем данных становится так много, что админам приходится связывать их друг с другом, а тут одним эксель файлом уже не обойтись. Представим, решили вы сделать свой аналог ютуба, как будете хранить инфу о пользователях? Список юзеров, там, каналы, кто на что подписан, лайки и вот это все. Сложить это все в одну таблицу? Будет неудобно и медленно работать. Очевидно, надо разделить сущности на несколько таблиц - юзеры, каналы и видосы: Теперь свяжем данные между собой и добавим информацию о том, кто создал канал, и на каком канале залили видео. Ага, получились связанные таблицы. Связанные, от слова связь. А связь, это по-английски relation. А в айти тусовке они так и называются - реляционные базы данных, и это один самых распространенных типов баз данных. Еще есть нереляционные базы данных, о них подробнее можно прочитать в этой статье про NoSQL. Уф, ну теперь с данными стало гораздо удобнее работать, и мы избежали большой таблицы с повторяющимися строчками, разбив все на несколько табличек. Такой процесс еще называется нормализацией, когда мы избавляемся от избыточных данных. Ну и как раз для этого мы ввели в каждой таблице специальное поле - ID, которое идентифицирует каждую запись. Этот айди называется Primary Key, он же “первичный ключ”. А в таблице которая будет на него ссылаться, он будет называться Foreign Key, или по-русски “внешний ключ”. Нырнем в детали и поговорим про типы связей между таблицами. Первый тип называется “Один-ко-многим” или “многие-к-одному” (One-to-Many или Many-to-One). В нашем примере, у каждого видео может быть только один канал, где оно выложено, но на одном канале может быть много видео, поэтому в двух последних строках ID канала у нас повторяется, верно? Отношения «один-ко-многим» также можно рассматривать как отношения «многие-к-одному», в зависимости от того, с какой стороны вы на это смотрите. Второй тип связей называется “один-к-одному” (One-to-One) - классические табличные отношения. Вообще, это редко используемый тип связи, обычно его делают для безопасности. Это как если на нашем аналоге ютуба, мы разрешили бы создавать только один канал одному пользователю и в таблице с каналами ID создателя не могло повторяться. Такое себе, согласен? В таком случае вообще можно было бы обойтись и одной таблицей. Ну и третий тип связей, это “многие ко многим” (Many-to-many). Это когда у нас появляется промежуточная таблица связей, которая как бы соединяет два отношения “один ко многим”, которые мы обсудили в начале разбора типов связей. Давайте сделаем таблицу с лайками балалайками, где будем хранить ID пользователей и ID видео, к которым они поставили лайк: А вот так они связан: каждый пользователь может поставить лайк каждому видео. Теперь вопрос - а где все это хранить? Не в экселе же. И тут на сцену выходит термин СУБД, она же система управления базами данных - это программа, которая позволяет создавать, редактировать и администрировать реляционную базу. Ну и для управления всей этой петрушкой используется язык структурированных запросов, SQL (Structured Query Language) эскюэль или сиквел, как иногда его называют за рубежом. Он очень простой и понятный, вот смотри - чтобы найти названия всех видео с одного канала, нам нужно выполнить следующий запрос: SELECT name FROM videos WHERE channel_id = 201 То есть мы буквально говорим: выбери (SELECT) имена из (FROM) таблицы видео, где (WHERE) айдишник (ID) канала равен 201. Если вы хотите взять данные из нескольких таблиц и объединить результат, то нужно использовать в запрос параметр JOIN (от английского соединить). Вот такая упрощающая жизнь админам аналогия с разговорным языком. Так, SQL конечно позволяет добавлять, удалять и изменять данные и сами таблицы. Но важно не забывать про схему базы данных (Database schema), которая служит для описания структуры таблицы, ее полей и ограничений. Прикол в том, что если вам потребуется добавить или убрать столбец в таблице, то это изменение коснется вообще всех данных в таблице, таким образом если мы добавляем новый столбец, то он теперь будет присутствовать в каждой строке. Окей, а для чего вообще нужны ограничения? Для целостности твоих данных. Помнишь мы рассказали про первичный и внешний ключ? Так вот, благодаря им мы можем удостовериться, что в таблицу не попадет запись, которая ссылается на несуществующий айдишник. Или различные ограничения полей, которые не дадут записать дублирующие или пустые данные в нашу базу (Not NULL и Unique). И еще: транзакции. Эта штука, которая позволяет как бы склеить несколько SQL запросов в один. Ну вот представь такую задачку: вставить данные в первую таблицу, а во второй указать ID вставленной записи. Если ты делаешь это без использования транзакций, а во время второго этапа у тебя отвалится интернет, то первая запись попадет в базу, а вторая нет. Ага, появляется интернет, и ты с улыбкой на лице идешь снова выполнить эти запросы, только на этот раз получишь ошибку, что такая запись уже есть, ибо первая то уже в базе! А в случае использования транзакций, при получении ошибки, мы откатимся до того момента, который был до начала транзакции. А еще все эти радости помогают реляционным БД (базам данных) соответствовать так называемым требованиям ACID, которые нужны для сохранности данных - это очень важно в банковской отрасли, или любой другой, где целостность и сохранность данных супер важны. Давай разберемся с аббревиатурой: Atomicity — атомарность, или же проще говоря, непрерывность: это как раз про транзакции, которые мы обсудили только что. Либо операция выполняется целиком, либо никак. Consistency — согласованность: данные, записываемые в таблицу должны соответствовать всем выставленным правилам и ограничениям, помнишь, мы говорили про первичный и внешний ключи, а также про уникальность? Isolation — изолированность: если вы гоняете тонну транзакций одновременно, они не должны пересекаться и влиять друг на друга. Это очень важно для высоконагруженных баз Durability — надежность: если мы получили подтверждение, что транзакция выполнена, то значит наши данные в сохранности, даже если после этого произошел сбой. Ну и в качестве примеров таких баз данных назовем: Microsoft SQL Server, Oracle Database, MySQL, MariaDB и PostgreSQL.
img
Мы продолжаем заниматься автоматизацией нашей ИТ – инфраструктуры и сегодня хотим рассказать о простом и надежном методе мониторинга IP – АТС Asterisk в типовой SOHO – сети с помощью маршрутизатора Mikrotik. С помощью сетевой утилиты Netwatch мы настроим почтовые уведомления в случае недоступности нашего Asterisk. Что такое Netwatch? В операционной системе Mikrotik Router OS «зашит» достаточно богатый функционал для маршрутизатора его ценовой категории. Одним из очень полезных элементов этого функционала является сетевая утилита Netwatch. Работает она достаточно просто – отправляя через указанный промежуток времени ICMP – запросы маршрутизатор отслеживает состояние хоста, который подлежит мониторингу. Другими словами, роутер отправляет «пинг» на хост через определенный интервал (по умолчанию 1 минута), и если в течении таймаута хост не отвечает, то он считается недоступным. Внимательно отнеситесь к подбору значений interval и timeout, так потенциально, повышенное значение первого может создать излишнюю нагрузку на маршрутизатор, а второй параметр, при наличии большой задержки у вас на сети, может привести к некорректному определению недоступности хоста. Настройка SMTP на Mikrotik Чтобы сетевая утилита работала корректно, необходимо настроить учетную запись. Настройки произведем на примере SMTP от Yandex. Переходим во вкладку Tools -> Email Server - укажите здесь почтовый сервер для исходящей почты smtp.yandex.ru Port - указываем 465 порт для безопасного соединения по протокол SMTP Start TLS - указываем tls only From - адрес электронной почты, который будет в письмах в качестве адреса отправителя User - логин на почтовом сервере Яндекса Password - пароль от почты Нажимаем Apply. Далее, проверим наши настройки. Нажмите на кнопку Send Email: Address - в данном случае наш Микротик преобразовал доменное имя smtp.yandex.ru в IP – адрес. Port - так же указываем 465 User - логин пользователя почтой Password - пароль от почтового аккаунта TLS - отметьте галочкой To - адрес получателя письма From - укажите адрес отправителя Subject - тема письма Body - сообщение По окончанию нажимаем на кнопку Send Email. У нас появилось отправленное письмо: Мониторинг Asterisk с помощью Netwatch После того как мы проверили отправку почты, приступаем к настройке сетевого мониторинга. Переходим во вкладку Tools -> Netwatch: Ранее, мы рассказывали как настроить мониторинг пиров и транков на IP – АТС Asterisk. Host - в данном поле укажите IP – адрес вашего Asterisk Interval - интервал, через который будут отправлять ICMP запросы (пинги) на IP – АТС Asterisk. По умолчанию интервал равен 00:01:00 (1 минута) Timeout - таймаут, в течение которого, хост мониторинга должен ответить на запросы. Если это время будет превышено, то хост будет считаться недоступным. По умолчанию, 1000мс (1 секунда) Далее нажимаем на вкладку Up, в которой необходимо настроить скрипт, который будет отработан при доступности Asterisk. Скопируйте скрипт ниже, предварительно указав в поле to вашу почту : tool e-mail send to=info@merionet.ru subject="Asterisk доступен" body="Asterisk доступен по сети" Далем тоже самое для вкладки Down, в которой будет выполняться скрипт по недоступности Asterisk. Не забудьте изменить почту: tool e-mail send to=info@merionet.ru subject="Asterisk не доступен!" body="Сервер IP – АТС Asterisk не доступен по протоколу ICMP – необходимо проверить" По окончанию настроек нажмите Apply и OK.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59