Kurze Zeiten Nicht-Erreichbarkeit Oster-VServer

  • Ich stelle mittels eines mehrmals die Minute stattfindenden Monitorings mit einem Timeout von 3 Sekunden über den Tag verteilt Ausfälle von einigen Minuten fest.


    Kann jemand aus Erfahrung sagen, ob das auf Netzwerkprobleme zurückzuführen ist, oder durch Probleme am VServer (Osteraktion 2 VCores und 2 GB Ram) liegen kann?


    Bei meinen anderen 3 virtuellen Servern bei anderen Anbietern kenne ich das so nicht.

  • Die heutigen Ausfälle mit 3 Sekunden Timeout: 01.57 02.02 14.05 16.01 17.48 18.09 19.51 20.02 20.16 Uhr.


    Viele mögen das ja in Ordnung finden, aber ich glaube nicht, dass es ok ist, wenn eine Webseite nach drei Sekunden nicht erscheint. Vor allem wenn sie so optimiert ist, dass es eigentlich in 0,2 bis 0,3 erledigt ist.


    Es wäre schön zu wissen, was das Problem sein könnte, was man ändern könnte ...


    Für mich ist es jetzt kein Beinbruch, da es nur ein Zweit-Failover-Server ist, und nicht wirklich gebraucht wird. Da mein Haupthoster extrem zuverlässig ist und zum Beispiel nicht mal Ausfälle beim Update seiner Cloudsoftware und -hardware hat - Live Migration sei dank.


    Ich hab ja schon einiges im Vorfeld in die Richtung gelesen, wollte Netcup aber selbst kennenlernen.

  • Den ganzen Tag gleichmäßig: CPU 12 Prozent, Ram 20 Prozent,

    Vom Traffic her gibt es sowohl bei Hetrixtools als auch in der Anzeige bei Netcup keinerlei Spitzen.


    Der Server sendet nur an einige Monitoring-Dienste und zwei andere Cloud-Server von mir, von denen er überwacht wird und er selbst überwacht die zwei anderen und den eigentlichen Hauptserver. Gesamttraffic 24 Stunden: 563 MB OUT und 360 MB IN.


    Die IP des Netcup-Server würde nur im Failover-Fall automatisch ins DNS eingetragen. Es kommt also außer Monitoring-Traffic nichts rein und raus, deshalb auch keinerlei Spitzen.


    Die eigene Messung erfolgt mittels Curl mit einem Timeout von 3 Sekunden. Um die danach anfallende Ladezeit zu ermitteln müsste ich zum Beispiel das Timeout auf 20 Sekunden hochsetzen, die Ladezeit ausgeben lassen und dann halt diese Ausgabe überprüfen ob sie über 3 Sekunden liegt.


    Habe ich vorher so gemacht, ist aber jetzt weniger belastend für die Server, wenn ich das Timeout einfach auf 3 Sekunden setze und die Ladezeitanalyse weglasse (Es läuft jede Sekunde ein Curl-Aufruf). Denn die drei Sekunden sind meine Schmerzgrenze, die mich wirklich interessiert. Sonst wird das Monitoring nur sinnlos aufgehalten, mit Infos die mir keinen Mehrwert bringen.

  • Womit werden die 12% CPU-Last produziert?

    Ein Server im Leerlauf sollte doch kaum mehr als 0,5-1% CPU Last aufweisen.


    Warum weißt Du, dass das Problem am NetCup vServer liegt und nicht auf Deinem Monitoring-Server von dem aus Du den Curl-Aufruf tätigst?

    Sprichst Du den Server mittels IP-Adresse oder Domain-Name an? Sofern Domain-Name könnte das Problem auch in der Namensauflösung liegen. Welche DNS-Server verwendet Dein Monitoring-Server? Könnten diese vielleicht ab und an mal träge reagieren?

  • Hallo gunnarh scheint dich wirklich zu interessieren.


    Warum weißt Du, dass das Problem am NetCup vServer liegt und nicht auf Deinem Monitoring-Server von dem aus Du den Curl-Aufruf tätigst.


    Das ist wirklich ein Problem, was schwer anzugehen ist, wenn man nur zwei Server hat, die sich gegenseitig überwachen. Server A ruft mittels Curl Server B auf und kommt in ein Timeout. Liegt das Problem an z. B. der schlechten Netzwerkverbindung von Server B? Oder doch an der von Server A?


    Wenn man auf Basis dieser Informationen ein automatisches Failover laufen lässt, schaltet man am Ende auf den kranken Server um.


    Deshalb nutze ich diese Lösung auch nur für ein zusätzliches Monitoring und nicht für das Failover.


    Aber zu deiner Frage: Weil zwei andere Server sagen, dass es der Netcup-Server ist und die zwei anderen selbst untereinander nichts zu meckern haben.


    Womit werden die 12% CPU-Last produziert?

    Ein Server im Leerlauf sollte doch kaum mehr als 0,5-1% CPU Last aufweisen.


    Wow, Curl braucht wirklich viel Leistung, vor allem wenn man sich noch ein paar zusätzliche Daten ausgeben lässt und die analysiert. Und ich pinge nicht nur, oder schaue auf den Status 200. Ich prüfe den Inhalt durch Abfrage eines Suchwortes.


    Ich musste das Monitoring-Script schon heftig abrüsten, weil ich die CPU-Last auf allen Servern dauerhaft auf über 80 Prozent lag.


    Deshalb läuft das auch nicht auf dem Hauptserver, der ist für die schnelle Lieferung der Seiten zuständig.


    Und der Server muss auch ständig auf das Monitoring antworten. Dabei werden nicht nur statische Dateien abgefragt, sondern die müssen jedesmal frisch mit PHP und MySQL erzeugt werden. Damit ich auch sehe, ob nicht nur nginx, sondern alles noch läuft.


    Zitat von gunnarh


    "Sprichst Du den Server mittels IP-Adresse oder Domain-Name an? Sofern Domain-Name könnte das Problem auch in der Namensauflösung liegen. Welche DNS-Server verwendet Dein Monitoring-Server? Könnten diese vielleicht ab und an mal träge reagieren?"


    Ich gebe die eigentliche URL mit Domainnamen an, definiere aber die zu benutzende IP über "--resolve". Es wird also keine DNS-Auflösung benötigt (die wird unabhängig überwacht).


    Die von Curl am Ende benutzte IP lasse ich mir ausgeben und überprüfe, ob sie auch der entspricht, die Curl verwenden sollte. Wenn nicht gibt es einen Alert. Ich überprüfe also, ob auch der richtige Server überwacht wird, dass sich ein Monitoring-Server nicht ausversehen wegen der host-Datei selbst überwacht.

  • Ich hatte in der Vergangenheit immer wieder solche Probleme bei verschiedenen Servern. Der Support hat dann auf Anfrage die entsprechende VM auf ein anderes Hostsystem verschoben (am besten ein MTR mitschicken) was das Problem gelöst hat. Die Begründung das Problem betreffend fiel zuletzt wie folgt aus: "Es handelte sich um Lastspitzen, welche die Performance etwas beeinträchtigt hat. Nachdem nun ein paar Server vom Wirtsystem weg-migriert wurden, läuft nun wieder alles ordnungsgemäß." (Interessant ist aber, dass lediglich die Erreichbarkeit von außen beeinträchtigt war (auf Netzwerkebene), nicht der Server/die laufenden Anwendungen selbst.)

    Ob es sich bei Dir um dieselbe Ursache handelt kann ich natürlich nicht sagen.

  • Bildschirmfoto 2018-04-20 um 10.55.00.png

    Habe diese Peaks auch in meinem HTTP-Responsetime monitoring. Für verschiedene Systeme / Server.

    Ich wende mich damit nicht an den Support, da ich nicht angeben/nachweisen kann, wo das Problem liegt. Wenn man das nicht kann, bekomme ich sowieso höchstens Tipps wie man es analysieren könnte. Da es kein systematisches Problem ist und ich nicht dazu da bin das netcup-Netzwerk zu analysieren, kümmere ich mich nicht weiter darum und nehme es soweit hin.

  • (Interessant ist aber, dass lediglich die Erreichbarkeit von außen beeinträchtigt war (auf Netzwerkebene), nicht der Server/die laufenden Anwendungen selbst.)

    Ich gehe davon aus, dass das bei mir genau so ist.


    Eigentlich muss das ja alles funktionieren, ohne dass der Kunde das selbst merken muss.


    Beim Oster-VPS waren 2 vCores inklusive, geliefert wurde mir nur einer. Erst nach Kontakt mit dem Support wurde mir ein zweiter zugeteilt.


    Ich wende mich damit nicht an den Support, da ich nicht angeben/nachweisen kann, wo das Problem liegt. Wenn man das nicht kann, bekomme ich sowieso höchstens Tipps wie man es analysieren könnte. Da es kein systematisches Problem ist und ich nicht dazu da bin das netcup-Netzwerk zu analysieren, kümmere ich mich nicht weiter darum und nehme es soweit hin.

    Vielen Dank für die Bestätigung. Was ist das für ein Monitoring auf dem Bild?


    Ich habe mich auch noch nicht an den Support gewendet. Wenn Netcup sowas nicht grundsätzlich selbst merkt und solche Probleme löst, dann scheinen die einen anderen Qualitätsanspruch zu haben. Da bringt glaube ich jede Diskussion nichts (hab ich auch keine Zeit und Lust dazu).


    Mein Vertrag vom Oster-VPS läuft ja drei Monate, wenn es bis zur Kündigungsfrist noch auftritt, werde ich einfach weiterziehen ...


    Es ist ja auch schade, dass es dem "normalen" Kunden gar nicht auffällt und der dann halt Pech hat. Man braucht schon ein sehr kurzfristiges Monitoring, das ganze aller 5 Minuten oder minütlich bringt da höchstens mal einen Zufallstreffer.


    Von außen macht ja Netcup einen guten Eindruck, also das Marketing funktioniert. Mir sagen hier einige Angebote gut zu, und ich wollte im Herbst noch mehr hier buchen, auch die zugehörige Domain rüberholen etc.

  • Ich bin seit 2012 Kunde bei netcup und meiner Erfahrung nach sind Verfügbarkeit und Performance der KVM-Server (davor Linux vServer) unterm Strich wirklich top. Dass es derartige Probleme hin und wieder gibt (hatte ich jetzt immer öfter bei neu bestellten Servern, bei Erwähnung meines ersten Tickets dazu wird der entsprechende Server dann idR fix migriert und alles ist wieder gut) und nicht von netcup selbst bemerkt werden ist dagegen bedenklich - da stimme ich zu.

  • Ich bin seit 2012 Kunde bei netcup und meiner Erfahrung nach sind Verfügbarkeit und Performance der KVM-Server (davor Linux vServer) unterm Strich wirklich top. Dass es derartige Probleme hin und wieder gibt (hatte ich jetzt immer öfter bei neu bestellten Servern, bei Erwähnung meines ersten Tickets dazu wird der entsprechende Server dann idR fix migriert und alles ist wieder gut) und nicht von netcup selbst bemerkt werden ist dagegen bedenklich - da stimme ich zu.

    Das möchte ich an dieser Stelle auch betonen / genau so unterschreiben!

    Was ist das für ein Monitoring auf dem Bild?

    Ein einfaches Python-Script misst die Dauer bis das gesamte Dokument einer bestimmte URL transferiert wurde (sprich: der HTML-Code einer bestimmten Seite). Das ganze ist in munin eingebunden. Jede farbige Linie stellt die Responsetime einer bestimmten URL dar (Großteil sind einfach URLs von Kunden). Die meisten sind bei 100ms unten. Alle Ziel-Server und der Monitoring-Server stehen bei netcup; es wird also intern geroutet.

    Ursprünglich wollte ich damit erkennen wie sich bestimmte (Webserver-)Einstellungen langfristig auf die Response-Times der Webseiten auswirken.

  • Ursprünglich wollte ich damit erkennen wie sich bestimmte (Webserver-)Einstellungen langfristig auf die Response-Times der Webseiten auswirken.

    Gute Sache und lokal sinnvoller als noch das Netzwerk einzubeziehen.


    Ich habe die Optimierungen mit webpagetest.org überprüft, dabei merkt man aber schon die Varianz der einzelnen Testserver. Ich habe dann mehrere Tests von verschiedenen Standorten aus durchgeführt.

    Dass es derartige Probleme hin und wieder gibt (hatte ich jetzt immer öfter bei neu bestellten Servern

    Meiner ist ja nicht nur neu, sondern auch noch ein Billigserver aus der Ostereiersuche. Ich dachte immer, dass solche Aktionen ins Marketingbudget gehen, aber vielleicht sind es einfach wirklich nur Billigpakete. Dann fände ich es aber gut, wenn man das irgendwie erkennen kann, dass die Normalangebote besser sein können, wenn man Wert auf gleichmäßige Leistung legt.


    Ich vermute mal, dass Netcup den Oster-vServer nicht zwecks besserer Leistung verschieben wird.

  • Nur zur Info, die gestrigen Ausfälle mit 3 Sekunden Timeout: 00.01 00.06 00.07 01.24 02.00 03.56 19.01 20.30 21.50 Uhr.


    Vielleicht hat ja ein Mitarbeiter von Netcup eine Idee woran es liegt, oder kann zur Aufklärung beitragen?

  • Ich denke mal, selbst wenn [netcup] Felix P. das hier ließt wird er Dich zum Support schicken. Wenn Du denen ein MTR schickst von einem Zeitraum wo das Problem aufgetreten ist werden sie eine Migration veranlassen.


    Die Zeiten decken sich jedenfalls mit meinen Erfahrungen, bei mir traten die Probleme immer in den Abendstunden auf.