Module um Internetverbindung zu checken?

[Serpens66]

Hallo

mein Python Skript läuft auf so einem Server-provider auf Debian 8.1 und macht dort API Calls zu ein paar REST APIs von webseiten mit dem requests modul.

Ab und zu kommt es vor, dass die Verbindung ziemlich schlecht ist und ich lange keine Antwort bekomme, bzw dass wie von mir eingestellt nach 30 sekunden ein timeout geraised wird.
Sobald dies häufiger in einem kurzem Zeitraum vorkommt, schreib ich in der Regel die Website oder meinen Server Provider an und frag die, warum die Verbindung so schlecht ist. In 99% der Fälle heißt es dann "ne, ist alles tip top, mach doch mal ein mtr und ping test". Dann mache ich diese tests und zeige ihnen das Ergebnis. Wieder in 99% der Fälle ist das Ergebnis einwandfrei und zeigt keinerlei Verbindungsprobleme.
Wenn es dann trotzdem weiterhin immer mal wieder Verbindungsprobleme gibt, aber einem alle sagen "alles tip top", dann kommt man sich ziemlich hilflos vor.

Soweit ich als Amateur diese Lage beurteilen kann, schätze ich es so ein, dass es tatsächlich zb für 5 Minuten pro Stunde Verbindungsprobleme gibt. Und wenn ich mtr und diese Tests mache, dann ist das gerade ein Zeitraum in dem die Verbindung tatsächlich gut ist. Deshalb sind diese Tests relativ nutzlos und ich kann dem Support nichts zeigen, damit sie die Ursache für die Störung finden könnten.

Was ich nun also suche:
Gibt es eine Möglichkeit, wie ich nonstop die genauen Verbindungsdetails zu einer website/api tracken kann, sodass wenn dann ein timeout passiert, ich direkt dem Support das ganze zeigen kann und er sieht "ah hier und da hat es gehangen, wir kümmern uns drum" ?
Entweder ein Python Modul, oder gerne auch iwas was nebenbei auf dem Debian 8.1 laufen kann.

edit:
warum ich nicht selbst google bemühe? Weil ich mich mit diesem Thema "Verbindungen" nicht auskenne und keine Ahnung habe, was für eine Analyse ala "mtr" benötigt wird. Also selbst wenn ich dann 4 versch. Programm/Module finde, hätte ich keine Ahnung welches für meine Zwecke verwendbar wäre.

[noisefloor]

Hallo,

wie viele API-Calls machst du denn? Es gibt ja auch diverse APIs, welche nur eine bestimmte Anzahl von Request pro Minute / Stunde / ... erlauben und wenn diese Anzahl überschritten ist, die API Calls entweder stark drosseln oder gar nicht mehr ausführen.

Abgesehen davon ist es IMHO Aufgabe des Providers, seine Anbindung und Anbindungsgeschwindigkeit zu monitoren... Wobei es natürlich auch sein könnte, dass die Anbindung des Rechenzentrums konstant gut ist, dein Server aber zu bestimmten Zeiten keine Bandbreite abbekommt.

Gruß, noisefloor

[Serpens66]

Hallo,

wie viele API-Calls machst du denn? Es gibt ja auch diverse APIs, welche nur eine bestimmte Anzahl von Request pro Minute / Stunde / ... erlauben und wenn diese Anzahl überschritten ist, die API Calls entweder stark drosseln oder gar nicht mehr ausführen.

Abgesehen davon ist es IMHO Aufgabe des Providers, seine Anbindung und Anbindungsgeschwindigkeit zu monitoren... Wobei es natürlich auch sein könnte, dass die Anbindung des Rechenzentrums konstant gut ist, dein Server aber zu bestimmten Zeiten keine Bandbreite abbekommt.

Gruß, noisefloor

Auf die Rate Limits achtet mein Skript, bzw wenn es überschritten werden würde, gäbe es eine entsprechende Fehlermeldung, zb "HTTP 429 Too much requests"

Der Server Provider hat laut eigener Aussage keinerlei Zugriff auf mein System und verlangt halt jedesmal ping und mtr tests, die dann leider immer "tolle Verbindung" zeigen.Also gibt es diesbezüglich nichts?

