Vlákno názorů k článku
Linux sysinfo: získávání systémových informací ve formátu JSON od Uncaught ReferenceError: - jaký je pro tohle use case? Krátkým pohledem...

jaký je pro tohle use case? Krátkým pohledem vidím, že parsuješ textový výstup příkazů, což je někdy velice ošemetné, viz třeba tvůj hosts, kde jak vidím nepočítáš s mezerou jako oddělovačem. Krom toho nevidím, že bys nějak pracoval s locales, pro přenosný script se hodí, když si tohle pohlídá.

Na tyhle věci používáme osquery, výstup má daleko spolehlivější. Případně velice slušnou práci dělá ansible -m setup

jaký je pro tohle use case?
- Sběr dat a následná analýza jinými nástroji (např. pro monitoring).

Krátkým pohledem vidím, že parsuješ textový výstup příkazů, což je někdy velice ošemetné, viz třeba tvůj hosts, kde jak vidím nepočítáš s mezerou jako oddělovačem.
- Ano, parsuji textové výstupy příkazů a děkuji za upozornění na jakoukoliv chybu ve způsobu zpracování dat.

Krom toho nevidím, že bys nějak pracoval s locales, pro přenosný script se hodí, když si tohle pohlídá.
- Ne, s locales momentálně nepracuji.

Na tyhle věci používáme osquery, výstup má daleko spolehlivější. Případně velice slušnou práci dělá ansible -m setup
- Nesnažím se konkurovat zaběhlým projektům se spoustou vývojářů. Toto je můj hobby projekt, který je teprve v začátku a nabízím jej jako možnost jak získat užitečné údaje ze systému a nemuset při tom psát vlastní parsery.

Petr.

A proc nesbirat tyto informace rovnou z /proc a /sys, ale cekat na existenci mezi-vrstvy?

Taky si říkám...

Přesně, tohle je peklo a za trest když to někdo takto dělá. Už jsem v životě narazil na několik případů kde toto vedlo ke ztrátě dat a podobným problémům.

Člověk si řekne vždyť ono to jen zpracovává výstup nějaké aplikace a ten dá na výstup. No to platí jen do té doby než se všude po netu začnou objevovat super návody, které daný nástroj využívají jako mezi krok pro další příkazy. A to že to v 90% funguje je sice pěkné, ale v těch 10% to může způsobit obrovské škody.

Za mne by se nikdy neměl zpracovávat výstup nástrojů, které negenerují nějaký standardní formát (TSV,CSV,JSON­,XML,SDL,YAML­...)

A toto je podla teba co?
kill `ps -ef | fgrep nieco | cut -c 12-30`
Na unixe dlhe roky spracovavame textove vystupy nestandardnych formatov a nemame z toho hlavu v smutku.

Tak samozřejmě mohou být případy kdy to funguje. Já ani netvrdím opak. A ten tvůj příklad vůbec není to o čem se bavím.

A ten tvůj příklad vůbec není to o čem se bavím.

Tak mas neco realneho?

Právě, že máme. Na Unixu dlouhé roky existují neřešitelné bezpečnostní problémy, náhodně se vyskytující bugy a odporné rovnáky na ohejbáky, protože v r. 1969 někdo dostal zvrácený nápad zpracovávat jakákoli data jako netypovaný a nestrukturovaný proud oktetů, a od té doby si fanboyové myslí, že je to tak dobře. Není, nebylo a nikdy nebude.

Škoda, že se více neuchytily třeba ty LISP machines. Aktuálně by asi bylo lepší posílat např. EDN, což je superset JSONu a má i další výhody jako jednodušší streamovatelnost. Možná jsou lepší varianty, ale tohle mi nepřijde špatné a je možné v tom reprezentovat dost dobře i čísla různých přesností nebo třeba množiny.
Problém bych viděl v tom, že by muselo existovat něco jako Clojure a bez garbage collection a tedy méně dynamického, aby se to dalo zkompilovat do strojového kódu předem. To by přesto asi umožňovalo nějaký interpret na způsob Babashky. Nemyslím ale, že by to byl neřešitelný problém. Jistě by nebyl problém vytvořit i nástroje, které by pracovaly s EDN v jazycích jako Rust, kde by se "prostě" přidala jen knihovna, která by většinu operací ulehčovala.
Možná by to šlo i nějak nalepit na současný systém na způsob Closh, ale myslím spíš, že je to dlouhodobě víc práce a slepá cesta.

Nevím, jestli víte jak funguje Ansible, ale dělá úplně to samé co moje aplikace (aspoň tedy co se týká získávání dat) . Na vzdáleném hostu spustí systémový příkaz s parametry, získá výstup a ten potom parsuje. Moje aplikace to dělá lokálně.

Viz Ansible - systemd.py
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/systemd.py#L331

def parse_systemctl_show(li­nes):
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/systemd.py#L290

Ansible je tu již nějaký ten rok a za tu dobu má vyladěny parsery a obrovské množství přispěvatelů.

Položím vám otázku - pokud by moje aplikace používala stejné příkazy a parsery jako Ansible, tak by pro vás byla důvěryhodná?

Petr

Důvěryhodnost si získáte tím, že bude dlouhou dobu fungovat a dávat správné výstupy na různých hardwarech, s různými jádry, na různých locales, ... Toho nedosáhnete, když se nebude používat - a nebude se používat, dokud toho nedosáhnete. Obvykle start života takového nástroje začíná tím, že jej potřebuje nějaký "vyšší" systém. Viz např. ansible.

Komentáře kolegů chápu, taky mi nepřijde jako příliš progresivní brát výstupy (a tím pádem být závislý) na dalších programech, nota bene, když ty informace máte při ruce v /sys a /proc. Použít výstup z jiného programu IMO dává smysl jen v tom případě, pokud je potřeba data interpretovat - doplnit např. o hodnoty z číselníků, které jádro neposkytne přímo.

Jenže, co člověk, to názor. Nejlepší je vrátit se k tomu, na co se Vás už někdo ptal. Jaký je use case. To usnadní zodpovědět tyto otázky.

Že má nějaký produkt "vychytaný" parser ještě neznamená, že způsob, jakým data získává, není z principu špatně zvolený. Tudíž že nemá jenom poměrně spolehlivý rovnák na ohýbák. Není podstatné, jestli mu důvěřuje ten nebo onen; až v tom Ansible nebo někde jinde narazí na okrajový příklad, který nevychytali nebo ten parser někdo "zoptimalizuje" tak, že část případů nebude fungovat, bude to houby platné.

Nový projekt má smysl, pokud máte dostatečně speciální případ použití nebo nějakou novou funkcionalitu. Může být, že třeba považujete Vaši verzi za technologicky lepší, pak je ale vhodné se vyhnout opakování starých chyb a slepých uliček.

Problémem není jen parsování nestrukturovaného výstupu nebo Python 2. Ansible je důvěryhodné i proto, že má za sebou obrovské množství lidí. Když už se objeví nějaký bug, tak ho v Ansible celkem rychle opraví. A je poměrně dobrá pravděpodobnost, že to bude platit i za rok nebo dva.

NIH (not invented here) syndromu je potřeba se vyhýbat. Prospěšnější je přispět do už zavedených projektů. Soukromé pokusy jsou v pořádku, pokud se něco potřebujete naučit. Nicméně pro jejich úspěšné rozšíření je potřeba mnohem více úsilí.

Mimochodem zrovna u toho systemd je tam skoro více dokumentace než kódu. Právě proto, že si autoři jsou vědomi toho, jak to může být křehké.

A ansible jde pustit lokálně: ansible -m setup localhost

ano, ansible také volá také cli příkazy, nepovažuji to za nejlepší způsob, ale je poměrně dobře ověřen praxí a za mě dává spolehlivé výsledky, dá se použít rychle. Za dobu co ho používám jsem hlásil jen minimum problémů.

Osquery od facebooku nebo třeba monitorovací nástroj netdata používá /dev, /proc aj. zařízení pro získávání věšiny informací, to považuji za správnou a udržovatelnou cestu. API v tomhle případě se totiž mění pozvolna, naopak formát textových výstup je mění každou chvíli a závisí na spoustě jiných skutečností.

Každý kdo pracuje s linuxem si parsuje cli a repl výstupy, ale je rozdíl si to udělat pro sebe na konkrétní použití, rovnou si ověřovat výstup a předhodit to jako projekt veřejnosti, kde bych už nějakou přenositelnost a ověřenost čekal.