@hjälpsam: Vad gäller fritt utrymme tycker jag det är väldigt trevligt att bygga en graf av det.
Många vanliga användningsområden har en ganska stadig tillväxt av data, då kan man med enkelhet läsa ut från grafen;
"I nuvarande tempo kommer diskutrymmet att ta slut inom två månader, ska jag korrigera lagringen eller bygga ut min array?"
Sett alldeles för många som har en varning när det är 90% fullt och sedan en numerisk siffra för att visa mängden ledigt.
Det försvårar för dig som administratör att vara proaktiv!
Jag brukar använda programvaran rrd-tool för att bygga grafer, eftersom jag tycker den är enkel att knacka in nästan vilket värde som helst i, så länge man kan sin terminalmagi. http://oss.oetiker.ch/rrdtool/
Att se om linan är uppe eller nere har jag själv använt en extern tjänst som jag varit mycket nöjd med, https://www.pingdom.com/
Körde tidigare egna system för det, men då min server bara håller i en domän klarar jag mig fint på gratismodellen.
@HerrNilsson
Menade verkligen inte att man ska undvika övervakning, jag menar att många har en felaktig inställning till när och hur det ska användas. Har sett fler än en uppsättning där tusen saker övervakas, men ingen ger något värde i slutänden. Många verkar tro att ju fler övervakningspunkter jag har, desto bättre.
Jag anser att man ska försöka bygga upp en miljö som i största mån ska undvika att skapa situationer som kräver övervakningslarm. Det måste vara din utgångspunkt. Sedan ska övervakningen utgå från att hjälpa dig att vara proaktiv, så du kan ta tag i problem innan de hinner resultera i fel.
Jag kan exemplifiera vad jag menar med ditt citat här:
Här skulle många nöja sig med att sätta en larmtemperatur, som de höftar fram. Kanske till och med för låg så den skickar false positives.
Vad jag vill göra är att skapa mer värde. Genom att bygga en graf över CPU-temperaturen istället för ett rent värde, så kan du över tid se om ett problem håller på att uppstå. Exempelvis att datorn sakta dammar igen eller garderoben inte är anpassad för sommaren. Genom att kasta ett getöga en gång i veckan är detta fel man kan ta hand om innan de uppstår.
Med rent varnande och larmande, så sitter du kanske på jobbet när datorn börjar bli tokvarm. Du vet inte varför, du vet inte hur länge det pågått och du kan inte göra något förrän om tre timmar när du kommit hem.
Om en disk dör i min array vill jag att den slutar att skriva och helst att maskinen stänger av sig eller åtminstone går till read-only. Härifrån skulle jag således redan få ett larm på att min maskin gått ner eller på att min tjänst rapporterar dålig hälsa. Självklart är det trevligt att få ett larm om RAID-arrayen med, men håller min array på att skadas när jag sover, kan det kännas rimligare att stoppa allt än att vänta på att jag ska vakna och ta ett beslut.
Absolut. Jag menar bara att man ska ha det som grundtänk i konfiguration och när man skriptar. Det är alltid trevligare att se till att schemalagda jobb och annat stannar och sköter sig än att man får larm och vet att man omedelbart måste skynda sig för annars skrivs data sönder.
Just detta var ett problem på min arbetsplats. IT-avdelningen hade larm vid nästan full disk på servrar som utvecklare använde till att köra långvariga jobb på. Eftersom övervakning traditionellt låg på IT-avdelningen men filerna på servrarna tillhörde utvecklarna skapade detta ofta problem. IT kunde inte röra filerna och utvecklarna såg inte övervakningssystemet förrän varningarna skickats ut. Men då hade de långvariga jobben ändå hunnit gå sönder efter timmar av körtid.
Lösningen blev att utvecklarna fick skriva om sina jobb, så de aldrig startade om det inte fanns tillräckligt mycket ledigt utrymme. Utvecklarna fick nästan omedelbar feedback efter de försökt starta jobbet och kunde därför direkt rensa bland sina filer och spara timmar. Istället som innan när IT fick ett disklarm, jobbet gick sönder för utvecklarna, IT säger till utvecklarna att rensa bland sina filer och jobbet får startas om.
Nu blir givetvis inte detta lika applicerbart när man är ensam admin, men du kan nog se fördelen i att fokusera runt hur man kör sina jobb snarare än att larma när fel uppstår.
Visst, fast här är övervakning väldigt svårt, för det kräver att din process är skriven för att kunna svara på om den har hängt sig eller inte. Om vi bortser från det, så ser jag till att mina processer startas om automatiskt i fall de dör. Detta vill man självklart ha loggat (och kanske ett larm på), men det viktiga är ju att automatisera att processen går upp.
Självklart, men än en gång, här vill du ju utgå från att kunna vara proaktiv. Helst ska din applikation rapportera och varna om det här direkt när skrivning misslyckas och försöka hantera det. I nästa hand vill du ha kontinuerlig övervakning på filens ålder och trigga en varning när snittet är passerat med x%, så du har chans att fixa innan det är ett problem. I sista hand vill jag ha ett larm på att det skitit sig.