edit:
in meinem aktuellen Fall schickte mir die website sogar ihre Logs von meinen API Calls. Daraus war im aktuellen Fall ersichtlich, dass der Call, auf dessen Antwort ich 30 sekunden vergeblich gewartet habe, niemals bei ihnen angekommen ist.

[sls]

Hi,

falls es schnell gehen muss und auch eine nicht-Python-Lösung sein darf, würde ich dir Smokeping ans Herz legen. Damit kannst du die Verbindungen zu deinem Server und vice versa monitoren.

Du kannst zum einen custom-ping-checks, aber auch HTTP-checks durchführen, falls du Web-Applikationen überwachen möchtest. Dort lässt sich auch einfach ein E-Mail-Alerting einrichten, welches unter definierten Voraussetzungen eine E-Mail an dich oder den Support schickt, wenn der Uplink gerade grottig ist.

Einen MTR musst du halt dauerhaft laufen lassen, und ich bezweifle auch dass dieser so granular ist, dass sich damit Timeouts sicher und genau ermitteln lassen.

Mfg,

sls

[nezzcarth]

Was ich nun also suche:
Gibt es eine Möglichkeit, wie ich nonstop die genauen Verbindungsdetails zu einer website/api tracken kann, sodass wenn dann ein timeout passiert, ich direkt dem Support das ganze zeigen kann und er sieht "ah hier und da hat es gehangen, wir kümmern uns drum" ?
Entweder ein Python Modul, oder gerne auch iwas was nebenbei auf dem Debian 8.1 laufen kann.

Prinzipiell gibt die Möglichkeit schon und das würde man so angehen, dass man den ausgehenden Traffic "weiter unten" mitschneidet und analysiert. Das kann zum Beispiel mit einem entsprechenden Debugging-Proxy auf HTTP-Ebene geschehen, oder noch "tiefer unten" mit einem Analyse-Tool, das den Verkehr am Netzwerk-Interface monitored. Allerdings muss man dafür wissen, wie die Protokolle funktionieren und zusätzlich kann man sich da mitunter rechtliche Probleme einhandeln, insb. wenn da auch fremder Traffic bei ist. D.h. einen Dump zu erstellen und dem Provider zu schicken fällt wohl weg, auch wenn das technisch möglich ist.

[__deets__]

@nezzcarth das von dir vorgeschlagene Vorgehen hat auch keine Chance bezüglich des von mir skizzieren Szenarios. Damit bekommst du auch nur raus wenn es geklappt hat. Wenn der Server nicht antwortet weißt du immer noch nicht warum bzw ob das Request durchging oder vorher versandet ist.

[__deets__]

Ups. Falscher Thread. Antwort trotzdem gleich

[nezzcarth]

@nezzcarth das von dir vorgeschlagene Vorgehen hat auch keine Chance bezüglich des von mir skizzieren Szenarios. Damit bekommst du auch nur raus wenn es geklappt hat. Wenn der Server nicht antwortet weißt du immer noch nicht warum bzw ob das Request durchging oder vorher versandet ist.

Ja, das stimmt natürlich. Allerdings denke ich, dass dieses Vorgehen schon helfen könnte, die möglichen Szenarien einzugrenzen und zum Beispiel deines als wahrscheinlich anzunehmen. Wenn man beim Client den durchkommenden Traffic anschaut, kann man zumindest schon mal sehen, dass alle Requests ordnungsgemäß den Rechner verlassen und eine valide Form haben und dass dies auch auf alles, was ankommt, zutrifft. Umgekehrt kann man sehen, wenn auf Protokoll-Ebene irgendwas Defektes ankommt. Dann ist zumindest schon mal klar, dass unterwegs etwas schief geht. Und wenn man dann umgekehrt feststellen kann, dass zum Beispiel Paketverluste sonst nicht auftreten, kann man annehmen, dass vielleicht etwas beim API-Provider oder auf dem spezifischen Weg zu ihm schief geht.

[__deets__]

