Jeder weiß, dass es immer ein gutes Zeichen ist, wenn Ihr DevOps etwas entspannt, ruhig und selbstbewusst ist. Das bedeutet, dass das Projekt unter Kontrolle ist und alles so funktioniert, wie es sollte. Und wenn sie sich Sorgen machen, ist das für jeden ein Grund, sich Sorgen zu machen. Vor allem, wenn die Fehlerprotokollierung des Projekts ein Unruhestifter ist.
Heute möchte ich die Geschichte des Problems mit dem enormen Unterschied zwischen den Daten von Cloudflare und NEL Analytics erzählen, den wir bei einem unserer größten Projekte entdeckt haben (eine Blockchain-Infrastruktur, die über 800 Millionen Anfragen pro Tag verarbeitet). Keine Sorge, es hat ein Happy End.
Folgendes ist passiert.
In meinem Tagesablauf als Senior DevOps and Tech Lead gibt es nichts Besonderes. Meine Arbeit sollte langweilig sein, aber manchmal stolpere ich über Störungen und Unvollkommenheiten, die mich dazu anregen, dem Problem auf die Spur zu kommen und es zu lösen. Ja, manchmal muss man ein Problem finden, bevor man es löst.
Beim Durchsuchen der Berichte über den Projektstatus in Cloudflare sah ich eine unglaubliche Anzahl von 408 Fehlern auf der Website, etwa 20 Millionen in den letzten 24 Stunden. Darauf wurde ich neugierig.
Das war viel zu viel, vor allem, wenn unsere Infrastruktur durch andere Arten von Ausfällen überlaufen würde, wenn mindestens 1/10.000 dieser 408 Fehler auftreten würden. Da wir die Daten nicht direkt von der Website, sondern über Cloudflare erhalten, dachte ich, ich sollte mir diesen Fall genauer ansehen. Der Punkt, den ich lösen musste: Sollte ich mir Sorgen um die Cloudflare-Zahlen machen, wenn auf der Infrastrukturseite alles in Ordnung wäre? Wie kann ich wirklich zuverlässige Statistiken zu unserer Fehlerprotokollierung erhalten? Gibt es ein besseres Tool, um das zu verfolgen?
Spoiler: Natürlich gab es ein besseres Instrument für die Fehlerverfolgung, da die „Fehler“ von Cloudflare nicht das sind, was sie sein sollten. Und ich werde es dir jetzt beweisen.
Wie Sie vielleicht wissen, ist Cloudflare Analytics eine Webanalyseplattform, die in Echtzeit Einblicke in Traffic, Seitenaufrufe und Besucherverhalten bietet. Sie sammelt Daten mit einer Vielzahl von Methoden, darunter JavaScript-Tags, Web Beacons und Serverprotokolle. Cloudflare Analytics bietet eine Fülle von Informationen zur Leistung von Websites, einschließlich Seitenladezeiten, Absprungraten und Konversionsraten. Es ermöglicht Benutzern auch, spezifische Metriken zu untersuchen, um einen detaillierteren Überblick über die Leistung der Website zu erhalten. In der Regel reicht das aus, damit sich der Webseitenbesitzer ein allgemeines Bild davon machen kann, was vor sich geht.
Cloudflare verwendet eine Vielzahl von Methoden, darunter Real User Monitoring (RUM), synthetisches Monitoring und serverseitiges Monitoring. RUM beinhaltet die Verfolgung von Benutzerinteraktionen mit einer Website in Echtzeit mithilfe von JavaScript-Tags oder Browser-Plugins. Bei der synthetischen Überwachung werden Benutzerinteraktionen mit einer Website von verschiedenen Standorten und Geräten aus simuliert. Bei der serverseitigen Überwachung werden serverseitige Fehler und Leistungskennzahlen wie Antwortzeiten und Serververfügbarkeit verfolgt. Bei diesen Methoden wird sowohl die Verarbeitung von Daten als auch die Arbeit mit Rohereignissen vorausgesetzt.
408-Fehler werden in der Regel durch Netzwerk-Timeouts verursacht, die auftreten, wenn ein Server zu lange braucht, um auf eine Anfrage eines Clients zu antworten. Diese Fehler können durch eine Vielzahl von Faktoren verursacht werden, darunter langsame Netzwerkverbindungen, Serverüberlastung oder schlecht optimierter Code. In unserem Fall haben wir die Infrastruktur dieses Projekts schon früher optimiert, sodass alle Hauptfaktoren von den Ursachen des Auftretens ausgeschlossen wurden.
Eine mögliche Erklärung dafür, warum Cloudflare mehr 408-Fehler meldet, ist, dass es empfindlicher auf Netzwerk-Timeouts reagiert als andere Protokollierungssysteme. Es verwendet ein globales Netzwerk von Servern und Rechenzentren, um Daten von einer Vielzahl von Standorten und Geräten zu sammeln. Dieses System erkennt möglicherweise Netzwerk-Timeouts, die an entfernten oder schlecht verbundenen Standorten auftreten, mit größerer Wahrscheinlichkeit. Andere Protokollierungssysteme reagieren möglicherweise nicht so empfindlich auf diese Art von Fehlern, oder sie sind möglicherweise so konfiguriert, dass sie sie ignorieren.
Eine andere mögliche Erklärung ist, dass Cloudflare alle 408 Fehler meldet, während andere Logging-Systeme möglicherweise einige dieser Fehler herausfiltern. Beispielsweise können einige Protokollierungssysteme so konfiguriert sein, dass 408-Fehler ausgeschlossen werden, die in Zeiten mit hohem Traffic oder Serverüberlastung auftreten, da diese Fehler unter diesen Umständen als „erwartet“ oder „normal“ angesehen werden können. Cloudflare hingegen kann alle 408 Fehler melden, unabhängig davon, in welchem Kontext sie auftreten.
Es ist auch erwähnenswert, dass die Anzahl der gemeldeten 408 Fehler durch Faktoren wie Website-Verkehr, Serverlast und Netzwerkbedingungen beeinflusst werden kann. Beispielsweise kann es bei einer Website mit hohem Traffic wahrscheinlicher sein, dass 408 Fehler auftreten, da der Server möglicherweise überlastet ist oder nicht in der Lage ist, mit eingehenden Anfragen Schritt zu halten. Ebenso kann es bei einer Website, die auf einem langsamen oder schlecht verbundenen Server gehostet wird, mit höherer Wahrscheinlichkeit zu Netzwerk-Timeouts und 408-Fehlern kommen.
Jeder dieser Gründe könnte uns die Wahrheit entziehen. Deshalb haben wir uns entschlossen, nach einer anderen Lösung für die Fehlerverfolgung zu suchen, und haben zum Zeitpunkt der Entscheidungsfindung die zuverlässigste von allen gefunden.
Netzwerkfehlerprotokollierung (NEL) ist ein neuer HTTP-Header, mit dem Netzwerkfehler auf Websites protokolliert und analysiert werden können. NEL kann verwendet werden, um Netzwerkfehler wie fehlgeschlagene Anfragen, DNS-Auflösungsfehler und Verbindungstimeouts zu überwachen und Probleme, die zu einer schlechten Benutzererfahrung und Umsatzeinbußen führen können, schnell zu diagnostizieren und zu beheben. Es ist ein einfach zu erstellendes, quelloffenes und zuverlässiges Tool — jedes Merkmal entspricht meinem DevOps-Geschmack.
Die NEL-Spezifikation ist ein W3C-Standard, der definiert, wie Webbrowser mit dem NEL-Header umgehen sollen. Der NEL-Header konfiguriert einen Client (Browser) so, dass er Netzwerkberichte [Fehler] an den von Report-To bereitgestellten Header-Endpunkt sendet. Es ist wie ein Link zu einem Feedback-Formular, in dem jeder Benutzer einige Gedanken zu der Website hinterlassen kann. Aber es ist für automatische Berichte gedacht.
Projekte können auf verschiedene Weise von NEL profitieren. Durch die Überwachung von Netzwerkfehlern können Entwickler schnell Probleme identifizieren und beheben, die zu einer schlechten Benutzererfahrung oder zu Umsatzeinbußen führen können. Sie können NEL-Daten auch verwenden, um Trends beim Auftreten von Fehlern zu erkennen und ihre Websites oder Anwendungen zu optimieren, um die Häufigkeit von Fehlern zu reduzieren.
Einer der Hauptvorteile von NEL besteht darin, dass Webentwickler umfassendere Daten zu Netzwerkfehlern sammeln können. Traditionell verließen sich Entwickler bei der Diagnose von Netzwerkfehlern auf die clientseitige Fehlerprotokollierung oder auf serverseitige Protokolle. Diese Methoden konnten jedoch häufig nicht alle Fehler erfassen. Mit NEL können Entwickler Fehler erkennen, die auf der Client- und Serverseite auftreten, und sie können diese Informationen verwenden, um Muster und Trends beim Auftreten von Fehlern zu identifizieren.
Ein weiterer Vorteil von NEL besteht darin, dass es ein Standardformat für die Protokollierung von Netzwerkfehlern bietet, das es Entwicklern erleichtert, Daten aus verschiedenen Quellen zu analysieren und zu vergleichen. Dies kann besonders für große Projekte mit vielen Entwicklern oder für Unternehmen mit mehreren Websites oder Anwendungen nützlich sein.
Um NEL verwenden zu können, müssen Webentwickler den NEL-Header in ihre HTTP-Antworten aufnehmen. Der Header enthält eine URI, die auf einen Berichtsendpunkt verweist, an den der Browser das JSON-Objekt sendet, das den Netzwerkfehler beschreibt. Entwickler können diese Informationen dann verwenden, um Netzwerkfehler zu analysieren und zu diagnostizieren.
Eine der Herausforderungen bei der Verwendung von NEL besteht darin, dass ein Backend-System erforderlich ist, um die Fehlerberichte zu verarbeiten und zu speichern. Entwickler müssen einen Berichtsendpunkt einrichten, der die Fehlerberichte verarbeiten und speichern kann, und sie benötigen ein System, um die Daten zu analysieren und darauf zu reagieren.
Mit NEL können Sie schnell Probleme diagnostizieren und beheben, die zu einer schlechten Benutzererfahrung und Umsatzeinbußen führen können, und Ihre Projekte optimieren, um die Häufigkeit von Fehlern im Laufe der Zeit zu reduzieren. Und in unserem Fall brauchten wir NEL, um das Bild von 408 Fehlern von Cloudflare gegenüberzustellen und eine einzige Wahrheit zu finden, auf die wir uns verlassen konnten.
Nachdem wir NEL implementiert haben, bekommen wir mit Sicherheit ein viel realistischeres Bild davon, was vor sich ging. Außerdem haben wir dem Kunden diese Lösung vorgestellt und erneut Applaus bekommen.
Die NEL Grafana berichtete, dass alles ruhig und sauber verlief, mit rund 400 Fehlern, die an einer Infrastruktur mit 800 Millionen Anfragen pro Tag nichts änderten.
Die letzten zwei Tage haben uns die richtige Anzahl von Fehlern gezeigt, die vertrauenswürdig sein können, da wir sie direkt von der Website erhalten, nicht über den Drittanbieter.
Diese kleine Geschichte zeigt uns, wie wichtig es ist, die Zwecke unserer Instrumente zu verstehen, anstatt sie blind und gedankenlos zu benutzen. Eine weitere Lektion, die Sie daraus lernen können, ist, dass die Lösung selbst für das gefährlichste Problem ein einfaches und oberflächliches Werkzeug sein könnte, nicht irgendein Heiliger Gral.
Wir schätzen NEL für den Start, die Erklärbarkeit und die Zuverlässigkeit. Diese Funktionen gefallen uns an all unseren Lösungen. Das ist der wahre Weg für effizientes Tracking und Analytik — vermeiden Sie Blackbox-Lösungen und geschlossene Drittanbieter-Lösungen und halten Sie sich an transparente und offene Instrumente.
Und Sie werden so ruhig sein wie professionelle DevOps.
.jpg)
.jpg)
