• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    SNIPERCZEZabbix, nagios a další monitorovací nástroje
    Zabbix - "Zabbix offers advanced monitoring, alerting and visualisation features today which are missing in other monitoring systems, even some of the best commercial ones." Nagios - "Nagios is a powerful IT management system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes."
    rozbalit záhlaví
    HNZ
    HNZ --- ---
    1 odpověď
    SAMGARR: aby mi to reklo, kolik je k dispozici updatu
    SAMGARR
    SAMGARR --- ---
    1 odpověď
    HNZ: Co si predstavujes pod monitorovanim apt?
    HNZ
    HNZ --- ---
    1 odpověď
    nevite nekdo jak monitorovat apt na debianu 10 pomoci promethea? nedelal jste to nekdo?
    MRDAC_BEDEN
    MRDAC_BEDEN --- ---
    QUIP: reagoval jsem pouze na dump/delete/recover - to je reseni, ktere se pouziva na MariaDB, ne v dospelych databazich. TimescaleDB je super.
    QUIP
    QUIP --- ---
    1 odpověď
    MRDAC_BEDEN: Autovacuum / vacuum neni zadny magicwand. Kdyby jo, nebude existovat TimescaleDB. Ta reorganizace dat taky stoji nejakou rezii, nemusi to byt vhodne do kazdeho provozu (at uz kvuli zpomaleni produkcniho provozu, nebo opotrebovavani SSD, nebo dalsi fragmentaci na filesystemu pod tou DB, protoze PG nevi nic o usporadani dat pod tim).
    Nerikam, ze Vacuum obecne je spatne, naopak, ale ma to i sva negativa a neresi to vsechno. Nektere problemy tim naopak muzou vzniknout.
    MRDAC_BEDEN
    MRDAC_BEDEN --- ---
    1 odpověď+1
    QUIP: pg_dumpall, smazat db a obnovit na PostgreSQL? PostgreSQL na to ma jiz desetileti nastroj VACUUM. Standartne by se o tuto praci mel starat proces autovacuum, ale muze selhat (statistika), proto je vhodne cas od casu poustet VACUUM, pripadne VACUUM FULL
    VACUUM FULL;
    VELDRANE
    VELDRANE --- ---
    Ahoj, nevi nekdo jak v promql udelat ze subquery element ? Priklad:

    sort_desc 
    (avg by (pod_set, namespace) 
        (label_replace(
                (container_memory_working_set_bytes{namespace=~"cosi",pod_name!="", name!~"^k8s.*", pod_name!~"^ipf.*", container_name!~".+", compute="generic"}
            / on (namespace,pod_name)
            label_join
                (sum by (pod, namespace) 
                    (kube_pod_container_resource_limits_memory_bytes{namespace=~"cosi",pod!="", pod!~"^ipf.*"})
                    , "pod_name"
                    , ""
                    , "pod")
                * 100),
            "pod_set"
            , "$1"
            , "pod_name"
            , "(.*)-(.*)-.{5}")))

    Mam takovyhle sileny query kde vysledkem je vytizeni limitu/requestu per deployment, statefulset, whatsever. For je v tom ze pokzady ty limity requesty jsou nastaveny jinak a neco jinyho je mit 70% z 0.5 coru a neco jinyho je to z 6 coru. Bohuzel tu informaci o limitech jako takovych to subquery nakonec "ztrati" a ja ji nemuzu pouzit treba v grafane pro popisek legendy, coz by se mi dost hodilo. Neexistuje nejaka funkce v promql ktera by tohle umela ? Label_join to asi neumi. Dik
    VOJTAM
    VOJTAM --- ---
    Ahoj, nemáte někdo pls. tip na Nagis Windows Agenta ?
    TOTAL
    TOTAL --- ---
    +2
    QUIP: Tak pecka, stroj byl opet pomaly ... chyba byla u poskytovale VPS (zapis na disk) ... Nejdriv mi tvrdili, jak mam vse spatne ja. Hmm. Tak jsem si aspon rozsiril obzory. Diky ;)
    TBC
    TBC --- ---
    Resil jste nekdo napojení dat z nejakeho HTTP API, ktere presentuje data v jsonu do Promethea? Pouzili jste na to nejaky exporter a jen priohnuly, nebo jste to museli nejak napsat sami?
    TOTAL
    TOTAL --- ---
    QUIP: Tak jsem to zkusil prehodit na TIMESCALEDB ... a ten jejich timescaledb-tune je mazec ;) Kazdopadne pozoruji vyrazny rozdil. Zkusim si s tim pohrat a neco si vice nastudovat. Ale tohle mi prijde jako spravna cesta. Kleslo vytizeni stroje (bodejt by ne ;) ).

    Diky vsem za reakce a rady !
    QUIP
    QUIP --- ---
    2 odpovědi
    TOTAL: Dej pak vedet, jak jsi s tim pochodil, ja mam Zabbix zatim jen pro testovaci ucely a protoze vic pracuju s MySQL (MariaDB), tak to mam napojene na MySQL, ale kdyz jsem cetl ty krasny veci o TimescaleDB, tak bych tomu asi taky dal sanci, protoze az do Zabbixu nahazim tech par desitek hostu, tak se to zacne taky chovat jinak, nez kdyz to ted testuju se 3 hostama. :)
    TOTAL
    TOTAL --- ---
    1 odpověď
    QUIP: Tak jsi mel pravdu. Po dumpu a restore je velikost DB o 1,5GB mensi ... mazec. Ted jdu testovat (rozhodne to rychlejsi je). Ale vrta mi hlavou ten TIMESCALEDB ... i kdyz to je kanon na vrabce, ale uz jenom si ho zkusit ;)

    Diky moc za nasmerovani.
    TOTAL
    TOTAL --- ---
    QUIP: Uz na tom importu pracuju ;)

    Co se tyce TIMESCALEDB, tak to vypada na slusny rozdil .... to jsem uplne minul ;)

    RATTKIN: Diky za tip ... ;)
    QUIP
    QUIP --- ---
    3 odpovědi
    TOTAL: Jako uplne prvni krok zkus udelat pg_dumpall, smazat DB a ten dump zase naimportovat zpatky. Tim zajistis, ze data nebudou nijak fragmentovana atd. Problem to nijak zahadne nevyresi, ale muze ti to pomoc s analyzou, jestli je tvuj problem nejak spojeny s fragmentaci / filesystemem, nebo je problem uz celkovy objem.
    Ono treba u MySQL s InnoDB tabulkama ten dump a re-load casto vyresi vetsinu problemu s rychlosti, protoze z principu InnoDB neuvolnuje stare misto po DELETEd zaznamech, takze po case ma DB na disku treba 20GB velmi fragmentovanych dat a po reloadu je to treba jen 2GB a vsechno zase rok fici jak z praku. Nevim, jak se v tomhle chova PG.

    Ted jsem si jeste v rychlosti vyhledal neco o TimescalDB a vypada to, jako nejlepsi volba:
    TimescaleDB vs. PostgreSQL for time-series: 20x higher inserts, 2000x faster deletes, 1.2x-14,000x faster queries
    Jednodussi nez table partitions.

    Zabbix, Time Series Data and TimescaleDB – Zabbix Blog
    https://blog.zabbix.com/zabbix-time-series-data-and-timescaledb/6642/

    4 TimescaleDB setup [Zabbix Documentation 5.2]
    https://www.zabbix.com/documentation/current/manual/appendix/install/timescaledb
    TOTAL
    TOTAL --- ---
    1 odpověď
    QUIP: Zatim smeruju, ze tu DB budu muset smazat a (data nijak nepotrebuji) a jet znovu s pozorovanim, co to dela .... na VPS jsem psal, samozrejme pisi, ze u nich neni problem, ale u me v DB, nebo sluzbe, ktera cte a zapisuje ...

    RATTKIN: Nepouzival jsem nikdy. Jsou nejake vyhody proti klasickemu POSTGRESQL ? Ted se divam a v konfiguraci POSTGRESQL staci jen toto ? Ma to cenu zkouset ?

    shared_preload_libraries = 'timescaledb'

    Co se stane potom ? ;) Ma jiny pristup k DB ? Nikdy jsem tohle nezkousel.
    RATTKIN
    RATTKIN --- ---
    2 odpovědi
    TOTAL: máš tam timescale db?
    QUIP
    QUIP --- ---
    1 odpověď
    TOTAL: 4GB neni nic velkeho, to je fakt. Nemam ale moc velke zkusenosti s tuningem PostgreSQL, vicp racuju s MySQL a tam je tech moznosti tuningu opravdu hodne.
    NVME je hodne rychly, ale zase jestli je to nejaky sdileny stroj verejneho poskytovatele, mozna tam ostatni VM delaji takovy provoz, ze pro tvoji VM uz moc nezbyva.
    Druha varianta je, ze to VM ma na hypervisoru nastavene nejake limity. On takovy O2 cloud ma treba 200 iops u zakladniho disku a to je faaakt malo. Takze zkus prozkoumat, jestli to nebrzi nejake nastaveni, jestli skutecne pro tvoji VM je tolik IOPS, kolik je potreba.
    TOTAL
    TOTAL --- ---
    RUDOLF: To nevim, jestli ovlivnim ;) Ten stroj zapisuje cca 22hodnost za sekundu. Coz by mela byt sranda, ale asi neni kdyz ta DB takhle roste ...
    TOTAL
    TOTAL --- ---
    2 odpovědi
    QUIP: Ten stroj je VPS a ted to prohlizim a mas pravdu. Zda se, ze ma opravdu problemy se zapisem na disk (i kdyz by tam melo byt NVMe). Jen jen to dost promenlive. A to muze byt i ta DB. Housekeeper mi bezi cca 1/h. Zase tolik dat podrobne neni nutne udrzovat. Co se tycen pameti a CPU, vytizene to je cca na 50-60%.

    Co se tyce POSTGRESQL, tak to byla instalace s vytvorenim strukrury a jina vetsi udrzba nebyla delana. Mam daleko vetsi instalaci na MYSQL a tam se to nedeje.

    Mam vsechna data v jedne tabulce. Partitions nepouzivam, ale podivam se na to. Diky za tip ! Velikost je cca 4GB.

    Diky moc za tve postrehy.

    RUDOLF
    RUDOLF --- ---
    1 odpověď
    TOTAL: moje zkušenost, že za vše můžou špatně koncipovaný Query;-)

    osobně se na postgres dívám, jen skrz nějakou appku, co z toho vytahá zajímavý věci.. přes psql-fu jsem se málokdy k něčemu kloudnýmu dostal..
    Kliknutím sem můžete změnit nastavení reklam