Da die Kontrolle über des TE über die geschätzt 30 hops einer IP Verbindung nur bei bestenfalls 3-4 gegeben ist, halte ich das trotzdem für aussichtslos. Und letztlich muss man das ja auch einfach akzeptieren, das Netzwerkverbindungen nichts 100%iges sind. Wer damit nicht klar kommt, hat ein Problem. Natürlich sollte man eine große Fehleranzahl untersuchen, aber da es IMMER zu einem Fehler kommen kann, und das auch bei allen Hops zwischen Client und Host kann nur ein robustes weil zB Idempotentes verfahren helfen.

[nezzcarth]

@__deets__: Okay, aus der Perspektive gesehen kein weiterer Einspruch

[Serpens66]

wäre "tcpdump" eine mögliche Lösung? Das wurde noch vom Betreiber der Website vorgeschlagen.
Bräuchte für sowas nur ein Anfänger-tutorial ^^

[__deets__]

Lösung eh nicht. Es ist ein Tool (DAS Tool) für die Netzwerkanalyse. Aber wenn du immer das gleiche machst, das mal durchkommt und mal nicht, dann bringt das eher nichts. Denn requests macht da betsimmt nichts anderes von mal zu mal, und damit liegt das Problem entweder bei deiner virtuellen Maschine, oder einem der Rechner/Systeme dazwischen.

Vielversprechender wäre eher mal zu schauen ob du dein Skript von zuhause oder zB einer zeitweise gemieteten Amazon EC2 Instanz robuster betreiben kanns. Wenn es da weniger Fehler sind, interessiert es vielleicht deinen Provider.

Last but not least: dein Problem, das deine ganze Herangehensweise nicht robust ist, ändert das nicht. Ich würde da ansetzen.

[Serpens66]

Lösung eh nicht. Es ist ein Tool (DAS Tool) für die Netzwerkanalyse. Aber wenn du immer das gleiche machst, das mal durchkommt und mal nicht, dann bringt das eher nichts. Denn requests macht da betsimmt nichts anderes von mal zu mal, und damit liegt das Problem entweder bei deiner virtuellen Maschine, oder einem der Rechner/Systeme dazwischen.

Vielversprechender wäre eher mal zu schauen ob du dein Skript von zuhause oder zB einer zeitweise gemieteten Amazon EC2 Instanz robuster betreiben kanns. Wenn es da weniger Fehler sind, interessiert es vielleicht deinen Provider.

Last but not least: dein Problem, das deine ganze Herangehensweise nicht robust ist, ändert das nicht. Ich würde da ansetzen.

Es ist wie immer schwer für mich die wichtigen Infos aus Experten-Antworten rauszulesen
Deswegen versuch ichs mal:
"tcpdump bringt dir nichts. Lass das Skript woanders laufen und schau ob genauso oft timeouts kommen."

Den Rest der Antwort hab ich nicht verstanden (besonders den letzten Satz). Ist das obige also deine Hauptaussage die ich mir merken kann, oder sollte ich etwas anderes deiner Aussage noch beachten?

Ich will damit nur beleuchten, was von deiner Antwort bei mir angekommen ist. Denn zwischen Anfängern und Experten gibt es, bei mir besonders oft, Kommunikationsprobleme, dass nur die Hälfte von dem was ein Experte schreibt, auch beim Anfänger ankommt


Aktuell ist mein komplettes Verständis von dieser Verbindungsproblematik:
Jeder nutzt das Itnernet und macht ständig iwelche Anfragen. Aber dennoch ist es aus unerfindlichen Gründen niemanden bisher gelungen, dass man vernünftig analysieren kann wo es klemmt. Wenn was nicht geht, dann gehts halt nicht.
("Offtopic" jetzt gerade hab ich zb Probleme mit der websocket verbindung, die ohne ersichtlichen Grund sich nach ~ 1 Minute ständig selbst beendet... und auch hier werde ich wohl niemals rausfinden warum.... irgendwann gehts dann wieder vonalleine... Das find ich ziemlich schlimm =/)

[BlackJack]

