пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
IP – АТС Asterisk – сложная система обработки телефонных вызовов, состоящая из различных драйверов и модулей. Зачастую системные администраторы сталкиваются с неисправностью того или иного функционала: не работает входящая/исходящая связь, односторонняя слышимость, проблемы с внутренними номерами и так далее. Чтобы решить данные проблемы, надо понять их суть – посмотреть в журнал (лог – файл) Asterisk и узнать, что же происходит на самом деле. О том, как правильно собрать логи, их глубина и параметры, а также про сбор сетевого дампа расскажем в этой статье.
Настройка логирования
Приступаем к настройке. Для этого, нам необходим посмотреть содержимое файла /etc/asterisk/logger.conf. Давайте откроем его:
[root@asterisk ~]# cat /etc/asterisk/logger.conf
[general]
#include logger_general_additional.conf
#include logger_general_custom.conf
[logfiles]
#include logger_logfiles_additional.conf
#include logger_logfiles_custom.conf
Как видим, в данный файл включен «кастомная» настройка – файл logger_logfiles_custom.conf . В нем мы и будем производить необходимые настройки. Допустим, мы хотим записывать в файл logs_ echo date("Ymd"); основные события. Для этого, откроем для редактирования файл и добавим в него следующую запись:
[root@asterisk ~]# vim logger_logfiles_custom.conf
logs_ echo date("Ymd"); => notice,warning,error,debug,verbose,dtmf
Сохраняем изменения нажатием :x!.
Начиная с 13 версии Asterisk, существует возможность создавать задачи на логирования прямо из консоли. Для этого существует команда logger add channel . Например:
logger add channel logs_ echo date("Ymd"); notice,warning,error,debug,verbose,dtmf
Логирование будет остановлено при следующем рестарте Asterisk.
Глубина записи логов
В Asterisk можно задавать глубину логирования параметром verbose и debug. Первый режим более информативен для администратора, когда необходимо оперативно понять причину неисправности, тогда как второй режим более полезен для более глубоко анализа. Глубина задается от 1 до 10, где 10 – максимальный уровень информативности:
asterisk*CLI> core set verbose 3
asterisk*CLI> core set debug 3
После этого, необходимо перезагрузить модуль логирования:
asterisk*CLI> module reload logger
Дебаг на уровне каналов
В Asterisk можно производить дебаг на уровне отдельных драйверов. Например, если вы хотите отладить подключения по протоколу SIP – своя команда, по IAX – другая. Ниже представлен список:
Драйвер
Команда отладки
SIP (версия вышел 1.6)
sip set debug on
SIP (версия 1.4)
sip set debug
PJSIP
pjsip set logger on
Запись CDR
cdr set debug on
IAX2 (версия вышел 1.6)
iax2 set debug on
IAX2 (версия 1.4)
iax2 set debug
Остановить логирование
Когда отладка закончена, необходимо вернуть все в первоначальный вид. Отключаем дополнительный дебаг:
asterisk*CLI> core set verbose 0
asterisk*CLI> core set debug 0
Чтобы выключить дебаг на конкретных каналах, даем команду вида:
asterisk*CLI> sip set debug on
asterisk*CLI> iax2 set debug off
Далее, в файле /etc/asterisk/logger.conf закомментируйте или удалите добавленную строчку. После этого перегружаем модуль логирования:
asterisk*CLI> module reload logger
Дебаг Asterisk в файл
Прямо из консоли можно добавлять дебаг в файл. Для этого, его необходимо первоначально создать. Например:
[root@asterisk ~]# touch /home/asterisk_cli.txt
Далее, вызываем консоль сервера IP – АТС Asterisk следующим способом:
[root@asterisk ~]# asterisk -rvvvv | tee /home/asterisk_cli.txt
В открывшейся консоли дайте одну из перечисленных команд дебага, например, sip set debug on. Весь вывод будет сохранен в указанном файле. По окончанию укажите в консоли sip set debug off и quit.
Сетевой дамп Asterisk для анализа в Wireshark
Простейшим способом снять сетевой дамп является утилита tcpdump. Чтобы ей воспользуйтесь командой:
[root@asterisk ~]# tcpdump -s 0 -w /home/dump.cap
Затем, после снятия необходимого дампа, Вы сможете сохранить файл dump.cap в директории /home себе на компьютер, для последующего анализа. Помимо этого, в команде есть возможность дать дополнительные ключи, например -i eth0 - указание интерфейса, с которого необходимо снять дамп, а port 5060 - указать порт, на который приходят пакеты.
JIT-компиляция – это метод повышения производительности интерпретируемых программ. JIT расшифровывается как Just-in-time. Во время выполнения программа может быть скомпилирована в машинный код для повышения ее производительности. Также этот метод известен как динамическая компиляция.
Динамическая компиляция имеет несколько преимуществ перед статической. При запуске приложений на JAVA или C# среда выполнения может профилировать приложение во время его исполнения. Это позволяет создавать более оптимизированный код. Если поведение приложения меняется во время его исполнения, то среда выполнения может перекомпилировать код.
Есть некоторые недостатки, заключающиеся в задержках при запуске или непроизводительных издержках при компиляции во время выполнения. Чтобы ограничить эти издержки, многие JIT-компиляторы компилируют только пути кода, которые часто используются.
Обзор
Традиционно существует два метода преобразования исходного кода в форму, которую можно запустить на платформе. Статистическая компиляция преобразует код в язык для конкретной платформы. Интерпретатор непосредственно выполняет исходный код.
JIT-компиляция пытается использовать преимущества обоих. В то время как выполняется интерпретируемая программа, JIT-компилятор определяет участки часто используемого кода и компилирует его в машинный код. В зависимости от компилятора это можно сделать для метода или меньшего участка кода.
Впервые динамическая компиляция была описана в статье о языке LISP Дж. Маккарти в 1960 году.
Компиляция на лету, JIT или динамическая компиляция – это компиляция, которая выполняется непосредственно во время исполнения программы, а не до этого. Что в этот момент происходит? Перевод в машинный код. Преимущества JIT-компиляции заключаются в том, что поскольку компиляция происходит во время выполнения, то JIT-компилятор имеет доступ к динамической информации времени выполнения, а это в свою очередь позволяет ему оптимизировать процесс (например, встраивать функции).
Что важно понимать, когда речь идет о JIT-компиляции? Она скомпилирует байт-код в инструкции машинного кода работающего компьютера. Это означает, что полученный машинный код оптимизирован для архитектуры процессора конкретного компьютера.
В качестве примеров JIT-компиляторов можно привести JVM (Java Virtual Machine - виртуальная машина Java) на Java и CLR (Common Language Runtime – общеязыковая исполняющая среда) на C#.
История
Изначально компилятор отвечал за преобразование языка высокого уровня (выше, чем ассемблер) в объектный код (машинные инструкции), который затем должен был быть связан (линкером) с исполняемой программой.
В какой-то момент эволюции языков компиляторы начали компилировать язык высокого уровня в псевдокод, который затем интерпретировался (интерпретатором) для запуска программы. Это исключило объектный код и исполняемые программы и позволило перенести эти языки на несколько операционных систем и аппаратных платформ. Одним из первых был Pascal (который скомпилирован в P-Code); более современными примерами являются Java и C#. Со временем термин P-Code был заменен на байт-код, поскольку большинство псевдоопераций имеют длину в один байт.
JIT-компилятор – это функция интерпретатора, которая вместо интерпретации байт-кода при каждом вызове компилирует байт-код в инструкции машинного кода работающей машины, а затем вызывает этот объектный код. В идеальном варианте эффективность выполнения объектного кода должна превзойти неэффективность перекомпиляции программы при каждом ее запуске.
Обычный сценарий
Исходный код полностью преобразуется в машинный код.
JIT-сценарий
Исходный код преобразуется в структуру на языке ассемблера, например, IL (промежуточный язык) для C#, ByteCode для Java.
Промежуточный код преобразуется в машинный только тогда, когда приложение нуждается в том, чтобы необходимые коды были преобразованы в машинный код.
JIT или не JIT
При JIT-компиляции не весь код преобразуется в машинный код. Для начала преобразуется только необходимая часть кода. Затем, если вызываемый метод или выполняемые функции находятся не в виде машинного кода, то они тоже будут преобразованы в машинный код. Это снижает нагрузку на ЦП. Поскольку машинный код будет генерироваться во время выполнения, то JIT-компилятор создаст машинный код, оптимизированный для запуска архитектуры ЦП машины.
Ниже приведены некоторые примеры JIT-компиляторов:
Java: JVM (Java Virtual Machine – виртуальная машина Java)
C#: CLR (Common Language Runtime – общеязыковая исполняющая среда)
Android: DVM (Dalvik Virtual Machine – виртуальная машина Dalvik) или ART (Android RunTime – среда выполнения Android-приложений) в новых версиях
Виртуальная машина Java (JVM) выполняет байт-код и ведет подсчет времени выполнения функции. Если это значение превышает предустановленный порог, то JIT-компилятор компилирует код в машинный код, который в дальнейшем может быть выполнен непосредственно процессором (в отличие от случая, когда javac компилирует код в байт-код, а затем интерпретатор интерпретирует этот байт-код построчно, переводя его в машинный код, и выполняет его).
Кроме того, при следующем вычислении функции тот же скомпилированный код выполняется снова, в отличие от обычной интерпретации, когда код повторно интерпретируется построчно. Это значительно ускоряет процесс выполнения программы.
Базы данных — это ключевой компонент современных информационных систем, благодаря которому мы можем информацию храненить (заметьте, что не хоронить), управлять и изменять. Проще говоря, БД используются для удобной работы с некоторыми данными, которые нужны нам для проекта. Например, при оформлении заказа через приложение доставка использует базу данных для хранения информации о адресе, предпочтениях и истории заказов. В более сложных системах, таких как социальные сети, интернет-магазины или банковские платформы, объёмы данных значительно увеличиваются, что требует выбора подходящей технологии для их обработки.
Вот тут и возникает главный вопрос: SQL или NoSQL? В чем-то это можно сравнить с выбором чая или кофе — оба варианта хороши, но каждый подходит для своих целей. SQL — это про строгий порядок и чёткую структуру, как таблицы в Excel. NoSQL — это про гибкость и скорость, когда данные могут выглядеть, как угодно, например, JSON-документы или даже графы. Понимание разницы между ними важно, чтобы не пытаться забивать гвозди микроскопом. Собственно, чтобы разобраться тонкостях SQL и NoSQL, мы здесь сегодня и собрались.
Что такое SQL?
SQL (Structured Query Language) — это язык для работы с базами данных, который позволяет создавать, изменять и извлекать данные. Если представить базу данных как библиотеку, то SQL — это библиотекарь, который знает, где лежит каждая книга, как её найти и что с ней можно сделать, вот только с таким библиотекарем надо общаться на его языке. SQL используется в реляционных базах данных, где информация хранится в виде таблиц с чёткой структурой: строки — это записи, а столбцы — свойства этих записей.
Реляционные базы данных основаны на принципе отношений (relation) и обладают ключевыми особенностями: чёткая структура данных, возможность связывать таблицы через ключи (например, первичный и внешний ключи), а также поддержка транзакций. С их помощью можно уверенно управлять большими объёмами данных, сохраняя порядок. Среди популярных SQL-баз данных можно выделить MySQL (любимец разработчиков за простоту), PostgreSQL (гибкий и мощный инструмент), Microsoft SQL Server (корпоративный стандарт для Windows-систем) и Oracle Database (монстр для серьёзных задач).
Главные преимущества SQL — это строгая структура, которая помогает избежать хаоса в данных, возможность писать сложные запросы для анализа и обработки информации, а также поддержка ACID-принципов (атомарность, согласованность, изолированность и долговечность). Это значит, что данные будут надёжно защищены от ошибок и останутся целыми даже при сбоях.
Что такое NoSQL?
NoSQL (или *Not Only SQL*) — это подход к базам данных, который не ограничивается реляционной моделью. Если SQL — это строгий учитель математики, который всё записывает в таблички, то NoSQL — это творческий художник, который говорит: «А зачем нам таблицы? Давайте просто хранить данные так, как удобно!» NoSQL-базы созданы для работы с огромными объёмами данных, где гибкость и скорость важнее строгой структуры.
Существует несколько основных типов NoSQL-баз данных, каждая из которых заточена под свои задачи. Документные базы (например, MongoDB и CouchDB) хранят данные в виде документов (обычно JSON или BSON). Колонночные базы (Cassandra, HBase) организуют данные в столбцы, а не строки. Они идеально подходят для аналитики больших данных, где важно быстро обрабатывать миллионы записей. Графовые базы (Neo4j) хранят данные в виде узлов и связей между ними — это выбор номер один для задач вроде построения социальных сетей или рекомендаций (например, кто кого знает или что купить дальше). А базы типа ключ-значение (Redis, DynamoDB) — это как словарь: запрашиваешь значение по ключу. Они невероятно быстры и отлично подходят для кэширования или хранения сессий.
Основные преимущества NoSQL: во-первых, гибкость. Не нужно заранее продумывать структуру таблиц — добавляй новые поля на лету! Во-вторых, масштабируемость. NoSQL-базы легко растут горизонтально (добавляй новые серверы и не переживайте). И наконец, высокая производительность. Для многих задач NoSQL быстрее реляционных баз, потому что они избавлены от лишних проверок и строгих правил. Так что, если данные больше похожи на хаотичный поток, чем на аккуратный Excel-файл, NoSQL может стать отличным помощником.
Так, мы поняли общие различия между SQL и NoSQL, но в большей степени нас всех ведь интересует, когда и что использовать, так что остановимся на этом поподробнее.
Когда использовать SQL, а когда NoSQL?
Каждая БД по сути дела отвечает разным требованиям потребностям при разработке. Когда нам нужен молоток – мы используем молоток, однако, когда отвёртка – мы используем её. И использовать что-то взамен, наверное, можно, при большом желании, но всё же не нужно.
Итак, в случае, если проект — это что-то, где данные должны быть идеально структурированы, как бухгалтерский отчёт или банковская система, то SQL — твой лучший друг. Банковские транзакции, например, требуют соблюдения строгих правил: деньги не могут «исчезнуть» из одной таблицы и «не появиться» в другой (хотя иногда очень хотелось бы). Здесь на помощь приходит транзакционность (ACID-свойства). Если не вдаваться в подробности, то это набор принципов, которые обеспечивают надёжность операций в реляционных базах данных. В случаях, когда нам важно иметь структурированные данные, важна целостность данных и возможность выполнять сложные запросы, вроде «покажи мне все операции за последние три месяца по клиентам с балансом выше 100000 рублей». Если же речь идёт о разработке CRM-системы для небольшой компании или создания сайта-визитки с базой пользователей, SQL тоже подойдёт идеально. Реляционные базы данных, такие как MySQL или PostgreSQL, хорошо работают с небольшими и средними объёмами данных, обеспечивая простоту настройки и поддержки.
Другой случай, что нам надо построить высоконагруженное приложение, которое ежедневно обрабатывает миллионы запросов. Например, социальная сеть, где пользователи постят фотографии, ставят лайки и пишут комментарии. Или интернет-магазин с миллионами товаров и отзывов. Здесь NoSQL становится незаменимым. Почему? Потому что он позволяет быстро масштабироваться: если нагрузка растёт, нужно просто добавить новые серверы в кластер. К тому же NoSQL отлично справляется с гибкими структурами данных. Например, в документной базе MongoDB можно хранить информацию о товарах так: у одного товара есть описание и отзывы, а у другого — только цена и дата выпуска. Никаких ошибок из-за несоответствия структуры! А если завтра вам нужно будет добавить поле «рейтинг», это можно сделать без каких-либо проблем и головной боли.
Ещё один пример использования NoSQL — системы реального времени. Например, это подходит для какой-нибудь онлайн-игры, где миллионы игроков взаимодействуют друг с другом. Здесь скорость важнее всего: Redis или DynamoDB помогут мгновенно доставлять данные игрокам. Или возьмём IoT (интернет вещей): миллионы датчиков отправляют данные каждую секунду — хранить их в реляционной базе было бы слишком медленно.
И так, мы поняли, при четкости и структурированности используем SQL, в случаях, где нам нужно быстродействие и разнообразие используем NoSQL. А что, если их… Сложить? А почему нет? Можно использовать сразу все. Разберемся?
Можно ли использовать SQL и NoSQL вместе?
В мире возможно почти все, а потому рассмотрим гибридный подход — это способ объединить сильные стороны SQL и NoSQL, чтобы получить лучшее из двух миров. Например, реляционные базы данных (SQL) отлично подходят для работы с критически важными данными, где важна строгая структура, транзакционность и согласованность. А NoSQL прекрасно справляется с задачами, где важна масштабируемость, гибкость или высокая скорость работы, например, при хранении логов, кэшей или данных IoT.
Как пример, возьмем интернет-магазин. Для управления заказами, клиентами и платежами используем SQL-базу, например PostgreSQL, где всё строго: таблицы, связи, транзакции. Но вот для рекомендаций товаров или хранения истории просмотров пользователей лучше подойдёт NoSQL-решение, такое как MongoDB или Redis. Почему? Потому что данные здесь не требуют жёсткой структуры и меняются очень быстро.
Или же как еще один пример возьмем приложение для доставки еды (это самые любимые приложения, пожалуй). Заказы клиентов могут храниться в MySQL — это важно для финансовой отчётности и аналитики. Но для хранения геолокации курьеров в реальном времени используем Redis: данные обновляются каждую секунду, а не нужно сохранять их навсегда. А ещё можно добавить Elasticsearch для быстрого поиска ресторанов по ключевым словам — вот вам уже три разные базы данных в одном проекте!
Гибридный подход помогает использовать преимущества каждой технологии там, где они действительно нужны. Главное — не перегружать архитектуру и помнить: если есть молоток, это ещё не значит, что все задачи — гвозди, еще есть и гайки, и шурупы и болты. Собственно, в больших проектах в основном и используются сразу и SQL, и NoSQL, просто для разных задач. В маленьких же проектах уже необходимо смотреть на потребности.