Lad mig diskutere et emne, der ikke i sagens natur er PostgreSQL-specifikt, men som jeg jævnligt støder på, mens jeg undersøger problemer på kundesystemer, vurderer "understøttelse" af disse systemer osv. Det er vigtigheden af at have en overvågningsløsning til systemmålinger og konfigurere den rimeligt , og hvorfor sar er stadig mit yndlingsværktøj (i hvert fald på Linux).
Om vigtigheden af overvågning
For det første er overvågning af grundlæggende systemmetrikker (CPU, I/O, hukommelse) ekstremt vigtig. Det er lidt mærkeligt at skulle påpege dette i diskussioner med andre ingeniører, men jeg vil sige, at 1 ud af 10 ingeniører mener, at de egentlig ikke har brug for overvågning. Begrundelsen går normalt i denne retning:
Det er sandt, at overvågning tilføjer overhead, ingen tvivl om det. Men det er sandsynligvis ubetydeligt i forhold til, hvad applikationen gør. Faktisk sar tilføjer ikke rigtig noget ekstra instrumentering, det er blot at læse tællere fra nerven, beregne deltaer og skrive det til disk. Det kan have brug for lidt diskplads og I/O (afhængigt af antallet af CPU'er og diske), men det er det hele.
For eksempel vil indsamling af statistik pr. sekund på en maskine med 32 kerner og flere diske producere ~5GB rådata om dagen, men den komprimerer ekstremt godt, ofte til ~5-10%). Og det er næsten ikke synligt i top . Opløsning pr. sekund er lidt ekstrem, og brug af 5 eller 10 sekunder vil reducere overhead yderligere.
Så nej, det viser sig, at overhead faktisk ikke er en gyldig grund til ikke at aktivere overvågning.
Omkostninger vs. fordele
Endnu vigtigere, "Hvor meget overhead eliminerer jeg ved ikke at aktivere overvågning?" er det forkerte spørgsmål at stille. I stedet bør du spørge "Hvilke fordele får jeg af overvågningen? Opvejer fordelene omkostningerne?”
Vi ved allerede, at omkostningerne (overhead) er ret små eller helt ubetydelige. Hvad er fordelene? Efter min erfaring er det uvurderligt at have overvågningsdata.
For det første giver det dig mulighed for at undersøge problemer - at se på en masse diagrammer og lede efter pludselige ændringer er overraskende effektivt og fører dig ofte direkte til det rigtige problem. På samme måde er det meget nyttigt at sammenligne de aktuelle data (indsamlet under problemet) med en baseline (indsamlet, når alt er i orden) og umuligt, hvis du kun aktiverer overvågning, når tingene går i stykker.
For det andet giver det dig mulighed for at evaluere trends og identificere potentielle problemer, før de rent faktisk rammer dig. Hvor meget CPU bruger du? Vokser CPU-forbruget over tid? Er der nogle mistænkelige mønstre i hukommelsesbrug? Du kan kun besvare disse spørgsmål, hvis du har overvågningen på plads.
Hvorfor sar er mit yndlingsværktøj
Lad os antage, at jeg har overbevist dig om, at overvågning er vigtig, og at du bestemt bør gøre det. Men hvorfor er sar vores yndlingsværktøj, når der er forskellige smarte alternativer, både on-premise og cloud-baserede?
- Det er inkluderet i alle distributioner, og det er trivielt at installere/opsætte. Dette gør det ret nemt at overbevise folk om at aktivere det.
- Det er lige på maskinen. Så hvis du SSH til maskinen, kan du også få overvågningsdataene.
- Den bruger simpelt tekstoutput. Trivielt behandle dataene - importer dem til en database, analyser, vedhæft dem til en supportbillet. Det er ret svært med andre værktøjer, der generelt ikke tillader dig at eksportere data nemt, kun viser diagrammer og/eller i væsentlig grad begrænser, hvilken analyse du kan udføre osv.
Jeg indrømmer, at noget af dette kommer fra det faktum, at jeg arbejder for en virksomhed, der leverer PostgreSQL-tjenester til andre virksomheder (det være sig 24×7 support eller Remote DBA. Så vi får normalt kun en meget begrænset adgang til kundesystemer (for det meste kun databaseservere) og intet mere). Det betyder at have alle de vigtige data på selve databaseserveren, tilgængelige via almindelig SSH, er ekstremt praktisk og eliminerer unødvendige rundrejser kun for at anmode om endnu et stykke data fra et andet system. Hvilket sparer både tid og fornuft på begge sider.
Hvis du har mange systemer at administrere, vil du sandsynligvis foretrække en overvågningsløsning, der indsamler data fra mange maskiner til et enkelt sted. Men for mig, sar stadig vinder.
Så hvordan konfigureres det?
Jeg nævnte at installere og aktivere sar (eller rettere sysstat , som er pakken inklusive sar ) er meget enkel. Desværre er standardkonfigurationen noget dårlig. Efter installation af sysstat , finder du noget lignende i /etc/cron.d/sysstat (eller hvor som helst din distribution gemmer cron konfiguration):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Dette siger effektivt sa1 kommandoen vil blive udført hvert 10. minut, og den vil indsamle en enkelt prøve over 1 sekund. Der er to problemer her. For det første er 10 minutter ret lav opløsning. For det andet dækker prøven kun 1 sekund ud af 600, så de resterende 9:59 er ikke rigtig inkluderet i den. Dette er noget OK for langsigtet trending, hvor tilfældig stikprøveudtagning i lav opløsning er tilstrækkelig. Til andre formål skal du sandsynligvis gøre sådan noget i stedet for:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Som samler en prøve i minuttet, og hver prøve dækker et minut. -S XALL betyder, at al statistik skal indsamles, inklusive afbrydelser, individuelle blokenheder og partitioner osv. Se man sadc for flere detaljer.
Oversigt
Så for at opsummere dette indlæg i et par enkle punkter:
- Du bør have overvågning, selvom du tror, du ikke har brug for det. Når du støder på problemer, er det for sent.
- Omkostningerne ved overvågning er sandsynligvis ubetydelige, men bestemt meget lavere end fordelene ved at have overvågningsdataene.
sarer praktisk og meget effektiv. Måske vil du bruge noget andet i fremtiden, men det er et godt første skridt.- Standardkonfigurationen er ikke særlig god (lav opløsning, 1 sekunds prøver). Overvej at øge opløsningen.
En ting, jeg ikke har nævnt, er den sar beskæftiger sig kun med systemmålinger - CPU, diske, hukommelse, processer, ikke med PostgreSQL-statistikker. Du bør selvfølgelig også overvåge den del af stakken.