Web-интерфейс для вашей asterisk. статистика для call-центров, отделов продаж, прослушивание звонков и многое другое

Введение

Я буду использовать очень простую проверку. В интернете находится много рецептов по мониторингу asterisk с помощью zabbix. Есть готовые наборы скриптов на питоне, есть шаблоны. Можно настроить мониторинг практически всего, что только пожелаешь.

Мне не хотелось во всем этом разбираться и нагромождать в систему, так как нужно только состояние транков — зарегистрирован или нет. Усложнять чем-то еще свои системы мониторинга не хотелось. Больше никакие данные мне не нужны. Я стараюсь настраивать мониторинг только тех параметров, которые реально необходимы. Это позволяет экономить время и ресурсы сервера.

С помощью простого sh скрипта я буду проверять суммарное количество транков в системе и сравнивать это число с числом зарегистрированных транков. Если разница этих чисел будет отлична от нуля, значит как минимум одна регистрация отвалилась. Нужно на всякий случай проверить сервер и выяснить причину.

После этой проверки можно тем же скриптом и перезапустить регистрации, но я в статье ограничусь только мониторингом состояния. Лично мне перезапуск в данном случае не нужен, так как ситуации бывают редко и я хочу сам проверить, почему регистрации отвалились.

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

  1. Установка CentOS 8.
  2. Настройка CentOS 8.
  3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

  1. Установка Debian 10.
  2. Базовая настройка Debian.
  3. Установка и настройка zabbix на debian.

Если у вас есть вопросы по настройке Asterisk, рекомендую мою очень подробную статью на эту тему. Там разобран на примерах основаной функционал современной ip атс.

Для отладки и тестирования работы voip я рекомендую сервис Zadarma. Плюс его в том, что после регистрации вы получите настройки пира для внутренней сети оператора. И внутри этой сети вы можете бесплатно звонить. Например, я одного пира регистрирую на sip клиенте смартфона и с него звоню на второй аккаунт, пир от которого настроен в астериске. Таким образом эмулирую внешний звонок. Удобно отлаживать различные конфигурации звонков, не требуя платного подключения.

Мониторинг asterisk в zabbix сервере

Всю теорию я изложил выше. Осталось только добавить готовый шаблон на сервер и посмотреть на результат. Скачиваем шаблон — zabbix-asterisk-template.xml и импортируем его на сервер. В шаблоне присутствуют 6 элементов данных, которые мы определили в агенте, 5 триггеров и 1 график просто для красоты, чтобы был :). В этом шаблоне надобности в графиках нет. Остановлюсь подробнее на триггерах.

Таблица триггеров в шаблоне мониторинга asterisk
Asterisk down on {HOST.NAME} Срабатывает, если последняя проверка количества запущенных процессов астериск вернула 0.
Asterisk restarted on {HOST.NAME} Тригер реагирует на изменение uptime службы. Если он стал меньше 300 секунд, то считается, что служба была перезапущена.
Fail2ban down on {HOST.NAME}  Срабатывает, если последняя проверка количества запущенных процессов fail2ban вернула 0.
Fail2ban inactive on {HOST.NAME}  Проверяет, есть ли в правилах iptables цепочки fail2ban. Если нет, срабатывает.
Trunk not registered on {HOST.NAME}  Срабатывает, если хотя бы одна из регистраций отвалилась.

Первые 4 триггера очевидны, по ним комментировать нечего. Остановлюсь на последнем с проверкой транков. Данный триггер проверяет текстовую строку «All trunks are online», которую возвращает итем. Если 2 раза подряд ее не было, значит проблема, и идет оповещение. Проблема закрывается, когда она же появляется 2 раза подряд. Сделал специально 2 проверки, чтобы не было ложных срабатываний на моментах перерегистрации или кратковременных сбоев, которые не требуют вмешательства.

После применения шаблона на хостах, увидите примерно такую картинку в «Последних данных».

Если какой-то транк отвалится, то в оповещении на почте будет его название. У меня вот так выглядят подобные оповещения.

На этом по мониторингу asterisk в zabbix все. Надеюсь, раскрыл тему достаточно подробно и понятно.

Настройки

  • «Основные»Путь к файлам записей разговоров, ваш логотип, отображать ли статус АТС, и прочие настройки разместились здесь. Также, внизу страницы, найдутся демон для синхронизации данных АТС в облачную версии и инструкция по его настройке.
  • «Номера»
    • «Внешние»
      На этой страничке нужно внести все ваши «городские» номера и понятную легенду (например, «Москва», «Питер», «Реклама» и т.д.) для них.
    • «Внутренние»
      Началом работы с настройкой служит кнопка «Загрузить номера из БД».
      Она подтянет соответствие внутренний_номер <-> callerid из базы данных (в запросе используются все звонки за последний год).
      Далее список ведется вручную, вы можете исправить его, дополнить, а также задать пароль для каждого сотрудника, дабы он мог авторизоваться и посмотреть свои звонки.
  • «Группы»
    Группировать внутренние номера полезно в случае, если их очень много или нужно разделение, например, на отделы или смены. Список всех групп выглядит следующим образом:
    Добавлять/удалять сотрудников можно по одному, используя мультиселект (ctrl/cmd + ЛКМ):
    и поиск:
  • «Супервизоры»
    Именно здесь администратор редактирует список супервизоров и назначает им доступ к отчетам групп и очередей.
    Меню настройки супервизора похоже на настройку групп, есть все те же возможности.
    Вот как оно выглядит:
  • «Комментарии»
    Внесите необходимые комментарии, и после сможете выставить один из них для любого звонка в группе табличных отчетов.

Параметры мониторинга asterisk

В интернете есть примеры мониторинга asterisk. Кое-что я оттуда подсмотрел, но готового решения, которое бы мне подошло полностью, я не увидел, поэтому решил сделать по-своему. Я подумал в решил, что мне полезны для мониторинга следующие метрики:

  1. Состояние транков. Если один из них отваливается, я узнаю о его имени уже в оповещении на почте.
  2. Состояние самой службы asterisk на сервере. Тут все просто — либо работает, либо нет.
  3. Состояние работы программы fail2ban. Тоже все просто — либо работает, либо нет.
  4. Наличие цепочек fail2ban в таблице iptables. Эта проверка гарантирует, что fail2ban не только запущен, но и успешно блокирует нарушителей.
  5. Факт перезапуска сервиса asterisk. Как бонус к этой метрике — uptime службы астериска.
  6. Количество активных разговоров в данный момент.

Небольшие комментарии к метрикам. Если сервер смотрит в интернет, то обязательно наличие iptables и fail2ban. Боты будут регулярно к вам стучаться и перебирать учетки. Так что следить за работой этих служб необходимо. По транкам я уже сказал, это один из основных параметров, так как время от времени они отваливаются. Гораздо чаще, чем сами сервисы. На всякий случай будем следить за работой сервиса астериск на сервере. Он хоть у меня обычно и не падает, даже не припомню такого, но теоретически с ним это может происходить. Мониторинг перезагрузки и аптайма службы сделан в основном для любопытства. Практической пользы в этой метрике я не вижу, если вы единственный админ на сервере и без вас его никто не перезапускает. Мониторинг за количеством активных звонков в asterisk сделан для того, чтобы можно было оценить примерную нагрузку и занятость линий.

Я больше не придумал, на что еще стоит обратить внимание. Некоторые считают количество звонков в день, количество транков, пиров, их статус

Я лично не вижу в этом большого смысла. Если кто-то считает, что есть еще важные параметры в asterisk, которые надо мониторить, прошу поделиться.

Анализ sip трафика asterisk с помощью sngrep

Давайте посмотрим, что у нас происходит во время регистрации у провайдера. В данном случае это проект zadarma. Запускаем в одной консоли sngrep, а в другой выполняем команду, в результате которой в том числе обновятся все регистрации.

# asterisk -rx "sip reload"

Смотрим консоль с sngrep. Там появилась строка с командой register.

Выбираем ее и жмем Enter. Проваливаемся в более подробную информацию о событии. Направления стрелок указывают направления передачи информации. Сначала наш сервер отправил запрос на регистрацию.

Потом удаленный сервер прислал ответ о том, что все в порядке.

Обращаю внимание на выделенный параметр expires=120. Это время действия регистрации, которую установил для нас сервер

Она равна двум минутам. Если мы посмотрим на левый столбец последнего скрина, то заметим, что повторный запрос на регистрацию нашим сервером был отправлен через 105 секунд. Это время expires — 15 секунд.

Дальше подключим нового абонента к нашему серверу и посмотрим на его регистрацию. Это будет софтофон с номером 100.

Смотрим подробности обмена информацией.

Клиент с user-agent 3CXPhone запросил регистрацию с временем 120. Наш сервер зарегистрировал его с указанными параметрами.

