Facebook объявил (https://code.facebook.com/posts/844436395567983/introducing-.../) об открытии исходных текстов проекта osquery (http://osquery.io/), в рамках которого развивается необычный инструмент низкоуровневого мониторинга за состоянием операционной системы. Своеобразность проекта заключается в том, что все отслеживаемые ресурсы отражены в форме виртуальной базы данных, обращение к которой производится через отправку SQL-запросов. Код написан на языке C++ и доступен (https://github.com/facebook/osquery) под лицензией BSD. Из операционных систем поддерживаются OS X и Linux.Через SQL-запросы можно достаточно подробно анализировать состояние системы, например, как с SQL-таблицами можно работать со списками выполняемых процессов, загружаемыми модулями ядра, списками пользователей, открытыми сетевыми соединениями, таблицами маршрутизации. Каждый запрос отражает текущее состояние в данный момент времени. Несмотря на том, что в рамках проекта развивается подготовлена подборка (https://github.com/facebook/osquery/tree/master/osquery/tables) готовых ресурсов для мониторинга, при желании можно легко добавлять собственные уровни абстрации с поддержкой новых ресурсов и подключать их в форме плагинов.
SQL-запросы можно передавать через стандартный вход в утилиту osquery или использовать специально подготовленный интерактивный интерфейс командной строки. Синтаксис запросов совместим (https://github.com/facebook/osquery/wiki/using-osqueryi) с SQLite. Для планирования опроса состояния систем на разных хостах подготовлен специальный фоновый процесс osqueryd, который может использоваться для создания распределённой инфраструктуры мониторинга, охватывающей несколько серверов. Кроме опроса текущего состояния разных систем, osqueryd занимается накоплением статистики изменений параметров систем, агрегирует имеющуюся статистику и ведёт лог изменений состояния.
В качестве примера, демонстрирующего удобство предлагаемого подхода, приводится запрос для вывода имён, идентификаторов и прикреплённых портов для всех процессов, слушающих сетевые соединения на указанном сетевом интерфейсе:<font color="#461b7e">
SELECT DISTINCT
process.name, listening.port, process.pid
FROM processes AS process
JOIN listening_ports AS listening
ON process.pid = listening.pid
WHERE listening.address = '0.0.0.0';
</font>
Другой пример, показывает как найти выполняемые процессы, исполняемых файлов которых уже нет в файловой системе (например, для выявления вредоносного ПО):<font color="#461b7e">
SELECT name, path, pid FROM processes WHERE on_disk = 0;
</font>
URL: https://code.facebook.com/posts/844436395567983/introducing-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=40964
Это SDM. Sql-driven monitoring
Это BDSM. BaseData SQL Monitoring :)Давайте файловую систему в SQL уже допилим, а то всё никак, ни у кого не доходят руки :)
Bobby Tables обещал переименовать файл с своим hello world.
открой для себя примеры в berkley db 5.x там был пример файловой системы и журнала в bd.
А если хорошо посмотришь - то файловая система это такая большая база данных из нескольких таблиц key<>value и очень быстрая.
Только доступа по SQL запросам к файловой системе что-то не видать. Т.е. ФС key<>value есть и SQL базы есть, а полнофункционально ФС с SQL нет. BDB 5.x с примером считать полнофункцилнальной ФС полагаю не следует. А вообще смысла нет в такой ФС в целом, это как танк и самолет в единое целое совместить - получится и не танк и не самолет.
Но вообще, тут как-бы ирония по поводу SQL.
чем не пример? bdb предоставляет контейнер с транзакциями - таблица аллоцированых инод, таблица аллоцированых блоков, и стопка таблиц с именами inode id, где-то поблочно данные, где-то записи директорий.реализовать тоже самое на SQLite, за нефик делать. И будет sql доступ.
А вот и вообще готовое - http://oracle-base.com/articles/11g/dbfs-11gr2.php
http://search.cpan.org/dist/sqlfs-perl/bin/sqlfs.plэто не доступ через sql к FS ?
Назад к AS/400?
Тогда уж вперед к system i
это BSDM)))
Было мнение, что zfs и есть некое подобие SQL.
8-o
Впрочем мнение местных Ыгспердов как обычно основанно на НЕЗНАНИИ и SQL и ZFS :)
Пройдите в сад!(С)
необычный инструмент - согласен. а вот есть ли от него какая-то практическая польза - сложно сказать
Высокая производительность, низкое потребление ресурсов.
Простота вывода в внешние системы мониторинга посредством SQL запросов.
Много есть систем мониторинга, получающих инфу через SQL-запросы? И что, SNMP по сравнению с SQL сильно тяжёлый и переусложнённый язык? (Если считать языком определение MIB'ов)
> Высокая производительность, низкое потребление ресурсов.это же чушь полнейшная. Внедрение языка который позволяет делать хитрые запросы ну совсем никак не помогает улучшению производительности и потреблению ресурсов. Если это ещё сделать кое-как, то наоборот - даст ощутимый тормоз всего.
Еще как помогает, если альтернатива - дикая смесь ps, grep и тому подобного.Может, SQL - и не лучший выбор (черт, да он даже для баз данных - ни хрена не лучший выбор), но идея получения хорошо структурированного ответа на запрос, не разорваный по десяти утилитам - отличная.
>Еще как помогает, если альтернатива - дикая смесь ps, grep и тому подобногода ну его нафиг такие альтернативы
> он даже для баз данных - ни хрена не лучший выборА что для баз данных лучше?
профит заключается в возможности делать хитрые запросы для анализа. В обычных системах, например, нет интерфейся для произвольных запросов и их приходится кодить как-то руками. Это в теории, хз насколько хорошо это сделано в топике.
Похоже, появились люди, называющие себя "администраторами" и кодящие на языке HTML и SQL...
Чем более убоги пользователи, тем сильнее приходится под них прогибаться.
Вот точно так же убогие скудоумцы, не осилившие пайпы из grep, awk, tail, ... ликуют от предлагаемых им в systemd бинарных логов с SQL интерфейсом...
Ну, вообще все эти грепы с авками хороши для чего-то однократного или нетребовательного к ресурсам, иначе - SQL рулит. Что не отменяет полного идиотизма РЕАЛИЗАЦИИ этого дела в systemd. Ибо можно было получить все преимущества, не теряя совместимости с класическими текстовыми логами.
Портировали оффтопиковый WQL ?
> Портировали оффтопиковый WQL ?скорее WMI
а не, все верно WMI Query Language == WQL
Откройте глаза. WMI это слизанный формат CIM. В котором это все давно.
Саму возможность делать WQL с linux чтобы получить инфу с windows тачки, давно сделали http://www.aldeid.com/wiki/Wmic-linuxНо это же не полноценные рычаги управления системой, это так, только статистику с нужным колонками получить. Вот если бы сделали полноценную систему управления хостом из консоли/через утилитку запросами
INSERT INTO etc.passwd (username,password) VALUES ("_KUL", "12345");
это бы админы оценили!
p.s. Лучше бы разработчики systemd эту идею развили, меньше врагов имели бы.
> Саму возможность делать WQL с linux чтобы получить инфу с windows тачки,
> давно сделали http://www.aldeid.com/wiki/Wmic-linux
> Но это же не полноценные рычаги управления системой, это так, только статистику
> с нужным колонками получить. Вот если бы сделали полноценную систему управления
> хостом из консоли/через утилитку запросами
> INSERT INTO etc.passwd (username,password) VALUES ("_KUL", "12345");
> это бы админы оценили!
> p.s. Лучше бы разработчики systemd эту идею развили, меньше врагов имели бы.это частично реализует любая scm... (Ansible, Puppet, Chef, cdist)
там, конечно не sql, но оно там и не надо