Dotaz: Co mi uklada RRD databaza?

[yogiman3]

Zdravim, po zkonštruovaní meraka teploty na báze DS18S20 som sa rozhodol, že namerané data chcem zobrazovať pomocou RRD grafu. Databazu vytváram takto:

rrdtool create temperature.rrd --start "now" --step 300 \
DS:temp:GAUGE:500:-273:5000 RRA:AVERAGE:0.5:1:60

dáta updatujem raz za 5 minut a vykresľujem takto:

rrdtool update temperature.rrd N:21
rrdtool graph graph.png -s "now - 3000s" -e "now" DEF:mydata=temperature.rrd:temp:AVERAGE LINE1:mydata#ff0000:"Teplota"

Problem je v tom že keď si "dumpnem" databázu tak hodnoty uložené v jednotlivých riadkoch nezodpovedajú skutočným hodnotám ale nejakým priemerom aktuálnej a predchádzajúcich hodnôt. Ja by som chcel docieliť, aby sa ukladali skutočne namerané hodnoty. Ďakujem za každú pomoc.

Odpovědi

[JF]

A dyt to dela presne co cos rrd zadal. Kdyz tam pises average, tak to prumeruje. Vsimni si, ze ja v prvnim radku zadne average nemam.

if [ ! -f /tmp/monitor2.rrd ]; then
/usr/sbin/rrdtool create /tmp/monitor2.rrd --step 300 \
            DS:temperature:GAUGE:600:U:U  \
            RRA:AVERAGE:0.5:1:600      \
            RRA:AVERAGE:0.5:6:700      \
            RRA:AVERAGE:0.5:24:775     \
            RRA:AVERAGE:0.5:288:797    \
            RRA:MAX:0.5:1:600          \
            RRA:MAX:0.5:6:700          \
            RRA:MAX:0.5:24:775         \
            RRA:MAX:0.5:288:797
fi

Takhle to aktualizuji:

TEMPERATURE=`cat /proc/acpi/thermal_zone/THRM/temperature | sed -e 's/temperature: *\(.*\) C/\1/'`
/usr/sbin/rrdupdate /tmp/monitor2.rrd N:$TEMPERATURE

 

Takhle to kreslim:

if [ /tmp/monitor2.rrd -nt /tmp/www/temperature-day.png ]
then
  rm -f /tmp/www/temperature-day.png
fi
if [ ! -f /tmp/www/temperature-day.png ]
then
/usr/sbin/rrdtool graph /tmp/www/temperature-day.png --start -86400 -t "CPU temperature day" -w 600 \
            DEF:input=/tmp/monitor2.rrd:temperature:AVERAGE \
            LINE1:input#FF0000:"temperature" >/dev/null
fi

 

A tohle je vysledek:

  http://78.108.103.11:11080/cgi-bin/temperature.cgi

[JF]

Po pravde receno RRD zase tak dokonale neznam. Nevim, co delam jinak, ale me to tohle "prumerovani" nedela. Muj postup vyse je spise pro inspiraci a mozna odpovi i nejaky lepsi RRD guru.

[yogiman3]

Ďakujem. Ešte by ma zaujímalo prečo treba toľko RRA archívov, a ako sa vyberajú dáta z konkrétneho archívu pri vykresľovaní grafu?

[AraxoN]

Tie ďalšie archívy sú s menšou presnosťou, ale na väčšie obdobie - aby bolo možné kresliť graf napríklad za celý uplynulý rok (dva, tri, ...), ale zároveň aby to nezaberalo veľa miesta (čo by pri ukladaní každej hodnoty každých 5 minút zaberalo). Prakticky to robí tak, že z viacerých vzoriek urobí jednu pomocou nejakej štatistickej funkcie (AVG, MIN, MAX, ...). Funkcia a počet vzoriek sa definuje pri vytváraní databázy.

Ktorý archív sa použije - to si rrdgraph vyberá sám automaticky, tak aby v ňom bolo celé obdobie, ktoré sa má vykresliť a aby bolo zároveň čo najpresnejšie.

