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

Некоторое время назад к нашим партнёрам, занимающимся изготовлением и обслуживанием комплексных систем энергоснабжения базовых станций, обратился оператор сотовой связи в Африке. Проект был рассчитан на 1000-2000 базовых станций. В рамках этого проекта AggreGate использовался для мониторинга, управления, визуализации и построения отчётов. Входе эксплуатации системы потребовались отчёты, с помощью которых можно быстро посмотреть основные параметры оборудования. Эти отчёты в дальнейшем использовались для формирования KPI работы системы энергоснабжения, подбора оптимальных параметров, определения графика обслуживания и построения маршрута для команды инженеров.

Мы создали гибкий инструмент для AggreGate, позволяющий удобно формировать эту таблицу, используя как исторические данные, так и статистические данные. Функцию summary(). В данной статье мы рассмотрим, как получить таблицу данных по историческим значениям.

Что такое реактивное программирование? Статья в Википедии учит, что это — парадигма программирования, ориентированная на потоки данных и распространение изменений. Это определение, хоть и технически корректно (ещё бы!), даёт крайне размытое представление о том, что же за всем этим скрывается на самом деле. Между тем, концепция реактивности проста и естественна, и объяснять её лучше всего на следующем примере.

Все мы когда-нибудь пользовались электронными таблицами типа Microsoft Excel. В ячейке таблицы пользователь может написать формулу, которая ссылается на другие ячейки. Если значение любой из них изменится — формула будет пересчитана, и наша ячейка автоматически обновится. При этом, если наша ячейка участвует в других формулах — то и они будут автоматически пересчитаны, и так далее, и так далее — процесс, напоминающий развитие цепной реакции. Так вот, это и есть главная идея реактивного программирования!

На хабре было уже немало статей на тему реактивного программирования (раз, два, три, четыре и другие) — в основном в них описывается реактивность в своей FRP-ипостаси в виде библиотек навроде bacon.js для JavaScript, JavaRx для Java и т.д. В данной статье пойдёт речь о реализации и применении реактивного программирования в языке Jancy. Материал будет интересен к прочтению даже если вы никогда не слышали о языке Jancy и не собираетесь на нём ничего писать — потому что далее мы продемонстрируем достаточно необычный подход к реактивности из императивного языка.

Зачем вообще создавать новый язык программирования? Их уже существует невероятное количество — по моему твёрдому убеждению, значительно больше, чем надо. И наверняка далеко не последнюю роль в данном положении вещей играет то, что создание компиляторов — это невероятно увлекательный процесс. С поправкой на арбузы и свиные хрящики — это вообще одна из самых «вкусных» работ, о которых может мечтать увлечённый программист.

Непередаваемо здоровским является цветочно-конфетный период — первый этап изучения теории компиляторов по толстым умным книжкам, и — тут же! — её применения на практике, в своём собственном языке. Даже печальная перспектива того, что создатель языка вполне может оказаться его единственным пользователем, не способна перевесить радость творчества и остановить сферического-в-вакууме компиляторного Кулибина. Разумеется, если удовлетворение собственного интереса является не только важной, но и единственной движущей силой всего процесса — вышеописанная перспектива с неизбежностью будет воплощена в жизнь. Но даже если это и НЕ единственная причина создания нового языка — перспектива стать одиноким пользователем своего творения всё равно имеет шансы реализоваться.

В своих первых статьях на хабре мы пообещали рассказывать о конкретных проектах, в которых применяется наша система. Идей очень много, но начать мы решили с рассказа об одном из наших внутренних DIY-проектов:

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

Основной модуль конструктора Lego Mindstorms EV3 может работать с прошивкой leJOS, позволяющей запускать Java-приложения. Специально для этого Oracle выпустил и поддерживает отдельную версию полноценной Java SE.

Нормальная JVM позволила мне использовать встроенный в нее протокол Java Management Extensions (JMX), чтобы реализовать удаленное управление роботом-манипулятором. Для объединения управляющих элементов, показаний датчиков и картинок с установленных на роботе IP-камер используется мнемосхема, сделанная на платформе AggreGate.

Одной из важных технологий любой серьезной системы мониторинга сетей является метод обнаружения связей сетевых элементов на 2-м и 3-м уровне модели OSI.



С точки зрения алгоритмов эта задача является одной из самых интересных встреченных нами во время разработки нашей системы.

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

Продолжаем цикл статей о терминале/сниффере IO Ninja и переходим к рассмотрению одной из самых выигрышных сторон новой версии нашего продукта – программируемости. Она открывает новые применения такого, казалось бы, заурядного инструмента, как терминал или сниффер.

Обзор архитектуры плагинов

Как и в предыдущей, второй версии продукта, исполнимые файлы третьей версии IO Ninja содержат лишь фреймворк необходимых компонентов (включая UI виджеты, движок для логгирования и классы для работы с IO, такие как io.Socket, io.Serial, io.PCap и т.д.). Логика же работы с конкретными транспортами содержится в плагинах, написанных на языке Jancy. Эти плагины лежат в выделенной папке «scripts» в виде исходных кодов и доступны как для ознакомления, так и для редактирования пользователями.

Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.



Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

• Никогда не заглядывать внутрь MIB-файлов
• Не знать, что такое OID-ы и никогда не оперировать с ними
• Не пользоваться отдельной SNMP-утилитой для предварительного просмотра данных во время настройки

При внедрении систем мониторинга и управления IT-инфраструктурой часто приходится сталкиваться с «нестандартными» устройствами. Нередко про такое устройство наверняка известно только то, что оно поддерживает SNMP. Подключение его к проекту придется начать с ответа на вопрос о том, какую информацию о себе оно предоставляет. Обычно для этого проводится полный опрос устройства, и полученные данные анализируются на предмет выявления полезной информации… Но тут, как говорится, есть нюансы. В этой заметке я расскажу об одном таком — о разработанном нами алгоритме быстрого определения «поддерживаемых» устройством MIB-модулей.

Данная статья является продолжением предыдущей, вводной статьи, в которой речь шла о мотивации и истории создания терминала/сниффера IO Ninja, и было немного рассказано про встроенные возможности нашего продукта. Продолжим рассказ о том, что доступно «из коробки», но с более практическим уклоном.

IO Ninja изначально задумывалась как утилита типа «всё-в-одном», и в комплект поставки входит большое количество встроеных плагинов для работы со всеразличными транспортами в разных режимах. Однако вместо сухого перечисления списка плагинов и их возможностей я решил продемонстрировать маленькую выборку задач из жизни, с которыми в нашей компании сталкивались на практике, и с которыми общеизвестные терминалы и мониторы справляются хуже, чем IO Ninja (а чаще не справляются вообще).

В этой статье мы продолжаем рассказ о продуктах, разработанных на основе IoT-платформы AggreGate. В 2010-м году, через два года после появления продукта AggreGate Network Manager, мы стартовали проект AggreGate SCADA/HMI – СКАДА-системы 4-го поколения.
Что же такое СКАДА 4-го поколения?

Диагностика проблем надежности и производительности в сложных ИТ-инфраструктурах требует понимания целостной картины всех процессов и событий, а также возможности отслеживать важнейшие тренды. Необходимость внедрения единой («зонтичной») системы управления ИТ-инфраструктурой обоснована классическими для бизнеса причинами:

Приветствую вас, уважаемые хабровчане!

Сегодня я хотел начать рассказ об одном интересном продукте представляемой мной на хабре компании Tibbo. Продукт этот может оказаться полезен широкому кругу IT-профессионалов, включая системных администраторов, специалистов по информационной безопасности, и, наконец, простых разработчиков, которым нет-нет, да и приходится программировать общение с устройствами и другой низкоуровневый ввод/вывод.

Разговор пойдёт про программируемый терминал/сниффер IO Ninja (здесь и далее я буду опускать слово «эмулятор» и говорить просто «терминал»). Подозреваю, что само определение «терминал/сниффер» может выглядеть достаточно непривычно, если не сказать странно. Поэтому начнём с истории возникновения IO Ninja.

Развитие Интернет быстро достигает уровня, когда он «просто есть». Нам все чаще не приходится задумываться, как именно мы сейчас подключены к сети, кто наш оператор связи, и, тем более, как подключение организовано технически. Повсеместное проникновение беспроводных сетей и постепенное распространение IPv6 позволяет тысячам простых устройств и датчиков беспрерывно общаться друг с другом и отправлять свои данные «в облако». Быстрое усложнение инфраструктуры привело к замене термина «Машина-к-машине» (Machine-to-Machine, M2M) на более актуальный термин «Интернет вещей» (Internet of things, IoT).



Формируя что-то вроде распределенного интеллекта, устройства Интернета вещей тем не менее нуждаются в централизованном управлении, в системе или сервисе для их настройки, хранения и интерпретации собранных данных. Являясь центральным «мозгом» инфраструктуры облака устройств, система управления также пополняет машинные базы знаний подключенных устройств и обновляет их программное обеспечение.