{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Z\u00e1klady monitorovania PostgreSQL. Alexej Lesovsk\u00fd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Odpor\u00fa\u010dam obozn\u00e1mi\u0165 sa s preh\u013eadom predn\u00e1\u0161ky Alexeja Lesovsk\u00e9ho z Data Egret \"Z\u00e1klady monitorovania PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

V tejto predn\u00e1\u0161ke Alexej Lesovsk\u00fd hovor\u00ed o k\u013e\u00fa\u010dov\u00fdch aspektoch statistiky PostgreSQL, o tom, \u010do znamenaj\u00fa a pre\u010do by mali by\u0165 s\u00fa\u010das\u0165ou monitorovania; o tom, ak\u00e9 grafy by mali by\u0165 v monitorovan\u00ed, ako ich prida\u0165 a ako ich interpretova\u0165. Predn\u00e1\u0161ka bude u\u017eito\u010dn\u00e1 pre administr\u00e1torov datab\u00e1z, syst\u00e9mov\u00fdch administr\u00e1torov a v\u00fdvoj\u00e1rov, ktor\u00ed sa zauj\u00edmaj\u00fa o rie\u0161enie probl\u00e9mov s PostgreSQL.<\/p>\n

\n

\r\n \"Prehrajte\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Vol\u00e1m sa Alexej Lesovsk\u00fd, zastupujem spolo\u010dnos\u0165 Data Egret. <\/p>\n

<\/p>\n

Trochu slov o sebe. Kedysi d\u00e1vno som za\u010d\u00ednal ako syst\u00e9mov\u00fd administr\u00e1tor. <\/p>\n

<\/p>\n

Spravoval som r\u00f4zne Linuxy, venoval som sa r\u00f4znym veciam spojen\u00fdm s Linuxom, t. j. virtualiz\u00e1ciou, monitorovan\u00edm, pracoval som s proxy at\u010f. Ale v istom momente som sa za\u010dal viac zaobera\u0165 datab\u00e1zami, PostgreSQL. Ve\u013emi sa mi p\u00e1\u010dil. A v istom momente som za\u010dal tr\u00e1vi\u0165 v\u00e4\u010d\u0161inu svojho pracovn\u00e9ho \u010dasu PostgreSQL. Takto som sa postupne stal PostgreSQL DBA.<\/p>\n

<\/p>\n

A po\u010das celej mojej kari\u00e9ry ma v\u017edy zauj\u00edmali t\u00e9my \u0161tatistiky, monitorovania, zberu telemetrie. Ke\u010f som bol syst\u00e9mov\u00fdm administr\u00e1torom, ve\u013emi som sa zaoberal Zabbixom. A nap\u00edsal som mal\u00fa sadu skriptov ako zabbix-extensions<\/a><\/noindex>. Bol dos\u0165 popul\u00e1rny vo svojej dobe. Mohli ste tam monitorova\u0165 ve\u013emi r\u00f4zne d\u00f4le\u017eit\u00e9 veci, nielen Linux, ale aj r\u00f4zne komponenty.<\/p>\n

<\/p>\n

Moment\u00e1lne sa u\u017e venujem len PostgreSQL. P\u00ed\u0161em u\u017e nie\u010do in\u00e9, \u010do umo\u017e\u0148uje pracova\u0165 so \u0161tatistikou PostgreSQL. Vol\u00e1 sa pgCenter<\/a><\/noindex> (\u010dl\u00e1nok na habre \u2014 PostgreSQL \u0161tatistika bez nervov a nap\u00e4tia<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Kr\u00e1tke \u00favodn\u00e9 zamyslenie. Ak\u00e9 s\u00fa situ\u00e1cie, ktor\u00e9 za\u017e\u00edvaj\u00fa na\u0161i z\u00e1kazn\u00edci? Doch\u00e1dza k nejakej hav\u00e1rii s\u00favisiacej s datab\u00e1zou. A ke\u010f sa u\u017e datab\u00e1za obnov\u00ed, prich\u00e1dza ved\u00faci oddelenia alebo ved\u00faci v\u00fdvoja a hovor\u00ed: \u201ePriatelia, mali by sme monitorova\u0165 datab\u00e1zu, preto\u017ee sa stalo nie\u010do zl\u00e9 a v bud\u00facnosti by sa to nemalo opakova\u0165.\u201c A tu za\u010d\u00edna zauj\u00edmav\u00fd proces v\u00fdberu monitorovacieho syst\u00e9mu alebo prisp\u00f4sobenia existuj\u00faceho syst\u00e9mu na to, aby sme mohli monitorova\u0165 na\u0161u datab\u00e1zu \u2013 PostgreSQL, MySQL alebo in\u00e9. A kolegovia za\u010d\u00ednaj\u00fa navrhova\u0165: \u201ePo\u010dul som, \u017ee existuje tak\u00e1 datab\u00e1za. Po\u010fme ju pou\u017ei\u0165.\u201c Kolegovia sa za\u010d\u00ednaj\u00fa medzi sebou h\u00e1da\u0165. A nakoniec sa rozhodneme pre nejak\u00fa datab\u00e1zu, ale monitorovanie PostgreSQL v nej je dos\u0165 slab\u00e9 a v\u017edy je potrebn\u00e9 nie\u010do vylep\u0161ova\u0165. Berieme si nejak\u00e9 repozit\u00e1re z GitHubu, klonujeme ich, prisp\u00f4sobujeme skripty, nejako nastavujeme. A na konci to prech\u00e1dza do istej manu\u00e1lnej pr\u00e1ce. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Preto sa v tejto predn\u00e1\u0161ke pok\u00fasim poskytn\u00fa\u0165 v\u00e1m ur\u010dit\u00e9 poznatky o tom, ako vybera\u0165 monitorovanie nielen pre PostgreSQL, ale aj pre datab\u00e1zy. A poskytn\u00fa\u0165 tie vedomosti, ktor\u00e9 v\u00e1m umo\u017enia vylep\u0161i\u0165 va\u0161e monitorovanie, aby ste z neho z\u00edskali nejak\u00fd \u00fa\u017eitok a aby ste mohli monitorova\u0165 svoju datab\u00e1zu s pr\u00ednosom, aby ste v\u010das upozornili na nejak\u00e9 predch\u00e1dzaj\u00face havarijn\u00e9 situ\u00e1cie, ktor\u00e9 m\u00f4\u017eu nasta\u0165. <\/p>\n

<\/p>\n

A tie my\u0161lienky, ktor\u00e9 bud\u00fa v tejto prezent\u00e1cii, m\u00f4\u017eu by\u0165 priamo prisp\u00f4soben\u00e9 akejko\u013evek datab\u00e1ze, \u010di u\u017e ide o rela\u010dn\u00e9 datab\u00e1zy alebo noSQL. Preto tu nebude len PostgreSQL, ale aj mno\u017estvo receptov, ako to urobi\u0165 v PostgreSQL. Bud\u00fa tam pr\u00edklady dotazov, pr\u00edklady ent\u00edt, ktor\u00e9 s\u00fa v PostgreSQL pre monitorovanie. A ak va\u0161a RDBMS m\u00e1 podobn\u00e9 funkcie, ktor\u00e9 umo\u017e\u0148uj\u00fa ich za\u010dleni\u0165 do monitorovania, m\u00f4\u017eete ich tie\u017e prisp\u00f4sobi\u0165, prida\u0165 a bude to skvel\u00e9.<\/p>\n

<\/p>\n

\"Z\u00e1kladyV predn\u00e1\u0161ke nebudem
\nrozpr\u00e1va\u0165 o tom, ako doru\u010dova\u0165 a uklada\u0165 metriky. Nechcem hovori\u0165 o post-processingu d\u00e1t a ich poskytovan\u00ed u\u017e\u00edvate\u013eovi. A nebudem hovori\u0165 o alertingu.
\nPo\u010das rozpr\u00e1vania budem ukazova\u0165 r\u00f4zne sn\u00edmky obrazovky existuj\u00facich monitorovan\u00ed a ob\u010das ich skritizujem. Napriek tomu sa budem sna\u017ei\u0165 nespom\u00edna\u0165 zna\u010dky, aby som nevytv\u00e1ral reklamu alebo antireklamu t\u00fdmto produktom. Preto v\u0161etky zhody s\u00fa n\u00e1hodn\u00e9 a zost\u00e1vaj\u00fa na va\u0161ej fant\u00e1zii.
\n\"Z\u00e1klady
\nNajprv si ujasn\u00edme, \u010do je to monitorovanie. Monitorovanie je ve\u013emi d\u00f4le\u017eit\u00e1 vec, ktor\u00fa treba ma\u0165. To v\u0161etci ch\u00e1pu. No z\u00e1rove\u0148 monitorovanie nepatr\u00ed medzi obchodn\u00e9 produkty a priamo neovplyv\u0148uje zisk spolo\u010dnosti, preto sa mu v\u017edy venuje pozornos\u0165 len okrajovo. Ak m\u00e1me \u010das, venujeme sa monitorovaniu, ak \u010das nem\u00e1me, v poriadku, d\u00e1me to do backlogu a niekedy sa k t\u00fdmto \u00faloh\u00e1m vr\u00e1time. <\/p>\n

<\/p>\n

Na\u0161a sk\u00fasenos\u0165 ukazuje, \u017ee ke\u010f prich\u00e1dzame k klientom, monitorovanie je \u010dasto nedostato\u010dne vypracovan\u00e9 a nem\u00e1 zauj\u00edmav\u00e9 funkcie, ktor\u00e9 by n\u00e1m pomohli vykon\u00e1va\u0165 pr\u00e1cu s datab\u00e1zami efekt\u00edvnej\u0161ie. Preto je potrebn\u00e9 monitorovanie v\u017edy doladi\u0165. <\/p>\n

<\/p>\n

Datab\u00e1zy s\u00fa komplikovan\u00e9 veci, ktor\u00e9 je tie\u017e potrebn\u00e9 monitorova\u0165, preto\u017ee predstavuj\u00fa \u00falo\u017eisko inform\u00e1ci\u00ed. Inform\u00e1cie s\u00fa pre spolo\u010dnos\u0165 ve\u013emi d\u00f4le\u017eit\u00e9, nem\u00f4\u017eeme ich nijako strati\u0165. No z\u00e1rove\u0148 s\u00fa datab\u00e1zy ve\u013emi zlo\u017eit\u00fdmi kusmi softv\u00e9ru. Skladaj\u00fa sa z ve\u013ek\u00e9ho mno\u017estva komponentov. Mnoh\u00e9 z t\u00fdchto komponentov je potrebn\u00e9 monitorova\u0165. <\/p>\n

<\/p>\n

\"Z\u00e1kladyAk hovor\u00edme konkr\u00e9tne o PostgreSQL, m\u00f4\u017eeme ho predstavi\u0165 ako sch\u00e9mu, ktor\u00e1 sa sklad\u00e1 z ve\u013ek\u00e9ho mno\u017estva komponentov. Tieto komponenty navz\u00e1jom komunikuj\u00fa. Z\u00e1rove\u0148 v PostgreSQL existuje takzvan\u00fd subsyst\u00e9m Stats Collector, ktor\u00fd umo\u017e\u0148uje zbiera\u0165 \u0161tatistiky o fungovan\u00ed t\u00fdchto subsyst\u00e9mov a poskytova\u0165 ak\u00fdsi rozhranie administr\u00e1torovi alebo pou\u017e\u00edvate\u013eovi, aby mohol prehliada\u0165 tieto \u0161tatistiky. <\/p>\n

<\/p>\n

Tieto \u0161tatistiky s\u00fa prezentovan\u00e9 vo forme s\u00faboru funkci\u00ed a poh\u013eadov (view). M\u00f4\u017eeme ich nazva\u0165 aj tabu\u013ekami. Teda s pomocou oby\u010dajn\u00e9ho klienta psql sa m\u00f4\u017eete pripoji\u0165 k datab\u00e1ze, vykona\u0165 select na tieto funkcie a poh\u013eady a z\u00edska\u0165 konkr\u00e9tne \u010d\u00edsla o fungovan\u00ed subsyst\u00e9mov PostgreSQL. <\/p>\n

<\/p>\n

M\u00f4\u017eete tieto \u010d\u00edsla prida\u0165 do va\u0161ej ob\u013e\u00fabenej monitorovacej syst\u00e9mu, nakresli\u0165 grafy, prida\u0165 funkcie a z\u00edska\u0165 analytiku na dlhodob\u00e9 obdobie. <\/p>\n

<\/p>\n

V tejto spr\u00e1ve nebudem zva\u017eova\u0165 v\u0161etky tieto funkcie podrobne, preto\u017ee by to mohlo trva\u0165 cel\u00fd de\u0148. Zameriam sa doslovne na dve, tri alebo \u0161tyri veci a budem rozpr\u00e1va\u0165, ako pom\u00e1haj\u00fa zlep\u0161i\u0165 monitoring.
\n\"Z\u00e1klady
\nA ak hovor\u00edme o monitorovan\u00ed datab\u00e1zy, na \u010do treba monitorova\u0165? V prvom rade by sa mala sledova\u0165 dostupnos\u0165, preto\u017ee datab\u00e1za je slu\u017eba, ktor\u00e1 poskytuje pr\u00edstup k d\u00e1tam klientom a potrebujeme monitorova\u0165 jej dostupnos\u0165, ktor\u00e1 tie\u017e zahr\u0148uje niektor\u00e9 kvalitn\u00e9 a kvantitat\u00edvne charakteristiky. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Rovnako je potrebn\u00e9 monitorova\u0165 klientov, ktor\u00ed sa prip\u00e1jaj\u00fa k na\u0161ej datab\u00e1ze, preto\u017ee m\u00f4\u017eu by\u0165 norm\u00e1lnymi klientmi, ale aj \u0161kodliv\u00fdmi klientmi, ktor\u00ed m\u00f4\u017eu datab\u00e1ze po\u0161kodi\u0165. Taktie\u017e ich treba monitorova\u0165 a sledova\u0165 ich \u010dinnos\u0165.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ke\u010f sa klienti prip\u00e1jaj\u00fa k datab\u00e1ze, je jasn\u00e9, \u017ee za\u010d\u00ednaj\u00fa pracova\u0165 s na\u0161imi d\u00e1tami, a preto mus\u00edme monitorova\u0165 aj to, ako klienti pracuj\u00fa s d\u00e1tami: s ktor\u00fdmi tabu\u013ekami, v men\u0161ej miere s ktor\u00fdmi indexmi. T. j. mus\u00edme pos\u00fadi\u0165 pracovn\u00fa z\u00e1\u0165a\u017e (workload), ktor\u00fa vytv\u00e1raj\u00fa na\u0161i klienti.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Pracovn\u00e1 z\u00e1\u0165a\u017e sa samozrejme sklad\u00e1 z dopytov. Aplik\u00e1cie sa prip\u00e1jaj\u00fa k datab\u00e1ze, z\u00edskavaj\u00fa d\u00e1ta pomocou dopytov, a preto je d\u00f4le\u017eit\u00e9 hodnoti\u0165, ak\u00e9 dopyty s\u00fa v na\u0161ej datab\u00e1ze, sledova\u0165 ich adekv\u00e1tnos\u0165, aby neboli zle nap\u00edsan\u00e9, \u017ee niektor\u00e9 mo\u017enosti treba prepisova\u0165 a optimalizova\u0165 tak, aby fungovali r\u00fdchlej\u0161ie a s lep\u0161ou v\u00fdkonnos\u0165ou. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A ke\u010f hovor\u00edme o datab\u00e1ze, datab\u00e1za je v\u017edy spojen\u00e1 s pozad\u00edm procesmi. Pozadie procesy umo\u017e\u0148uj\u00fa udr\u017eiava\u0165 v\u00fdkon datab\u00e1zy na dobrej \u00farovni, a preto na svoju \u010dinnos\u0165 vy\u017eaduj\u00fa ur\u010dit\u00e9 mno\u017estvo zdrojov. Z\u00e1rove\u0148 sa m\u00f4\u017eu prekr\u00fdva\u0165 so zdrojmi klientskych dopytov, a preto n\u00e1ro\u010dn\u00e1 \u010dinnos\u0165 pozadn\u00fdch procesov m\u00f4\u017ee priamo ovplyvni\u0165 v\u00fdkon klientskych dopytov. Preto ich treba tie\u017e monitorova\u0165 a sledova\u0165, aby nedo\u0161lo k \u017eiadnym probl\u00e9mom v oblasti pozadn\u00fdch procesov. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A to v\u0161etko v r\u00e1mci monitorovania datab\u00e1z zost\u00e1va v syst\u00e9movej metrike. Ale vzh\u013eadom na to, \u017ee v\u00e4\u010d\u0161ina na\u0161ej infra\u0161trukt\u00fary sa pres\u00fava do cloudu, syst\u00e9mov\u00e9 metriky jednotliv\u00e9ho hostite\u013ea v\u017edy ustupuj\u00fa do pozadia. No v datab\u00e1zach s\u00fa st\u00e1le aktu\u00e1lne a monitorovanie syst\u00e9mov\u00fdch metr\u00edk je samozrejme potrebn\u00e9. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

So syst\u00e9mov\u00fdmi metrikami je v\u0161etko celkom v poriadku, v\u0161etky modern\u00e9 monitorovacie syst\u00e9my u\u017e tieto metriky podporuj\u00fa, ale vo v\u0161eobecnosti niektor\u00e9 komponenty st\u00e1le ch\u00fdbaj\u00fa a je potrebn\u00e9 prida\u0165 niektor\u00e9 veci. O t\u00fdchto veciach sa tie\u017e zmienim, nieko\u013eko sn\u00edmok bude o nich. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nPrv\u00fd bod pl\u00e1nu \u2013 to je dostupnos\u0165. \u010co je to dostupnos\u0165? Dostupnos\u0165, pod\u013ea m\u00f4jho n\u00e1zoru, je schopnos\u0165 datab\u00e1zy obsluhova\u0165 pripojenia, t. j. datab\u00e1za je spusten\u00e1, ako slu\u017eba, akceptuje pripojenia od klientov. A t\u00fato dostupnos\u0165 je mo\u017en\u00e9 hodnoti\u0165 niektor\u00fdmi charakteristikami. Tieto charakteristiky je ve\u013emi vhodn\u00e9 umiestni\u0165 na dashboardy. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nV\u0161etci vedia, \u010do s\u00fa to dashboardy. To je, ke\u010f sa jedin\u00fdm poh\u013eadom na obrazovku z\u00edska potrebn\u00e1 inform\u00e1cia. A u\u017e m\u00f4\u017eete okam\u017eite ur\u010di\u0165 \u2013 existuje probl\u00e9m v datab\u00e1ze alebo nie.
\nPod\u013ea toho je dostupnos\u0165 datab\u00e1zy a in\u00e9 k\u013e\u00fa\u010dov\u00e9 charakteristiky v\u017edy potrebn\u00e9 umiestni\u0165 na dashboardy, aby tieto inform\u00e1cie boli po ruke, aby ste ich mali v\u017edy bl\u00edzko. Niektor\u00e9 \u010fal\u0161ie detaily, ktor\u00e9 u\u017e pom\u00e1haj\u00fa pri vy\u0161etrovan\u00ed incidentov, pri rie\u0161en\u00ed nejak\u00fdch havarijn\u00fdch situ\u00e1ci\u00ed, je potrebn\u00e9 umiestni\u0165 na sekund\u00e1rne dashboardy alebo skry\u0165 v odkazoch drilldown, ktor\u00e9 ved\u00fa na extern\u00e9 monitorovacie syst\u00e9my. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Pr\u00edklad jednej zn\u00e1mej monitorovacej s\u00fastavy. Je to ve\u013emi v\u00fdkonn\u00fd monitorovac\u00ed syst\u00e9m. Zbiera ve\u013ea d\u00e1t, ale z m\u00f4jho poh\u013eadu m\u00e1 zvl\u00e1\u0161tny pojem dashboardov. Existuje odkaz \u201evytvori\u0165 dashboard\u201c. Ale ke\u010f vytvor\u00edte dashboard, vytvor\u00edte ak\u00fdsi zoznam pozost\u00e1vaj\u00faci z dvoch st\u013apcov, ak\u00fdsi zoznam grafov. A ke\u010f si potrebujete nie\u010do pozrie\u0165, za\u010dnete my\u0161ou klika\u0165, listova\u0165, h\u013eada\u0165 potrebn\u00fd graf. A to zaber\u00e1 \u010das, t. j. dashboardy, ako tak\u00e9, neexistuj\u00fa. Existuj\u00fa len zoznamy grafov.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

\u010co treba prida\u0165 do t\u00fdchto dashboardov? M\u00f4\u017eeme za\u010da\u0165 s takou charakteristikou, ako je \u010das odozvy. V PostgreSQL existuje poh\u013ead pg_stat_statements. Predvolene je zak\u00e1zan\u00fd, ale je to jeden z d\u00f4le\u017eit\u00fdch syst\u00e9mov\u00fdch poh\u013eadov, ktor\u00fd je v\u017edy potrebn\u00e9 zapn\u00fa\u0165 a pou\u017e\u00edva\u0165. Uchov\u00e1va inform\u00e1cie o v\u0161etk\u00fdch vykonan\u00fdch dotazoch, ktor\u00e9 boli vykonan\u00e9 v datab\u00e1ze. <\/p>\n

<\/p>\n

M\u00f4\u017eeme teda vych\u00e1dza\u0165 z toho, \u017ee m\u00f4\u017eeme z\u00edska\u0165 s\u00fahrnn\u00fd \u010das vykonania v\u0161etk\u00fdch dotazov a rozdeli\u0165 ho pod\u013ea po\u010dtu dotazov za pomoci vy\u0161\u0161ie uveden\u00fdch pol\u00ed. Ale to je tak\u00e1 priemern\u00e1 teplota v nemocnici. M\u00f4\u017eeme vych\u00e1dza\u0165 z in\u00fdch pol\u00ed \u2013 minim\u00e1lny \u010das vykonania dotazov, maxim\u00e1lny a medi\u00e1nov\u00fd. A dokonca m\u00f4\u017eeme zostavova\u0165 percentily, v PostgreSQL existuj\u00fa pr\u00edslu\u0161n\u00e9 funkcie na to. M\u00f4\u017eeme z\u00edska\u0165 nejak\u00e9 \u010d\u00edsla, ktor\u00e9 charakterizuj\u00fa \u010das odpovede na\u0161ej datab\u00e1zy na u\u017e vykonan\u00e9 dotazy, t. j. nevykon\u00e1vame falo\u0161n\u00fd dotaz 'select 1' a sledujeme \u010das odpovede, ale analyzujeme \u010das odpoved\u00ed na u\u017e vykonan\u00e9 dotazy a vyjadrujeme ho bu\u010f ako samostatn\u00e9 \u010d\u00edslo, alebo vytv\u00e1rame graf. <\/p>\n

<\/p>\n

Je tie\u017e d\u00f4le\u017eit\u00e9 sledova\u0165 po\u010det ch\u00fdb, ktor\u00e9 syst\u00e9m v s\u00fa\u010dasnosti generuje. A na to m\u00f4\u017eeme pou\u017ei\u0165 poh\u013ead pg_stat_database. S\u00fastred\u00edme sa na pole xact_rollback. Toto pole ukazuje nielen po\u010det rollbackov, ktor\u00e9 sa v datab\u00e1ze uskuto\u010d\u0148uj\u00fa, ale aj po\u010det ch\u00fdb. Podmiene\u010dne povedan\u00e9, m\u00f4\u017eeme t\u00fato hodnotu zobrazi\u0165 na na\u0161om dashboarde a sledova\u0165, ko\u013eko m\u00e1me v s\u00fa\u010dasnosti ch\u00fdb. Ak je ch\u00fdb ve\u013ea, je to dobr\u00fd d\u00f4vod pozrie\u0165 sa do logov a zisti\u0165, ak\u00e9 s\u00fa to chyby a pre\u010do sa vyskytuj\u00fa, a potom ich vy\u0161etrova\u0165 a rie\u0161i\u0165.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

M\u00f4\u017eete prida\u0165 aj nie\u010do ako Tachometer. To je po\u010det transakci\u00ed za sekundu a po\u010det dotazov za sekundu. Povedzme, \u017ee tieto \u010d\u00edsla m\u00f4\u017eete pou\u017ei\u0165 ako aktu\u00e1lny v\u00fdkon va\u0161ej datab\u00e1zy a sledova\u0165, \u010di s\u00fa tu vrcholy v dotazoch, vrcholy v transakci\u00e1ch alebo naopak, \u017ee datab\u00e1za nie je za\u0165a\u017een\u00e1, preto\u017ee nejak\u00fd backend zlyhal. Na t\u00fato hodnotu je d\u00f4le\u017eit\u00e9 v\u017edy sa pozera\u0165 a pam\u00e4ta\u0165 si, \u017ee pre n\u00e1\u0161 projekt je tak\u00fdto v\u00fdkon norm\u00e1lny, a hodnoty nad a pod t\u00fdm s\u00fa u\u017e nejak\u00e9 probl\u00e9mov\u00e9 a nejasn\u00e9, a teda je potrebn\u00e9 presk\u00fama\u0165, pre\u010do s\u00fa tak\u00e9to \u010d\u00edsla.<\/p>\n

<\/p>\n

Na to, aby sme mohli hodnoti\u0165 po\u010det transakci\u00ed, m\u00f4\u017eeme sa op\u00e4\u0165 obr\u00e1ti\u0165 na poh\u013ead pg_stat_database. M\u00f4\u017eeme s\u010d\u00edta\u0165 po\u010det commitov a po\u010det rollbackov a z\u00edska\u0165 po\u010det transakci\u00ed za sekundu. <\/p>\n

<\/p>\n

V\u0161etci rozumej\u00fa, \u017ee do jednej transakcie sa m\u00f4\u017ee zmesti\u0165 nieko\u013eko po\u017eiadaviek? Preto sa TPS a QPS mierne l\u00ed\u0161ia. <\/p>\n

<\/p>\n

Po\u010det po\u017eiadaviek za sekundu m\u00f4\u017eeme z\u00edska\u0165 z pg_stat_statements a jednoducho spo\u010d\u00edta\u0165 s\u00fa\u010det v\u0161etk\u00fdch vykonan\u00fdch po\u017eiadaviek. Je jasn\u00e9, \u017ee porovn\u00e1vame aktu\u00e1lnu hodnotu s predch\u00e1dzaj\u00facou, od\u010d\u00edtame, z\u00edskame delta a z\u00edska\u0165 mno\u017estvo.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

M\u00f4\u017eeme prida\u0165 dodato\u010dn\u00e9 metriky pod\u013ea z\u00e1ujmu, ktor\u00e9 tie\u017e pom\u00e1haj\u00fa hodnoti\u0165 dostupnos\u0165 na\u0161ej datab\u00e1zy a sledova\u0165, \u010di neboli nejak\u00e9 v\u00fdpadky. <\/p>\n

<\/p>\n

Jedna z t\u00fdchto metrik je uptime. Ale uptime v PostgreSQL je trochu zlo\u017eit\u00e1 z\u00e1le\u017eitos\u0165. Povedzme si pre\u010do. Ke\u010f sa PostgreSQL spust\u00ed, za\u010d\u00edna sa po\u010d\u00edta\u0165 uptime. Ale ak v nejakom momente, napr\u00edklad v noci, bola vykonan\u00e1 nejak\u00e1 \u00faloha, pri\u0161iel OOM-killer a n\u00fatene ukon\u010dil podproces PostgreSQL, potom v takom pr\u00edpade PostgreSQL ukon\u010d\u00ed spojenie v\u0161etk\u00fdch klientov, resetuje \u0161ardovan\u00fa pam\u00e4\u0165 a za\u010dne obnovu z posledn\u00e9ho kontroln\u00e9ho bodu. A k\u00fdm trv\u00e1 t\u00e1to obnova z kontroln\u00e9ho bodu, datab\u00e1za neprij\u00edma pripojenia, t. j. t\u00fato situ\u00e1ciu m\u00f4\u017eeme pova\u017eova\u0165 za v\u00fdpadok. Ale pritom sa po\u010d\u00edtadlo uptime nresetuje, preto\u017ee zoh\u013ead\u0148uje \u010das spustenia postmastera od samotn\u00e9ho za\u010diatku. Preto je mo\u017en\u00e9 tak\u00e9to situ\u00e1cie prehliadnu\u0165.<\/p>\n

<\/p>\n

Tie\u017e by sme mali monitorova\u0165 po\u010det workerov vacuumu. V\u0161etci vedia, \u010do je to autovacuum v PostgreSQL? Je to zauj\u00edmav\u00fd subsyst\u00e9m v PostgreSQL. O \u0148om je nap\u00edsan\u00fdch ve\u013ea \u010dl\u00e1nkov, bolo prezentovan\u00fdch mnoho predn\u00e1\u0161ok. Mnoho diskusi\u00ed sa vedie o vacuume, o tom, ako by mal fungova\u0165. Mnoh\u00ed ho pova\u017euj\u00fa za nevyhnutn\u00e9 zlo. A je to tak. Je to ak\u00fdsi analogick\u00fd zberate\u013e odpadu, ktor\u00fd \u010dist\u00ed zastaran\u00e9 verzie riadkov, ktor\u00e9 nie s\u00fa potrebn\u00e9 \u017eiadnej z transakci\u00ed a uvo\u013e\u0148uje miesto v tabu\u013ek\u00e1ch a indexoch pre nov\u00e9 riadky. <\/p>\n

<\/p>\n

Pre\u010do by sme ho mali monitorova\u0165? Preto\u017ee vacuum ob\u010das sp\u00f4sobuje ve\u013ek\u00e9 probl\u00e9my. Spotrebov\u00e1va ve\u013ek\u00e9 mno\u017estvo zdrojov a po\u017eiadavky od klientov za\u010d\u00ednaj\u00fa trpie\u0165. <\/p>\n

<\/p>\n

Monitorova\u0165 by sme ho mali cez poh\u013ead pg_stat_activity, o ktorom budem hovori\u0165 v nasleduj\u00facej \u010dasti. Tento poh\u013ead zobrazuje aktu\u00e1lnu aktivitu v datab\u00e1ze. A prostredn\u00edctvom tejto aktivity m\u00f4\u017eeme sledova\u0165 po\u010det vakuov\u00fdch procesov, ktor\u00e9 pr\u00e1ve teraz be\u017eia. M\u00f4\u017eeme sledova\u0165 vakuov\u00e9 procesy a vidie\u0165, \u017ee ak prekro\u010d\u00edme limit, je to sign\u00e1l pozrie\u0165 sa do nastaven\u00ed PostgreSQL a optimalizova\u0165 pr\u00e1cu vakuuma. <\/p>\n

<\/p>\n

\u010eal\u0161ou zvl\u00e1\u0161tnos\u0165ou PostgreSQL je, \u017ee ve\u013emi trp\u00ed dlh\u00fdmi transakciami. Najm\u00e4 od transakci\u00ed, ktor\u00e9 visia a ni\u010d nerobia. Tieto sa naz\u00fdvaj\u00fa stat idle-in-transaction. Tak\u00e1to transakcia zadr\u017eiava blok\u00e1cie, a t\u00fdm br\u00e1ni fungovaniu vakuumu. A v d\u00f4sledku toho tabulky narastaj\u00fa, zvy\u0161uj\u00fa sa na ve\u013ekosti. A dotazy, ktor\u00e9 pracuj\u00fa s t\u00fdmito tabulkami, za\u010d\u00ednaj\u00fa fungova\u0165 pomal\u0161ie, preto\u017ee je potrebn\u00e9 preh\u013ead\u00e1va\u0165 v\u0161etky star\u00e9 verzie riadkov z pam\u00e4te na disk a sp\u00e4\u0165.<\/strong> Preto by sme mali monitorova\u0165 aj \u010das, d\u013a\u017eku najdlh\u0161\u00edch transakci\u00ed a najdlh\u0161\u00edch dotazov vakuumu. A ak vid\u00edme nejak\u00e9 procesy, ktor\u00e9 be\u017eia ve\u013emi dlho, u\u017e viac ako 10-20-30 min\u00fat pre OLTP za\u0165a\u017eenie, mali by sme na ne venova\u0165 pozornos\u0165 a bu\u010f ich n\u00fatene ukon\u010di\u0165, alebo optimalizova\u0165 aplik\u00e1ciu, aby sa nespracov\u00e1vali a neviseli tak dlho.<\/strong> Pre analytick\u00e9 za\u0165a\u017eenie je 10-20-30 min\u00fat norm\u00e1lne, niekedy s\u00fa aj dlh\u0161ie. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nPotom m\u00e1me variant s pripojen\u00fdmi klientmi. Ke\u010f u\u017e sme vytvorili dashboard a vystavili na \u0148om k\u013e\u00fa\u010dov\u00e9 metriky dostupnosti, m\u00f4\u017eeme tam prida\u0165 aj dodato\u010dn\u00e9 inform\u00e1cie o pripojen\u00fdch klientoch. <\/p>\n

<\/p>\n

Inform\u00e1cie o pripojen\u00fdch klientoch s\u00fa d\u00f4le\u017eit\u00e9, preto\u017ee z poh\u013eadu PostgreSQL s\u00fa klienti r\u00f4zni. Existuj\u00fa dobr\u00ed klienti a zl\u00ed klienti. <\/p>\n

<\/p>\n

Jednoduch\u00fd pr\u00edklad. Pod klientom rozumiem aplik\u00e1ciu. Aplik\u00e1cia sa pripojila k datab\u00e1ze a hne\u010f za\u010d\u00edna posiela\u0165 svoje dotazy, datab\u00e1za ich spracov\u00e1va a vykon\u00e1va, v\u00fdsledky vracia klientovi. To s\u00fa dobr\u00ed a spr\u00e1vni klienti. <\/p>\n

<\/p>\n

Niekedy nast\u00e1vaj\u00fa situ\u00e1cie, \u017ee klient sa pripojil, udr\u017eiava spojenie, ale pritom ni\u010d nerob\u00ed. Nach\u00e1dza sa v stave idle. <\/p>\n

<\/p>\n

Ale existuj\u00fa aj zl\u00ed klienti. Napr\u00edklad, ten ist\u00fd klient sa prihl\u00e1sil, otvoril transakciu, nie\u010do robil v datab\u00e1ze a potom pre\u0161iel do k\u00f3du, povedzme, aby sa obr\u00e1til na extern\u00fd zdroj alebo aby spracoval z\u00edskan\u00e9 \u00fadaje. Ale z\u00e1rove\u0148 neuzavrel transakciu. A transakcia zost\u00e1va v datab\u00e1ze a blokuje riadky. To je zl\u00e9. A ak sa n\u00e1hodou aplik\u00e1cia niekde vn\u00fatri zr\u00fati cez v\u00fdnimku (Exception), transakcia m\u00f4\u017ee zosta\u0165 otvoren\u00e1 ve\u013emi dlho. A to priamo ovplyv\u0148uje v\u00fdkon PostgreSQL. PostgreSQL bude pracova\u0165 pomal\u0161ie. Preto je d\u00f4le\u017eit\u00e9 tak\u00fdch klientov v\u010das sledova\u0165 a n\u00fatene ukon\u010dova\u0165 ich \u010dinnos\u0165. Mus\u00edte optimalizova\u0165 svoju aplik\u00e1ciu, aby sa tak\u00e9to situ\u00e1cie nevyskytovali. <\/p>\n

<\/p>\n

In\u00fdmi zl\u00fdmi klientmi s\u00fa \u010d\u00edhaj\u00faci klienti. Ale st\u00e1vaj\u00fa sa zl\u00fdmi kv\u00f4li okolnostiam. Napr\u00edklad, jednoduch\u00e1 visiac\u00e1 transakcia: m\u00f4\u017ee otvori\u0165 transakciu, z\u00edska\u0165 z\u00e1mky na nejak\u00e9 riadky, potom sa niekde v k\u00f3de zr\u00fati a zostane visiacou transakciou. Pr\u00edde in\u00fd klient, po\u017eiada o tie ist\u00e9 \u00fadaje, ale naraz\u00ed na zablokovanie, preto\u017ee t\u00e1 visiac\u00e1 transakcia u\u017e zadr\u017eiava z\u00e1mky na niektor\u00e9 potrebn\u00e9 riadky. A druh\u00e1 transakcia bude visie\u0165 v o\u010dak\u00e1van\u00ed, kedy prv\u00e1 transakcia skon\u010d\u00ed alebo ju spr\u00e1vca n\u00fatene ukon\u010d\u00ed. T\u00fdmto sp\u00f4sobom m\u00f4\u017eu \u010d\u00edhaj\u00face transakcie narasta\u0165 a prekro\u010di\u0165 limit pripojen\u00ed k datab\u00e1ze. A ke\u010f je limit prekro\u010den\u00fd, aplik\u00e1cia u\u017e nem\u00f4\u017ee pracova\u0165 s datab\u00e1zou. To u\u017e je havarijn\u00e1 situ\u00e1cia pre projekt. Preto je potrebn\u00e9 sledova\u0165 zl\u00fdch klientov a v\u010das na ne reagova\u0165. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed pr\u00edklad monitorovania. A tu je u\u017e sol\u00eddny dashboard. Na vrchu s\u00fa inform\u00e1cie o pripojeniach. DB connection \u2013 8 kusov. A to je v\u0161etko. Nem\u00e1me inform\u00e1cie o tom, ktor\u00ed klienti s\u00fa akt\u00edvni, ktor\u00ed klienti s\u00fa iba idle, ni\u010d nerobia. Neexistuj\u00fa inform\u00e1cie o visiacich transakci\u00e1ch a \u010d\u00edhaj\u00facich pripojeniach, t. j. je to len \u010d\u00edslo ukazuj\u00face po\u010det pripojen\u00ed a v\u0161etko. A \u010falej sa u\u017e h\u00e1dajte sami.
\n\"Z\u00e1klady
\nAby sme pridali tieto inform\u00e1cie do monitorovania, mus\u00edme sa obr\u00e1ti\u0165 na syst\u00e9mov\u00fd poh\u013ead pg_stat_activity. Ak tr\u00e1vite ve\u013ea \u010dasu v PostgreSQL, je to ve\u013emi dobr\u00fd poh\u013ead, ktor\u00fd by sa mal sta\u0165 va\u0161\u00edm priate\u013eom, preto\u017ee zobrazuje aktu\u00e1lnu aktivitu v PostgreSQL, t. j. \u010do sa v \u0148om deje. Pre ka\u017ed\u00fd proces existuje samostatn\u00fd riadok, ktor\u00fd zobrazuje inform\u00e1cie o tomto procese: z ktor\u00e9ho hostite\u013ea bolo pripojenie vykonan\u00e9, pod ak\u00fdm pou\u017e\u00edvate\u013eom, ak\u00fdm menom, kedy bola transakcia spusten\u00e1, ak\u00fd dopyt sa teraz vykon\u00e1va, ak\u00fd dopyt bol vykonan\u00fd naposledy. A, prirodzene, stav klienta m\u00f4\u017eeme hodnoti\u0165 pod\u013ea po\u013ea stat. Podmiene\u010dne povedan\u00e9, m\u00f4\u017eeme spravi\u0165 groupovanie pod\u013ea tohto po\u013ea a z\u00edska\u0165 tie \u0161tatistiky, ktor\u00e9 s\u00fa teraz v datab\u00e1ze a po\u010det pripojen\u00ed, ktor\u00e9 s\u00fa s t\u00fdmto statom v datab\u00e1ze. A u\u017e z\u00edskan\u00e9 \u010d\u00edsla m\u00f4\u017eeme posiela\u0165 do n\u00e1\u0161ho monitorovania a nakresli\u0165 pod\u013ea nich grafy.
\nTakisto je d\u00f4le\u017eit\u00e9 hodnoti\u0165 trvanie transakcie. U\u017e som hovoril, \u017ee je d\u00f4le\u017eit\u00e9 hodnoti\u0165 trvanie \u00fadr\u017eby, ale aj transakcie sa hodnotia presne rovnak\u00fdm sp\u00f4sobom. Existuj\u00fa polia xact_start a query_start. Tieto, podmiene\u010dne povedan\u00e9, ukazuj\u00fa \u010das za\u010diatku transakcie a \u010das za\u010diatku dopytu. Berieme funkciu now(), ktor\u00e1 zobrazuje aktu\u00e1lny \u010das a od\u010d\u00edtame \u010dasov\u00fa pe\u010diatku transakcie a dopytu. A dost\u00e1vame trvanie transakcie, trvanie dopytu. <\/p>\n

<\/p>\n

Ak vid\u00edme dlh\u00e9 transakcie, mali by sme ich u\u017e dokon\u010di\u0165. Pre OLTP z\u00e1\u0165a\u017e s\u00fa dlh\u00e9 transakcie u\u017e viac ako 1-2-3 min\u00faty.<\/strong>. Pre OLAP z\u00e1\u0165a\u017e s\u00fa dlh\u00e9 transakcie norm\u00e1lne, ale ak sa vykon\u00e1vaj\u00fa viac ne\u017e dve hodiny, je to tie\u017e znak toho, \u017ee niekde m\u00e1me nerovnov\u00e1hu.<\/strong> <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nKe\u010f sa klienti pripoja k datab\u00e1ze, za\u010dn\u00fa pracova\u0165 s na\u0161imi d\u00e1tami. Oslovuj\u00fa tabu\u013eky, oslovuj\u00fa indexy, aby z\u00edskali \u00fadaje z tabu\u013eky. A je d\u00f4le\u017eit\u00e9 hodnoti\u0165, ako klienti pracuj\u00fa s t\u00fdmito d\u00e1tami.<\/p>\n

<\/p>\n

To evaluate our workload and understand which tables are the most 'active', this is necessary. For example, this is essential when we want to place 'hot' tables on fast SSD storage. On the other hand, archival tables that we no longer use can be moved to 'cold' storage on SATA disks, allowing them to reside there with access granted only as needed. <\/p>\n

<\/p>\n

It is also useful for detecting anomalies after various releases and deployments. For instance, if a project rolls out a new feature, such as added functionality for working with the database, we can build usage graphs for the tables that will allow us to easily identify these anomalies. For example, spikes in updates or deletions will be clearly visible.<\/p>\n

<\/p>\n

Moreover, we can detect anomalies in the 'distorted' statistics. What does this mean? PostgreSQL has a very strong and efficient query planner, and developers spend considerable time improving it. How does it function? To create effective plans, PostgreSQL collects statistics on the distribution of data in the tables at regular intervals. This includes the most frequent values: the count of unique values, information on NULLs in the table, and much more. <\/p>\n

<\/p>\n

Based on this statistics, the planner generates several query plans, selects the most optimal one, and uses this plan to execute the query and return the data. <\/p>\n

<\/p>\n

Sometimes, the statistics can become 'distorted'. The quality or quantity of data in a table may change, but the statistics might not have been updated. Consequently, the generated plans could turn out to be suboptimal. If our plans are not optimized based on the collected monitoring data related to the tables, we can spot these anomalies. For instance, if the data quality changes and a sequential scan of the table is suddenly used instead of the index, and if the query only needs to return 100 rows (with a limit set to 100), a complete scan would be performed, which always negatively impacts performance. <\/p>\n

<\/p>\n

A m\u00f4\u017eeme to vidie\u0165 v monitorovan\u00ed. M\u00f4\u017eeme sa pozrie\u0165 na tento dotaz, vykona\u0165 pre\u0148 explain, zhroma\u017edi\u0165 \u0161tatistiky, vytvori\u0165 nov\u00fd dodato\u010dn\u00fd index a reagova\u0165 na tento probl\u00e9m. Preto je to d\u00f4le\u017eit\u00e9. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

\u010eal\u0161\u00edm pr\u00edkladom monitorovania je nie\u010do, \u010do mnoh\u00ed poznaj\u00fa, preto\u017ee je ve\u013emi popul\u00e1rne. Kto to pou\u017e\u00edva vo svojich projektoch? Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Ale tu je jedna zlomyse\u013en\u00e1 oh\u013eadn\u00e1. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Existuje nieko\u013eko grafov. A ako jednotka s\u00fa uveden\u00e9 bajty, t.j. s\u00fa tam 5 grafov: Insert data, Update data, Delete data, Fetch data a Return data. Ako jednotka merania s\u00fa uveden\u00e9 bajty. Ale probl\u00e9m je v tom, \u017ee \u0161tatistika v PostgreSQL vracia d\u00e1ta v tuple (riadkoch). A preto s\u00fa tieto grafy ve\u013emi dobr\u00fdm sp\u00f4sobom, ako zn\u00ed\u017ei\u0165 v\u00e1\u0161 pracovn\u00fd z\u00e1\u0165a\u017e mnohokr\u00e1t, preto\u017ee tuple nie s\u00fa bajty, tuple s\u00fa riadky, a s\u00fa r\u00f4znej d\u013a\u017eky. T.j. vypo\u010d\u00edta\u0165 pracovn\u00fd z\u00e1\u0165a\u017e v bajtoch pomocou tuple je nere\u00e1lny alebo ve\u013emi zlo\u017eit\u00fd \u00falohou. Preto, ke\u010f pou\u017e\u00edvate dashboard alebo integrovan\u00e9 monitorovanie, je v\u017edy d\u00f4le\u017eit\u00e9 pochopi\u0165, \u017ee to funguje spr\u00e1vne a vracia v\u00e1m presne hodnoten\u00e9 d\u00e1ta. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ako z\u00edska\u0165 \u0161tatistiky pre tieto tabu\u013eky? Na to existuje v PostgreSQL nieko\u013eko rod\u00edn poh\u013eadov. A hlavn\u00fdm poh\u013eadom je pg_stat_user_tables<\/a><\/noindex>. User_tables znamen\u00e1, \u017ee tabu\u013eky boli vytvoren\u00e9 v mene pou\u017e\u00edvate\u013ea. Na rozdiel od toho existuj\u00fa syst\u00e9mov\u00e9 poh\u013eady, ktor\u00e9 pou\u017e\u00edva samotn\u00fd PostgreSQL. A existuje s\u00fahrnn\u00e1 tabu\u013eka Alltables, ktor\u00e1 obsahuje syst\u00e9mov\u00e9 aj pou\u017e\u00edvate\u013esk\u00e9 tabu\u013eky. M\u00f4\u017eete sa odrazi\u0165 od akejko\u013evek z nich, ktor\u00e1 sa v\u00e1m najviac p\u00e1\u010di.<\/p>\n

<\/p>\n

Pod\u013ea vy\u0161\u0161ie uveden\u00fdch pol\u00ed m\u00f4\u017eete hodnoti\u0165 po\u010det insert, update a delete. Ten pr\u00edklad dashboardu, ktor\u00fd som pou\u017eil, pr\u00e1ve vyu\u017e\u00edva tieto polia na hodnotenie charakterist\u00edk pracovn\u00e9ho z\u00e1\u0165a\u017ee. Preto sa m\u00f4\u017eeme tie\u017e odrazi\u0165 od nich. Ale treba ma\u0165 na pam\u00e4ti, \u017ee to s\u00fa tuple, nie bajty, tak\u017ee nem\u00f4\u017eeme jednoducho vzia\u0165 a spravi\u0165 to v bajtoch.<\/p>\n

<\/p>\n

Na z\u00e1klade t\u00fdchto d\u00e1t m\u00f4\u017eeme zostavi\u0165 takzvan\u00e9 TopN tabu\u013eky. Napr\u00edklad, Top-5, Top-10. A m\u00f4\u017eeme sledova\u0165 tie hor\u00face tabu\u013eky, ktor\u00e9 s\u00fa vyu\u017e\u00edvan\u00e9 viac ako ostatn\u00e9. Napr\u00edklad 5 \"hor\u00facich\" tabuliek pod\u013ea vkladania. A na z\u00e1klade t\u00fdchto TopN tabuliek hodnot\u00edme na\u0161u pracovn\u00fd z\u00e1\u0165a\u017e a m\u00f4\u017eeme hodnoti\u0165 v\u00fdkyvy pracovn\u00e9ho z\u00e1\u0165a\u017ee po r\u00f4znych vydaniach a aktualiz\u00e1ci\u00e1ch, a nasadeniach. <\/p>\n

<\/p>\n

Je d\u00f4le\u017eit\u00e9 pos\u00fadi\u0165 ve\u013ekos\u0165 tabuliek, preto\u017ee niekedy v\u00fdvoj\u00e1ri zav\u00e1dzaj\u00fa nov\u00e9 funkcie a na\u0161e tabu\u013eky za\u010d\u00ednaj\u00fa nabera\u0165 na ve\u013ekosti, preto\u017ee sa rozhodli prida\u0165 \u010fal\u0161ie \u00fadaje, ale nepredpovedali, ako to ovplyvn\u00ed ve\u013ekos\u0165 datab\u00e1zy. Tak\u00e9to pr\u00edpady n\u00e1s tie\u017e prekvapia. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A teraz m\u00e1m na v\u00e1s mal\u00fa ot\u00e1zku. Ak\u00fa ot\u00e1zku si kladiete, ke\u010f zaznamen\u00e1te za\u0165a\u017eenie na serveri s datab\u00e1zou? Ak\u00e1 je va\u0161a nasleduj\u00faca ot\u00e1zka? <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ale v skuto\u010dnosti vznik\u00e1 nasleduj\u00faca ot\u00e1zka. Ak\u00e9 dopyty sp\u00f4sobuj\u00fa za\u0165a\u017eenie? Nie je zauj\u00edmav\u00e9 sledova\u0165 procesy, ktor\u00e9 sp\u00f4sobuj\u00fa za\u0165a\u017eenie. Je jasn\u00e9, \u017ee ak je hostite\u013e s datab\u00e1zou, datab\u00e1za je spusten\u00e1 a jasn\u00e9 je, \u017ee tam bud\u00fa len datab\u00e1zy, ktor\u00e9 bud\u00fa vyu\u017e\u00edvan\u00e9. Ak otvor\u00edme Top, uvid\u00edme tam zoznam procesov v PostgreSQL, ktor\u00e9 nie\u010do robia. Z Top nebude jasn\u00e9, \u010do robia. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Je preto potrebn\u00e9 identifikova\u0165 tie dopyty, ktor\u00e9 sp\u00f4sobuj\u00fa najv\u00e4\u010d\u0161ie za\u0165a\u017eenie, preto\u017ee ladenie dopytov zvy\u010dajne prin\u00e1\u0161a v\u00e4\u010d\u0161\u00ed pr\u00ednos, ako ladenie konfigur\u00e1cie PostgreSQL alebo opera\u010dn\u00e9ho syst\u00e9mu, alebo dokonca ladenie hardv\u00e9ru. Pod\u013ea mojich odhadov je to pribli\u017ene 80-85-90 %. A to sa rob\u00ed omnoho r\u00fdchlej\u0161ie. R\u00fdchlej\u0161ie je upravi\u0165 dopyt, ako upravi\u0165 konfigur\u00e1ciu, napl\u00e1nova\u0165 re\u0161tart, najm\u00e4 ak nie je mo\u017en\u00e9 re\u0161tartova\u0165 datab\u00e1zu, alebo prid\u00e1va\u0165 hardv\u00e9r. Jednoduch\u0161ie je niekde prepracova\u0165 dopyt alebo prida\u0165 index, aby sme z\u00edskali lep\u0161\u00ed v\u00fdsledok z tohto dopytu. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nJe potrebn\u00e9 monitorova\u0165 dopyty a ich adekv\u00e1tnos\u0165. Zoberme si in\u00fd pr\u00edklad monitorovania. A tu tie\u017e vyzer\u00e1 monitoring v\u00fdborne. S\u00fa tu inform\u00e1cie o replik\u00e1cii, inform\u00e1cie o priepustnosti, blokovan\u00ed, vyu\u017e\u00edvan\u00ed zdrojov. V\u0161etko je skvel\u00e9, ale ch\u00fdbaj\u00fa inform\u00e1cie o dopytoch. Nie je jasn\u00e9, ak\u00e9 dopyty sa vykon\u00e1vaj\u00fa v na\u0161ej datab\u00e1ze, ako dlho trvaj\u00fa, ko\u013eko t\u00fdchto dopytov je. V monitore mus\u00edme v\u017edy ma\u0165 tieto inform\u00e1cie. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Aby sme z\u00edskali tieto inform\u00e1cie, m\u00f4\u017eeme pou\u017ei\u0165 modul pg_stat_statements. Na jeho z\u00e1klade m\u00f4\u017eeme vytv\u00e1ra\u0165 r\u00f4zne grafy. Napr\u00edklad m\u00f4\u017eeme z\u00edska\u0165 inform\u00e1cie o naj\u010dastej\u0161\u00edch dotazoch, t. j. t\u00fdch dotazoch, ktor\u00e9 sa vykon\u00e1vaj\u00fa naj\u010dastej\u0161ie. \u00c1no, po nasaden\u00ed to m\u00f4\u017ee by\u0165 ve\u013emi u\u017eito\u010dn\u00e9 na poh\u013ead na to, aby sme pochopili, \u010di nedoch\u00e1dza k n\u00e1hlemu n\u00e1rastu dotazov. <\/p>\n

<\/p>\n

M\u00f4\u017eeme monitorova\u0165 najdlh\u0161ie dotazy, t. j. tie dotazy, ktor\u00e9 trvaj\u00fa najdlh\u0161ie. Tieto dotazy pracuj\u00fa s procesorom a spotrebov\u00e1vaj\u00fa vstup\/v\u00fdstup. To m\u00f4\u017eeme tie\u017e hodnoti\u0165 pod\u013ea pol\u00ed total_time, mean_time, blk_write_time a blk_read_time. <\/p>\n

<\/p>\n

M\u00f4\u017eeme hodnoti\u0165 a monitorova\u0165 najn\u00e1ro\u010dnej\u0161ie dotazy z h\u013eadiska vyu\u017eitia zdrojov, tie, ktor\u00e9 \u010d\u00edtaj\u00fa z disku, pracuj\u00fa s pam\u00e4\u0165ou alebo naopak vytv\u00e1raj\u00fa nejak\u00fa z\u00e1pisov\u00fa z\u00e1\u0165a\u017e.<\/p>\n

<\/p>\n

M\u00f4\u017eeme hodnoti\u0165 aj naj\u0161tedrej\u0161ie dotazy. To s\u00fa tie dotazy, ktor\u00e9 vracaj\u00fa ve\u013ek\u00e9 mno\u017estvo riadkov. Napr\u00edklad to m\u00f4\u017ee by\u0165 nejak\u00fd dotaz, pri ktorom zabudli nastavi\u0165 limit, a vracia cel\u00e9 obsahy tabu\u013eky alebo \u017eiadan\u00fdch tabuliek.<\/p>\n

<\/p>\n

A m\u00f4\u017eeme tie\u017e monitorova\u0165 dotazy, ktor\u00e9 pou\u017e\u00edvaj\u00fa do\u010dasn\u00e9 s\u00fabory alebo do\u010dasn\u00e9 tabu\u013eky. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nA zostali n\u00e1m pozadie procesy. Pozadie procesy \u2013 to s\u00fa predov\u0161etk\u00fdm checkpointy alebo sa tie\u017e naz\u00fdvaj\u00fa kontroln\u00e9 body, autovacuum a replik\u00e1cia. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed pr\u00edklad monitorovania. Na\u013eavo je karta \u00dadr\u017eba, prejdeme na \u0148u a d\u00fafame, \u017ee uvid\u00edme nie\u010do u\u017eito\u010dn\u00e9. Ale s\u00fa tu len \u010dasy prev\u00e1dzky vakuovania a zhroma\u017e\u010fovania \u0161tatistiky, viac ni\u010d. To s\u00fa ve\u013emi chudobn\u00e9 inform\u00e1cie, preto je v\u017edy potrebn\u00e9 ma\u0165 inform\u00e1cie o tom, ako funguj\u00fa pozadie procesy v na\u0161ej datab\u00e1ze a \u010di nie s\u00fa probl\u00e9my s ich \u010dinnos\u0165ou. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ke\u010f sa zaober\u00e1me kontroln\u00fdmi bodmi, treba si uvedomi\u0165, \u017ee kontroln\u00e9 body vypr\u00e1zd\u0148uj\u00fa \u201e\u0161pinav\u00e9\u201c str\u00e1nky z oblasti delenia pam\u00e4te na disk, potom vytv\u00e1raj\u00fa kontroln\u00fd bod. A tento kontroln\u00fd bod m\u00f4\u017ee by\u0165 nesk\u00f4r pou\u017eit\u00fd ako nejak\u00e9 miesto pri obnove, ak by napr\u00edklad PostgreSQL bolo n\u00e1hle ukon\u010den\u00e9. <\/p>\n

<\/p>\n

Aby sa odstr\u00e1nili v\u0161etky '\u0161pinav\u00e9' str\u00e1nky na disk, je potrebn\u00e9 vykona\u0165 ur\u010dit\u00fd objem z\u00e1pisu. A zvy\u010dajne na syst\u00e9moch s ve\u013ek\u00fdm objemom pam\u00e4te \u2013 je to ve\u013emi ve\u013ea. A ak sa u n\u00e1s kontroln\u00e9 body robia ve\u013emi \u010dasto v nejakom kr\u00e1tkom intervale, diskov\u00e1 v\u00fdkonnos\u0165 bude ve\u013emi v\u00fdrazne klesa\u0165. A z\u00e1kazn\u00edcke po\u017eiadavky bud\u00fa trpie\u0165 nedostatkom zdrojov. Bud\u00fa bojova\u0165 o zdroje a bude im ch\u00fdba\u0165 v\u00fdkon. <\/p>\n

<\/p>\n

Cez pg_stat_bgwriter pod\u013ea uveden\u00fdch pol\u00ed m\u00f4\u017eeme sledova\u0165 po\u010det nast\u00e1vaj\u00facich kontroln\u00fdch bodov. A ak m\u00e1me za ur\u010dit\u00fd \u010dasov\u00fd \u00fasek (za 10-15-20 min\u00fat, za polhodinu) ve\u013emi ve\u013ea kontroln\u00fdch bodov, napr\u00edklad 3-4-5, m\u00f4\u017ee to by\u0165 u\u017e probl\u00e9m. A treba sa pozrie\u0165 do datab\u00e1zy, pozrie\u0165 sa na konfigur\u00e1ciu, \u010do sp\u00f4sobuje tak\u00e9 mno\u017estvo kontroln\u00fdch bodov. Mo\u017eno ide o nejak\u00fd ve\u013ek\u00fd z\u00e1pis. Na z\u00e1klade pracovn\u00e9ho za\u0165a\u017eenia m\u00f4\u017eeme u\u017e pos\u00fadi\u0165, preto\u017ee m\u00e1me grafy pracovn\u00e9ho za\u0165a\u017eenia u\u017e pridan\u00e9. M\u00f4\u017eeme upravi\u0165 parametre kontroln\u00fdch bodov a zabezpe\u010di\u0165, aby nemali ve\u013ek\u00fd dopad na v\u00fdkon po\u017eiadaviek.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Znova sa vraciam k autovacuum, preto\u017ee to je vec, ako som u\u017e povedal, ktor\u00e1 m\u00f4\u017ee \u013eahko ovplyvni\u0165 v\u00fdkon ako diskov, tak aj po\u017eiadaviek, preto je v\u017edy d\u00f4le\u017eit\u00e9 hodnoti\u0165 mno\u017estvo autovacuum. <\/p>\n

<\/p>\n

Po\u010det pracovn\u00edkov autovacuum v datab\u00e1ze je obmedzen\u00fd. Predvolene s\u00fa traja, tak\u017ee ak n\u00e1m neust\u00e1le pracuj\u00fa traja pracovn\u00edci v datab\u00e1ze, znamen\u00e1 to, \u017ee je autovacuum nedostato\u010dne nastaven\u00e9, je potrebn\u00e9 zv\u00fd\u0161i\u0165 limity, prehodnoti\u0165 nastavenia autovacuum a zasahova\u0165 do konfigur\u00e1cie.
\nJe d\u00f4le\u017eit\u00e9 posudzova\u0165, ktor\u00ed na\u0161i pracovn\u00edci vykon\u00e1vaj\u00fa vacuum. Bu\u010f je spusten\u00fd od pou\u017e\u00edvate\u013ea, DBA pri\u0161iel a ru\u010dne spustil nejak\u00e9 vacuum, a to vytvorilo z\u00e1\u0165a\u017e. Objavila sa nejak\u00e1 probl\u00e9m. Alebo je to po\u010det vacuum, ktor\u00e9 odpo\u010d\u00edtavaj\u00fa transak\u010dn\u00e9 po\u010d\u00edtadlo. Pre niektor\u00e9 verzie PostgreSQL s\u00fa to ve\u013emi n\u00e1ro\u010dn\u00e9 vacuum. A m\u00f4\u017eu \u013eahko ovplyvni\u0165 v\u00fdkon, preto\u017ee prech\u00e1dzaj\u00fa celou tabu\u013ekou vcelku, skenuj\u00fa v\u0161etky bloky v tejto tabu\u013eke. <\/p>\n

<\/p>\n

A samozrejme, d\u013a\u017eka vakuovania. Ak m\u00e1me dlh\u00e9 vakuovania, ktor\u00e9 trvaj\u00fa ve\u013emi dlho, znamen\u00e1 to, \u017ee by sme sa mali op\u00e4\u0165 pozrie\u0165 na konfigur\u00e1ciu vakuovania a mo\u017eno prehodnoti\u0165 jeho nastavenia. Preto\u017ee m\u00f4\u017ee nasta\u0165 situ\u00e1cia, ke\u010f vakuum pracuje na tabu\u013eke dlh\u00fa dobu (3-4 hodiny), ale po\u010das tejto doby sa v tabu\u013eke nahromadil \u010fal\u0161\u00ed ve\u013ek\u00fd objem m\u0155tvych riadkov. A hne\u010f ako sa vakuum dokon\u010d\u00ed, bude musie\u0165 op\u00e4\u0165 vakuova\u0165 t\u00fato tabu\u013eku. A dostaneme sa do situ\u00e1cie \u2013 nekone\u010dn\u00e9ho vacuum. V takom pr\u00edpade vakuum nezvl\u00e1da svoju pr\u00e1cu a tabu\u013eky za\u010d\u00ednaj\u00fa postupne narasta\u0165 na ve\u013ekosti, hoci objem u\u017eito\u010dn\u00fdch d\u00e1t v nich zost\u00e1va rovnak\u00fd. Preto pri dlh\u00fdch vakuovaniach v\u017edy sledujeme konfigur\u00e1ciu a sna\u017e\u00edme sa ju optimalizova\u0165, ale pritom tak, aby netrpela v\u00fdkonnos\u0165 klientskych po\u017eiadaviek. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

V s\u00fa\u010dasnosti takmer nie je in\u0161tal\u00e1cia PostgreSQL, kde by nebola streamov\u00e1 replik\u00e1cia. Replik\u00e1cia je proces prenosu d\u00e1t z hlavn\u00e9ho uzla na replik\u00e1ciu.<\/p>\n

<\/p>\n

Replik\u00e1cia v PostgreSQL je realizovan\u00e1 cez \u017eurn\u00e1l transakci\u00ed. Hlavn\u00fd uzol generuje \u017eurn\u00e1l transakci\u00ed. \u017durn\u00e1l transakcie cez sie\u0165ov\u00e9 pripojenie ide na replik\u00e1ciu, kde sa \u010falej reprodukuje. V\u0161etko je jednoduch\u00e9. <\/p>\n

<\/p>\n

Na monitorovanie lagovania replik\u00e1cie sa pou\u017e\u00edva poh\u013ead pg_stat_replication. Ale s t\u00fdm nie je v\u0161etko jednoduch\u00e9. V verzii 10 sa poh\u013ead do\u010dkal nieko\u013ek\u00fdch zmien. Po prv\u00e9, niektor\u00e9 polia boli premenovan\u00e9. A niektor\u00e9 polia boli pridan\u00e9. V 10. verzii sa objavili polia, ktor\u00e9 umo\u017e\u0148uj\u00fa hodnoti\u0165 lag replik\u00e1cie v sekund\u00e1ch. To je ve\u013emi pohodln\u00e9. Pred verziou 10 bola mo\u017enos\u0165 hodnoti\u0165 lag replik\u00e1cie v bajtoch. T\u00e1to mo\u017enos\u0165 zostala aj v 10. verzii, t.j. m\u00f4\u017eete si vybra\u0165, \u010do je pre v\u00e1s pohodlnej\u0161ie - hodnoti\u0165 lag v bajtoch alebo hodnoti\u0165 lag v sekund\u00e1ch. Mnoh\u00ed robia oboje.<\/p>\n

<\/p>\n

Napriek tomu, aby sa hodnotil lag replik\u00e1cie, je potrebn\u00e9 pozna\u0165 poz\u00edciu \u017eurn\u00e1lu v transakcii. A tieto poz\u00edcie \u017eurn\u00e1lu transakci\u00ed s\u00fa pr\u00e1ve vo v\u00fdh\u013eade pg_stat_replication. Povedzme, \u017ee pomocou funkcie pg_xlog_location_diff() m\u00f4\u017eeme zobra\u0165 dve body v \u017eurn\u00e1le transakcie. Spo\u010d\u00edta\u0165 medzi nimi rozdiel a z\u00edska\u0165 lag replik\u00e1cie v bajtoch. To je ve\u013emi pohodln\u00e9 a jednoduch\u00e9. <\/p>\n

<\/p>\n

V 10. verzii bola t\u00e1to funkcia premenovan\u00e1 na pg_wal_lsn_diff(). Vo v\u0161etk\u00fdch funkci\u00e1ch, poh\u013eadoch a n\u00e1strojoch, kde sa vyskytovalo slovo \u201exlog\u201c, bolo nahraden\u00e9 hodnotou \u201ewal\u201c. T\u00fdka sa to nielen poh\u013eadov, ale aj funkci\u00ed. Je to tak\u00e9to novinky. <\/p>\n

<\/p>\n

Navy\u0161e v 10. verzii pribudli riadky, ktor\u00e9 konkr\u00e9tne ukazuj\u00fa oneskorenie. Ide o write lag, flush lag, replay lag. T. j. tieto veci je d\u00f4le\u017eit\u00e9 monitorova\u0165. Ak vid\u00edme, \u017ee m\u00e1me oneskorenie replik\u00e1cie, je potrebn\u00e9 presk\u00fama\u0165, pre\u010do vzniklo, odkia\u013e sa vzalo a odstr\u00e1ni\u0165 probl\u00e9m. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

So syst\u00e9mov\u00fdmi metrikami je prakticky v\u0161etko v poriadku. Ke\u010f sa zaklad\u00e1 ak\u00e9ko\u013evek monitorovanie, za\u010d\u00edna so syst\u00e9mov\u00fdmi metrikami. Ide o vyu\u017eitie procesorov, pam\u00e4te, swapu, siete a disku. Napriek tomu tam ch\u00fdba mnoho parametrov predvolene. <\/p>\n

<\/p>\n

Ak je s vyu\u017eit\u00edm procesora v\u0161etko v poriadku, s vyu\u017eit\u00edm disku s\u00fa probl\u00e9my. Zvy\u010dajne v\u00fdvoj\u00e1ri monitorovac\u00edch n\u00e1strojov prid\u00e1vaj\u00fa inform\u00e1cie o priepustnosti. M\u00f4\u017ee to by\u0165 v iops alebo bajtoch. Ale zab\u00fadaj\u00fa na latenciu a vyu\u017eitie diskov\u00fdch zariaden\u00ed. Ide o d\u00f4le\u017eitej\u0161ie parametre, ktor\u00e9 umo\u017e\u0148uj\u00fa hodnoti\u0165, ako s\u00fa na\u0161e disky za\u0165a\u017een\u00e9 a ako spoma\u013euj\u00fa. Ak m\u00e1me vysok\u00fa latenciu, znamen\u00e1 to, \u017ee existuj\u00fa nejak\u00e9 probl\u00e9my s diskami. Ak m\u00e1me vysok\u00e9 vyu\u017eitie, znamen\u00e1 to, \u017ee disky nezvl\u00e1daj\u00fa.<\/strong> S\u00fa to kvalitnej\u0161ie charakteristiky ako priepustnos\u0165.<\/p>\n

<\/p>\n

Hoci \u0161tatistiku je mo\u017en\u00e9 z\u00edska\u0165 aj z filesyst\u00e9mu \/proc, ako sa to rob\u00ed pre vyu\u017eitie procesorov. Pre\u010do tieto inform\u00e1cie nezapracov\u00e1vaj\u00fa do monitorovan\u00ed, neviem. Napriek tomu je d\u00f4le\u017eit\u00e9 ma\u0165 toto vo svojom monitorovan\u00ed.<\/strong> <\/p>\n

<\/p>\n

Rovnako je to aj v pr\u00edpade sie\u0165ov\u00fdch rozhran\u00ed. Existuj\u00fa inform\u00e1cie o priepustnosti siete v paketoch, v bajtoch, ale napriek tomu ch\u00fdbaj\u00fa inform\u00e1cie o latencii a vyu\u017eit\u00ed, aj ke\u010f to je tie\u017e u\u017eito\u010dn\u00e9.<\/strong> <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ak\u00e9ko\u013evek monitorovania maj\u00fa nedostatky. A ak\u00e9ko\u013evek monitorovanie si zoberiete, v\u017edy bude nevyhovova\u0165 nejak\u00fdm krit\u00e9ri\u00e1m. Napriek tomu sa vyv\u00edjaj\u00fa, prid\u00e1vaj\u00fa sa nov\u00e9 funkcie, nov\u00e9 veci, preto si vyberte nie\u010do a doladte to. <\/p>\n

<\/p>\n

A na to, aby ste to doladili, mus\u00edte v\u017edy ma\u0165 predstavu o tom, \u010do znamen\u00e1 poskytovan\u00e1 \u0161tatistika a ako s jej pomocou mo\u017eno vyrie\u0161i\u0165 probl\u00e9my. <\/p>\n

<\/p>\n

A nieko\u013eko k\u013e\u00fa\u010dov\u00fdch momentov:<\/p>\n

<\/p>\n