Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 278 сообщений
Cообщения с меткой

opensource - Самое интересное в блогах

Следующие 30  »
rss_dirty_ru

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

Среда, 19 Декабря 2018 г. 14:37 (ссылка)



https://vimeo.com/79098420



Компания Cyberbotics объявила, что Webots, крутой симулятор роботов, который они разрабатывают уже более 20 лет, теперь стал опенсорсным и доступен для бесплатного скачивания. Теперь каждый может придумать себе своего собственного робота.

Точное моделирование физики позволяет создавать шагающих, колёсных, летающих, плавающих роботов, а также модульные системы, которые могут соединяться/разъединяться. Вы можете как сами задавать параметры робота, так и подобрать их при помощи эволюционных алгоритмов (см. ВДПВ)

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

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

В общем, наслаждайтесь! Ссылка на сайт.

P. S. Не уверен, что на ВДПВ используется Webots, но очень похоже.




Написал с сомнением irygaev
на technopark.d3.ru
/
комментировать


https://technopark.d3.ru/comments/1708377

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Проекту ReactOS требуются студенты для участия в Google Summer of Code 2018

Суббота, 17 Марта 2018 г. 19:18 (ссылка)

image



Привет, Хабр!

Спешим сообщить, что операционная система ReactOS уже третий год подряд получает слот на Google Summer of Code!

В случае успешной сдачи работы участник Google Summer of Code получит 2 400 евро.



Кто может участвовать?



Участвовать могут любые студенты и аспиранты (т.к. в юрисдикции США аспиранты считаются PhD Students).



Что надо сделать, чтобы участвовать?




  1. Зарегистрироваться на https://summerofcode.withgoogle.com/;

  2. Выбрать вариант участия как студент;

  3. Выбрать ReactOS как проект участия;

  4. Описать в свободной форме то, что вы хотите сделать для проекта;

  5. Подписаться на почтовую рассылку разработчиков и продублировать туда текст из пункта 4;

  6. Обговорить в IRC свое участие;

  7. Взять в вашем учебном заведении Proof of Enrollment – бумагу, которая подтверждает, что вы являетесь студентом (или аспирантом) этого учебного заведения на срок Google Summer of Code.



Поторопитесь! Подача заявок закончится 27 марта!



Возможные идеи для участия – под катом.

Читать дальше ->

https://habrahabr.ru/post/351382/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Если у вас нет собаки…

Четверг, 01 Марта 2018 г. 16:21 (ссылка)

Если вашему бизнесу необходим BDD с живой документацией на русском, нет выделенной позиции тестировщика, либо уровень его знаний недостаточен для самостоятельной автоматизации и важно обеспечение единого стека технологий между scrum-командами, то вам безусловно необходимо хотя бы раз подключить нашу библиотеку Akita и проверить ее в действии.

Перед тем как пуститься в рассказы о том, что такое библиотека Akita, хотелось бы рассказать о том, как мы дошли до мысли о ее реализации, какие проблемы хотели решить и что в итоге у нас получилось.
Читать дальше ->

https://habrahabr.ru/post/350238/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Портирование Embox на Xen

Вторник, 20 Февраля 2018 г. 13:53 (ссылка)





Пару лет назад на Мат-Мехе проходил студпроект по превращению Embox в идеальную платформу для столь модного нынче облака. Одной из очевидных частей этой задачи, было портирование на какую-нибудь платформу виртуализации, и выбор пал на Xen. В данной статье я расскажу о процессе портирования студентами ОС под Xen, добавлении новой платформы в Embox, ну и, конечно, зачем вообще всё это затевалось.
Читать дальше ->

https://habrahabr.ru/post/349526/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Новые возможности мониторинга Java приложений в Zabbix 3.4

Четверг, 16 Ноября 2017 г. 13:12 (ссылка)

Что случилось?



Вышел долгожданный релиз Zabbix 3.4, который принёс много полезных улучшений, среди которых оказались настраиваемые JMX endpoints и гибкое обнаружение MBean’ов.



Это так круто, да?



Если вы используете Zabbix и вам требуется мониторить Java приложения, то да — это может сильно облегчить вам жизнь, потому что раньше приходилось прибегать к различным ухищрениям, а теперь всё работает, как говорится, “из коробки”.



Читать дальше ->

https://habrahabr.ru/post/342226/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Zabbix 3.4: Массовый сбор данных на примерах счетчика Меркурий и smartmontools

Четверг, 21 Сентября 2017 г. 13:37 (ссылка)






wabbit


сегодня в 13:37

Администрирование





Zabbix 3.4: Массовый сбор данных на примерах счетчика Меркурий и smartmontools






  • Tutorial






Всем привет, ранее мы уже упоминали о возможностях по массовому сбору данных в новой версии опенсорс системы мониторинга Zabbix 3.4. Теперь остановимся на этом функционале поподробнее, и чтобы было нагляднее, расскажем о нем на двух примерах:




  • сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236

  • сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.







А в чем была собственно проблема?



