{"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\/da\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Grundl\u00e6ggende overv\u00e5gning af PostgreSQL. Alexey Lesovsky","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jeg vil gerne pr\u00e6sentere en oversigt over pr\u00e6sentationen af Alexey Lesovsky fra Data Egret \"Grundlag for overv\u00e5gning af PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

I denne pr\u00e6sentation vil Alexey Lesovsky tale om de centrale punkter i PostgreSQL-statistik, hvad de betyder, og hvorfor de skal v\u00e6re en del af overv\u00e5gningen; hvilke grafer der b\u00f8r v\u00e6re med i overv\u00e5gningen, hvordan man tilf\u00f8jer dem, og hvordan man fortolker dem. Pr\u00e6sentationen vil v\u00e6re nyttig for databaseadministratorer, systemadministratorer og udviklere, der er interesserede i fejlfindingsarbejde i Postgres.<\/p>\n

\n

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

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Mit navn er Alexey Lesovsky, jeg repr\u00e6senterer Data Egret. <\/p>\n

<\/p>\n

Lidt om mig selv. Jeg startede engang for l\u00e6nge siden som systemadministrator. <\/p>\n

<\/p>\n

Jeg administrerede forskellige Linux-systemer og arbejdede med forskellige opgaver relateret til Linux, dvs. virtualisering, overv\u00e5gning, arbejdede med proxy osv. Men p\u00e5 et tidspunkt begyndte jeg at fokusere mere p\u00e5 databaser, PostgreSQL. Jeg kunne virkelig godt lide det. Og p\u00e5 et tidspunkt begyndte jeg at arbejde med PostgreSQL det meste af min arbejdstid. S\u00e5 gradvist blev jeg PostgreSQL DBA.<\/p>\n

<\/p>\n

Og gennem hele min karriere har jeg altid v\u00e6ret interesseret i emner som statistik, overv\u00e5gning og indsamling af telemetri. Da jeg var systemadministrator, arbejdede jeg t\u00e6t med Zabbix. Jeg skrev et lille s\u00e6t scripts som zabbix-extensions<\/a><\/noindex>. Det var ret popul\u00e6rt p\u00e5 det tidspunkt. Og man kunne overv\u00e5ge meget vigtige aspekter, ikke kun Linux, men ogs\u00e5 forskellige komponenter.<\/p>\n

<\/p>\n

I dag arbejder jeg med PostgreSQL. Jeg skriver noget andet, som muligg\u00f8r arbejde med PostgreSQL-statistik. Det hedder pgCenter<\/a><\/noindex> (artikel p\u00e5 Habr \u2014 Postgres-statistik uden nerve og stress<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

En lille introduktion. Hvilke situationer oplever vores kunder? Der opst\u00e5r en fejl relateret til databasen. Og n\u00e5r databasen er blevet gendannet, kommer lederen af afdelingen eller udviklingslederen og siger: \u201eVenner, vi b\u00f8r overv\u00e5ge databasen, fordi der skete noget d\u00e5rligt, og vi skal s\u00f8rge for, at det ikke sker igen i fremtiden.\u201c Og her begynder den interessante proces med at v\u00e6lge et overv\u00e5gningssystem eller tilpasse et eksisterende overv\u00e5gningssystem, s\u00e5 vi kan overv\u00e5ge vores database \u2013 PostgreSQL, MySQL eller andre. Og kollegerne begynder at foresl\u00e5: \u201eJeg har h\u00f8rt, at der findes en bestemt database. Lad os bruge den.\u201c Kollegerne begynder at diskutere indbyrdes. Og i sidste ende v\u00e6lger vi en bestemt database, men overv\u00e5gningen af PostgreSQL i den er ret svag, og det er ofte n\u00f8dvendigt at tilf\u00f8je noget ekstra. Tage nogle repositories fra GitHub, klone dem, tilpasse scripts, og justere dem p\u00e5 en eller anden m\u00e5de. Og til sidst resulterer det i noget manuelt arbejde. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Derfor vil jeg i denne pr\u00e6sentation fors\u00f8ge at give dig nogle indsigter om, hvordan man v\u00e6lger overv\u00e5gning ikke kun for PostgreSQL, men ogs\u00e5 for databaser generelt. Og give den viden, der g\u00f8r det muligt for dig at forbedre din overv\u00e5gning, s\u00e5 du kan f\u00e5 noget nytte ud af det, s\u00e5 du kan overv\u00e5ge din database effektivt og i tide advare om potentielle n\u00f8dsituationer, som kan opst\u00e5. <\/p>\n

<\/p>\n

De id\u00e9er, der pr\u00e6senteres i denne pr\u00e6sentation, kan direkte tilpasses til enhver database, hvad enten det er en SQL-database eller noSQL. S\u00e5 her handler det ikke kun om PostgreSQL, men der vil v\u00e6re mange opskrifter p\u00e5, hvordan man g\u00f8r det i PostgreSQL. Der vil v\u00e6re eksempler p\u00e5 foresp\u00f8rgsler og eksempler p\u00e5 enheder, der findes i PostgreSQL til overv\u00e5gning. Og hvis din database har de samme funktioner, der g\u00f8r det muligt at integrere dem i overv\u00e5gningen, kan du ogs\u00e5 tilpasse dem, tilf\u00f8je dem, og det vil fungere godt.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggendeI pr\u00e6sentationen vil jeg ikke
\ntale om, hvordan man indsamler og opbevarer m\u00e5linger. Jeg vil ikke sige noget om efterbehandling af data og om, hvordan man pr\u00e6senterer dem for brugeren. Og jeg vil ikke tale om alarmering.
\nUnder the narrative, I will share various screenshots of existing monitoring systems and critique them as I go along. However, I will try not to mention brand names in order to avoid creating any advertising or negative advertising for these products. Therefore, any similarities are purely coincidental and left to your imagination.
\n\"Grundl\u00e6ggende
\nLet's start by understanding what monitoring is. Monitoring is a very important element that is essential to have. Everyone understands this. However, at the same time, monitoring does not relate to a business product and does not directly affect a company\u2019s profit, which is why monitoring is often given time on a residual basis. If we have time, we deal with monitoring; if there is no time, that's okay, we'll put it on the back burner and come back to these tasks someday. <\/p>\n

<\/p>\n

Therefore, from our experience when we visit clients, monitoring is often underdeveloped and lacks interesting features that could help us work better with the database. Thus, monitoring always requires improvements. <\/p>\n

<\/p>\n

Databases are complex elements that also need to be monitored because databases are stores of information. And information is very important for a company; it cannot be lost under any circumstances. At the same time, databases are very complex pieces of software. They consist of a large number of components, and many of these components need monitoring. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggendeWhen we talk specifically about PostgreSQL, it can be envisioned as a diagram consisting of many components. These components interact with each other. Meanwhile, PostgreSQL has a so-called Stats Collector subsystem that allows gathering statistics about the operation of these subsystems and provides an interface for the administrator or user to view this statistics. <\/p>\n

<\/p>\n

This statistics is presented as a set of functions and views. They can also be referred to as tables. That is, with a standard psql client, you can connect to the database, perform a select query on these functions and views, and obtain specific figures regarding the performance of PostgreSQL subsystems. <\/p>\n

<\/p>\n

You can add these figures to your favorite monitoring system, create graphs, add functions, and obtain long-term analytics. <\/p>\n

<\/p>\n

Men i denne rapport vil jeg ikke gennemg\u00e5 alle disse funktioner grundigt, fordi det kan tage hele dagen. Jeg vil fokusere p\u00e5 to til fire ting og tale om, hvordan de hj\u00e6lper med at forbedre overv\u00e5gningen.
\n\"Grundl\u00e6ggende
\nOg n\u00e5r vi taler om overv\u00e5gning af databasen, hvad skal vi s\u00e5 overv\u00e5ge? F\u00f8rst og fremmest skal vi overv\u00e5ge tilg\u00e6ngeligheden, fordi databasen er en tjeneste, der giver adgang til data for kunderne, og vi skal overv\u00e5ge dens tilg\u00e6ngelighed, samt nogle kvalitets- og kvantitative karakteristika. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Vi skal ogs\u00e5 overv\u00e5ge kunderne, der opretter forbindelse til vores database, fordi de kan v\u00e6re b\u00e5de normale kunder og skadelige kunder, der kan skade databasen. Deres aktiviteter skal ogs\u00e5 overv\u00e5ges.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

N\u00e5r kunderne opretter forbindelse til databasen, begynder de \u00e5benlyst at arbejde med vores data, s\u00e5 vi skal overv\u00e5ge, hvordan kunderne arbejder med dataene: hvilke tabeller de bruger og, mindre grad, hvilke indekser. Det vil sige, at vi skal vurdere den arbejdsbyrde (workload), som vores kunder skaber.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Men arbejdsbyrden best\u00e5r selvf\u00f8lgelig ogs\u00e5 af foresp\u00f8rgsler. Applikationer opretter forbindelse til databasen og henter data ved hj\u00e6lp af foresp\u00f8rgsler, s\u00e5 det er vigtigt at vurdere, hvilke foresp\u00f8rgsler vi har i databasen, overv\u00e5ge deres passendehed, sikre at de ikke er d\u00e5rligt skrevet, og at nogle indstillinger skal omskrives for at fungere hurtigere og med bedre ydeevne. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Og eftersom vi taler om databasen, er databasen altid forbundet med baggrundsprocesser. Baggrundsprocesserne holder databasen i god stand, s\u00e5 de kr\u00e6ver en vis m\u00e6ngde ressourcer til deres drift. Samtidig kan de overlappe med ressourcerne fra kundernes foresp\u00f8rgsler, s\u00e5 en ressourcekr\u00e6vende drift af baggrundsprocesserne kan p\u00e5virke ydeevnen af kundernes foresp\u00f8rgsler. Derfor skal de ogs\u00e5 overv\u00e5ges for at sikre, at der ikke er ubalancer i forhold til baggrundsprocesserne. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Og alt dette i databaseoverv\u00e5gningsplanen forbliver i systemmetrikken. Men i betragtning af at vores infrastruktur stort set flytter til skyen, kommer systemmetrikkerne for en enkelt v\u00e6rt altid i anden r\u00e6kke. Men i databaser er de stadig relevante, og det er selvf\u00f8lgelig ogs\u00e5 n\u00f8dvendigt at overv\u00e5ge systemmetrikker. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Med systemmetrikkerne er alt mere eller mindre i orden, alle moderne overv\u00e5gningssystemer underst\u00f8tter allerede disse metrikker, men generelt mangler der stadig nogle komponenter, og der er behov for at tilf\u00f8je visse ting. Dette vil jeg ogs\u00e5 ber\u00f8re, der vil v\u00e6re et par slides om dem. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nDet f\u00f8rste punkt p\u00e5 planen er tilg\u00e6ngelighed. Hvad er tilg\u00e6ngelighed? Tilg\u00e6ngelighed i min opfattelse er evnen for databasen til at h\u00e5ndtere forbindelser, dvs. databasen er oppe, og som en tjeneste accepterer den forbindelser fra kunder. Og denne tilg\u00e6ngelighed kan vurderes ud fra nogle karakteristika. Disse karakteristika er meget bekvemme at vise p\u00e5 dashboards. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nAlle ved, hvad dashboards er. Det er n\u00e5r du kaster et blik p\u00e5 sk\u00e6rmen, hvor den n\u00f8dvendige information er samlet. Og du kan straks afg\u00f8re \u2013 er der et problem i databasen eller ej.
\nTilsvarende er det altid n\u00f8dvendigt at vise database-tilg\u00e6ngelighed og andre n\u00f8glekarakteristika p\u00e5 dashboards, s\u00e5 denne information er lige ved h\u00e5nden, altid t\u00e6t p\u00e5 dig. Nogle yderligere detaljer, der allerede hj\u00e6lper ved efterforskning af h\u00e6ndelser eller katastrofesituationer, skal allerede vises p\u00e5 sekund\u00e6re dashboards eller skjules i drilldown-links, der f\u00f8rer til tredjeparts overv\u00e5gningssystemer. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Eksempel p\u00e5 et velkendt overv\u00e5gningssystem. Det er et meget imponerende overv\u00e5gningssystem. Det indsamler en masse data, men efter min mening har det en m\u00e6rkelig forst\u00e5else af dashboards. Der er et link til at 'oprette dashboard'. Men n\u00e5r du opretter et dashboard, opretter du en slags liste best\u00e5ende af to kolonner, en slags liste over grafer. Og n\u00e5r du skal se noget, begynder du at klikke med musen, scrolle, lede efter den n\u00f8dvendige graf. Og det tager tid, dvs. der findes ikke rigtige dashboards. Der er kun lister over grafer.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Hvad skal der tilf\u00f8jes til disse dashboards? Man kan starte med en egenskab som svartid. I PostgreSQL findes der en visning kaldet pg_stat_statements. Som standard er den deaktiveret, men det er en af de vigtige systemvisninger, som altid skal aktiveres og bruges. Den gemmer oplysninger om alle udf\u00f8rte foresp\u00f8rgsler, der er blevet k\u00f8rt i databasen. <\/p>\n

<\/p>\n

Derfor kan vi tage udgangspunkt i at tage den samlede tid for alle foresp\u00f8rgsler og dividere det med antallet af foresp\u00f8rgsler ved hj\u00e6lp af de f\u00f8rn\u00e6vnte felter. Men det er en gennemsnitlig temperatur p\u00e5 hospitalet. Vi kan tage udgangspunkt i andre felter \u2013 den minimale, maksimale og median tid for udf\u00f8relse af foresp\u00f8rgsler. Vi kan endda bygge percentiler; der er relevante funktioner til dette i PostgreSQL. Og vi kan f\u00e5 nogle tal, der karakteriserer svartiden p\u00e5 vores database baseret p\u00e5 allerede udf\u00f8rte foresp\u00f8rgsler, dvs. vi udf\u00f8rer ikke en falsk foresp\u00f8rgsel 'select 1' og ser p\u00e5 svartiden, men vi analyserer svartiderne for allerede udf\u00f8rte foresp\u00f8rgsler og viser enten et enkelt tal eller tegner en graf baseret p\u00e5 det. <\/p>\n

<\/p>\n

Det er ogs\u00e5 vigtigt at holde \u00f8je med antallet af fejl, der genereres af systemet i \u00f8jeblikket. Og til dette kan man bruge visningen pg_stat_database. Vi orienterer os efter feltet xact_rollback. Dette felt viser ikke kun antallet af rollback, der finder sted i databasen, men tager ogs\u00e5 h\u00f8jde for antallet af fejl. Man kan sige, at vi kan vise dette tal p\u00e5 vores dashboard og se, hvor mange fejl vi har i \u00f8jeblikket. Hvis der er mange fejl, er det en god grund til at kigge i loggene og se, hvad det er for nogle fejl, og hvorfor de opst\u00e5r, og derefter unders\u00f8ge og l\u00f8se dem.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Man kan tilf\u00f8je noget som en Tachometer. Dette er antallet af transaktioner pr. sekund og antallet af foresp\u00f8rgsler pr. sekund. Man kan sige, at man kan bruge disse tal som den aktuelle ydelse for sin database og overv\u00e5ge, om der er spidser i foresp\u00f8rgslerne, spidser i transaktionerne, eller om databasen er underbelastet, fordi en eller anden backend er faldet ud. Det er vigtigt altid at holde \u00f8je med dette tal og huske, at for vores projekt er s\u00e5dan en ydelse normal, mens v\u00e6rdier over og under allerede er problematiske og uklare, hvilket betyder, at man skal se p\u00e5, hvorfor s\u00e5danne tal opst\u00e5r.<\/p>\n

<\/p>\n

For evaluating the number of transactions, we can again refer to the pg_stat_database view. We can sum the number of commits and the number of rollbacks to get the number of transactions per second. <\/p>\n

<\/p>\n

Everyone understands that multiple requests can fit into one transaction, right? Therefore, TPS and QPS are slightly different. <\/p>\n

<\/p>\n

The number of requests per second can be obtained from pg_stat_statements by simply calculating the total of all executed requests. It\u2019s clear that we compare the current value with the previous one, subtract, obtain the delta, and get the amount.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Additional metrics can be added as desired, which also help to evaluate the availability of our database and track whether there were any downtimes. <\/p>\n

<\/p>\n

One of these metrics is uptime. However, uptime in PostgreSQL is a somewhat tricky thing. Let me explain why. When PostgreSQL starts up, it begins to count uptime. But if at some point, for example at night, a task was executed and the OOM-killer forcefully terminated the PostgreSQL child process, in this case PostgreSQL will disconnect all clients, reset the shared memory area, and begin recovery from the last checkpoint. While this recovery from the checkpoint is ongoing, the database does not accept connections, i.e., this situation can be assessed as downtime. However, the uptime counter will not reset because it tracks the time since the postmaster was first started. Therefore, such situations may be overlooked.<\/p>\n

<\/p>\n

It is also important to monitor the number of vacuum workers. Does everyone know what autovacuum is in PostgreSQL? It is an interesting subsystem in PostgreSQL. Many articles have been written about it, numerous talks have been made. There has been much discussion about vacuum and how it should work. Many consider it an unavoidable evil, and rightly so. It's somewhat akin to a garbage collector that cleans up outdated versions of rows that are needed by none of the transactions and frees up space in tables and indexes for new rows. <\/p>\n

<\/p>\n

Why is it necessary to monitor it? Because vacuum can sometimes cause significant issues. It consumes a large amount of resources, and client requests start to suffer from it. <\/p>\n

<\/p>\n

Og man b\u00f8r overv\u00e5ge det via visningen pg_stat_activity, som jeg vil tale om i n\u00e6ste afsnit. Denne visning viser den aktuelle aktivitet i databasen. Gennem denne aktivitet kan vi spore antallet af vacuum-processer, der arbejder lige nu. Vi kan overv\u00e5ge vacuumene og se, at hvis vi overskrider gr\u00e6nsen, er det en grund til at kigge i PostgreSQL's indstillinger og optimere vacuum-arbejdet. <\/p>\n

<\/p>\n

En anden funktion ved PostgreSQL er, at det virkelig lider under lange transaktioner. Is\u00e6r under transaktioner, der h\u00e6nger og ikke laver noget. Disse kaldes stat idle-in-transaction. En s\u00e5dan transaktion holder l\u00e5se, hvilket forhindrer vacuumet i at arbejde. Som f\u00f8lge heraf svulmer tabellerne op, de \u00f8ges i st\u00f8rrelse. Og foresp\u00f8rgsler, der arbejder med disse tabeller, begynder at k\u00f8re langsommere, fordi de skal l\u00e6se alle de gamle versioner af r\u00e6kker fra hukommelsen til disken og tilbage.<\/strong> Derfor er det ogs\u00e5 vigtigt at overv\u00e5ge tiden, l\u00e6ngden af de l\u00e6ngste transaktioner og de l\u00e6ngste vacuum-foresp\u00f8rgsler. Og hvis vi ser nogen processer, der har k\u00f8rt meget l\u00e6nge, mere end 10-20-30 minutter for OLTP-belastning, s\u00e5 b\u00f8r vi allerede v\u00e6re opm\u00e6rksomme p\u00e5 dem og afslutte dem tvingende, eller optimere applikationen, s\u00e5 de ikke kaldes og h\u00e6nger s\u00e5 l\u00e6nge.<\/strong> For analytisk belastning er 10-20-30 minutter normalt, der kan endda v\u00e6re endnu l\u00e6ngere. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nDern\u00e6st har vi muligheden med tilsluttede klienter. N\u00e5r vi har oprettet et dashboard og vist vigtige tilg\u00e6ngelighedsmetrikker, kan vi ogs\u00e5 tilf\u00f8je yderligere information om de tilsluttede klienter. <\/p>\n

<\/p>\n

Information om tilsluttede klienter er vigtig, fordi, set fra PostgreSQL's synspunkt, kan klienter v\u00e6re forskellige. Der er gode klienter, og der er d\u00e5rlige klienter. <\/p>\n

<\/p>\n

Et simpelt eksempel. Med kunden forst\u00e5r jeg en applikation. Applikationen har forbindelse til databasen og begynder straks at sende sine foresp\u00f8rgsler, databasen behandler dem og udf\u00f8rer dem, resultaterne returneres til klienten. Det er gode og korrekte klienter. <\/p>\n

<\/p>\n

Der er situationer, hvor klienten opretter forbindelse, holder forbindelsen, men samtidig ikke laver noget. Den er i en tilstand af idle. <\/p>\n

<\/p>\n

Men findes ogs\u00e5 d\u00e5rlige kunder. For eksempel har en kunde m\u00e5ske tilsluttet sig, \u00e5bnet en transaktion, lavet noget i databasen og derefter g\u00e5et ind i koden for at henvise til en ekstern kilde eller for at bearbejde de data, han har modtaget. Alligevel har han ikke lukket transaktionen. S\u00e5 transaktionen h\u00e6nger i databasen og blokerer en r\u00e6kke. Dette er en d\u00e5rlig tilstand. Hvis applikationen pludselig fejler et sted inde i sig (Exception), kan transaktionen forblive \u00e5ben i lang tid. Dette p\u00e5virker direkte PostgreSQL's ydeevne. PostgreSQL vil arbejde langsommere. Derfor er det vigtigt at overv\u00e5ge s\u00e5danne kunder rettidigt og afslutte deres arbejde tvangsm\u00e6ssigt. Man skal ogs\u00e5 optimere sin applikation for at undg\u00e5 s\u00e5danne situationer. <\/p>\n

<\/p>\n

Andre d\u00e5rlige kunder er ventende kunder. De bliver d\u00e5rlige p\u00e5 grund af omst\u00e6ndigheder. For eksempel kan en simpel ventende transaktion \u00e5bne en transaktion, tage l\u00e5se p\u00e5 nogle r\u00e6kker, og hvis den p\u00e5 et tidspunkt fejler i koden, forbliver der en h\u00e6ngende transaktion. En anden kunde ankommer, anmoder om de samme data, men han st\u00f8der p\u00e5 en blokering, fordi den h\u00e6ngende transaktion allerede holder l\u00e5se p\u00e5 nogle n\u00f8dvendige r\u00e6kker. Den anden transaktion vil s\u00e5 h\u00e6nge i venten p\u00e5, at den f\u00f8rste transaktion afsluttes eller p\u00e5 at dens administrator tvangsm\u00e6ssigt lukker den. P\u00e5 den m\u00e5de kan ventende transaktioner hobe sig op og overskride databasen tilslutningsgr\u00e6nse. N\u00e5r gr\u00e6nsen overskrides, kan applikationen ikke l\u00e6ngere arbejde med databasen. Dette er en n\u00f8dsituation for projektet. Derfor er det vigtigt at overv\u00e5ge d\u00e5rlige kunder og reagere i tide. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Et andet eksempel p\u00e5 overv\u00e5gning. Her er allerede et ordentligt dashboard. Der er information om forbindelserne \u00f8verst. DB connection \u2013 8 stykker. Og det er alt. Vi har ikke information om, hvilke kunder der er aktive, og hvilke der bare er idle og ikke laver noget. Der er ingen information om h\u00e6ngende transaktioner eller ventende forbindelser, alts\u00e5 er det bare et tal, der viser antallet af forbindelser og intet andet. Og s\u00e5 m\u00e5 man g\u00e6tte selv.
\n\"Grundl\u00e6ggende
\nFor at tilf\u00f8je denne information til overv\u00e5gning, skal man henvise til systemvisningen pg_stat_activity. Hvis du tilbringer meget tid i PostgreSQL, er dette en fremragende visning, der b\u00f8r blive din ven, da den viser den aktuelle aktivitet i PostgreSQL, dvs. hvad der sker i det. Hver proces har en separat linje, der viser information om denne proces: fra hvilken v\u00e6rt forbindelsen er etableret, under hvilken bruger, med hvilket navn, hvorn\u00e5r transaktionen blev startet, hvilken foresp\u00f8rgsel der udf\u00f8res nu, og hvilken foresp\u00f8rgsel der blev udf\u00f8rt sidst. Og i overensstemmelse hermed kan vi vurdere klientens tilstand ud fra feltet stat. Man kan sige, at vi kan gruppere efter dette felt og f\u00e5 de nuv\u00e6rende stats, der findes i databasen, samt antallet af forbindelser, der har denne stat i databasen. Og de opn\u00e5ede tal kan vi sende til vores overv\u00e5gning og tegne grafer baseret p\u00e5 dem.
\nDet er ogs\u00e5 vigtigt at vurdere varigheden af transaktionen. Jeg har allerede n\u00e6vnt, at det er vigtigt at vurdere varigheden af vacuum-processerne, men transaktionerne skal vurderes p\u00e5 samme m\u00e5de. Der er felterne xact_start og query_start. De viser, n\u00e5r transaktionen og foresp\u00f8rgslen startede. Vi anvender funktionen now(), som viser det nuv\u00e6rende tidsstempel, og tr\u00e6kker tidsstemplet for transaktionen og foresp\u00f8rgslen fra. Og vi f\u00e5r varigheden af transaktionen, varigheden af foresp\u00f8rgslen. <\/p>\n

<\/p>\n

Hvis vi ser lange transaktioner, b\u00f8r vi afslutte dem. For OLTP-belastning er lange transaktioner mere end 1-2-3 minutter<\/strong>. For OLAP-belastning er lange transaktioner normale, men hvis de varer mere end to timer, er det ogs\u00e5 et tegn p\u00e5, at vi har en ubalance et sted.<\/strong> <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nN\u00e5r kunderne har oprettet forbindelse til databasen, begynder de at arbejde med vores data. De henvender sig til tabeller, de henvender sig til indekser for at hente data fra tabellen. Og det er vigtigt at vurdere, hvordan kunderne arbejder med disse data.<\/p>\n

<\/p>\n

Dette er n\u00f8dvendigt for at vurdere vores arbejdsbelastning og f\u00e5 en id\u00e9 om, hvilke tabeller der er de mest \"aktive\". Dette er vigtigt i situationer, hvor vi \u00f8nsker at placere de \"aktive\" tabeller p\u00e5 hurtig SSD-lagring. For eksempel kan vi flytte nogle arkivtabeller, som vi ikke l\u00e6ngere bruger, til en \"kold\" arkivplads p\u00e5 SATA-diske, hvor de kan v\u00e6re, og tilgangen til dem vil ske efter behov. <\/p>\n

<\/p>\n

Det er ogs\u00e5 nyttigt til at opdage anomalier efter forskellige udgivelser og deployment. Antag, at et projekt har lanceret en ny funktion. For eksempel er der blevet tilf\u00f8jet ny funktionalitet til arbejdet med databasen. Hvis vi opbygger grafer over brugen af tabellerne, vil vi let kunne opdage disse anomalier p\u00e5 graferne. For eksempel kan vi se spidser i opdateringer eller sletninger. Det vil v\u00e6re meget tydeligt.<\/p>\n

<\/p>\n

Vi kan ogs\u00e5 opdage anomalier i \"forstyrret\" statistik. Hvad betyder det? PostgreSQL har en st\u00e6rk og meget god foresp\u00f8rgselsplanl\u00e6gger. Og udviklerne bruger mange ressourcer p\u00e5 at forbedre den. Hvordan fungerer den? For at kunne opbygge gode planer indsamler PostgreSQL statistik om datafordelingen i tabellerne med et vist tidsinterval og regelm\u00e6ssighed. Det er de mest hyppige v\u00e6rdier: antal unikke v\u00e6rdier, information om NULL i tabellen, en masse information. <\/p>\n

<\/p>\n

Baseret p\u00e5 denne statistik opbygger planl\u00e6ggeren flere foresp\u00f8rgsler, v\u00e6lger den mest optimale og bruger denne foresp\u00f8rgselsplan til at udf\u00f8re selve foresp\u00f8rgslen og returnere dataene. <\/p>\n

<\/p>\n

Nogle gange kan statistikken v\u00e6re \"forstyrret\". Kvaliteten og m\u00e6ngden af data kan have \u00e6ndret sig i tabellen, men statistikken er ikke blevet indsamlet. Og de dannede planer kan vise sig at v\u00e6re suboptimale. Hvis vi har suboptimale planer i henhold til den indsamlede overv\u00e5gning af tabellerne, kan vi se denne anomalier. For eksempel kan dataene have \u00e6ndret kvalitet, og i stedet for at bruge indekset er der blevet anvendt en sekventiel gennemgang af tabellen. Det vil sige, hvis foresp\u00f8rgslen kun skal tilbagef\u00f8re 100 r\u00e6kker (med begr\u00e6nsning limit 100), s\u00e5 vil der blive foretaget en fuld gennemgang for denne foresp\u00f8rgsel. Og det p\u00e5virker altid ydeevnen negativt. <\/p>\n

<\/p>\n

Og vi kan se dette i overv\u00e5gningen. Og allerede se denne foresp\u00f8rgsel, udf\u00f8re en explain for den, samle statistik, bygge et nyt ekstra indeks. Og allerede reagere p\u00e5 dette problem. Derfor er det vigtigt. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Et andet eksempel p\u00e5 overv\u00e5gning. Jeg tror, mange kender det, fordi det er meget popul\u00e6rt. Hvem bruger det i deres projekter. 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. Men der er \u00e9n d\u00e5rlig detalje. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Der er flere grafer. Og som en enhed er der angivet bytes, dvs. der er 5 grafer. Det er Insert data, Update data, Delete data, Fetch data og Return data. Som enhed for m\u00e5ling er der angivet bytes. Men det er s\u00e5dan, at statistikken i PostgreSQL returnerer data i tuples (r\u00e6kker). Og derfor er disse grafer en meget god m\u00e5de at undervurdere din arbejdsbelastning flere gange, ti gange, fordi en tuple ikke er en byte, en tuple er en r\u00e6kke, det er mange bytes, og den har altid variabel l\u00e6ngde. Det vil sige, at det at beregne arbejdsbelastningen i bytes ved hj\u00e6lp af tuples er en umulig opgave eller meget vanskelig. Derfor, n\u00e5r du bruger dashboardet eller indbygget overv\u00e5gning, er det altid vigtigt at forst\u00e5, at det fungerer korrekt og returnerer dig korrekt vurderede data. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Hvordan f\u00e5r man statistik for disse tabeller? Til dette har PostgreSQL et vist antal visninger. Og den prim\u00e6re visning er pg_stat_user_tables<\/a><\/noindex>. User_tables betyder, at tabellerne er oprettet p\u00e5 brugerens vegne. I mods\u00e6tning til dette er der systemvisninger, som bruges af PostgreSQL selv. Og der er en opsummeringstabel kaldet Alltables, som inkluderer b\u00e5de system- og brugertabeller. Du kan basere dig p\u00e5 hvilken som helst af dem, som du bedst kan lide.<\/p>\n

<\/p>\n

Efter de angivne felter kan man vurdere antallet af insert, update og delete. Det eksempel dashboard, jeg brugte, bruger netop disse felter til at vurdere egenskaberne ved arbejdsbelastningen. Derfor kan vi ogs\u00e5 basere os p\u00e5 dem. Men det er v\u00e6rd at huske, at det er tuples og ikke bytes, s\u00e5 vi kan ikke bare tage og g\u00f8re det til bytes.<\/p>\n

<\/p>\n

Baseret p\u00e5 disse data kan vi konstruere s\u00e5kaldte TopN-tabeller. For eksempel, Top-5, Top-10. Og man kan spore de 'varme' tabeller, der anvendes mere end andre. For eksempel de 5 'varme' tabeller p\u00e5 inds\u00e6ttelse. Og ud fra disse TopN-tabeller vurderer vi vores arbejdsbelastning og kan vurdere udsving i arbejdsbelastningen efter forskellige udgivelser, opdateringer og implementeringer. <\/p>\n

<\/p>\n

Det er ogs\u00e5 vigtigt at vurdere st\u00f8rrelsen p\u00e5 tabellen, da udviklere nogle gange ruller en ny funktion ud, og vores tabeller begynder at vokse i st\u00f8rrelse, fordi de beslutter at tilf\u00f8je yderligere data, men ikke har forudset, hvordan det vil p\u00e5virke st\u00f8rrelsen p\u00e5 databasen. S\u00e5danne tilf\u00e6lde er ogs\u00e5 overraskelser for os. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Og nu et lille sp\u00f8rgsm\u00e5l til dig. Hvilket sp\u00f8rgsm\u00e5l opst\u00e5r, n\u00e5r du bem\u00e6rker belastning p\u00e5 databaserver? Hvilket n\u00e6ste sp\u00f8rgsm\u00e5l t\u00e6nker du straks? <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Men i virkeligheden opst\u00e5r det n\u00e6ste sp\u00f8rgsm\u00e5l. Hvilke foresp\u00f8rgsler for\u00e5rsager belastningen? Alts\u00e5, det er ikke interessant at se p\u00e5 processerne, som for\u00e5rsager belastningen. Det er klart, at hvis der er en host med en database, s\u00e5 k\u00f8rer databasen der, og det er klart, at det kun er databasen, der vil blive udnyttet. Hvis vi \u00e5bner Top, vil vi se en liste over processer i PostgreSQL, som laver et eller andet. Fra Top vil det ikke v\u00e6re klart, hvad de laver. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Derfor er det n\u00f8dvendigt at opdage de foresp\u00f8rgsler, der for\u00e5rsager den h\u00f8jeste belastning, fordi tuning af foresp\u00f8rgsler som regel giver mere gevinst end tuning af PostgreSQL-konfigurationen eller operativsystemet, eller endda tuning af hardwaren. Efter min vurdering er det cirka 80-85-90 %. Og det kan g\u00f8res meget hurtigere. Det er hurtigere at rette en foresp\u00f8rgsel end at \u00e6ndre konfigurationen, planl\u00e6gge en genstart, is\u00e6r hvis databasen ikke kan genstartes, eller tilf\u00f8je hardware. Det er nemmere at omskrive en foresp\u00f8rgsel et sted eller tilf\u00f8je et indeks for at f\u00e5 et bedre resultat fra denne foresp\u00f8rgsel. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nDerfor er det n\u00f8dvendigt at overv\u00e5ge foresp\u00f8rgslerne og deres ad\u00e6kvathed. Lad os tage et andet eksempel p\u00e5 overv\u00e5gning. Og her ser overv\u00e5gningen ogs\u00e5 fremragende ud. Der er information om replikation, der er information om b\u00e5ndbredde, l\u00e5sning, ressourceudnyttelse. Alt ser perfekt ud, men der er ingen information om foresp\u00f8rgsler. Det er uklart, hvilke foresp\u00f8rgsler der udf\u00f8res i vores database, hvor l\u00e6nge de udf\u00f8res, og hvor mange af disse foresp\u00f8rgsler er der. Vi skal altid have denne information i overv\u00e5gningen. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Og for at f\u00e5 disse oplysninger kan vi bruge modulet pg_stat_statements. Baseret p\u00e5 det kan vi opbygge forskellige typer diagrammer. For eksempel kan vi f\u00e5 information om de mest hyppige foresp\u00f8rgsler, det vil sige dem, der udf\u00f8res oftest. Ja, efter deployment er det ogs\u00e5 meget nyttigt at se p\u00e5 det og forst\u00e5, om der er nogen pludselige stigninger i foresp\u00f8rgslerne. <\/p>\n

<\/p>\n

Vi kan overv\u00e5ge de l\u00e6ngste foresp\u00f8rgsler, det vil sige de foresp\u00f8rgsler, der tager l\u00e6ngst tid at udf\u00f8re. De belaster CPU'en og forbruger I\/O. Vi kan ogs\u00e5 vurdere dette ud fra felterne total_time, mean_time, blk_write_time og blk_read_time. <\/p>\n

<\/p>\n

Vi kan vurdere og overv\u00e5ge de mest ressourcekr\u00e6vende foresp\u00f8rgsler, dem der l\u00e6ser fra disken, som arbejder med hukommelsen, eller omvendt, som skaber en skrivebelastning.<\/p>\n

<\/p>\n

Vi kan vurdere de mest gener\u00f8se foresp\u00f8rgsler. Det er de foresp\u00f8rgsler, der returnerer et stort antal r\u00e6kker. For eksempel kan det v\u00e6re en foresp\u00f8rgsel, hvor der er glemt at s\u00e6tte en gr\u00e6nse. Og den returnerer simpelthen alt indholdet i tabellen eller foresp\u00f8rgslen for de anmodede tabeller.<\/p>\n

<\/p>\n

Og vi kan ogs\u00e5 overv\u00e5ge foresp\u00f8rgsler, der bruger midlertidige filer eller midlertidige tabeller. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende
\nOg vi har baggrundsprocesser. Baggrundsprocesser er prim\u00e6rt tjekpunkter, eller hvad de ogs\u00e5 kaldes, kontrolpunkter, autovacuum og replikation. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Et andet eksempel p\u00e5 overv\u00e5gning. Der er en fane til venstre kaldet Maintenance, vi g\u00e5r ind p\u00e5 den og h\u00e5ber at se noget nyttigt. Men her er der kun information om tiden for vakuum og statistikindsamling, ikke mere. Det er meget fattige oplysninger, s\u00e5 vi skal altid have information om, hvordan baggrundsprocesserne fungerer i vores database, og om der er problemer som f\u00f8lge af deres arbejde. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

N\u00e5r vi betragter kontrolpunkter, skal vi huske, at kontrolpunkter rydder \u00absnuskede\u00bb sider fra det shardede hukommelsesomr\u00e5de til disken og derefter opretter et kontrolpunkt. Dette kontrolpunkt kan derefter bruges som et sted ved genopretning, hvis PostgreSQL skulle afsluttes pludseligt. <\/p>\n

<\/p>\n

For this reason, to flush all 'dirty' pages to disk, a certain amount of writing needs to be done. Typically, on systems with large memory, this is substantial. If we have checkpoints occurring very frequently within a short interval, disk performance can significantly decline. Client requests will suffer from a lack of resources. They will compete for resources and will find the performance inadequate. <\/p>\n

<\/p>\n

Accordingly, through pg_stat_bgwriter and the specified fields, we can monitor the number of occurring checkpoints. If we have a lot of checkpoints within a certain time frame (10-15-20 minutes, half an hour), say 3-4-5, it may indicate a problem. We need to examine the database and check the configuration to identify what is causing this abundance of checkpoints. There might be some large write operations. Based on the workload, we can assess since the workload graphs have already been added. We can fine-tune the checkpoint parameters so that they do not significantly impact query performance.<\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

I am returning to autovacuum because it is something, as I've mentioned, that can easily hinder the performance of both disks and queries, so it's always important to evaluate the number of autovacuum tasks. <\/p>\n

<\/p>\n

The number of autovacuum workers in the database is limited. By default, there are three, so if we consistently have three workers running in the database, it means that autovacuum is underconfigured. Limits need to be raised, and autovacuum settings should be reviewed to delve into the configuration.
\nIt is important to evaluate which autovacuum workers are running. It may be one initiated by a user, where a DBA manually started a vacuum task, creating a load. We may encounter certain issues that arise from this. Alternatively, it could be the number of vacuums that are incrementing the transaction counter. For some versions of PostgreSQL, these can be very intensive vacuums. They can easily hinder performance since they read the entire table completely, scanning all blocks in the table. <\/p>\n

<\/p>\n

Og selvf\u00f8lgelig varigheden af vakuumerne. Hvis vi har lange vakuumer, der arbejder i meget lang tid, betyder det, at vi igen skal overveje konfigurationen af vakuummet og muligvis revidere dets indstillinger. For der kan opst\u00e5 en situation, hvor vakuummet arbejder over en tabel i lang tid (3-4 timer), men i l\u00f8bet af vakuumets arbejde har der igen samlet sig et stort antal d\u00f8de r\u00e6kker i tabellen. Og s\u00e5 snart vakuummet er f\u00e6rdigt, skal det igen vakuumere denne tabel. Og vi ender i en situation med et uendeligt vakuum. I s\u00e5danne tilf\u00e6lde klarer vakuummet ikke sit arbejde, og tabellerne begynder gradvist at svulme i st\u00f8rrelse, selvom m\u00e6ngden af nyttige data i dem forbliver den samme. Derfor ser vi altid p\u00e5 konfigurationen ved lange vakuumer og fors\u00f8ger at optimere den, men uden at det g\u00e5r ud over ydeevnen for kundernes foresp\u00f8rgsler. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Der er nu n\u00e6sten ikke nogen installation af PostgreSQL, hvor der ikke er stream replication. Replication er processen med at overf\u00f8re data fra master til replika.<\/p>\n

<\/p>\n

Replication i PostgreSQL fungerer via transaktionsloggen. Master genererer transaktionsloggen. Transaktionsloggen sendes via netv\u00e6rksforbindelsen til replikaen, og derefter bliver den reproduceret p\u00e5 replikaen. Det er meget simpelt. <\/p>\n

<\/p>\n

Til overv\u00e5gning af replikaionslag anvendes visningen pg_stat_replication. Men det er ikke s\u00e5 enkelt. I version 10 har visningen gennemg\u00e5et flere \u00e6ndringer. For det f\u00f8rste er nogle felter blevet omd\u00f8bt. Og nogle felter er blevet tilf\u00f8jet. I version 10 er der tilf\u00f8jet felter, der g\u00f8r det muligt at vurdere replikaionslaget i sekunder. Det er meget praktisk. Inden version 10 var det muligt at vurdere replikaionslaget i bytes. Denne mulighed er ogs\u00e5 bevaret i version 10, dvs. du kan v\u00e6lge, hvad der er mere praktisk for dig - at vurdere laget i bytes eller vurdere laget i sekunder. Mange g\u00f8r begge dele.<\/p>\n

<\/p>\n

Men for at kunne vurdere replikaionslaget skal man kende journalens position i transaktionen. Og disse journalpositioner findes netop i visningen pg_stat_replication. Groft sagt kan vi ved hj\u00e6lp af funktionen pg_xlog_location_diff() tage to punkter i transaktionsloggen. Beregn forskellen mellem dem og f\u00e5 replikaionslaget i bytes. Det er meget praktisk og enkelt. <\/p>\n

<\/p>\n

I den tiende version blev denne funktion omd\u00f8bt til pg_wal_lsn_diff(). Generelt blev alle funktioner, udsigtsposter og v\u00e6rkt\u00f8jer, der indeholdt ordet 'xlog', \u00e6ndret til 'wal'. Dette g\u00e6lder b\u00e5de for udsigtsposter og funktioner. Det er s\u00e5dan en nyhed. <\/p>\n

<\/p>\n

Derudover blev der i den tiende version tilf\u00f8jet linjer, som specifikt viser lag. Det er write lag, flush lag, replay lag. Det vil sige, at disse faktorer er vigtige at overv\u00e5ge. Hvis vi ser, at der er lag i replikationen, skal vi unders\u00f8ge, hvorfor det opstod, hvor det kom fra, og l\u00f8se problemet. <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Med de systemm\u00e6ssige m\u00e5linger er n\u00e6sten alt i orden. N\u00e5r der oprettes en hvilken som helst overv\u00e5gning, starter den med systemm\u00e6ssige m\u00e5linger. Dette d\u00e6kker CPU-udnyttelse, hukommelse, swap, netv\u00e6rk og disk. Men der er mange parametre, der ikke er inkluderet som standard. <\/p>\n

<\/p>\n

Hvis CPU-udnyttelsen er i orden, er der problemer med diskudnyttelsen. Som regel tilf\u00f8jer udviklere overv\u00e5gningsv\u00e6rkt\u00f8jer oplysninger om b\u00e5ndbredde. Det kan v\u00e6re i iops eller bytes. Men de glemmer latency og udnyttelse af diskene. Disse er vigtigere parametre, som g\u00f8r det muligt at vurdere, hvor belastede vores diske er, og hvor meget de bremser. Hvis vi har h\u00f8j latency, betyder det, at der er problemer med diskene. Hvis vi har h\u00f8j udnyttelse, betyder det, at diskene ikke kan klare opgaven.<\/strong> Dette er mere kvalitetsegnede karakteristika end b\u00e5ndbredde.<\/p>\n

<\/p>\n

Selvom denne statistik ogs\u00e5 kan opn\u00e5s fra filsystemet \/proc, som det g\u00f8res for CPU-udnyttelse. Jeg ved ikke, hvorfor de ikke inkluderer disse oplysninger i overv\u00e5gninger. Men det er da vigtigt at have dette i sin overv\u00e5gning.<\/strong> <\/p>\n

<\/p>\n

Det samme g\u00e6lder netv\u00e6rksinterfaces. Der er oplysninger om netv\u00e6rksb\u00e5ndbredde i pakker, i bytes, men alligevel er der ingen information om latency og ingen information om udnyttelse, selvom det ogs\u00e5 er nyttig information.<\/strong> <\/p>\n

<\/p>\n

\"Grundl\u00e6ggende<\/p>\n

<\/p>\n

Enhver overv\u00e5gning har mangler. Uanset hvilken overv\u00e5gning du v\u00e6lger, vil den altid ikke opfylde visse kriterier. Men alligevel udvikler de sig, nye funktioner og nye ting tilf\u00f8jes, s\u00e5 v\u00e6lg noget og finpuds det. <\/p>\n

<\/p>\n

Og for at kunne finpudse skal man altid have et klart billede af, hvad den leverede statistik betyder og hvordan man kan bruge den til at l\u00f8se problemer. <\/p>\n

<\/p>\n

Og nogle n\u00f8glepunkter:<\/p>\n

<\/p>\n