Теперь предположим, что к нам подключается очень много клиентов и мы хотим увеличить интервал регистрации с 120 секунд до 600 (10 минут), чтобы на сервер сыпалось поменьше запросов. Мы можем указать этот параметр на стороне каждого клиента, но это более хлопотно. Вместо этого изменим минимальное время регистрации на сервере. Проверим, какое оно установлено сейчас.

# asterisk -rx "sip show settings" | grep "Reg. min duration\|Reg. max duration\|Reg. default duration"

Reg. min duration 60 secs
Reg. max duration: 3600 secs
Reg. default duration: 120 secs

Изменим параметр Reg. default duration и Reg. min duration до 600 секунд. Для этого добавляем в sip.conf в блок параметры.

defaultexpiry=600
minexpiry=600

Перечитываем настройки.

# asterisk -rx "sip reload"

Открываем в консоли sngrep и снова подключаемся тем же софтфоном. Проверяем регистрацию.

Клиент шлет запрос с Expires: 120, мы ему подтверждаем регистрацию с нашим временем — 600.

Повторно за регистрацией абонент придет теперь только через 10 минут.

Главная

  • «Общая», где представлена информация о всех поступивших на АТС звонках в разрезе внешних («городских») номеров.
    Скриншот верхней части страницы был до ката, ниже идут диаграммы и график:
  • «Очереди и Группы», в котором отображена информация о входящих звонках:
    Здесь можно выбрать одновременно все очереди (повторюсь — очереди Asterisk), или одну/несколько необходимых.
    Скриншоты отчета по исходящим звонкам под спойлером ниже, дабы не нагружать пост
    Отчет строится по всем исходящим вызовам сотрудников вовне, либо в разрезе группы, которую вы можете создать в «Настройки — Группы».
  • оценить «выхлоп» рекламной компании, где вы указали определенный номер телефона
  • понять какой номер наиболее «популярен» у клиентов
  • узнать соотношение принятых/пропущенных к поступившим на АТС звонкам в целом
  • получить картину по входящим звонкам как по очереди(ям) так и по каждому оператору в отдельности
  • отследить количественные и качественные характеристики исходящих вызовов сотрудников

«Главная»«Звонки»

Настройка zabbix-agent

Для мониторинга за asterisk, я буду использовать один скрипт и несколько обработанных выводов из запросов к астериску. Начнем со скрипта. Он будет проверять статус транков и если какой-либо из них будет в offline, назовет его. Кладем этот скрипт в директорию /etc/zabbix/scripts.

Я все прокомментировал. Добавлю только пояснение к регулярке, которая определяет проблемные транки. Я знаком со следующими состояниями транков, когда они не работают:

  • Request Sent
  • No Authentication
  • Auth. Sent
  • Rejected

Соответственно, эти состояния я и ищу. Если один из транков находится в одном из этих состояний, то он считается проблемным.

Далее создаем файл конфигурации zabbix с UserParameters в /etc/zabbix/zabbix_agentd.d.

Некоторые из приведенных метрик требуют права root для своего исполнения. Скажу честно, мне было лениво разбираться с разрешениями и я просто запустил zabbix с правами root. Для этого в его конфиге /etc/zabbix/zabbix_agentd.conf раскомментировал следующую строку:

После этого можно перезапустить zabbix-agent и проверить работу будущих итемов.

Проверяем, насколько корректно агент возвращает указанные значения.

Все в порядке. В завершении настройки агента, поясню некоторые моменты для тех, кто не очень разбирается в bash скриптах. Для мониторинга статусов служб я просто вывожу список всех процессов, вычленяю из него нужный мне процесс, в данном случае asterisk или fail2ban и подсчитываю количество этих процессов. Далее в шаблоне я просто буду проверять число этих процессов. Если оно будет равно 0, значит процессы не работают.

Для анализа цепочки iptables я также обрабатываю ее вывод, ищу строки со словами fail2ban и подсчитываю их количество. Если они равны 0, значит fail2ban не работает, либо работает, но не добавляет правила в iptables, что по большому счету и равно тому, что он не работает.

Для мониторинга активных разговоров, я обрабатываю соответствующий вывод asterisk, вырезаю лишние строки и оставляю только необходимое мне число.

Дополнительные материалы по Zabbix

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:

  • Знания, ориентированные на практику;
  • Реальные ситуации и задачи;
  • Лучшее из международных программ.
Рекомендую полезные материалы по Zabbix:
Настройки системы
  • Установка 4.0
  • Обновление 3.0 -> 3.2
  • Обновление 3.4 -> 4.0
  • Установка Zabbix Proxy
  • Работа на NGINX

Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу.

Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0.

Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями.

Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах.

Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm.

