По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В больших корпоративных сетях, которые занимаются обслуживанием клиентов важно вовремя получать уведомления о неполадках в сети и устранять их. В этом деле администраторам помогают системы мониторинга, которых сегодня в сети существует достаточно много, как платных, так и бесплатных.
Своего рода стандартом в ИТ является PRTG (Paessler Router Traffic Grapher), которая может отправлять уведомления о событиях через e-mail, SMS, Push-уведомлений. Сегодня сложно представить кого-то, кто не пользуется хоть одним мессенджером. Среди них особо выделяется Telegram, который пользуется популярностью благодаря своей безопасности и функционалу. Здесь можно создать своего бота, который будет выполнять все ваши команды исходя из поставленной задачи. В одном из материалов мы рассказывали уже о том, как использовать Telegram для управления "Умным домом".
Здесь же расскажем о том, как интегрировать Telegram в PRTG и получать уведомления не на почту, на Telegram. Принцип работы такой: система мониторинга, в нашем случае PRTG, отправляет сообщения боту, а тот в свою очередь выводит их группу.
Что нам нужно
Telegram аккаунт
Группа, куда будем добавлять нашего бота
Доступ с PRTG сервера на https://api.telegram.org/
Создание бота
Для начала нам нужно создать бота, в чем на поможет "The Botfather". Начинаем новый чат с ним в Telegram:
Командой /newbot под руководством Botfather начинаем создание бота. Задаем ему имя, которое будет отображаться и имя пользователя:
После этих несложных манипуляций получаем API токен нашего бота, который используем в будущем. По умолчанию, бот может быть добавлен в любую группу и может получать сообщения от кого угодно. Ограничить это можно в настройках приватности, которые доступны командами /setprivacy и /setjoingroups.
Далее добавляем бота в группу, где находятся администраторы и другой заинтересованный персонал.
Через группу посылаем боту сообщение /start, чтобы активировать его. Затем уже настраиваем политики приватности, о которых говорилось выше. С созданием бота закончили, теперь нужно настроить получение уведомлений
Настройка уведомлений
Помните, в конце создания бота нам выдали API ключ. Перейдите по следующей ссылке, предварительно подставив вместо <apikey> API ключ вашего бота:
https://api.telegram.org/bot<apikey>/getMe
Вы должны получить что-то подобное:
{ "ok": true, "result": { "id": 1234567890, "first_name": "PRTGNotiBot", "username": "PRTGNotificationBot" }}
Если вышли какие-то ошибки, убедитесь, что API ключ введён правильно. Далее открываем ту же ссылку, только вместо getMe подставляем getUpdates. Мы получим список чатов, в которые добавлен наш бот.
{ "ok": true, "result": [{ "update_id": 521075218, "message": { "message_id": 3, "from": { "id": 11512298, "first_name": "xxxxxxxxx", "last_name": "xxxxxxxxx", "username": "xxxxxxxxx" }, "chat": { "id":-12345690, "title": "[Paessler] IT", "type": "group", "all_members_are_administrators": true }, "date": 1493834122, "text": "/start", "entities": [{ "type": "bot_command", "offset": 0, "length": 6 }] } }]}
Из этого вывода нам нужен идентификатор чата, включая знак "-". Теперь мы готовы создать шаблон уведомления в PRTG. Переходим в Setup > Account Settings > Notifications.
Добавляем новый шаблон уведомления:
Выбираем вводим название шаблона, выбираем тип сенсора (рекомендуем pingsensor)
В качестве шаблона выбираем HTTP. Вводим ссылку https://api.telegram.org/bot<your-api-key>/sendMessage, подставив API токен вашего бота.
В строку Postdata вводим следующие строки:
chat_id=-<your-chat-id>&text=There's a *%status* sensor in your PRTG*Last Message* %lastmessage*Down since* %since*Device* %device*Group* %group&parse_mode=Markdown
chat-id идентификатор чата, который получили выше.
text текст сообщения, который будет отправлять бот. Текст можно изменять по вашему усмотрению.
%status переменная PRTG. Звездочки вокруг него это стиль редактирования Telegram API. Как именно обрабатывать стиль указано в конце текста параметром parse_mode=Markdown.
Если нужно, чтобы уведомление пришло если сеть поднялась, то нужно создать другой шаблон с соответствующим текстом:
chat_id=-123456890&text=%device% is *%status*!&parse_mode=Markdown
Хотя можно совместить это в одном шаблоне, но лучше сделать два отдельных шаблона, на случай если каждому шаблону нужно добавить разные переменные, как в нашем случае.
Затем можно отправить тестовое сообщение, в результате чего должны получить что-то подобное:
Если все прошло успешно, нужно привязать шаблон к конкретному сенсору. Чтобы система не бомбила ваш Telegram из-за незначительных событий, лучше привязать шаблон к сенсору PING. Для этого переходим на вкладку Devices, среди сенсоров нужного устройства наводим курсор мыши на сенсор PING и кликаем на иконку звоночка.
Открывается страница добавления уведомлений. Выбираем Add State Trigger заполняем поля согласно политике организации. Можно сделать как на скриншоте:
Как видно на скриншоте, мы отправляем уведомление только когда сеть упала и поднялась. Повторно не посылаем, чтобы не надоедало.
Вот и всё. Думаю материал окажется полезным для вас.
Сетевая индустрия использует множество терминов и понятий для описания коммутации и маршрутизации, потому что многие термины пересекаются в определениях этих понятий. Это может сбить с толку. Работает ли маршрутизатор маршрутизатором или коммутатором? В чем разница между коммутацией на 3 уровне (L3) и маршрутизацией?
Что бы найти ответы на эти вопросы необходимо разобраться, что происходит с пакетом, когда он проходит через сеть.
Понимание широковещательных и коллизионных доменов
Два основных понятия, которые вы должны понять.
Коммутация. Понятие широковещательного домена и домена коллизий
На рисунке изображена простая сеть, иллюстрирующая эти два понятия.
Домен коллизий определяется как набор хостов, подключенных к сети. В некоторых случаях хосты одновременно не буду передавать пакеты из-за возможного столкновения последних.
Например, если Хост А и хост Б соединены прямым проводом, то они не смогут передавать пакеты одновременно. Однако, если между хостами установлено какое-то физическое устройств, то одновременная передача данных возможна, так как они находятся в отдельных доменах коллизий.
Широковещательный домен-это набор хостов, которые могут обмениваться данными, просто отправляя данные на 2 уровне(L2). Если узел A посылает широковещательный пакет для всех хостов, по локальной сети, и хост B получает его, эти два хоста находятся в одном широковещательном домене.
Широковещательный домен и домен коллизий
Мостовое соединение создает домен коллизий, но не широковещательный домен.
Традиционная коммутация пакетов и мостовое соединение- технически- это одно и то же. Основное различие заключается в том, что в большинстве коммутируемых сред каждое устройство, подключенное к сети, находится в отдельном домене коллизий.
Что же изменяется в формате типичного пакета, когда он проходит через коммутатор?
Рисунок не показывает измения в формате пакетов данных прошедших через коммутатор
Вообще, устройства по обе стороны от коммутатора не "видят", что между ними есть коммутатор, они также не знают назначения своих пакетов; коммутаторы прозрачны для устройств подключенных к сети.
Если узел А хочет отправить пакет на ip-адресс 192.168.1.2 (узел B), он отправляет в эфир широковещательный запрос для всех узлов, подключенных к тому же сегменту сети, запрашивает MAC-адрес хоста с IP-адресом 192.168.1.2 (это называется Address Resolution Protocol (ARP)). Так как узел B находится в том же широковещательном домене, что и узел A, узел A может быть уверен, что узел B получит этот широковещательный запрос и отправит ответный пакет с верным MAC-адресом для обмена пакетами.
Широковещательные домены и домены коллизии в маршрутизации
Сеть построена на основе маршрутизатора не создает широковещательный домен и домен коллизий данная схема приведена на рисунке:
Возникает вопрос, как пакет отправленный с хоста А достигнет хост Б с ip-адресом 192.168.2.1? Хост Ане может отправить широковещательный пакет для обнаружения адреса узла B, поэтому он должен использовать какой-то другой метод чтобы выяснить, как добраться до этого пункта назначения. Откуда узел А знает об этом? Обратите внимание, что после каждого IP-адреса на рисунке выше, есть значение / 24. Это число указывает длину префикса, или количество битов, установленных в маске подсети. Хост А может использовать эту информацию для определения что хост B не находится в том же широковещательном домене (не в том же сегменте), и хост A должен использовать определенный метод маршрутизации для достижения цели, как показано на рисунке ниже.
Теперь, когда хост A знает, что хост B не находится в том же широковещательном домене, что и он, он не может отправить широковещательный запрос для получения адреса хоста B. Как, тогда, пакету, отправленному с узла А, добраться до узла B?
Отправляя свои пакеты к промежуточному маршрутизатору, Хост A помещает в заголовок пакета IP-адрес хоста B, а также еще MAC-адрес промежуточного маршрутизатора, как показано на рисунке.
Узел А помещает MAC-адрес маршрутизатора в заголовок пакета. Маршрутизатор принимает этот пакет, приходящий из сети. Далее маршрутизатор проверяет IP-адрес назначения и определяет, какой наиболее короткий маршрут построить и сравнивает данные из пакета с таблицей маршрутизации (в данном случае сравниваются данные хоста B), и заменяет MAC-адрес правильным MAC-адресом для следующего перехода. Затем маршрутизатор пересылает пакет в другой сегмент, который находится в другом широковещательном домене.
Коммутация L3
Коммутация 3 уровня очень похожа на маршрутизацию, как показано на рисунке ниже (обратите внимание, что это то же самое, что изображено на рисунке выше). Это связано с тем, что коммутация 3 уровня является маршрутизируемой; Нет никакой функциональной разницы между коммутацией 3 уровня и маршрутизацией.
Автоматизировать свою IP – АТС Asterisk с каждым днем всё больше и больше нам приносит невероятное удовольствие. Поэтому, сегодня хотим вам поведать о том, как сократить расходы на звонки сотрудников в командировках, или просто находящихся вне офиса с помощью модуля FreePBX - DISA
/p>
Что такое DISA?
Представьте – выходной день, вы находитесь у себя на даче и спокойно поливаете свои любимые бархатцы на клумбе. Вдруг на телефон приходит смс – сообщение, о том, что один из самых прибыльных ваших клиентов из города Владивосток звонил, и не смог дозвониться. Что – то срочное, подумали вы, надо бы перезвонить. Но сколько будет стоить звонок в столицу приморского края? Интернета нет на ближайшие 20 километров, и позвонить через софтфон не получится. Тут на помощь приходит модуль DISA.
Взяв руки свой мобильный телефон, вы набираете номер вашей офисной IP – АТС Asterisk. Из голосового меню, нажимаете спасительные цифры 0897 и попадаете в сам модуль. Приятный голос спрашивает, не могли бы вы ввести пин – код, и, конечно, вы набираете на клавиатуре 384701. Гудок. Вы набираете номер клиента во Владивостоке. Через несколько секунд на том конце трубке раздается голос вызываемого абонента.
Скажем прямо, клиент был приятно удивлен, что в выходной день вы позвонили ему из офиса (у него определился номер вашей офисной IP – АТС Asterisk). Вы быстро решили все вопросы и вернулись.
Хотите такой же функционал? Сейчас расскажем как его настроить.
Настройка модуля DISA
Переходим к настройке модуля. Перейдите во вкладку Applications -> DISA. Нажмите на кнопку + Add DISA
Перед нами откроется форма настройки. Разберемся конкретно по каждому из пунктов:
DISA Name - название DISA. Создавайте названия, которые помогут вам проще понимать для чего создавалась конкретная опция, чтобы избежать путаницы в будущем.
PIN - при попадании на DISA, у пользователя будет запрошено ввести пароль, указанный в данном поле.
Обязательно создавайте PIN на DISA.Потенциально, злоумышленник, который получит доступ к этому модулю, сможет совершать звонки с телефона вашей компании. Это могут быть как финансовые, так и репутационные риски.
Response Timeout - если вы укажите номер, который не будет подходить по формату, то система будет ожидать время, указанное в данном поле, а после, разорвет соединение. По умолчанию 10 секунд. .
Digit Timeout - время, которое система отводит на ввод 1 цифры вызываемого номера. Например, когда номер будет полностью набран, лишь через 5 секунд DISA совершит на него звонок.
Call Recording - записывать ли звонки, совершаемые через модуль DISA.
Require Confirmation - запрашивать ли подтверждение о начале работы с модулем до того, как запрашивать пароль.
Caller ID -не обязательное поле. При совершении вызовов, система может подставлять определенный CallerID. Например, это может пригодиться для сбора статистики. Формат вода таков: "Имя" <123456789>
Context - в этом поле, вы можете указать контекст обработки исходящего от АТС вызова. Советуем оставить это поле по умолчанию – "from – internal"
Allow Hangup - позволяет завершить новый вызов с помощью нажатий сервисного кода (**)
По окончанию настроек, нажмите Submit и затем Apply Config. В списке настроек модуля появится наш новый DISA:
Настройка доступа к DISA из IVR
Перейдем к настройке доступа к DISA из IVR. Как мы сказали ранее, для доступа к модулю мы будем звонит на голосовое меню и набирать 0897. Итак, переходим в вкладку Applications -> IVR и начинаем редактировать наше существующее IVR – меню. Листаем в самый низ,до пункта IVR Entries и делаем настройку, как указано ниже:
Сохраняем конфигурацию. Готово, теперь мы будем экономить на звонках даже находясь в командировка, или на отдыхе.