Seitenhistorie

...

• Vom Icinga-Server aus überwachen:
  
  • Zunächst IP des Blechs testen. Falls nicht pingbar → Email an Kontaktadresse versenden
  • Pingtest Hoster-IP → Falls nicht pingbar: Auf Blech einloggen und mit virsh destroy $vname && virsh start $vname neu starten
    • Pro Host müsste es separat setzbar sein, was im Falle eines Ausfalls zu tun ist.
      • Teilweise ist Login auf Blech möglich
      • Prüfen wie man VMware-Kisten automatisiert töten kann
      • Bei gespendeten VMs muss teilweise einfach eine Email versendet werden. SMTP-Login dafür kann bereit gestellt werden
  • Falls gesetzt Nat-IP pingen (von außen)
• Vom Gateway selbst per nrpe:
  
  • Pro Domäne die a.b.c.2, a.b.c.3, a.b.c.11 und a.b.c.12 pingen, falls zwei nicht pingbar → Wahrscheinlich hängt das Batman → Neustart
    • Gleiches für V6: <Präfix>:$domäne::2, ::3, ::11, ::12 pingen → Falls zwei nicht pingbar → Neustart
    • (Falls die VM dabei hängen bleibt, greift die erste Regel)
  • Prüfen ob folgende Dienste laufen, und falls nicht automatisch neu starten (protokollieren, wie oft dies passiert ist)
    • bird
      
      • Ausgabe von birdc show proto überprüfen, ob OSPF „running“ und alle bgp „established“ sind.
        Falls nicht: Icinga-Service auf 'Warning' setzen. (Wenn auf einem Gateway bind abschmirt, fallen die Routingverbindungen zum Parntergateway mit aus)
    • bird6
      • Ausgabe von birdc6 show proto überprüfen, ob OSPF „running“ und alle bgp „established“ sind.
        Falls nicht: Icinga-Service auf 'Warning' setzen. (Wenn auf einem Gateway bind abschmirt, fallen die Routingverbindungen zum Parntergateway mit aus)
    • kea
    • collectd
    • py-respondd
  • Prüfen, ob ip r s t ffnet und ip -6 r s t ffnet einen default-Eintrag haben, falls nicht Email an hinterlegte Benachrichtigungsemail

...