Мониторинг служб и сервисов
 
  • Температура процессора
  • Nginx и php-fpm
  • Mysql репликация
  • Службы Linux
  • Рейд mdadm
  • Транки Asterisk
  • Synology

Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов.

Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров.

Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы.

Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks)

Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция.

Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix.

Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix.

Мониторинг различных значений
  • Мониторинг сайта
  • Мониторинг бэкапов
  • Размер бэкапа
  • Делегирование домена
  • Значения из текстового файла
  • Мониторинг логов

Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту.

Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time.

Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов.

Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены.

Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix.

Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога.

Звонки

  • «Внешние звонки»
    Покажет все звонки, поступившие извне на АТС или совершенные ее абонентами вовне. Делится на входящие и исходящие и позволяет искать звонки по очередям и/или группам.
    Помимо очереди(ей), в фильтре для входящих можно выбрать группу (например, если в диалплане после Queue() идет Dial(), то звонки тоже найдутся).
    В дополнение к основным фильтрам: дата, очередь(и) и/или группа, под спойлером есть еще ряд дополнительных. Вот как это выглядит:
    Переключим плашку Звонки: вверху страницы на «Исходящие»
    Фильтр несколько отличается, но в целом все тоже самое.
    Также отмечу, что дополнительные фильтры могут искать звонки как по внутреннему номеру абонента так и по его ФИО (соответствие ФИО номеру задается в «Настройки — Номера — Внутренние», расскажу чуть позже)
  • «Внутренние звонки»
    Отчет найдет вам все звонки между внутренними номерами, т.е. абонентами АТС.
    Подробно останавливаться не стану, думаю здесь все ясно.
  • «Пропущенные звонки»
    Это табличное исполнение отчета «Главная — Общая» в части пропущенных вызовов, т.е. покажет: кто/куда/во сколько вам позвонил и остался без ответа.
  • «Позвонили впервые»
    — А кто нам звонил впервые за указанный период времени (т.е. вообще когда-либо покуда ведется БД звонков с учетом выбранного периода)?
    — А вот кто (скрин снова под спойлером).
    Как и во всех табличных отчетах, мы видим:
    дату звонка, кто из сотрудников ответил, номер звонящего и наш городской, длительность и прочие данные.

FAQ«Звонки»

Настройка zabbix-agent

Для мониторинга за asterisk, я буду использовать один скрипт и несколько обработанных выводов из запросов к астериску. Начнем со скрипта. Он будет проверять статус транков и если какой-либо из них будет в offline, назовет его. Кладем этот скрипт в директорию /etc/zabbix/scripts.

# cat /etc/zabbix/scripts/asterisk.trunk-with-name.sh
#!/bin/bash

# Получаем количество всех транков в системе
total=`sudo asterisk -rx 'sip show registry' | sed -n '/registrations/p' | awk '{print $1}'`
# Получаем число активных транков
active=`sudo asterisk -rx 'sip show registry' | sed -n '/Registered/p' | wc -l`
# Получаем имена транков с проблемам
offline=`sudo asterisk -rx 'sip show registry' | sed -n '/Request\|Rejected\|Authentication\|Auth/p' | awk '{print $3}'`
# Сравниваем общее число с числом активных транков и выводим сообщение об их состоянии
if 
then
echo Trunks offline $offline
else
echo All trunks are online
fi

Я все прокомментировал. Добавлю только пояснение к регулярке, которая определяет проблемные транки. Я знаком со следующими состояниями транков, когда они не работают:

  • Request Sent
  • No Authentication
  • Auth. Sent
  • Rejected

Соответственно, эти состояния я и ищу. Если один из транков находится в одном из этих состояний, то он считается проблемным.

Далее создаем файл конфигурации zabbix с UserParameters в /etc/zabbix/zabbix_agentd.d.

# cat /etc/zabbix/zabbix_agentd.d/asterisk.conf
# Статус службы fail2ban
UserParameter=asterisk.fail2ban_status,ps cax | grep fail2ban | wc -l
# Количество цепочек fail2ban в iptables
UserParameter=asterisk.fail2ban_chain,iptables -nL | grep Chain | grep -E 'f2b|fail2ban' | wc -l
# Время работы службы asterisk
UserParameter=asterisk.uptime,asterisk -rx "core show uptime seconds" | grep --text -i "System uptime:" | gawk '{print $3}'
# Количество активных разговоров
UserParameter=asterisk.active_calls,asterisk -rvvvvvx 'core show channels'| grep --text -i 'active call'| cut -c1
# Статус транков
UserParameter=asterisk.trunk,/etc/zabbix/scripts/asterisk.trunk-with-name.sh
# Статус службы asterisk
UserParameter=asterisk.asterisk_status,ps cax | grep asterisk | wc -l

