Ubuntu Server für Minuten nicht erreichbar

  • Der Support hat mir mittlerweile geschrieben, dass ein erweitertes Monitoring für meine IPs geschaltet wurde und ich die genauen Zeitpunkte der Ausfälle nennen soll.


    Gestern hatte ich gegen 16:10, 9, 7:52, 7:29, 7:27 und 6:17 Probleme, betraf allerdings nur zwei IPs. Meine Haupt-IP war immer erreichbar. Heute Morgen um 7:35 waren alle IPs unerreichbar.


    Was mich gerade wundert, das Forum und die netcup Seite sind heute wahnsinnig träge (ich selbst bin zu Hause in Bad Herrenalb über unitymedia angebunden. die Serverausfälle, die ich beobachte, treten aber auf via Standleitung zu TelemaxX, unitymedia, Telekom Mobilfunk, ein RZ in Nürnberg wo mein Cacti läuft und aus USA oder wo auch immer uptimerobot die Server stehen hat).

  • Heute Nacht gab es um 3:30 Probleme; es gab wieder ein Problem bei der Munin Abfrage und eine eingehende email wurde zum Alternativ-Server, der mit MX 50 in der DNS Zone eingetragen ist gerouted. Vielleicht treten die Probleme häufiger auf - aber mein Abfrageintervall sind halt 5 Minuten.

  • Also, ich bin der Meinung, dass es eventuell effektiver ist, wenn man sich zur Überwachung der Verfügbarkeit seines Servers einen speziellen Dienstleister mit möglichst vielen geografisch verteilten Meßstellen nimmt, wie z.B. ServerGuard24. Denn eine Meßstelle bis eventuell auch drei dafür zu verwenden, halte ich aus meiner Sicht nicht wirklich für aussagekräftig. Und wenn sie dann noch auf dem eigenen Server läuft, erst recht nicht.


    Ich nehme mal an, dass der Dienstleister ServerGuard24 und eventuell auch Andere über alle geografisch verteilten Meßstellen die Verfügbarkeit des Servers prüfen wird. Und wenn dabei festgestellt wird, dass nur noch eine Meßstelle von vielen erkennt, dass der Server noch erreichbar ist, er auch als erreichbar erkannt wird. Denn primär geht es ja nur darum, zu prüfen, ob der betreffende Server auch noch dann erreichbar ist, wenn in dieser Zeit zufälligerweise schon viele andere Netzbetreiber mit deren Netzwerk Probleme haben.


    Seit Anfang diesen Jahres lasse ich meinen Root-Server durch den Dienstleister ServerGuard24 alle 5 Minuten prüfen und konnte bisher noch keine gravierenden Netzwerkprobleme von dessen Meßstellen bis zum Root-Server bezüglich der Verfügbarkeit feststellen.

  • sehr kostengünstig ist nicht immer besser

    Ich kann mich nicht beklagen, den immer wenn UptimeRobot angeschlagen hat, war die Seite auch wirklich nicht zu erreichen. Ich versuche dann ja auch immer nach den Gründen zu schauen, also von daher kann ich nur sagen dass es bislang immer sehr zuverlässig war. Zumal ich nicht auf die Zugriffszeiten achte, sondern ob die Seite erreichbar ist. Aber jedem steht es frei auch für die Dienstleistung zu bezahlen.

  • Ich wollte lediglich weitere Erfahrungen zu dem genannten Dienst einwerfen, diesen aber nicht grundlegend schlechtreden. Und Fehlalarme kann es sicherlich bei allen Angeboten geben. Ich teste derzeit beispielsweise StatusCake in der kostenlosen Version dafür und bin bisher auch zufrieden. Kann man aber bestimmt mal in einem eigenen Thema erörtern und Erfahrungen vergleichen.


    Sorry wenn ich durch meinem Einwand ein wenig vom eigentlichen Thema ablenkte. :)

  • Für das externe Monitoring sollten die Server aber auch nicht irgendwo in Übersee stehen - ich möchte ja die Verfügbarkeit des eigenen Servers testen und nicht die Stabilität irgendwelcher Seekabel.


    Zurück zum Thema: heute um 8:25, 10:00, 12:05, 14:00, konnte der eine vServer (v22016114011140388) wieder den anderen (v22016124011141793) nicht erreichen, um seine Munin Daten zu pollen. Wenn ich von meinem PC aus zu beiden Servern eine SSH-Verbindung offen habe friert die zu v22016114011140388 dann immer ein.

  • Sind bei euch alle IP Adressen betroffen oder nur zusätzliche? Der Support konnte bei mir zumindest nachvollziehen, dass die Ausfälle auftreten, sie betreffen aber fast ausschließlich die zusätzlichen IPs und nicht die Haupt-IP des Servers.

  • Gestern Nacht gab es noch 4 Probleme beim Munin polling: um 1:45, 5:25, 7:30 und 8:50.

    In dieser Nacht gab es keine Unterbrechung; das einzige, das ich geändert habe, ist die Frequenz des externen Monitorings von alle 5 Minuten auf minütlich. Das war ja auch schon so, als ich vom heimischen PC ein MTR zum Server laufen liess - auch während dieser Zeit traten keine Probleme auf. Ich werde heute Abend das externe Monitoring unterbrechen - mal sehen ob es wieder Probleme gibt. Eine bestehende SSH-Verbindung schützt nicht vor den Problemen - die wird dann gekappt.

  • snip_20170614191616.png


    Also je kürzer das externe Monitoring Intervall desto kürzer ist die SMTP Response Time!?

    Solange ich den Server jede Minute Abfrage liegt die Zeit unter 0,4s. Ab Mittags habe ich das Intervall auf 30 min gesetzt und seitdem klettert die Response Time auf Werte über 7s! Ab 10s treten die Probleme auf. Woran könnte das liegen?

  • In der letzten Nacht gab es keinerlei erkennbare Probleme. Nach meiner These müsste noch ein weiteres Monitoring dazu gekommen sein weil sich jetzt die SMTP Response Time bei etwa 1s eingependelt hat - sicherlich beeinflusst auch der echte Mail-Verkehr die ganze Sache - deswegen traten die Probleme auch eher nachts auf.

    Ich würde auch mit meinem betroffenen RS 500 SAS G7 SE 12M auf ein RS 1000 G7 SE (SAS) migrieren; wenn das so einfach möglich wäre.

  • Jetzt aus eventueller Verzweiflung einen größeren Server zu mieten, bei dem auch dieses Problem auftreten könnte, solltest du dir noch mal sehr gut überlegen.


    Eventuell ist es da schon sinnvoller, wenn du noch mal so einen kleinen Server dazunimmst und den kompletten Inhalt vom Ersten auf den Zweiten spiegelst, um damit das Problem weiter eingrenzen zu können.


    Eine weitere Möglichkeit wäre, wenn du deinen Problem-Server mal für ein paar Tage im Rettungsmodus zur intensiveren Beobachtung mit Hilfe eines anderen Betriebssystems als du derzeit einsetzt laufen lassen würdest. Denn damit kannst du auch schon mal feststellen, ob es an deiner Installation oder doch eher an der Infrastruktur des Providers liegt.