[Heron]

Zřejmně tomu rozumíš, tak se zeptám zde i když to s tématem moc nesouvisí (ale trochu jo). Nikde jsem nevyčetl kolik dat se mi do RRD DB vejde. Chápu, že se velikost nemění, takže se starší data začnou přepisovat (na tom je to vlastně založeno). Ale nevím kolik záznamů tam vlastně mohu uložit bez rizika přepsaní. Dejme tomu že chci ukládat každých 5 minut přesné (neprůmerované) hodnoty po dobu 10let - tj. 1051200 záznamů. Jak by pak vypadalo vytvoření RRD DB?

[AraxoN]

To koľko dát sa do DB vojde sa určuje pri vytváraní DB. Napríklad tento zápis - RRA:AVERAGE:0.5:6:700 znamená, že sa vytvorí tabuľka so 700 riadkami, kde v každom riadku bude spriemerovaných (AVERAGE) 6 hodnôt. Keďže hodnoty pribúdajú každých 5 minút (--step 300), tak každý riadok teda obsahuje hodnoty za 5*6 = 30 minút. Celkový časový rozsah, ktorý sa teda zmestí do tohto konkrétneho RRA je 30*700 = 21000 minút, čo je zhruba 14 a pol dňa. Takže z tohoto RRA sa dá spraviť pekný graf za posledné 2 týždne, ak by si chcel viac týždňov, alebo nejaký starší graf, tak rrdgraph už musí brať údaje z nejakého RRA ktoré má ešte menšiu presnosť. Na celkový obraz ešte doplním, že to 0.5 znamená koľko hodnôt z tých 6 môže byť neznámych (nezaznamenali sa napríklad kvôli reštartu počítača, či zlyhaniu čidla), aby celkový výsledok pre tento riadok ešte nebol neznámy. Je to podiel na celkovom počte hodnôt na ten riadok, t.j. v tomto prípade 0.5*6=3. Teda najviac 3 hodnoty za tú polhodinu môžu byť neznáme a vtedy ešte výsledná hodnota riadku bude spočítaná z tých zvyšných hodnôt. Keď by boli neznáme 4 a viac, tak aj celkový výsledok v tomto riadku už bude neznámy, čo sa na grafe prejaví tak, že v tom mieste bude prerušený graf a ostane tam biele miesto. 0.5 je celkom dobrá hodnota a zatiaľ iba v jednom prípade som ju potreboval zmeniť.

K druhej otázke - keby si chcel uchovávať hodnoty za 10 rokov s presnosťou na 5 minút, tak to je RRA:AVERAGE:0.5:1:1051200, ale týmto IMHO celkom popieraš úmysel, s ktorým bolo RRD vytvorené.

[Jary]

Nedávno jsem si chtěl taky logovat teplotu takle často a dlouho. Také mě napadlo RRD, ale pak jsem si říkal, že je tam hodně redundance a že by to chtělo uchovávat v něčem, jako FLAC ale s mnohem menši vzorkovací frekvencí a s neznámými hodnotami. Neví někdo takovém formátu (kodeku (:)?

[yogiman3]

skus logovať iba rozdiely aktuálnej teploty od predchádzajúcej a nejak vhodne kvantovať a entropicky kódovať :)))

[Heron]

Díky moc za podrobné vysvětlení.

K druhej otázke - keby si chcel uchovávať hodnoty za 10 rokov s presnosťou na 5 minút, tak to je RRA:AVERAGE:0.5:1:1051200, ale týmto IMHO celkom popieraš úmysel, s ktorým bolo RRD vytvorené.

Proč? Na všech existujících grafovadlech statistik mi vadí právě to, že neobsahují třeba rok stará data v dostatečném rozlišení (tředa 14:00-15:00 12.2.2006 ti nic nevykreslí). Tak jsem to začal ukládat do SQL databáze (právě proto, že u RRD jsem neměl jistotu co se mi přemaže), což je na jednu stranu plýtvání místem, ale ukazují se i jiné výhody.

