Odstraňování diakritiky tímto způsobem mi přišlo jako hrozné už před spoustou let. Je pravdou že v tomto případě to asi bude fungovat, ale používat to univerzálně na texty není dobrý nápad (těch znaků na replace je o mnoho více než ve vašm kódu). NodeJS také neznám, ale malé googlení - co zkusit iconv, iconv-lite?
Za mě dobrý, nedávno jsem viděl jeden team co si na obdobný task vzal spike na research a po 14 dnech přišel s tím ze to bude možné udělat. A v tu dobu neměl v podstatě nic k prezentaci. Předpokládám, že pro vás to bylo sobotní odpoledne. K té diakritice. Jména Prometheus labelů musí odpovídat teto regexp [a-zA-Z_][a-zA-Z0-9_]* tedy pouze ASCII alfanumericke znaky.
Na odstranění diakritiky bych zkusil Unicode property escapes a string.normalize funkci.
const str = “Žluťoučký kůň”
str.normalize("NFKD").replace(/\p{Diacritic}/gu, "")
a není lepší použít negaci toho pravidla? Protože přes tvůj výraz projde třeba ~, což ale také nemůže být v labelech.
Pokud je nějaký label nevalidní, prometheus nenačte nic z celého souboru, takže ošetřovat správně na výstupu je stěžejní. Tyhle ošetření, které fungují pouze na omezeném vzorku je pěkná past.
jo to je pravda, past to bude vzdycky, ja bych se v tomto pripade vydal cestou ne celeho jmena meny, ale pouzival bych 3 pismenne mezinarodni kody a problem by se vyresil take nejak sam od sebe. Myslim, ze v Grafana kdyby nekdo na celych jmenech trval by se to asi dalo vyresit nejakym key/value mapping, ale ruku do ohne bych za to nedal.
Ano, Grafana dovoluje modifikace zobrazovaných labelů - já v ní dělám třeba to, že z plného doménového jména stroje, které je v Prometheu jako "server.typ.datacentrum.domena.firma.com", si vytáhnu jen konkrétní části přes regex a zobrazím jako "datacentrum - server". A pro předem známé hodnoty (zajímají nás jen tyhle 4 měny) si člověk může udělat substituci jak chce.
Pokud by to nekdo chtel resit pres telegraf, tak tam bude konfigurace vypadat nejak takto:
[[inputs.http]]
name_override = "CNB Exchange Rate"
urls = [
"https://www.cnb.cz/en/financial-markets/foreign-exchange-market/central-bank-exchange-rate-fixing/central-bank-exchange-rate-fixing/daily.txt"
]
data_format = "csv"
csv_header_row_count = 1
interval = 3600
csv_delimiter = "|"
csv_skip_rows = 1
csv_tag_columns = ["Country","Currency","Amount","Code"]
tagexclude = ["url"]
Takto telegraf pouzivam v praci.
Este si mohol pridat prometheus output plugin sekciu.
https://github.com/influxdata/telegraf/blob/release-1.27/plugins/outputs/prometheus_client/README.md
Davam kurzy do InfluxDB, takze konfiguraci pro prometheus nevladnu. Ale samozrejme se to da libovolne dal rozvijet.
Jeste me napadlo, ze by nekdo mohl premyslet proc je tam radek
tagexclude = ["url"]
je to protoze to URL je celkem dlouhe a neni nijak zajimave, tak aby nasbirana data nezabirala tolik mista.
Dobrý howto článek!
Kolega se na názvy měny a země vybodl a prostě nám vyhodí jednoduchou mapu na způsob:
#:currency{:jpy 15.481,
:huf 6.376,
:hkd 2.917,
:cny 3.136,
:mxn 1.323,
:ils 5.974,
:idr 1.485,
:xdr 30.168,
:sgd 16.764,
:php 40.234,
:inr 27.504,
:ron 4.932,
:myr 4.878,
:try 0.849,
:gbp 28.46,
:eur 24.5,
:thb 63.813,
:dkk 3.284,
:bgn 12.527,
:pln 5.301,
:krw 1.718,
:zar 1.205,
:chf 25.547,
:sek 2.05,
:cad 16.827,
:aud 14.613,
:usd 22.829,
:nok 2.134,
:isk 17.049,
:brl 4.611,
:nzd 13.467}
Výhoda je, že celý parsing i stažení je realizováno na 14 řádcích i s docstringem a volitelně to umí stáhnout i jiné než aktuální datum (jedná se o tzv. multifunkci). Nikde to negrafíme, používá se to čistě pro účetnictví. Píše se to s jinými statistikami prostě jako JSON do PostgreSQL. Jinak Prometheus exportéry používáme interně na měření výkonu různých komponent sloužících OrgPadu, ale napsali jsme si primitivní "server", který periodicky sbírá metriky tak, že zavolá prom2json proti dané komponentě a dále už si to zredukujeme na to, co nás zajímá. Není to zdaleka tak sofistikované, jako Prometheus, ale nemusíme se nic dalšího učit, nastavovat, updatovat apod.
O domácím Kubernetes taky uvažuji, že bych napsal, používám MicroK8S na Ubuntu, které hostuji v HyperV. Funguje to velmi slušně, teď už skoro 2 roky, narazil jsem na pár drobných problémů, ale veskrze se to dá provozovat, asi jediná nevýhoda je spotřeba elektřiny, ale věřím že něco podobného lze postavit i na Raspberry Pi.
Jako na hrani dobry, ale k praktickemu uziti to ma daleko.
1) CNB zverejnuje typicky 1 kurz denne (o vikendu a svatcich zadnej), ale nekdy se stane ze tam jsou i dva :)
2) kdyz vase monstrum bude mit vypadek, tak budete mit diru v datech?
Mam taky vlastni skript, ktery synchronizuje CNB kurzy do nasi DB (klasika cron/PHP/MariaDB), kdyz zjisti diskontinuitu tak dotaha zpetne zbytek. Na druhem konci je pak php trida v ramci ucetniho systemu, ktere pri volani zadate castku, zdrojovou a cilou menu, nejaky cas.. a ono se vam to pokusi* najit referenci na kurz v dany moment i kolik to dela v cilove mene :)
*Pokusi.. CNB nevede vsechny meny, takze pri "NULL" se holt musi duverovat jinym informacim ktere indikuji kurz.
Určitě jsi skvělý programátor, a máš to pro účetní systém vymyšleno dobře, nicméně tady nebylo účelem mít nějaký dlouhodobý graf, historie zde není podstatná, podstatný je každodenní přehled a práce s emocemi, tedy jiné využití než zmiňuješ.
To co popisuješ, tedy účetní data, tam by určitě dávalo smysl se vydat nějakou cestou, která by třeba mohla fungovat, tak jak navrhuješ, to je pravda.