När väktaren dör: varför tystnad inte är goda nyheter

Inga varningsmejl på veckor. Det finns två förklaringar, och utifrån ser de exakt likadana ut: antingen är allt bra, eller så har väktaren dött.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox får inga varningsmejl
  • proxmox e-postnotiser fungerar inte
  • hur vet jag om proxmox övervakning körs
  • proxmox testa smtp-inställningar
  • proxmox servern gick ner utan besked
  • hur vet jag om proxmox monitoring körs

Du satte upp varningarna. Veckor har gått och inte ett enda mejl har kommit.

Det finns två förklaringar. Antingen har verkligen ingenting hänt, eller så har varningssystemet slutat fungera och du vet inte om det. Utifrån ser de två likadana ut.

Och det mänskliga sinnet tenderar att läsa tystnad som goda nyheter. Just därför lever den här sortens fel i månader utan att märkas.

Det här är ett annat problem än en kontroll som tystnar

På annat håll i den här wikin skrev vi: när en kontroll inte kan läsa sina data ska den inte tystna, den ska säga att den inte kunde läsa.

Det vi beskriver här ligger ett steg högre. Där tystnade en kontroll inuti en fungerande väktare. Här är väktaren själv borta. Det finns ingen kvar som talar, alltså inte heller någon som säger "jag kunde inte läsa det".

Hur en väktare dör tyst

Tjänsten stannar. En uppdatering, en krasch, för lite minne. Det som skulle berätta för dig är just det som stannade.

Postvägen brister. Ett lösenord ändras, en leverantör blockerar, adressen studsar. Väktaren fortsätter arbeta, skriver sina meddelanden, och inget av dem når dig. Det här är det mest bedrägliga, för på serversidan ser allt friskt ut.

Någon stänger av och glömmer. Notiser stängs av tillfälligt medan något utreds. Problemet löses. Notiserna förblir avstängda.

Maskinen stängs av. Ytterfallet: ingenting är trasigt, allt är bara tyst.

De fyra har en sak gemensamt: ingen av dem producerar ett meddelande. Och om ditt sätt att märka ett fel är att ta emot ett meddelande, då är fel som inte producerar meddelanden osynliga för dig.

Lösningen har en annan form: inte ett larm, utan ett hjärtslag

Riktningen måste vändas.

Ett larm säger: tala när något är fel. Ett hjärtslag säger: säg "jag lever" med jämna mellanrum även när ingenting händer. Och låt sedan någon märka när det sägandet upphör.

Skillnaden spelar roll. Ett larm är ett meddelande om ett problem; ett hjärtslag är ett meddelande om budbäraren själv. De besvarar olika frågor och ingen ersätter den andra.

Så snart det finns ett hjärtslag ändras tystnadens betydelse. Tystnad bär nu information: något som borde tala gör det inte.

Den som märker det måste vara utanför den bevakade maskinen

Det här är den del att stanna vid. En maskin kan inte rapportera sin egen död.

Platsen som bedömer hjärtslaget måste ligga utanför den bevakade servern: en annan maskin, en telefon, en yttre punkt. En kontroll som körs inuti servern stängs av med servern och säger ingenting till någon.

Även den enklaste hemmabyggda varianten räcker: låt servern lämna en markering någonstans varje timme, och titta på markeringens ålder. Ingen invecklad uppsättning behövs; det enda som behövs är att bedömningen sker någon annanstans.

Hjärtslaget har en egen fälla

Här finns ett subtilt konstruktionsfel, och de flesta uppsättningar går i det: att koppla hjärtslaget till schemat för något användaren kan stänga av.

Säg att det delar tidsstyrning med den dagliga sammanfattningen. Användaren stänger av sammanfattningen, för den kändes för mycket. Hjärtslaget upphör med den. Den yttre parten ser signalen sluta och larmar om "inga nyheter från din server" medan absolut ingenting är på gång.

Du gissar resultatet: användaren skräms en gång i onödan och stänger av larmet andra gången. Ett falsklarm som din egen säkerhetsmekanism producerar förstör förtroendet för den mekanismen snabbare än att inte ha någon alls.

Regeln: hjärtslaget måste ha sitt eget schema och inte vila på något som går att stänga av.

Samma form, någon annanstans

I artikeln om säkerhetskopieringsjobb i den här wikin skrev vi: titta inte på jobbets status, titta på åldern på den nyaste säkerhetskopian.

Samma form dyker upp här: fråga inte varningssystemet om det fungerar, titta på åldern på den senaste signalen. En status är ett påstående, en ålder är en mätning.

Och slutligen, det enda som ska göras på uppsättningsdagen: framkalla ett fel med flit och se mejlet komma fram. Ett oprövat larm är ingen mekanism, det är ett hopp.

Vad Atlas gör

Atlas Watch skickar en daglig sammanfattning, rapporterar kritiska lägen direkt utan att vänta på sammanfattningen, och vid sidan av dessa sänder en signal varje timme om att den lever.

Det som är värt att berätta är vad den signalen inte är kopplad till.

Signalen vilar varken på den dagliga sammanfattningens schema eller på larmets. Båda har egna inställningar och användaren kan stänga av vilken som. Hade signalen berott på dem skulle den ha upphört i samma stund som användaren stängde av sammanfattningen, och motparten skulle ha sagt "inga nyheter från den här servern" fastän ingenting var fel. Därför har signalen sitt eget schema.

Den andra detaljen följer samma tanke: så länge notisinställningen är avstängd skrivs signalens schemafil inte alls. Det blir alltså inget mellantillstånd av "påslagen men fungerar inte"; antingen finns signalen eller så finns den inte.

Notisvägen är din egen: du anger din egen e-postserver, och mejlet går ut från din server. Att skicka en signal till en yttre punkt är ett valfritt tillägg, och produkten är inte beroende av det för att fungera.

Den allmänna lärdomen: en säkerhetsmekanism får inte luta sig mot de avstängbara delarna av det den skyddar. Gör den det dör den tyst tillsammans med det.

Källor

Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.

Relaterade artiklar

Hur ser det här ut inne i Atlas?

Gå till produktsidan