{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andreas Gushchin (Zabbix): h\u00f8j ydeevne og indf\u00f8dt partitionering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi vil se p\u00e5, hvordan Zabbix fungerer med TimescaleDB som backend. Vi viser, hvordan man starter fra bunden, og hvordan man migrerer fra PostgreSQL. Vi vil ogs\u00e5 fremvise sammenlignende ydeevnetests af de to konfigurationer.<\/p>\n

\"HighLoad++,
\n
\nHighLoad++ Sibirien 2019. Sal \"Tomsk\". 24. juni, 16:00. Resum\u00e9 og pr\u00e6sentation<\/a><\/noindex>. Den n\u00e6ste HighLoad++ konference finder sted den 6. og 7. april 2020 i Sankt Petersborg. Detaljer og billetter via linket<\/a><\/noindex>.<\/p>\n

Andrej Gushchin (herefter \u2013 AG):<\/b> \u2013 Jeg er ingeni\u00f8r i teknisk support for ZABBIX (herefter \u2013 \"Zabbix\"), tr\u00e6ner. Jeg har arbejdet i over 6 \u00e5r i teknisk support og har direkte erfaring med ydeevne. I dag vil jeg tale om den ydeevne, TimescaleDB kan tilbyde, n\u00e5r man sammenligner med almindelig PostgreSQL 10. Der vil ogs\u00e5 v\u00e6re nogle introduktioner om, hvordan det hele fungerer.<\/a><\/noindex><\/p>\n

De vigtigste ydeevneudfordringer: fra indsamling til rensning af data<\/h3>\n

\nLad os starte med, at der er specifikke ydeevneudfordringer, som hvert overv\u00e5gningssystem m\u00f8der. Den f\u00f8rste ydeevneudfordring er hurtig indsamling og behandling af data.<\/p>\n

\"HighLoad++,
\n
\nEt godt overv\u00e5gningssystem skal hurtigt og til tiden indsamle alle data, behandle dem i henhold til triggerbetingelser, det vil sige behandle dem efter visse kriterier (som varierer fra system til system) og gemme dem i databasen, s\u00e5 disse data kan bruges senere.<\/p>\n

\"HighLoad++,
\n
\nDen anden ydeevneudfordring er opbevaring af historik. At opbevare i databasen og have hurtig og nem adgang til de metrikker, der er indsamlet over en bestemt periode. Det vigtigste er, at disse data er lette at f\u00e5 fat i, s\u00e5 de kan bruges i rapporter, diagrammer, triggere og i nogle t\u00e6rskelv\u00e6rdier til alarmer osv.<\/p>\n

\"HighLoad++,
\n
\nDen tredje ydeevneudfordring er rensning af historik, det vil sige n\u00e5r der kommer en dag, hvor du ikke beh\u00f8ver at gemme detaljerede metrikker, der er indsamlet i 5 \u00e5r (eller endda m\u00e5neder eller to m\u00e5neder). Nogle netv\u00e6rksnoder er blevet fjernet, eller nogle hosts er ikke l\u00e6ngere n\u00f8dvendige, fordi de er for\u00e6ldede og ikke l\u00e6ngere indsamles. Alt dette skal renses, s\u00e5 din database ikke vokser til en stor st\u00f8rrelse. Og generelt er rensning af historik ofte en alvorlig test for opbevaringssystemet \u2013 det p\u00e5virker ofte ydeevnen meget.<\/p>\n

Hvordan l\u00f8ser man cacheproblemer?<\/h3>\n

\nJeg vil nu tale specifikt om \u00abZabbix\u00bb. I \u00abZabbix\u00bb er den f\u00f8rste og anden opkald l\u00f8st ved hj\u00e6lp af caching.<\/p>\n

\"HighLoad++,
\n
\nIndsamling og behandling af data \u2013 vi bruger RAM til at gemme alle disse data. Der vil nu blive fortalt mere om disse data.<\/p>\n

Der er ogs\u00e5 en vis caching p\u00e5 databasesiden for de vigtigste foresp\u00f8rgsler \u2013 til grafer og andre ting.<\/p>\n

Caching p\u00e5 selve Zabbix-serveren: vi har ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Hvad er det?<\/p>\n

\"HighLoad++,
\n
\nConfigurationCache er den prim\u00e6re cache, hvor vi gemmer metrics, hosts, dataelementer, triggere; alt hvad der er n\u00f8dvendigt for at behandle pr\u00e6behandling, indsamle data, hvilke hosts der skal indsamles fra, og hvor ofte. Alt dette gemmes i ConfigurationCache for ikke at skulle henvende sig til databasen og skabe un\u00f8dvendige foresp\u00f8rgsler. Efter serverens opstart opdaterer vi denne cache (skaber) og opdaterer det j\u00e6vnligt (afh\u00e6ngigt af konfigurationens indstillinger).<\/p>\n

\"HighLoad++,
\n<\/p>\n

Caching i Zabbix. Dataindsamling<\/h3>\n

\nHer er diagrammet ret omfattende:<\/p>\n

\"HighLoad++,
\n
\nHovedkomponenterne i diagrammet \u2013 de er disse indsamler:<\/p>\n

\"HighLoad++,
\n
\nDet er selve indsamleprocesserne, forskellige \u00abpollere\u00bb, der er ansvarlige for forskellige typer indsamlinger. De indsamler data via icmp, ipmi, forskellige protokoller og sender det hele til pr\u00e6behandling.<\/p>\n

PreProcessing HistoryCache<\/h3>\n

\nHvis vi ogs\u00e5 har beregnede dataelementer (dem, der er bekendt med \u00abZabbix\u00bb, ved det), det vil sige beregnede, aggregationsdataelementer \u2013 vi henter dem direkte fra ValueCache. Hvordan den fyldes, vil jeg fort\u00e6lle om senere. Alle disse indsamler bruger ConfigurationCache til at f\u00e5 deres opgaver og sender derefter til pr\u00e6behandling.<\/p>\n

\"HighLoad++,
\n
\nPr\u00e6behandling bruger ogs\u00e5 ConfigurationCache til at modtage pr\u00e6behandlingstrin, behandler disse data p\u00e5 forskellige m\u00e5der. Fra version 4.2 er det flyttet til proxyen. Det er meget praktisk, fordi selve pr\u00e6behandlingen er en ret tung operation. Og hvis du har en meget stor \u00abZabbix\u00bb, med mange dataelementer og h\u00f8j indsamlingfrekvens, letter det arbejdet betydeligt.<\/p>\n

N\u00e5r vi har behandlet disse data p\u00e5 en eller anden m\u00e5de ved hj\u00e6lp af pr\u00e6behandling, gemmer vi dem i HistoryCache for yderligere behandling. Dette afslutter dataindsamlingen. Vi g\u00e5r til hovedprocessen.<\/p>\n

Arbejdet History syncer<\/h3>\n

\n\"HighLoad++,
\n
\nDen prim\u00e6re proces i \u00abZabbix\u00bb (da det er en monolitisk arkitektur) \u2013 History syncer. Dette er den prim\u00e6re proces, der h\u00e5ndterer atomisk behandling af hver datapunkt, det vil sige hver v\u00e6rdi:<\/p>\n