@Serpens66: Das was Du ziemlich schlimm findest ist halt wie das Internet funktioniert. Und eigentlich auch der Grund warum es so gut und letztlich ziemlich robust funktioniert. Das ist ein Netzwerk von vielen, vielen Geräten und Netzen und basiert grundsätzlich auf IP-Paketen die verschickt werden und zwar nach „best effort“. Das heisst die Knoten bemühen sich so gut sie können, geben aber keine Garantien. Pakete können in anderer Reihenfolge ankommen als sie abgeschickt werden, Pakete von einer Quelle zu einem Ziel können unterschiedliche Wege nehmen, Pakete können verloren gehen.

Und da die Knoten weder der Sender noch der Empfänger alle unter seiner Kontrolle hat, und auch nicht welche Knoten zwischen Sender- und Empfängernetz beteiligt sind, hat man entsprechend Grenzen in denen man herausfinden kann warum Pakete verloren gehen oder deutlich länger brauchen.

Darauf baut dann TCP auf. Da werden die Pakete durchnummeriert, damit der Empfänger weiss in welcher Reihenfolge die abgeschickt wurden, und es werden Pakete mit (”Nicht”-)Quittungen verschickt, so das man auf dem IP-Paketsystem eine Verbindung abbilden kann. Es gelten aber weiterhin unten drunter die „best effort“-Regeln von IP.

Was Du IMHO nicht in der Zusammenfassung hast ist der letzte Satz: Dein Programm *muss* damit klar kommen können das Verbindungen jederzeit für mehr oder weniger beliebig lange Zeit hängen bleiben oder abbrechen können. Ohne das Du allgemein herausfinden kannst ob und wie viel bei der Gegenseite bis zu dem Zeitpunkt angekommen ist. Das geht nur wenn die API dafür explizit oder implizit etwas vorsieht.

[Serpens66]

@BlackJack:
Danke dir... ich hoffe dennoch dass da mal iwer iwann was erfindet, wodurch es die Vorteile behält und dennoch besser wird...

Was Du IMHO nicht in der Zusammenfassung hast ist der letzte Satz: Dein Programm *muss* damit klar kommen können das Verbindungen jederzeit für mehr oder weniger beliebig lange Zeit hängen bleiben oder abbrechen können. Ohne das Du allgemein herausfinden kannst ob und wie viel bei der Gegenseite bis zu dem Zeitpunkt angekommen ist. Das geht nur wenn die API dafür explizit oder implizit etwas vorsieht.

Danke fürs übersetzen da wäre ich wirklich nie drauf gekommen, dass das mit dem letzten Satz gemeint ist.

Ja mein Programm kommt damit klar. Aber es ist dennoch sehr nervig, da die "Lösung" dafür heißt "alles abbrechen und 2 bis 10 minuten warten". Bzw die Calls die problemslos mehrmals gesendet werden dürfen, werden nochmal versucht.

[DasIch]

Du kannst nicht feststellen ob eine Nachricht angekommen ist oder nicht, die korrespondierende Antwort ist schließlich vielleicht einfach nicht zurück gekommen. Dementsprechend kannst die Anwendung nur so bauen, dass Nachrichten höchstens einmal oder mindestens einmal übertragen werden.

[DeaD_EyE]

Willkommen im Internet. Es ist noch viel schlimmer als du denkst.

Das Problem, welches du beschreibst, haben alle Admins, die z.B. Monitoring von irgendwelchen Diensten beitreiben. Es lässt sich nur feststellen, dass ein Dienst von einem gewissen Quellhost aus nicht erreichbar ist. Es kann z.B. sein, dass der Dienst vom Quellhost, also der Host auf dem das Monitoring betrieben wird, nicht erreichbar ist, aber sehr wohl aus anderen Netzwerken. Die richtige Entscheidung zu treffen, ist nicht einfach.

Es gibt keine "die Lösung".
Deswegen hast du über Google auch nichts gefunden.

Fang einfach den Timeout ab und versende z.B. eine Meldung per E-Mail. Wenn der Dienst wieder verfügbar ist, versendest du einfach eine weitere Meldung per Mail. Was dazwischen passiert, wirst du als Mensch entscheiden müssen. Letztendlich können Fehler noch an ganz anderer Stelle auftreten. Der Service kann abgestürzt sein, vielleicht ist im RZ der Strom ausgefallen oder der Uplink ist tot, der Router ist abgebrannt oder dein Provider hat Probleme.