Некоторые из приведенных метрик требуют права root для своего исполнения. Скажу честно, мне было лениво разбираться с разрешениями и я просто запустил zabbix с правами root. Для этого в его конфиге /etc/zabbix/zabbix_agentd.conf раскомментировал следующую строку:

AllowRoot=1

После этого можно перезапустить zabbix-agent и проверить работу будущих итемов.

# systemctl restart zabbix-agent

Проверяем, насколько корректно агент возвращает указанные значения.

 # zabbix_agentd -t asterisk.asterisk_status
asterisk.asterisk_status 
# zabbix_agentd -t asterisk.fail2ban_chain
asterisk.fail2ban_chain 
# zabbix_agentd -t asterisk.trunk
asterisk.trunk 

Все в порядке. В завершении настройки агента, поясню некоторые моменты для тех, кто не очень разбирается в bash скриптах. Для мониторинга статусов служб я просто вывожу список всех процессов, вычленяю из него нужный мне процесс, в данном случае asterisk или fail2ban и подсчитываю количество этих процессов. Далее в шаблоне я просто буду проверять число этих процессов. Если оно будет равно 0, значит процессы не работают.

Для анализа цепочки iptables я также обрабатываю ее вывод, ищу строки со словами fail2ban и подсчитываю их количество. Если они равны 0, значит fail2ban не работает, либо работает, но не добавляет правила в iptables, что по большому счету и равно тому, что он не работает.

Для мониторинга активных разговоров, я обрабатываю соответствующий вывод asterisk, вырезаю лишние строки и оставляю только необходимое мне число.

Метрики нагруженности Asterisk PBX как сервиса телефонии

Здесь я могу порекомендовать ряд команд, которые могут выводить ряд полезной информации:
— asterisk -rx ‘core show channels concise’ — список активных каналов и ряда их параметров с разделителем. Можно парсить с помощью awk для получения каких-то сгруппированных блоков информации для построения графиков в Grafana;
— asterisk -rx ‘core show calls’ — отображает количество активных звонков. Те кто в курсе того, как Asterisk PBX работает со звонками абонентов и считает их — знает, что точность этой цифры может колебаться в пределах от 70% до 100% (реальное число звонков может быть ниже отображаемого из-за особенностей конкретного dialplan-а), однако для получения обобщенной статистики по нагрузке этого в целом достаточно;
— asterisk -rx ‘sip show registry’ — вывод состояния регистрации аккаунтов у внешних провайдеров.
— asterisk -rx ‘sip show peer PeerName’ — вывод информации о конкретном peer-е (в данном примере PeerName). Полезно в комбинации с опцией qualify=yes, чтобы видеть его статус и задержку отклика. Если у вас есть аккаунт без регистрации — его можно проверять через данную команду.

Заключение

Уже в процессе написания статьи понял, чего в ней не хватает. Мониторинг пиров все же нужен, так как не всегда подключение к провайдеру идет с регистрацией. Если ее нет, то за провайдерским пиром надо бы наблюдать. Возможно, дополню статью позже

Сервера, на которых я все проверял не имели таких пиров, поэтому упустил этот момент, не обратил внимание

Конечно, не очень правильно запускать zabbix от root. Тут я схалявил, но у меня есть оправдание — в заббиксе нет нормального средства для дебага не работающих скриптов. Итем просто становится неподдерживаемым и частенько приходится гадать, в чем же проблема. Даже когда выставляешь все необходимые права, все перепроверяешь, на стороне агента запускаешь и все работает как надо. Но на сервере итем не принимает данные.

Данный шаблон должен работать вместе со стандартным шаблоном для linux. Я видел в сети примеры шаблонов мониторинга asterisk, куда были добавлены метрики таких параметров сервера, как память, процессор, сеть и т.п. Не вижу смысла в таком подходе. Шаблоны надо максимально разделять, чтобы ими было удобнее пользоваться и не нагружать сервера лишними метриками. Я под каждый функционал сервера делаю отдельный шаблон. Примеры таких шаблонов можно посмотреть в моей рубрике zabbix.

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

  • Познакомитесь с Terraform.
  • Изучите систему управления конфигурацией Ansible.
  • Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
  • Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
  • В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: