По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье пойдет речь о модуле под названием Configuration File Editor, модуле, который позволяет редактировать дополнительные (custom) файлы конфигурации в браузере – обычно эти файлы редактируются с помощью CLI или сторонних программ, таких как WinSCP.
Что бы открыть данный модуль, необходимо в выпадающем меню вкладки Admin -> Config Edit
Как видно выше – в модуле можно создать новый файл, и так же доступны две вкладки:
Asterisk Custom Configuration Files – данные файлы можно редактировать, практически все Custom файлы изначально пустые. Кроме того, можно создавать совершенно новые файлы. Важно помнить, что после создания нового файла необходимо будет применить конфиг с помощью кнопки Apply Config
Asterisk System Configuration Files – данные файлы являются системными и их нельзя редактировать в данном модуле
Обратите внимание на надпись «File is not writable» - кнопки «Save» и «Delete» так же неактивны.
Важно:
Для подключения custom файла в оригинальном файле должна быть запись следующего вида:
include ***_custom.conf
Однако, через данный модуль добавить данную строчку невозможно, но, в большинстве системных файлов данные команды уже присутствуют.
Если же вы создадите новый файл, с помощью кнопки + Add New File, то необходимо будет всё же использовать CLI для его подключения. К примеру, для использования файла test_newsettings_custom.conf, необходимо будет в нужный для вас системный .conf файл (который является системным файлом) прописать следующую строку:
include test_newsettings custom.conf
От себя добавлю, что чаще всего данный модуль может пригодиться не для редактирования, а для просмотра нужных вам файлов.
Hiya! Merion Metrics our call stats (CDR) application for Asterisk, it shows the most important diagrams and call graphs as well as call history in an easy and convenient format. Showing call stats this way makes them easy to understand for everyone - from CEO to an office manager
About Merion Metrics
Short description of Merion Metrics:
Full statistics - the most important info only: date, time, source and destination of a call, as well as it’s recording;
Free trial - try the whole spectrum of these features - completely for free;
Easy and quick installation - we are always here to help you;
Cross-platform - developed in Java. Compatible with any UNIX platform;
For supervisors - Got tired of heavy and awkward CDR interface in FreePBX? Or maybe you experienced something similar with CDR Viewer? we know that feeling;
Easy to export in PDF and CSV - export all your calls into PDF and send it over to your colleagues in an easy readable format;
Try Merion Metrics for free:
Try Merion Metrics
Merion Metrics Installation
Attention! You should to have a license key from our support team at this point. You can get it by follow link: https://asterisk.merionet.ru/merionmetrics
Of course for your convenience we have a step by step video guide. Enjoy :)
Installation video - guide
Installation guide by plain text
System Requirements
RAM: 256 MB min
CPU: Pentium 2 266 МГц + минимум
Java Runtime Environment (JRE): version 8+
Browser: Internet Explorer 9+
Preparation
Firstly, connect to your Asterisk via SSH using user root.
Directory creation for the app
Run the following commands:
mkdir /home/merionstat
Upload app distro MerionMonitoring-*.*.*.jar into the directory you’ve just created: /home/merionstat. You can do that using WinSCP, for example.
Important: App distro will have a certain version number. Here, in the installation guide, we always put version number as MerionMonitoring-*.*.*.jar. In your case it will be something like MerionMonitoring-1.1.9.jar.
SQL user creation
Follow the link that will generate an uncrackable password and right it down on save it somewhere. After that, execute the following command sequence:
mysql
CREATE USER 'interface'@'localhost' IDENTIFIED BY 'your_password';
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY 'your_password';
Where your_password - some freshly generated password from the link above пароль. For example:
mysql
CREATE USER 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz';
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz';
And yet another reminder – save your password somewhere else.
Call recordings directory
For sake of playing call recordings through our app, you have to do the following:
Generate another password via our password generator and save it;.
Execute the following commands:
mkdir /var/www/html/generated_password
chown asterisk:asterisk /var/www/html/generated_password
chmod 775 /var/www/html/generated_password
For example:
mkdir /var/www/html/5v9MpbtUA8
chown asterisk:asterisk /var/www/html/5v9MpbtUA8
chmod 775 /var/www/html/5v9MpbtUA8
Open file /etc/fstab and add there the following sequence:
/var/spool/asterisk/monitor/ /var/www/html/generated_password/ none rbind 0 0
For example:
/var/spool/asterisk/monitor/ /var/www/html/5v9MpbtUA8/ none rbind 0 0
Save all the changes in fstab file. After that, execute the following command in CLI:
mount -a
Start
Application launch
Run the following commands:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar &
Right after command’s execution press Enter.
Application setup
The first connection
After launching .jar archive, please open the following address in your web-browser: http://your_IP_address:7070/#!/config (You can use any browser, we recommend using Google Chrome). Once it opened, enter your license key – you can get it from our support engineer.
Click “Check the license”. If you encounter any kind of a problem during that phase, please address it to our technical support team: helpdesk@merionet.ru.
After that you have to pass the initial authorization, and to do that, you need to use the following credentials: admin/IEJu1uh32
On the next step you’ll need to configure database connection. If you are using Asterisk IP - PBX, just follow the guide:
Database - mysql or mariadb;
DB host:
If your DB installed on the same server as our application - localhost;
If your DB installed on some kind of external server - IP_address_of_your_database;
DB port - is being set up automatically, so please change it only if your DB is listening for requests on another port;
DB connection string - leave this without changes;
Table name - In case of Asterisk it’s cdr;
Scheme - that should be the name of database, for Asterisk it’s asteriskcdrdb;
User - You created the user some time ago in “SQL user creation” part of this guide. If you copied all the commands without any changes – that would be interface;
Password - the one you’ve probably generated using our password generator;
Voice recordings host - link like http://your_ip_address/generated_password/, where generated_password is a sequence you created on a previous stage Call recordings directory. So, it’s gonna be something like http://192.168.1.7/5v9MpbtUA8/;
Station type - Asterisk;
After you finish all the above, click “Connect”. If something went wrong, address the issue to our support team helpdesk@merionet.ru.
On the next step, you have to match field name in the table with it’s actual meaning. In case of Asterisk you can leave everything as it is.
At the bottom of this page click the button “Set the matches” and “Launch the Application”. Our app will redirect you to the application’s initial page. By default, administrator’s login and password are: admin/admin
Known issues
Application is already launched
If you can’t open the app using the default link http://IP_ADDRESS:7070/#!/config, please check if it wasn’t launched before. To do so, please run the command below:
ps aux | grep Merion
Analyze the command output:
root 4919 0.1 13.1 2120384 801784 ? Sl Dec11 19:12 java -jar MerionMonitoring-*.*.*.jar
If you see something similar, you have to kill the process using it’s PID (marked with orange in output example above). So execute the following command:
kill -9 4919
Check the output again: ps aux | grep Merion
If the one you’ve seen before is gone, then you can try to lauch it again:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar &
Database on the external server
If you are connecting to an external data base, you need to add some additional configuration for MySQL settings, that you’ve done in “SQL user creation”. You might need it if you install call stats app on a different server, not the one you have Asterisk installed on.
In this case you need to run the following commands on the server where you have your DB (usually it’s your Asterisk server):
mysql
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'IP_адрес_интерфейса' IDENTIFIED BY ''your_password';
Where:
your_password - password generated with our our tool;
Call_stats_app_IP_ADDRESS - IP-address of the server where you decided to install our Call Stats Application.
For example:
mysql
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'192.168.1.78' IDENTIFIED BY '6nzB0sOWzz';
Also, please check that the following ports are open:
3306 - for MySQL and MariaDB;
5432 - for PostgreSQL.
Slow data loading
If you are experiencing some issues with data download – it might be related to the big size of your database.
We recommend to launch our app (.jar file) with some additional keys. According to the “Application launch”, run the following command:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar -Xms128m -Xmx256m &
Where:
-Xms128m - minimal amount of RAM available for the app. In our example – it’s 128 Megabytes.
-Xmx256m - maximum amount of RAM available for the app. In our example – it’s 256 Megabytes;
How to send a request to our support team?
If you are experiencing any technical issues with configuration of our app – we will definitely help you. We’ll need the files from /home/merionstat directory – the one where you’ve put our distro MerionMonitoring-*.*.*.jar, according to step “Directory creation for the app”.
Depending on the phase where you’ve encountered any technical issues, you might have the following files there:
columns_mapping.cfg
configuration.properties
nohup.out
Please send us those files and description of your issue – we’ll try to help you.
Telegram - @merion_support_bot
Email - helpdesk@merionet.ru
Прочитайте материал про реактивное и упреждающее распределение достижимости в сетях.
Есть много случаев, когда более эффективно или в соответствии с конкретными ограничениями политики для плоскости управления изучать информацию о достижимости и топологии с другой плоскости управления, а не с помощью механизмов, описанных до этого момента в этой серии статей. Вот некоторые примеры:
Две организации должны соединить свои сети, но ни одна из них не хочет позволить другой контролировать политику и работу своих плоскостей управления;
Крупная организация состоит из множества бизнес-единиц, каждая из которых имеет возможность управлять собственной внутренней сетью в зависимости от местных условий и требований приложений.
Организация должна каким-то образом позволить двум плоскостям управления взаимодействовать при переходе от одной к другой.
Причины, по которым одна плоскость управления может получать информацию о доступности от другой, почти безграничны. Учитывая это требование, многие сетевые устройства позволяют операторам перераспределять информацию между плоскостями управления. При перераспределении достижимости возникают две проблемы, связанные с плоскостью управления: как обрабатывать метрики и как предотвращать петли маршрутизации.
Примечание. Перераспределение можно рассматривать как экспорт маршрутов из одного протокола в другой. На самом деле импорт/экспорт и перераспределение часто используются для обозначения одного и того же, либо разными поставщиками, либо даже в разных ситуациях одним и тем же поставщиком.
Перераспределение и метрики
Взаимосвязь между свойствами связи, политиками и метриками определяются каждым протоколом плоскости управления независимо от других протоколов. Фактически, более описательная или более полезная метрическая система - это то, что иногда привлекает операторов к определенному протоколу плоскости управления. На рисунке 12 показаны два участка сети, в которых работают две разные управляющие плоскости, каждая из которых использует свой метод расчета метрик связей.
Протоколы X и Y в этой сети были настроены с использованием двух разных систем для назначения показателей. При развертывании протокола X администратор разделил 1000 на скорость соединения в гигабитах. При развертывании протокола Y администратор создал "таблицу показателей" на основе наилучшего предположения о каналах с самой высокой и самой низкой скоростью, которые они могут иметь в течение следующих 10-15 лет, и назначил метрики для различных скоростей каналов в этой таблице. Результат, как показывает рисунок, несовместимые показатели:
10G каналы в протоколе X имеют метрику 100, в то время как в протоколе Y они имеют метрику 20.
100G-каналы как в протоколе X, так и в протоколе Y имеют метрику 10.
Предполагая, что более низкая метрика предпочтительна, если метрики добавлены, канал [B, C, F] будет считаться более желательным путем, чем канал [B, D, G]. Однако, если учитывать пропускную способность, оба канала будут считаться одинаково желательными.
Если между этими двумя протоколами настроено перераспределение, как следует обрабатывать эти метрики? Есть три общих решения этой проблемы.
Администратор может назначить метрику в каждой точке перераспределения, которая передается как часть внутренней метрики протокола. Например, администратор может назначить метрику 5 для пункта назначения E на маршрутизаторе C при перераспределении из протокола X в Y. Этот пункт назначения, E, вводится в протокол Y с метрикой 5 маршрутизатором C. На маршрутизаторе F метрика для E будет от 25 для C. В G стоимость достижения E будет 35 по пути [F, C]. Желательность использования любой конкретной точки выхода для любого конкретного пункта назначения выбирается оператором при назначении этих ручных метрик.
Метрика "другого" протокола может быть принята как часть внутренней метрики протокола. Это не работает в случае, когда один протокол имеет более широкий диапазон доступных метрик, чем другой. Например, если протокол Y имеет максимальную метрику 63, метрики 10G из протокола X будут "выше максимума"; ситуация, которая вряд ли будет оптимальной. При отсутствии такого ограничения маршрутизатор C внедрит маршрут к E со стоимостью 100 в протокол Y. Стоимость достижения E на маршрутизаторе F составит 110; стоимость в G будет от 130 до [F, C].
Примечание. Здесь вы можете увидеть компромисс между состоянием плоскости управления и оптимальным использованием сети, это еще один пример компромисса сложности при проектировании реальных протоколов. Перенос внешней метрики в отдельное поле добавляет состояние плоскости управления, но позволяет более оптимально управлять трафиком через сеть. Назначение или использование внешней метрики снижает состояние плоскости управления, но за счет возможности оптимизации потока трафика.
Внешняя метрика может быть перенесена в отдельное поле, поэтому каждое сетевое устройство может отдельно определять лучший путь к каждому внешнему адресату. Это третье решение является наиболее широко используемым, поскольку оно обеспечивает наилучшую возможность управления трафиком между двумя сетями. В этом решении C вводит достижимость для E с внешней стоимостью 100. В F есть две метрики в объявлении, описывающие достижимость для E; внутренняя метрика для достижения точки перераспределения (или выхода) - 20, а метрика для достижения точки E во внешней сети - 100. В G внутренняя метрика для достижения точки выхода - 30, а внешняя метрика - 100.
Как реализация будет использовать оба этих показателя? Следует ли протоколу выбирать ближайшую точку выхода или, скорее, самую низкую внутреннюю метрику? Это позволит оптимизировать использование локальной сети и потенциально деоптимизировать использование сетевых ресурсов во внешней сети. Должен ли протокол выбирать точку выхода, ближайшую к внешнему назначению, или, скорее, самую низкую внешнюю метрику? Это позволит оптимизировать сетевые ресурсы во внешней сети, потенциально за счет деоптимизации использования сетевых ресурсов в локальной сети. Или протоколу следует попытаться каким-то образом объединить эти две метрики, чтобы максимально оптимизировать использование ресурсов в обеих сетях?
Некоторые протоколы предпочитают всегда оптимизировать локальные или внешние ресурсы, в то время как другие предоставляют операторам возможность конфигурации. Например, протокол может позволять переносить внешние метрики в виде метрик разных типов, при этом один тип считается большим, чем любая внутренняя метрика (следовательно, сначала предпочтение отдается самой низкой внутренней метрике и использование внешней метрики в качестве средства разрешения конфликтов), а другой тип - это когда внутренние и внешние метрики считаются эквивалентными (следовательно, добавляются внутренние и внешние метрики для принятия решения о пути).
Перераспределение и петли маршрутизации
В приведенном выше обсуждении вы могли заметить, что места назначения, перераспределенные с одного протокола на другой, всегда выглядят так, как будто они подключены к перераспределяющему маршрутизатору. По сути, перераспределение действует как форма резюмирования (что означает, что удаляется информация о топологии, а не информация о достижимости), как описано ранее в этой серии статей. Хотя этот момент не является критическим для показателей перераспределения, важно учитывать способность плоскости управления выбирать оптимальный путь. В некоторых конкретных случаях деоптимизация может привести к тому, что плоскость управления не сможет выбрать пути без петель. Рисунок 13 демонстрирует это.
Чтобы построить петлю маршрутизации в этой сети:
Маршрут к хосту A перераспределяется от протокола X к Y с вручную настроенной метрикой 1.
Маршрутизатор E предпочитает маршрут через C с общей метрикой (внутренней и внешней) 2.
Маршрутизатор D предпочитает маршрут через E с общей метрикой 3.
Маршрутизатор D перераспределяет маршрут к хосту A в протокол X с существующей метрикой 3.
Маршрутизатор B имеет два маршрута к A: один со стоимостью 10 (напрямую) и один с метрикой от 4 до D.
Маршрутизатор B выбирает путь через D, создавая петлю маршрутизации.
И так далее (цикл будет продолжаться, пока каждый протокол не достигнет своей максимальной метрики).
Этот пример немного растянут для создания цикла маршрутизации в тривиальной сети, но все циклы маршрутизации, вызванные перераспределением, схожи по своей структуре. В этом примере важно, что была потеряна не только топологическая информация (маршрут к A был суммирован, что, с точки зрения E, было непосредственно связано с C), но и метрическая информация (исходный маршрут со стоимостью 11 перераспределяется в протокол Y со стоимостью 1 в C). Существует ряд общих механизмов, используемых для предотвращения формирования этой петли маршрутизации.
Протокол маршрутизации всегда может предпочесть внутренние маршруты внешним. В этом случае, если B всегда предпочитает внутренний маршрут A внешнему пути через D, петля маршрутизации не образуется. Многие протоколы маршрутизации будут использовать предпочтение упорядочивания при установке маршрутов в локальную таблицу маршрутизации (или базу информации о маршрутизации, RIB), чтобы всегда отдавать предпочтение внутренним маршрутам над внешними. Причина этого предпочтения состоит в том, чтобы предотвратить образование петель маршрутизации этого типа.
Фильтры можно настроить так, чтобы отдельные пункты назначения не перераспределялись дважды. В этой сети маршрутизатор D может быть настроен для предотвращения перераспределения любого внешнего маршрута, полученного в протоколе Y, в протокол X. В ситуации, когда есть только два протокола (или сети) с перераспределенной между ними информацией плоскости управления, это может быть простым решением. В случаях, когда фильтры необходимо настраивать для каждого пункта назначения, управление фильтрами может стать трудоемким. Ошибки в настройке этих фильтров могут либо привести к тому, что некоторые пункты назначения станут недоступными (маршрутизация черных дыр), либо приведет к образованию петли, потенциально вызывающей сбой в плоскости управления.
Маршруты могут быть помечены при перераспределении, а затем отфильтрованы на основе этих тегов в других точках перераспределения. Например, когда маршрут к A перераспределяется в протокол Y в C, маршрут может быть административно помечен некоторым номером, например, 100, чтобы маршрут можно было легко идентифицировать. На маршрутизаторе D можно настроить фильтр для блокировки любого маршрута, помеченного тегом 100, предотвращая образование петли маршрутизации. Многие протоколы позволяют маршруту нести административный тег (иногда называемый сообществом или другим подобным именем), а затем фильтровать маршруты на основе этого тега.