По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
С каждым днем современные сети и системы становятся только сложнее. Даже сеть небольшого и среднего масштаба SME (Small/Medium Enterprises) могут быть использовать сложнейшие системы как с точки зрения архитектуры, так и сложности администрирования. Nagios создан как мощный инструмент для мониторинга, администрирования и уведомления об отказах систем. Во фреймворк Nagios заложен мощный инструментарий с большим количеством опций, использование которых требует помимо понимания принципов работы Nagios, а так же и глубокого понимания используемых в корпоративном контуре систем. Это очень важный момент, так как Nagios не может научить системного администратора работе с его собственными системами, но он может послужить очень мощным инструментом в работе с ними. Итак, что же может Nagios? Ниже, мы приводим лишь небольшой обобщенный список функционала: Проверка работоспособности сервера Уведомление в случаях отказа сервера (email/SMS) Проверка запуска сервиса (например почта, веб-сервер (http), pop, ssh) Проверка процессов (или Windows сервиса) Обработка статистики с сервера (ключевые перфомансы сервера) Возможность настройки уведомлений определенных событий только для назначенной группы или конкретного пользователя Формирование отчетов по downtime (времени сервера в нерабочем состоянии) Nagios не содержит никаких встроенных инструментов проверки (плагинов). Важно понять, что Nagios обеспечивает надежный и расширяемый фреймворк для любого вида мониторинга, который только может придумать пользователь. Но как Nagios выполняет мониторинг сети? Существует огромное количество уже готовых плагинов, которые позволяет выполнять различные виды мониторинга. И если для вашей сети необходимо создать специфический алгоритм мониторинга, вы можете написать данный плагин самостоятельно. Почему Nagios? Nagios - отличный выбор для тех, кто хочет иметь широкий диапазон инструментов мониторинга. Основными конкурентными преимуществами Nagios являются: Nagios это Open Source решение Надежное решение Высочайший набор возможностей для конфигурации Легко масштабируется Активное сообщество разработчиков, где постоянно совершенствуется данная система мониторинга Nagios работает на множестве операционных систем Nagios можно адаптировать под огромное количество задач. Выделим наиболее популярные адаптации этой системы мониторинга: Ping для отслеживания доступности хоста Мониторинг сервисов, таких как SMTP, DHCP, FTP, SSH, Telnet, HTTP, NTP, DNS, POP3, IMAP и так далее Сервера баз данных, такие как SQL Server, Oracle, MySQL и Postgres Мониторинг на уровне приложений, например, web – сервер Apache, Postfix, LDAP, Citrix b так далее. Как Nagios работает? Nagios работает в качестве демона (фонового процесса) на выделенном сервере, периодически отправляя ICMP запросы на хост мониторинга. Полученная информация обрабатывается на сервере и отображается администратору в рамках WEB – интерфейса. Опционально, администратор может настроить уведомления на почту, интегрируя сервер мониторинга с почтовым сервером, либо настроить СМС уведомления.
img
Друг, начнем с цитаты: Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений. Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим. Про установку Redis в CentOS 8 мы рассказываем в этой статье. Redis как база данных Говорим про случай, когда Redis выступает в роли базы данных: Пару слов про ограничения такой модели: Размер БД ограничен доступной памятью Шардинг (техника масштабирования) ведет к увеличению задержки Это NoSQL - никакого языка SQL LUA скриптинг в качестве альтернативы Это нереляционная СУБД! Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа Доступ по общему паролю. Что скажут ваши безопасники? Теперь про преимущества модели: Скорость Хранение данных в памяти делает быстрее работу с ними Скрипты на LUA Выполнение прямо в памяти, опять же, ускоряет работу Удобные форматы запросов/данных Geospatial – геоданные (высота, ширина, долгота и так далее) Hyperloglog – статистическе алгоритмы Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями Алгоритмы устаревания данных Примеры использования Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля. Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию. А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis. Итого, для указанной выше схемы, мы хотим: Скорость Мы не хотим, чтобы пользователь долго ожидал авторизации Масштабирумость системы Сопоставление ключа (токена) с авторизациями юзера А вот, что на эти вызовы может ответить Redis: Redis хранит данные в памяти – он быстрый. Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста. В Redis куча вариантов хранения списков. Самый простой будет являться набором данных. В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать. Redis как кэш! Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных. Ограничения: Значения не могут превышать 512 МБ Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных Профит: Совместное использование кэша разными сервисами по сети Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом Временные ограничения для данных Еще один кейс Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке. Окей, кейс понятен. Рэдис, что скажешь на такие требования? Кэш должен хранить сортированные наборы данных Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами) Это должно быть быстрее, чем пересчет данных с нуля Что скажет Redis: Хранить наборы данных - легко Может вытаскивать сабсеты из наборов - легко Конечно быстрее. Ведь данные хранятся в памяти Redis как брокер сообщений Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик». Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы: Только тривиальная модель pub/sub Отсутствие очередей сообщений Ну а плюсы, как обычно для Редиса – скорость и стабильность. Кейс напоследок Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще. Требования по этой задаче: Низкая задержка Мы не хотим иметь трудности в процессе совместной работы сотрудников Стабильная работа и непрерывность Масштабирование Кампания растет и развивается Редис, твой выход! Низкая задержка – да, говорили об этом ранее Стабильность – минимальное количество точек отказа в Redis Стабильная работа и непрерывность Масштабирование – сделаем кластер, нет проблем. Выводы Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор. Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.
img
В сегодняшней статье расскажем как с помощью сервера Asterisk и и телефонных офисных аппаратов можно создать простейшую, эффективную систему оповещения и организовать внутреннюю селекторную связь. Как можно догадаться, речь сегодня пойдёт о модуле Paging and Intercom на примере Asterisk и FreePBX 13 /p> Модуль Paging and Intercom позволяет сконфигурировать группы телефонных аппаратов, которые будут автоматически принимать вызов при звонке из, так называемой Page Group , и проигрывать оповещательное сообщение через свои динамики. Например, в небольшом офисе можно настроить Page Group со специальным внутренним номером. Когда кто-либо из локальных пользователей наберет этот номер, все телефоны, находящиеся в группе автоматически примут вызов, и можно будет озвучивать сообщение одновременно на все телефоны. Нужно отметить, что этот модуль будет работать практически со всеми SIP телефонами, которые поддерживаются IP-АТС Asterisk. Модуль Paging and Intercom связан с другим модулем – Extensions, который предназначен для создания внутренних добавочных номеров (extension). При настройке Paging группы можно будет выбирать, какие внутренние номера необходимо в неё включить. Рассмотрим настройку модуля Paging and Intercom на примере FreePBX 13. Для того, чтобы попасть на страницу конфигурации модуля, необходимо с главной страницы перейти по следующему пути Applications -> Paging and Intercom . Перед нами откроется окно глобальных настроек Settings, где можно настроить, например, звуковое оповещение, которое услышат участники Page группы, когда локальный пользователь наберет номер группы. По умолчанию – это гудок (Beep), однако можно выбрать любой звук из System Recordings или выставить None, чтобы никакого звука не было вообще. Далее, на вкладке Paging Groups настраиваются непосредственно группы оповещения. Необходимо нажать Add Paging Group, чтобы открылись параметры новой группы. Рассмотрим ключевые параметры при создании Page Group Paging Extension – Внутренний номер группы оповещения. Именно его необходимо набрать, чтобы передать на телефоны участников группы необходимое сообщение Group Description – Описание группы, задается опционально. На примере выше указано “Sales”, то есть участники группы являются сотрудниками отдела продаж Device List – Здесь необходимо выбрать добавочные номера (Extensions) сотрудников, которые будут участниками группы оповещения. Рекомендуется не набирать в одну группу более 25 участников Announcement – Звуковое сообщение, проигрывающееся членам группы, когда происходит вызов группы Busy Extensions – Параметр, позволяющий настроить как поступать с участниками группы, если в момент вызова группы они разговаривают (Busy) Duplex – Параметр, позволяющий включить двустороннюю связь между членами группы Default Page Group – Определить данную группу как группу по умолчанию. В группу по умолчанию можно добавлять участников прямо из модуля Extensions
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59