Ter verdediging van sar (en hoe het te configureren)

Laat me een onderwerp bespreken dat niet inherent PostgreSQL-specifiek is, maar dat ik regelmatig tegenkom bij het onderzoeken van problemen met klantsystemen, het evalueren van de "supportability" van die systemen, enz. Het is het belang van het hebben van een monitoringoplossing voor systeemstatistieken, het redelijk configureren ervan , en waarom sar is nog steeds verreweg mijn favoriete tool (tenminste op Linux).

Over het belang van monitoring

Ten eerste is het bewaken van de basissysteemstatistieken (CPU, I/O, geheugen) uiterst belangrijk. Het is een beetje vreemd om dit in discussies met andere ingenieurs te vermelden, maar ik zou zeggen dat 1 op de 10 ingenieurs denkt dat ze niet echt toezicht nodig hebben. De redenering gaat meestal als volgt:

Het is waar dat monitoring overhead toevoegt, daar bestaat geen twijfel over. Maar het is waarschijnlijk te verwaarlozen in vergelijking met wat de applicatie doet. Eigenlijk, sar voegt niet echt extra instrumentatie toe, het leest alleen tellers uit de nernel, berekent delta's en schrijft dat naar schijf. Het heeft misschien wat schijfruimte en I/O nodig (afhankelijk van het aantal CPU's en schijven), maar dat is het dan ook.

Het verzamelen van statistieken per seconde op een machine met 32 cores en meerdere schijven zal bijvoorbeeld ongeveer 5 GB aan onbewerkte gegevens per dag produceren, maar het comprimeert buitengewoon goed, vaak tot ~5-10%). En het is nauwelijks zichtbaar in top . De resolutie per seconde is een beetje extreem, en het gebruik van 5 of 10 seconden zal de overhead verder verminderen.

Dus nee, het blijkt dat de overhead geen geldige reden is om monitoring niet in te schakelen.

Kosten versus voordelen

Maar nog belangrijker:"Hoeveel overhead elimineer ik door monitoring niet in te schakelen?" is de verkeerde vraag om te stellen. In plaats daarvan zou u zich moeten afvragen:"Welke voordelen haal ik uit de monitoring? Wegen de voordelen op tegen de kosten?”

We weten al dat de kosten (overhead) vrij klein of geheel verwaarloosbaar zijn. Wat zijn de voordelen? In mijn ervaring is het hebben van monitoringgegevens van onschatbare waarde.

Ten eerste stelt het je in staat om problemen te onderzoeken - kijken naar een heleboel grafieken en zoeken naar plotselinge veranderingen is verrassend effectief en leidt je vaak direct naar het juiste probleem. Evenzo is het vergelijken van de huidige gegevens (verzameld tijdens de uitgifte) met een baseline (verzameld wanneer alles in orde is) erg handig en onmogelijk als u alleen monitoring inschakelt wanneer dingen stuk gaan.

Ten tweede kunt u hiermee trends evalueren en potentiële problemen identificeren voordat ze u daadwerkelijk treffen. Hoeveel CPU gebruik je? Groeit het CPU-gebruik in de loop van de tijd? Zijn er verdachte patronen in het geheugengebruik? U kunt die vragen alleen beantwoorden als u over de monitoring beschikt.

Waarom `sar` is mijn favoriete tool

Laten we aannemen dat ik ervan overtuigd ben dat monitoring belangrijk is en dat je het zeker moet doen. Maar waarom is sar onze favoriete tool, als er verschillende mooie alternatieven zijn, zowel op locatie als in de cloud?

Het is inbegrepen in alle distributies, en is triviaal om te installeren/configureren. Dit maakt het vrij eenvoudig om mensen te overtuigen om het in te schakelen.
Het zit precies op de machine. Dus als u SSH naar de machine stuurt, kunt u ook de bewakingsgegevens krijgen.
Het gebruikt eenvoudige tekstuitvoer. Triviaal de gegevens verwerken - importeer ze in een database, analyseer ze en voeg ze toe aan een supportticket. Dat is vrij moeilijk met andere tools waarmee u de gegevens over het algemeen niet gemakkelijk kunt exporteren, alleen grafieken kunt weergeven en/of aanzienlijk kunt beperken welke analyse u kunt uitvoeren, enz.

Ik geef toe dat een deel hiervan voortkomt uit het feit dat ik werk voor een bedrijf dat PostgreSQL-services levert aan andere bedrijven (of het nu 24×7-ondersteuning is of externe DBA). We krijgen dus meestal slechts een zeer beperkte toegang tot klantsystemen (meestal alleen databaseservers) en niets meer. Dat betekent dat alle belangrijke gegevens op de databaseserver zelf, toegankelijk via gewone SSH, uiterst handig is en onnodige retourvluchten elimineert om alleen maar een ander stuk gegevens van een ander systeem op te vragen. Wat zowel tijd als gezond verstand bespaart aan beide kanten.

Als u veel systemen moet beheren, geeft u waarschijnlijk de voorkeur aan een monitoringoplossing die gegevens van veel machines op één plek verzamelt. Maar voor mij, sar wint nog steeds.

Dus, hoe configureer je het?

Ik noemde het installeren en inschakelen van sar (of liever sysstat , dat is het pakket inclusief sar ) is heel eenvoudig. Helaas is de standaardconfiguratie enigszins slecht. Na het installeren van sysstat , vind je zoiets in /etc/cron.d/sysstat (of waar uw distributie cron ook opslaat configuratie):

*/10 * * * * root /usr/lib64/sa/sa1 1 1

Dit zegt in feite de sa1 commando wordt elke 10 minuten uitgevoerd en het verzamelt een enkel monster gedurende 1 seconde. Er zijn hier twee problemen. Ten eerste is 10 minuten een vrij lage resolutie. Ten tweede beslaat het voorbeeld slechts 1 seconde van de 600, dus de resterende 9:59 zijn er niet echt in opgenomen. Dit is enigszins OK voor trending op de lange termijn, waar willekeurige steekproeven met een lage resolutie voldoende zijn. Voor andere doeleinden moet u waarschijnlijk iets als dit doen:

* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1

Die één monster per minuut verzamelt, en elk monster beslaat één minuut. De -S XALL betekent dat alle statistieken moeten worden verzameld, inclusief interrupts, individuele blokapparaten en partities, enz. Zie man sadc voor meer details.

Samenvatting

Dus, om dit bericht samen te vatten in een paar simpele punten:

Je zou monitoring moeten hebben, zelfs als je denkt dat je het niet nodig hebt. Zodra je problemen tegenkomt, is het te laat.
De kosten van monitoring zijn waarschijnlijk verwaarloosbaar, maar zeker veel lager dan de voordelen van het hebben van monitoringgegevens.
sar is handig en zeer efficiënt. Misschien gebruik je in de toekomst iets anders, maar het is een goede eerste stap.
De standaardconfiguratie is niet bijzonder goed (lage resolutie, samples van 1 seconde). Overweeg om de resolutie te verhogen.