Собирать данные через консольные утилиты или вызовы API данные можно было и ранее, но существовали сложности:




  • медленные запуски утилит каждый раз, на каждый нужный элемент данных

  • обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных

  • парсинг результата нужно было делать внешними скриптами/утилитами

  • а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты

  • кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.



В общем, дело было так:





А с появлением зависимых элементов данных, стало возможно так:





Как это работает?




  • В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или фривольном текстовом формате.

  • В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких функций препроцессинга как JSON path, XPath или Regex выделяют из текста нужную метрику.





Кстати, препроцессинг – тоже нововведение 3.4, он реализован добавлением новых процессов preprocessing_manager и preprocessing_worker на Zabbix-сервере. Поэтому, если вы обновляетесь с 3.2 – не забудьте обновить шаблон для сервера, чтобы мониторить их работу.



Переходим к примерам.





Меркурий 236





Представим, что на нашем проекте, кроме контейнеров, виртуальных машин, приложений, сетевых устройств, баз данных, бизнес показателей и всего прочего требующего контроля, присутствует необходимость мониторить показатели электросети и другой «инженерки», как, например, климатическое оборудование. Используются стандартные для нашей средней полосы устройства: трехфазный счетчик электроэнергии Меркурий 236 АRT-01 PQRS с интерфейсом RS-485, поверх которого общение происходит через проприетарный протокол производителя.

Задача ответственная – сразу собирать показатели напряжения, мощности, тока, потребления, частоты. Подключить такой прибор к серверу с Zabbix агентом – задача посильная – достаточно будет серийного порта с RS-485, например, в форме USB адаптера. Но как прочитать данные? Если бы не github и добрые люди, поделившиеся своим решением для умного дома, писать бы нам модуль к Zabbix, который бы мы учили разговаривать на протоколе счетчика и опрашивать показатели.

Утилита простая и удобная (за что автору большое человеческое спасибо) подключается к счетчику на указанный порт, считывает данные и отдает нам в виде текста, CSV или JSON.



Давайте попробуем установить и запустить:



git clone https://github.com/Shden/mercury236.git

cd mercury236

make

./mercury236 /dev/ttyS0 --help

Usage: mercury236 RS485 [OPTIONS] ...

RS485 address of RS485 dongle (e.g. /dev/ttyUSB0), required

--debug to print extra debug info

--testRun dry run to see output sample, no hardware required

Output formatting:

....

--help prints this screen





Запускается! Отлично, подключаем счетчик, опрашиваем, получаем JSON:



./mercury236 /dev/ttyS0 --json

{
"U": {
"p1": 0.35,
"p2": 0.35,
"p3": 226.86
},
"I": {
"p1": 0.00,
"p2": 0.00,
"p3": 0.39
},
"CosF": {
"p1": 0.00,
"p2": 0.00,
"p3": 0.60,
"sum": 0.60
},
"F": 50.00,
"A": {
"p1": 41943.03,
"p2": 41943.03,
"p3": 41943.03
},
"P": {
"p1": 0.00,
"p2": 0.00,
"p3": 53.45,
"sum": 53.45
},
"S": {
"p1": 0.00,
"p2": 0.00,
"p3": 89.83,
"sum": 89.83
},
"PR": {
"ap": 120.51
},
"PR-day": {
"ap": 86.00
},
"PR-night": {
"ap": 34.51
},
"PY": {
"ap": 0.00
},
"PT": {
"ap": 0.04
}
}




В итоге утилита уже сделала всю сложную работу за нас, реализовав протокол общения с счетчиком, вытащив данные, да еще и предложила нам это в виде удобного JSON объекта. Вот только раньше просто так мы ей не смогли бы воспользоваться — пришлось бы писать обвязку в виде скриптов, а самое главное – реализовывать механизм контроля доступа к среде последовательного порта. Ведь если два поллера Zabbix одновременно обратятся к нему – один за током третьей фазы 3, а другой — за током фазы 2, у нас не вернулось бы ничего.

В 3.4 все становится гораздо проще, и мы теперь быстро и легко можем передавать данные сторонних консольных утилит в Zabbix, не прибегая к оберточным скриптам, и не запуская по 10 раз одно и тоже на каждый элемент данных отдельно. Итак,





Настроим запуск утилиты mercury236 из Zabbix



sudo cp mercury236 /etc/zabbix/scripts

cd /etc/zabbix/scripts

chmod +x mercury236

sudo usermod -G dialout zabbix



Для запуска скрипта, создадим в конфиге Zabbix-агента новый UserParameter:

UserParameter=mercury236[],/etc/zabbix/scripts/mercury236 $1 $2


Сохраняем файл, не забываем перезапустить наш Zabbix-агент.

Теперь создадим в новом шаблоне родительский элемент данных:





Как видите, в родительском элементе данных нет ничего особенного – просто проверка через UserParameter Zabbix-агента. А это значит, что и нет никаких ограничений на то, какой тип проверки может выступать в роли родительского элемента – здесь могут быть и данные полученные через Zabbix trapper или через Внешние проверки. Единственное, мы выбрали Тип информации – Text и срок хранения истории в 1 день – хранить дольше мы собираемся метрики отдельно в зависимых элементах (можно не хранить данные вообще в родительском элементе, выставив срок хранения 0). Обратите внимание, что препроцессинг в этом элементе данных мы не трогаем.





Настроим получение наших метрик счетчика



Для того чтобы начать создавать зависимые элементы данных, можно воспользоваться новым помощником. Ну или просто нажать «Создать элемент данных»:





Создадим элемент данных для напряжения первой фазы, выберем:




  • Тип: Зависимый элемент данных

  • Основной элемент данных: mercury-get









Затем во вкладке «Предобработка» добавим наше выражение JSON Path:

Путь JSON: $.U.p1





Кстати, маленький совет. Чтобы не тратить много времени на отладку и ловлю ошибок, перед тем как заполнять JSON Path можно быстро проверить правильность выражения онлайн, например здесь: jsonpath.com, скопировав туда JSON, полученный от утилиты.

Аналогичным образом создаем другие интересующие нас метрики. В том числе — для накопленной энергии по дневному тарифу.



Для этого создадим новый элемент данных и выберем:




  • Тип: Зависимый элемент данных

  • Основной элемент данных: mercury-get



А вот во вкладке «Предобработка» обратите внимания на два нюанса:




  • будем использовать нотацию с квадратными скобками, так как в пути JSON есть дефис

  • препроцессинг может быть многошаговым, например здесь результата первого шага умножим на 1000, чтобы получить Вт*ч из кВт*ч









Проделаем аналогично для остальных ключевых метрик счетчика, в итоге получим вот такой список:







Доведем наш шаблон до ума



Чтобы шаблон был законченным, добавим триггеры, используя макросы, делая его максимально гибким. Не забываем про зависимости триггеров.







Что получилось



Шаблон готов, данные побежали, посмотрим, что у нас получилось:



Все последние данные, собранные за одно обращение:





Обратите внимание, что время сбора всех метрик абсолютно идентично.

Итоговый шаблон для счетчика доступен на репозитории решений на share.zabbix.com здесь.

Подведем итоги:




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

  • UserParameter остался, но схлопнулся до простого вызова. По сути можно даже system.run[] использовать

  • cкрипты-обертки тоже не писали. Всё распарсили через JSON path в шаблоне

  • cчетчик не мучали сильно, один запрос – все нужные нам данные разом.







Smartctl и smartmontools





Давно мы уже писали на хабре, как можно контролировать S.M.A.R.T. жестких дисков, чтобы успеть их вовремя поменять, через использование UserParameters. Такой подход работает, но он не был лишен недостатков:




  • избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска

  • пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)



Постараемся в 3.4 от всего этого избавится.



Случай с smartmontools имеет два отличия от примера со счетчиком выше:




  • smartctl нам JSON не возвращает

  • дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).



Но ничего страшного! Во-первых, зависимые элементы данных работают и для LLD, а во-вторых у нас среди preprocessing-фильтров есть и PCRE regex. Воспользуемся им, чтобы вытащить нужные показатели из не супер сильно структурированного ответа утилиты. Примерно такого:



Приступим.





Упрощаем UserParameters



Было:

UserParameter=uHDD[], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl


Стало:

UserParameter=uHDD.A[],sudo smartctl -A $1
UserParameter=uHDD.i[],sudo smartctl -i $1
UserParameter=uHDD.health[],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl


Аналогично делаем и для Windows, попутно избавляясь от CMD магии с использование for /F и find. Посмотреть можно тут.



Создаем новые родительские элементы данных



Для сбора всех атрибутов S.M.A.R.T. создадим прототип мастер-элемента данных:





Как и в предыдущем примере, ничего особенного настраивать не надо. Только Тип информации – Text, а Период хранения — 1 день.

Для сбора результатов тестов и инвентарных данных нам потребуется запускать smartctl с другими ключами. Поэтому аналогично создадим еще два элемента данных:




  • uHDD.i["{#DISKNAME}"]

  • uHDD.health["{#DISKNAME}"]







Настроим получение наших атрибутов S.M.A.R.T. диска



Создадим зависимый элемент данных для атрибута 5, Reallocated:





И во вкладке «Предобработка» используем регулярное выражение:





И так же как и с JSON Path, чтобы не тратить много времени на отладку и ловлю ошибок, перед тем как заполнять regex, удобно быстро проверить правильность выражения онлайн, например здесь: regex101.com скопировав туда наш вывод smartctl.

В итоге получим такой вот список прототипов:







Тестируем, смотрим что получилось



Для двух HDD:





Для SSD под Windows:





Подведем итоги примера с smartmontools:


  • мы убрали весь парсинг из UserParameters

  • нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно

  • когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения

  • жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.



Обновленный шаблон (заодно обновили триггеры, добавили элементы данных для SSD) доступен на репозитории решений на share.zabbix.com здесь.





В завершении



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/337856/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<opensource - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda