Blog

Píšeme o tom, co zaujalo nás. Třeba to bude zajímavé i pro Vás.

Grafana

Grafanu jsme nedávno využili v realizaci datového dashboardu pro systém prediktivního řízení spotřeby energie budov (PBC/ABM), který můžete najít na záložce Produkty. Po úspěšném dokončení pilotní aplikace tohoto projektu můžeme říci, že Grafana je skvělý nástroj, který Vám pomůže snadno a rychle vyřešit vizualizaci takových dat, která odpovídají filozofii návrhu tohoto nástroje.

Práce s Grafanou je rychlá a příjemná: rozjet si kontejnerizovanou Grafanu v Dockeru Vám zabere pár minut, a pak už si můžete hrát v drag-and-drop prostředí se spoustou možností vizualizace Vašich dat.

Jedinou vadou na kráse je zde dokumentace – ačkoliv Grafana má rozsáhlou dokumentaci pro všechny své funkce, existují zde matoucí rozdíly mezi verzemi. Zdá se, že každá verze Grafany přichází s redesignem jednotlivých nastavení a menu datových panelů, ovšem dokumentace je aktualizována jen se zpožděním. To bohužel vede k tomu, že jakmile se Vám přestane líbit základní práce s panely – která je opravdu povedená, jednoduchá a intuitivní – a chtěli byste přejít k detailnějšímu nastavení, často Vám nezbude než podívat se jak žádaná funkce vypadá v dokumentaci, a pak experimentovat s mírně odlišnou funkcí, kterou máte k dispozici Vy.

V rámci pilotního projektu PBC/ABM jsme zobrazovali časové řady dat pro topnou sezónu každého roku, zatímco letní období mimo topnou sezónu bylo bez jakýchkoliv dat. Zde jsme bohužel těžce narazili, jelikož Grafana předpokládá zobrazování kontinuálních dat, a to především se zaměřením na jejich průběh v reálném čase – na práci s nespojitými historickými daty není připravena.

Naším cílem bylo umožnit uživateli zvolit si topnou sezónu, která ho zajímá, a porovnat ji s jinou, referenční topnou sezónou. Grafana ovšem poskytuje jen velmi omezenou interaktivitu takové volby, a to s využitím interních proměnných pro uložení volby uživatele. I tak zůstanou některé problémy zcela neřešitelné. V našem případě se kamenem úrazu stalo automatické posouvání a měřítkování zobrazení grafu pro vybraná data – to Grafana v podstatě neumožňuje. Nezbylo nám tedy než nechat uživatele ručně posouvat časovou osu tam a zpět, což rozhodně není očekávaný komfort.

Ano, Grafana nabízí množství pluginů pro rozšíření svých funkcí, které jsou většinou k mání zadarmo. My jsme nakonec využili pouze grafický plugin Boom Theme pro individualizovaný vzhled našeho dashboardu, ale stránky Grafana Labs nabízí nepřeberně dalších pluginů, od integrace nových zdrojů dat (Jira, Prometheus, Elasticsearch) po nejrůznější specializované typy panelů. Všechny tyto pluginy ale sdílejí základní myšlenku Grafany, tedy zobrazování spojitých časových řad v grafech a tabulkách s tím, že uživatel je ten, kdo volí jaká data chce a jak je chce zobrazit.

Právě možnost práce s nespojitými daty a s inteligentním přizpůsobením se zobrazení vybraným datům byl jeden z klíčových prvků dosažení uživatelského komfortu práce s PBC/ABM. Proto jsme nakonec jinak skvělou Grafanu opustili a v rámci dalšího vývoje jsme implementovali vlastní frontend, který využívá univerzálnosti frameworku Vue.js a skvělých vlastností knihovny Plotly.

Grafanu bych tedy rozhodně doporučil komukoli, kdo si chce udělat rychlý přehled o svých datech, nebo sestavit jednoduché monitorování vývoje časových řad. Pro specifické záměry ale již Grafana nemusí postačit.

Výpadek nebo špatná koncepce – co je horší?

Dnes vláda České Republiky spustila Centrální rezervační systém pro řízení očkování proti COVID-19. Systém utrpěl ihned po startu výpadek, a ani po obnově provozu nebyl schopen zvládnout nápor uživatelů.

Jako informatik výpadek krátce po spuštění chápu, porodní bolesti jsou běžné pro uvádění větších systémů do provozu. Podle všech dostupných informací a zpráv o chování systému pod zátěží se ale zdá, že problémem je sama koncepce, architektura systému a jeho příprava k provozu.