[AraxoN]

Graf z konkrétnej hodiny tri roky dozadu je niečo čo obvykle ľudia nepotrebujú. Ak áno, tak to musia byť tak špecifické prípady, že SQL databáza je na to lepší nápad. V SQL je navyše možné s dátami robiť ďalšie spracovanie, čo v RRD ide buď dosť nemotorne, alebo vôbec.

RRD je nadizajnované tak, aby vedel spraviť grafy s rozumným kompromisom medzi presnosťou dát a veľkosťou databázy, pri zachovaní možnosti pozrieť sa aj na dlhšie časové úseky. Je možné tam spraviť asi aj tých 10 rokov na 5 min. presnosť, ale databáza už potom nebude malá (neskúšal som, ale odhadujem tak desiatky mega). A keď už máš také dáta tak je škoda zostať len pri robení grafov z nich. Toť môj názor.

[Heron]

Hmm, tak jsem RRD považoval za něco, co podle tvých slov není. K čemu je tedy RRD určené? Rychlé ukládání dat (přičemž průběžné počítá hodnoty do archivu podle zadané funkce a dokolečka je přepisuje) a na vykreslení grafu?

neskúšal som, ale odhadujem tak desiatky mega

Když jsem si s tím hrál tak jsem měl tři RRD soubory o celkové velikosti 1.5GB, což by mi vůbec nevadilo (to SQL se k tomu stejně taky dostane), ale jistota chyběla. V SQL mám všechna hrubá data a můžu si je kdykoliv proložit jakýmkoliv polynomem nebo jakkoliv průměrovat pro zvolených úsecích. Toto, jestli to dobře chápu, u RRD také není možné a je třeba tu fci zadat při vytvoření a pak to již nelze měnit.

[Ash]

Ano, rychlé ukládání dat, automatická agregace dat (databáze řeší sama, vy se o nic nestaráte, což u klasické relační databáze automaticky nemáte). Tedy ve výsledku sice ukládáte data s velkou přesností a nějaký čas je máte k dispozici, máte rovněž data za velmi dlouhou dubu (roky), ale databáze je malá, protože s postupem času se méně významná (=starší) data agregují kvůli úspoře místa a rychlosti.

[Ash]

Je dobré si dobře rozmyslet jak dlouho chcete ukládat přesné (neagregované) hodnoty. Někdy je třeba jeden den málo a chce to... alespoň týden, aby měl člověk pocit :) Resp. aby neměl pocit že když se na to dneska nepodívá, tak už zítra nebude mít dostatečně přesný graf.

[AraxoN]

Tak nejak - RRD je (podľa mňa) užitočné primárne na robenie grafov. Ukladanie údajov tam je len tak nejak sekundárne - v takom rozsahu, aby z toho bolo možné spraviť ten graf. To ukladanie dát má svoje záludnosti, ktoré keď sa do toho dostaneš tak Ti prídu úplne logické. Neoboznámený užívateľ ale len krúti hlavou - z čoho vlastne vznikol aj tento thread.

Keď ovládaš SQL, tak tam sú Tvoje dáta rozhodne viac pod kontrolou. RRD vie robiť nejaké aproximácie a odhady, ale k tomu som sa ešte nedostal, čiže neviem povedať ako veľmi to je flexibilné. Pri samotnom kreslení grafu potom je možné údaje ešte trochu spracovávať, ale skôr v takom rozsahu aby to lepšie vyzeralo na grafe - prerátať na percentá a tak.

