Till försvaret av sar (och hur man konfigurerar det)

Låt mig diskutera ett ämne som inte är PostgreSQL-specifikt i sig, men som jag regelbundet stöter på när jag undersöker problem på kundsystem, utvärderar "stödbarhet" för dessa system, etc. Det är vikten av att ha en övervakningslösning för systemmått, konfigurera den på ett rimligt sätt , och varför sar är fortfarande överlägset mitt favoritverktyg (åtminstone på Linux).

Om vikten av övervakning

För det första är övervakning av grundläggande systemmått (CPU, I/O, minne) extremt viktig. Det är lite konstigt att behöva påpeka detta i diskussioner med andra ingenjörer, men jag skulle säga att 1 av 10 ingenjörer tror att de egentligen inte behöver övervakning. Resonemanget går vanligtvis på följande sätt:

Det är sant att övervakning lägger till overhead, ingen tvekan om det. Men det är sannolikt försumbart jämfört med vad applikationen gör. Faktiskt, sar lägger egentligen inte till någon extra instrumentering, det är bara att läsa räknare från nerneln, beräkna delta och skriva det till disk. Det kan behöva lite diskutrymme och I/O (beroende på antalet processorer och diskar) men det är ungefär det.

Till exempel att samla in statistik per sekund på en maskin med 32 kärnor och flera diskar kommer att producera ~5 GB rådata per dag, men det komprimeras extremt bra, ofta till ~5-10 %). Och det är knappt synligt i top . Upplösningen per sekund är lite extrem, och att använda 5 eller 10 sekunder kommer att minska kostnaderna ytterligare.

Så nej, det visar sig att omkostnaderna faktiskt inte är ett giltigt skäl att inte aktivera övervakning.

Kostnader kontra fördelar

Ännu viktigare, "Hur mycket omkostnader eliminerar jag genom att inte aktivera övervakning?" är fel fråga att ställa. Istället bör du fråga "Vilka fördelar får jag av övervakningen? Uppväger fördelarna kostnaderna?”

Vi vet redan att kostnaderna (overhead) är ganska små eller helt försumbara. Vad är fördelarna? Enligt min erfarenhet är det ovärderligt att ha övervakningsdata.

För det första låter det dig undersöka problem – att titta på ett gäng diagram och leta efter plötsliga förändringar är förvånansvärt effektivt och leder dig ofta direkt till rätt problem. På samma sätt är det mycket användbart att jämföra aktuell data (som samlats in under problemet) med en baslinje (insamlad när allt är bra) och omöjligt om du bara aktiverar övervakning när saker går sönder.

För det andra låter det dig utvärdera trender och identifiera potentiella problem innan de faktiskt drabbar dig. Hur mycket CPU använder du? Ökar CPU-användningen med tiden? Finns det några misstänkta mönster i minnesanvändning? Du kan bara svara på dessa frågor om du har övervakningen på plats.

Varför `sar` är mitt favoritverktyg

Låt oss anta att jag har övertygat dig om att övervakning är viktig och att du definitivt borde göra det. Men varför är sar vårt favoritverktyg, när det finns olika snygga alternativ, både lokalt och molnbaserat?

Det ingår i alla distributioner och är trivialt att installera/konfigurera. Detta gör det ganska enkelt att övertyga folk att aktivera det.
Den är direkt på maskinen. Så om du SSH till maskinen kan du också få övervakningsdata.
Den använder enkel textutmatning. Trivial bearbeta data – importera den till en databas, analysera, bifoga den till en supportärende. Det är ganska svårt med andra verktyg som vanligtvis inte tillåter dig att exportera data enkelt, bara visar diagram och/eller avsevärt begränsar vilken analys du kan utföra, etc.

Jag erkänner att en del av detta kommer från det faktum att jag arbetar för ett företag som tillhandahåller PostgreSQL-tjänster till andra företag (vare sig det är 24×7 support eller Remote DBA. Så vi får vanligtvis bara en mycket begränsad tillgång till kundsystem (oftast bara databasservrar) och inget mer). Det betyder att ha all viktig data på själva databasservern, tillgänglig via vanlig SSH, är extremt bekvämt och eliminerar onödiga rundresor bara för att begära ytterligare en bit data från något annat system. Vilket sparar både tid och förnuft. på båda sidor.

Om du har många system att hantera föredrar du förmodligen en övervakningslösning som samlar in data från många maskiner till en enda plats. Men för mig, sar vinner fortfarande.

Så, hur konfigurerar man det?

Jag nämnde att installera och aktivera sar (eller snarare sysstat , vilket är paketet inklusive sar ) är väldigt enkelt. Tyvärr är standardkonfigurationen något dålig. Efter installation av sysstat , hittar du något liknande i /etc/cron.d/sysstat (eller varhelst din distribution lagrar cron konfiguration):

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

Detta säger effektivt sa1 kommandot kommer att utföras var 10:e minut, och det kommer att samla in ett enstaka prov under 1 sekund. Det finns två frågor här. För det första är 10 minuter ganska låg upplösning. För det andra täcker provet bara 1 sekund av 600, så de återstående 9:59 ingår inte riktigt i det. Detta är något OK för långsiktig trending, där slumpmässigt urval med låg upplösning är tillräckligt. För andra ändamål behöver du förmodligen göra något så här istället:

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

Som samlar ett prov per minut, och varje prov omfattar en minut. -S XALL betyder att all statistik bör samlas in, inklusive avbrott, enskilda blockenheter och partitioner, etc. Se man sadc för mer information.

Sammanfattning

Så, för att sammanfatta detta inlägg i några enkla punkter:

Du bör ha övervakning, även om du tror att du inte behöver det. När du väl stöter på problem är det för sent.
Kostnaderna för övervakning är förmodligen försumbara, men säkert mycket lägre än fördelarna med att ha övervakningsdata.
sar är bekvämt och mycket effektivt. Kanske kommer du att använda något annat i framtiden, men det är ett bra första steg.
Standardkonfigurationen är inte särskilt bra (låg upplösning, 1-sekunds samplingar). Överväg att öka upplösningen.