Systém pro řízení očkování se zdá být navržen jako klasický centrální systém, který je dimenzovaný na určitou zátěž, třeba 250 uživatelů za minutu. Od počátku ale bylo jasné, že charakter zátěže takového systému bude naprosto odlišný – systém bude mít právě 11 milionů uživatelů, kteří k němu budou přistupovat ve vlnách – například dnes všichni senioři. Do zahájení následující vlny bude systém zatížen pouze minimálně.

Dimenzování takového systému na špičkovou zátěž je nesmírně nákladné a pro „klidná období“ zcela neekonomické. Myslím, že měla být použita úplně jiná koncepce – rozložení zátěže v čase a prostoru – tedy více dílčích vstupních bodů po republice, distribuovaná databáze s vazbou na již existující zdroje medicínských dat pro snížení zátěže, ale zejména předregistrace uživatelů, případně další techniky, které by „ořezaly“ špičky zatížení. Tímto postupem se také daly odbavit porodní bolesti systému dlouho před ostrým startem. Celková „user experience“ by pak byla mnohonásobně lepší při stejných nebo nižších nákladech.

Celkově svědčí chování systému o tom, že použitá koncepce byla nepřiměřená zamýšlenému účelu použití. Škoda, koncepci je dnes už pozdě změnit – lze totiž očekávat, že se podobná situace, snad v menším měřítku, bude opakovat na začátku každé následující vlny očkování.

Kdo Vás sleduje?

Díky šikovnému appletu zvanému Blacklight, zdarma k použití na stránkách The Markup, si můžete sami zkusit ověřit, co o vašich aktivitách libovolná webová stránka zaznamenává. Stačí zadat webovou adresu a Blacklight zjistí, zda stránka poskytuje informace Facebooku a Googlu, zda předává uložené soubory cookies třetím stranám, kolik vyhodnocení pro účely reklamy na stránce běží, nebo zda stránka dokonce sleduje pohyb vaší myši a zaznamenává každý stisk klávesy.

Čaj nebo káva?

  • #errorcodes
  • #http

Věděli jste, že webové prohlížeče podporují chybové kódy čajníků? (Aneb jak se dostat od aprílového žertíku až k mezinárodní normě.)

Chybový kód HTTP 418 “I’m a teapot” („Jsem čajník“) indikuje, že server odmítl příkaz vaření kávy, protože se jedná a čajník. Tato hláška bylo poprvé navržena roku 1998, a následně roku 2014 rozšířena pro poskytování plné podpory hypertextových kávovarů dle protokolu HTCPCP (Hyper Text Coffee Pot Control Protocol). Tento protokol je nadstavbou klasického HTTP a zahrnuje nové metody jako BREW (pro zahájení vaření kávy) nebo WHEN (pro ukončení nalévání mléka).

V roce 2017 byl Markem Nottinghamem předložen návrh na odstranění podpory kódu 418 z Go a knihoven Python’s Requests a HttpAbstractions. Paradoxně však tento návrh vyvolal takovou bouři podpory pro tento aprílový žertík, až byl nakonec chybový kód 418 oficiálně označen za rezervovaný stavový kód HTTP. Nemusíme se tedy bát, že by v blízké budoucnosti přestaly naše čajníky mít možnost ohradit se proti vaření kávy.

Taky vám Firefox hlásí zablokovaný port?

  • #firefox
  • #itsecurity
  • #accesscontrol

Většina webových serverů běží na standardním portu 80 nebo 8080. Jsou ale takové weby, zejména servisní, které využívají nestandardní čísla portů. Pak se často setkáváme s chybou NS_ERROR_PORT_ACCESS_NOT_ALLOWED. Tato chyba říká, že Firefox zablokoval přístup na příslušný port z důvodu vaší bezpečnosti – může se totiž jednat o útok typu cross-site scripting. Pokud jste si ale jistí, že tento web nepředstavuje nebezpečí, můžete přístup na něj povolit. Do adresního řádku zadejte about:config, potvrďte bezpečnostní upozornění. Pak ve vyhledávacím okénku zapište security.ports. Objevit by se vám měla jediná volba network.security.ports.banned.override. Pokud neexistuje, vytvořte ji jako parametr typu Textový řetězec. Do hodnoty parametru zadejte seznam portů, které chcete povolit; jednotlivé porty oddělujte čárkou:

mozilla-blocked-port

Podrobnější popis naleznete například zde: https://developer.mozilla.org/en-US/docs/Mozilla/Mozilla_Port_Blocking

© 2020 — 2022 FesorData



IČO: 09074163