Ja osobne RRD používam (resp. sa chystám používať) na monitoring serverov - teplota, vyťaženie cpu, pamäť, traffic na diskoch a na sieťovkách, kvalita siete (ping, packet loss), vyťaženosť služieb - mail (in, out, spam, počet pripojení POP/IMAP, ...), web, DNS, databázy. Nič z toho nepotrebujem evidovať nejak presne, a čo potrebujem presne, to sa niekam loguje. Vlastne aby som bol presný - práve z tých logov sa to v niektorých prípadoch cez grep | wc -l ťáha do RRD. Skôr to potrebujem na to, aby som vedel lepšie odhadnúť trendy a mal prehľad, čo ktoré železo ešte znesie, a čo už nie, prípadne čo sa kde deje - ak v jednej mašine skokovo stúpne teplota disku o 10˚C, tak viem hneď povedať, že tam odišiel nejaký ventilátor. Alebo keď vidím, že za týždeň obsadenie diskov stúplo z 80% na 85%, tak viem, že buď začnem agresívnejšie čistiť, alebo mám 3 týždne na to, aby som kúpil ďalšie disky. A v takýchto prípadoch naozaj nepotrebujem vedieť, či sa pred dvoma rokmi niečo udialo 19.1. medzi 7:35 a 7:40, ale postačí mi, že to bolo medzi januárom a februárom. Až by som povedal, že príliš veľa údajov môže byť niekedy na škodu, lebo môže spôsobiť, že človek pre stromy neuvidí les.

Uf, nejak som sa rozpísal... Asi by som to mal radšej blognúť, až to budem mať hotové.

[Heron]

Díky, tak to jsem se trefil. Já si na

monitoring serverov - teplota, vyťaženie cpu, pamäť, traffic na diskoch a na sieťovkách, kvalita siete (ping, packet loss), vyťaženosť služieb

právě také píšu vlastní grafovadlo, protože RRD (Cacti, MRTG apod.) ukládají právě jen trendy a průměry, což se mi nelíbí. Ukládání dat už mi tu nějaký měsíc běží, DB (MySQL, ale uvažuji nad přehozením na Postgresql) to zvládá - tj. všechny připravené dotazy a pohledy jsou nad očekávání rychlé, takže nebude problém s tím interaktivně pracovat (už teď to má nějakých 5mil záznamů - lítá to jak blesk, nebojím se ani mnohaletého provozu se stovkami mil. záznamů). Teď mě právě čeká GUI, což je věc, kterou na programování přímo ... nemám rád .

[AraxoN]

Teď mě právě čeká GUI, což je věc, kterou na programování přímo ... nemám rád

nápodobne... moje "obľúbené" je hlavne "GUI" namixované v HTML, CSS, JS, AJAX, čo je trochu problém, keďže robíme hlavne webové aplikácie. Poslednou dobou sa mi do toho strašne nechce.

[Heron]

namixované v HTML, CSS, JS, AJAX

Néé, horové příběhy prosím néééé.

[Ash]

S postgresql opatrně, je to sice velmi sotisfikovaná databáze, ale rychlost tím půjde dolu.

[Heron]

Mezi MySQL s InnoDB enginem (kde to mám teď) a PostgreSQL (které zatím jen testuji) výkonnostní rozdíl moc není. V MYISAM to mít nemůžu, potřebuju cizí klíče.

[Ash]

Tak to pak jo :)

[AraxoN]

A si si istý, že pri tom volaní update tam vstupuje správny údaj? Pretože inak to je vcelku záhada - oproti tomu čo používam ja tam nevidím žiadny podstatný rozdiel...

[yogiman3]

ano, som si istý že mi tam vstupuje správny údaj. Je záhadou prečo rrd pri zapisovaní do db berie do úvahy aj predchádzajúce vzorky, lebo oni už nepatria do toho 5 min intervalu, ktorý sa má spriemerňovať :(

[AraxoN]

Systémové hodiny fungujú správne? Si si istý, že máš len jednu vzorku 5 minút (zle nastavený crontab)? Ako si došiel k záveru, že to priemeruje - odkladáš si tie hodnoty ešte niekam inam?

[yogiman3]

Som si zrobil experimentálny skript ktorý mi vkladal do databázy každých 5 sekúnd hodnotu 10 a potom 30 a 10 a 30 atd... a v grafe sa hodnoty postupne približovali k 20-tke. Raz mi to dokonca začalo fungovať správne a tuším že to súviselo s časom prvej zadanej hodnoty. Ale nejak z toho neviem vyvodiť záver :)

