• ú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
    TOTAL
    TOTAL --- ---
    +2
    vyreseno ...

    ---------

    UserParameter=UPSStatus,apcaccess | awk '/^(STATUS).*:/ { print $3 }'
    UserParameter=UPSBcharge,apcaccess | awk '/^(BCHARGE).*:/ { print $3 }'
    UserParameter=UPSTimeleft,apcaccess | awk '/^(TIMELEFT).*:/ { print $3 }'

    A zbytek doladit ... funguje. Diky za pozornost ;)
    TOTAL
    TOTAL --- ---
    Zdravim vespolek, mel bych na vas dotaz. Rad bych v ZABBIXU monitoroval UPS (pripojeno pres USB). Ted se probiram ruznymi verzemi, muzete mi nejakou konkretni doporucit ? Diky.

    Zabbix Share - APC
    https://share.zabbix.com/power-ups/apc
    HNZ
    HNZ --- ---
    SAMGARR: to sem vyguglil a asi mi nic jinyho nezbyde :(
    SAMGARR
    SAMGARR --- ---
    1 odpověď
    HNZ: Co bash script a textfile collector?
    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.
    Kliknutím sem můžete změnit nastavení reklam