[AraxoN]

Pri step 300 tam má ísť jedna hodnota za 5 minút. Ak ich tam za 5 minút príde viac, tak ich rrdupdate spriemeruje. Takže ak si tam dal 10, tak tam bolo 10. Následne si vložil 30, výsledok bol (10+30)/2 = 20. Potom si vložil 10 a výsledok sa zase zmenil (10+30+10)/3 = 16.666 a tak dookola, až kým neubehne 5 minút a nezačne sa robiť ďalší riadok. Čím viacej tých 10 a 30 tam za 5 minút prišlo, tým viac sa to blížilo ku 20, a podľa toho, či prvá bola 10 alebo 30 to bolo o niečo menej, alebo o niečo viac než 20.

Ak chceš ukladať hodnoty každých 5 sekúnd, tak by si mal pri vytváraní DB použiť --step 5.

[yogiman3]

Tak asi budem musieť nejako lepšie zabezpečiť to vkladanie dát. Doteraz som to skúšal s python skriptom, ale asi to nieje veľmi dobre riešenie. Vďaka za dosť podrobné vysvetlenie.

[AraxoN]

Ja tiež používam vlastný skript (PHP), ale ten púšťam cronom. Tým sa zabezpečí, že to ide raz za 5 minút, nie viac, nie menej. Ten skript potom robí na jedno spustenie len jeden rrd update a potom sa ukončí.

[yogiman3]

Už som si to prepisal do crona, dúfam že to pôjde ako má. (o 10 minut neskôr)

Nejde to ako má, tu je časť vystupu z dump-u:

<!-- 2009-01-19 15:30:00 CET / 1232375400 --> <row><v> 3.9000000000e+01 </v></row>
<!-- 2009-01-19 15:35:00 CET / 1232375700 --> <row><v> 3.9000000000e+01 </v></row>
<!-- 2009-01-19 15:40:00 CET / 1232376000 --> <row><v> 1.1107523360e+01 </v></row>
<!-- 2009-01-19 15:45:00 CET / 1232376300 --> <row><v> 1.0003952647e+01 </v></row>
 

a pritom tam vkladám náhodne vygenerované celé čisla z rozsahu 0 až 50 pomocou cronu

*/5 * * * * /home/bin/pytho.py

[yogiman3]

Už je to skoro OK, hodnoty sa líšia len v niekoľkých desatinách, ale i tak mi to príde ako nejaký bug rrdtoolsov.

[yogiman3]

Ešte pripojím namerané a uložené hodnoty

10 -> 1.0000000000e+01
2 -> 2.0356088000e+00
6 -> 5.9820156667e+00
41 -> 4.0840660983e+01
 

každopádne je to čudne :(

[yogiman3]

Citujem z FAQ na stranke rrdtools:

Q: I created an rrd file and then used rrdtool update to input a few values. I then used rrdtool fetch to get them back out. The values that come out of rrdtool are sort of similar to what I put in, but they do not match exactly.

A: Think of rrdtool as a 'sampling-device'. The data you provide through the update interface will be resampled to fit the bins you defined when setting the --step value at rrd creation time. If you want to get out exactly what you put in, you have to make sure that you provide your input exactly at the step boundaries (10:00:00, 10:05:00).

[Ash]

Ukládáte to přesně? Tedy nespoléháte se na systémový čas a cron, ale stanovíte vždy v rrdtool update i timestamp? rrdtool update "<timestamp>:<hotnota>"? A čtete to také přesně? (--start --end --step správné/normalizované)? V rámci testování to ani nemusíte dávat do cronu, prostě data nachrlíte v cyklu, postupně zvyšujete timestamp a měníte value.