Wenn Ihr API-Monitoring auf einem Server in einem Rechenzentrum läuft, sehen Sie nur einen Teil des Bildes. Ein Benutzer aus Brasilien kann einen 500-Fehler erhalten, während Ihr Dashboard in Moskau den grünen Status „Alles funktioniert“ anzeigt. Lassen Sie uns untersuchen, welche 5 Verfügbarkeitsmetriken ohne eine Anfrage über eine echte externe IP eines anderen Landes nicht gemessen werden können und wie Sie dies ohne komplexe Infrastruktur tun können.
Warum lokales Monitoring täuscht
Die meisten Teams richten das API-Monitoring über UptimeRobot, Pingdom oder ein eigenes Cron-Skript ein, das einmal pro Minute an den Endpunkt anfragt. Das Problem ist, dass diese Anfragen fast immer aus ein oder zwei Regionen kommen – normalerweise aus den USA oder Europa, wo die Server der Monitoring-Dienste stehen. Wenn Ihre Zielgruppe in Indien, Brasilien oder Südostasien ist, können lokale Anbieter den Datenverkehr drosseln, ein CDN-Knoten kann überlastet sein und DNS kann auf eine veraltete IP auflösen.
Ein weiteres häufiges Szenario ist das Geo-Blocking auf CDN- oder WAF-Ebene (Cloudflare, Akamai). Einige Sicherheitsregeln blockieren ganze IP-Bereiche aus bestimmten Ländern, und Ihr API ist physisch für einen Teil der Benutzer nicht zugänglich, während es von Ihrer Büro-IP aus perfekt funktioniert. Solche Probleme sind nicht zu diagnostizieren, wenn nur von einem Punkt aus getestet wird.
Ein drittes Szenario ist die Lastverteilung über Anycast oder regionale CDN-Edges. Eine Anfrage aus Deutschland kann auf einen Knoten gelangen, während eine aus Singapur auf einen völlig anderen, mit einer anderen Cache-Version oder Konfiguration, gelangt. Der Unterschied im Verhalten des APIs zwischen den Regionen ist keine Theorie, sondern etwas, mit dem Teams regelmäßig konfrontiert sind, deren Benutzer weltweit verteilt sind.
5 Verfügbarkeitsmetriken, die nur über eine externe IP sichtbar sind
Im Folgenden sind fünf Metriken aufgeführt, die nur dann ein realistisches Bild der Verfügbarkeit zeigen, wenn die Anfrage von einer IP-Adresse ausgeführt wird, die sich physisch im Zielgebiet befindet oder zumindest über dessen Netzwerk geroutet wird.
1. Antwortzeit (Latenz / RTT)
Die Round-Trip Time ist die Zeit vom Senden der Anfrage bis zum Erhalt des ersten Antwortpakets. Von einem Server in Europa kann die Latenz zu Ihrem API 20 ms betragen, während ein Benutzer aus Südostasien 400-600 ms warten muss, aufgrund der geografischen Entfernung und der Anzahl der Zwischenknoten (Hops). Wenn die Latenz nicht aus verschiedenen Regionen gemessen wird, kann leicht übersehen werden, wann der Dienst für einen Teil der Zielgruppe praktisch unbrauchbar wird – besonders kritisch für APIs, die auf Echtzeitoperationen angewiesen sind: Bietverfahren in der Werbung, Chats, Fintech-Transaktionen.
2. TTFB (Time To First Byte)
TTFB zeigt, wie lange der Server benötigt, um die Anfrage zu verarbeiten, bevor er mit dem Senden der Antwort beginnt. Diese Metrik hängt nicht nur vom Netzwerk ab, sondern auch davon, welcher Knoten des CDN oder des Load Balancers die spezifische Region bedient. Es kommt häufig vor, dass ein Edge-Server in einem Land die Antwort zwischenspeichert und sie in 50 ms liefert, während in einem anderen Land die Anfrage jedes Mal den Origin-Server erreicht und neu verarbeitet wird, was 800 ms oder mehr in Anspruch nimmt. Der Unterschied im TTFB zwischen den Regionen ist ein sicheres Zeichen für Probleme mit der CDN-Konfiguration oder unzureichender Abdeckung durch Edge-Knoten.
3. DNS-Resolver-Zeit
DNS-Resolving ist eine separate Quelle für Verzögerungen und Fehler, die vollständig vom lokalen Resolver des Benutzers abhängt. Wenn Sie GeoDNS eingerichtet haben (verschiedene A-Records abhängig von der Anfrage-Region), kann ein Fehler in der Konfiguration dazu führen, dass Benutzer aus einem Land auf ein Rechenzentrum auf einem anderen Kontinent aufgelöst werden – mit enormen Verzögerungen. Dieses Problem ist nur sichtbar, wenn die DNS-Resolver-Anfrage von einer realen IP des Ziellandes kommt; ein lokaler Test wird immer „richtig“ in Bezug auf Ihre eigene Geoposition aufgelöst.
4. Prozentsatz erfolgreicher Anfragen (Uptime) nach Regionen
Eine Uptime von 99,9 % auf dem Monitoring-Dashboard, das von einem Punkt aus anfragt, garantiert keine 99,9 % für Benutzer in einem anderen Land. Lokale Anbieter können Probleme mit dem Peering speziell zu Ihrem Hosting-Anbieter haben, was dazu führt, dass ein Teil der Anfragen aus Land X aufgrund von Zeitüberschreitungen fehlschlägt, während der Rest der Welt das Problem überhaupt nicht bemerkt. Um die tatsächliche Uptime zu sehen, müssen erfolgreiche und nicht erfolgreiche Anfragen separat für jede Region gezählt werden, nicht aggregiert.
5. Unterschiede in Inhalten und Statuscodes (Geo-Blocking und Personalisierung)
Die fünfte Metrik bezieht sich nicht auf die Geschwindigkeit, sondern auf den Inhalt der Antwort selbst. APIs können für bestimmte Länder 403 Forbidden zurückgeben aufgrund von WAF-Regeln, einen reduzierten Datensatz aufgrund von Lizenzbeschränkungen zurückgeben oder eine andere Version des Inhalts aufgrund von A/B-Tests zeigen, die an Geos gebunden sind. Wenn das API nur von Ihrer IP getestet wird, bleiben solche Unterschiede völlig unbemerkt – und genau diese sind oft die Ursache für Beschwerden von Benutzern aus bestimmten Regionen.
Wichtig zu verstehen
Alle fünf Metriken erfordern eine Anfrage von einer IP, die tatsächlich über das Netzwerk des Ziellandes geroutet wird. Ein VPN mit einem einzigen Server im Land oder ein Cloud-Server in derselben Region gibt ein ungefähres Bild, zeigt jedoch nicht, wie der Endbenutzer den Dienst mit einem bestimmten Anbieter und dessen Routen zu Ihrem API sieht.
Wie man Monitoring aus verschiedenen Ländern einrichtet
Die Logik der Einrichtung ist einfach: Sie senden dieselbe HTTP-Anfrage an Ihr API von mehreren Punkten gleichzeitig, erfassen alle fünf Metriken und vergleichen die Ergebnisse. Schritt für Schritt sieht das so aus:
- Erstellen Sie eine Liste der priorisierten Länder – normalerweise die Top 5 Länder nach Verkehrsaufkommen oder Umsatz.
- Für jedes Land bereiten Sie einen Ausgangspunkt mit einer realen IP dieses Landes vor (Proxy-Server oder physischer Server).
- Richten Sie ein Skript oder einen Dienst ein, der identische Anfragen über jeden Punkt mit einem festgelegten Intervall sendet (z. B. alle 5 Minuten).
- Protokollieren Sie alle 5 Metriken separat für jedes Land in einer Datenbank oder einem Metriksystem (Grafana, Prometheus, ClickHouse).
- Richten Sie Alarme für Abweichungen der Metriken vom Basisniveau ein – z. B. wenn die Latenz aus einem bestimmten Land innerhalb einer Stunde um das Dreifache gestiegen ist.
Der Schlüsselpunkt ist Punkt 2. Ohne einen realen Ausgangspunkt im gewünschten Land sind alle anderen Schritte sinnlos, da die Metriken nicht das messen, was der Benutzer sieht, sondern das, was Ihr eigener Monitoring-Server sieht.
Welchen Proxy-Typ für das Monitoring wählen
Für den Aufbau eines geografisch verteilten Monitorings werden häufig Proxy-Server verwendet – dies ist günstiger und schneller, als physische Server oder VPS in jedem benötigten Land zu mieten. Die Wahl des Proxy-Typs hängt davon ab, was genau Sie messen möchten.
| Proxy-Typ | Wann verwenden | Besonderheiten |
|---|---|---|
| Rechenzentrums-Proxys | Basisverfügbarkeit und Latenzprüfung, wenn keine Simulation eines echten Benutzers erforderlich ist | Hohe Geschwindigkeit, niedriger Preis, aber IP wird leicht als Rechenzentrums-IP identifiziert – nicht geeignet für Geo-Blocking-Tests nach Anbietern |
| Residential Proxys | Überprüfung dessen, was ein echter Benutzer mit einem Heimprovider sieht | IP gehört zu echten Anbietern in einem bestimmten Land, spiegelt die Routen und WAF-Regeln genauer wider |
| Mobile Proxys | Test der API-Verfügbarkeit für mobile Anwendungen und mobilen Datenverkehr | IP aus Mobilfunknetzen, zeigt Verzögerungen und Blockierungen, die spezifisch für mobilen Datenverkehr sind |
Wenn Ihr API hauptsächlich Web-Traffic von Desktops und Servern bedient, sind Rechenzentrums-Proxys für den Aufbau eines grundlegenden Monitorings ausreichend – sie bieten stabile Geschwindigkeiten und vorhersehbare Latenzen. Wenn Sie jedoch genau das überprüfen müssen, was der echte Benutzer sieht – einschließlich der Geo-Blocking-Regeln, die nach ASN des Anbieters eingerichtet sind – sollten Sie Residential Proxys verwenden, da diese über die Netzwerke gewöhnlicher Internetanbieter desselben Landes geroutet werden. Für mobile Anwendungen und SDKs, die Anfragen an das API stellen, ist es sinnvoll, auch Tests über mobile Proxys hinzuzufügen, da Mobilfunkanbieter häufig NAT und ihre eigenen Routing-Regeln verwenden, die sich von denen des Heim-Internets unterscheiden.
Fertiges Python-Skript zur Erfassung von Metriken
Im Folgenden finden Sie ein vereinfachtes Beispiel eines Skripts, das eine Anfrage über einen Proxy im angegebenen Land sendet und vier der fünf Metriken erfasst (Unterschiede im Inhalt müssen separat verglichen werden, indem die Antworten abgeglichen werden). Das Skript verwendet die Bibliothek requests und das Modul socket zur Messung der DNS-Resolver-Zeit.
import time
import socket
import requests
def measure_api(url, proxy, country_label):
hostname = url.split("//")[1].split("/")[0]
# 1. DNS-Resolver-Zeit
dns_start = time.time()
try:
socket.gethostbyname(hostname)
except socket.gaierror:
pass
dns_time = time.time() - dns_start
proxies = {
"http": proxy,
"https": proxy,
}
try:
start = time.time()
response = requests.get(
url,
proxies=proxies,
timeout=10,
stream=True
)
ttfb = time.time() - start # angenäherter TTFB
full_load_time = time.time() - start
status_code = response.status_code
success = status_code == 200
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": round(ttfb * 1000, 2),
"total_time_ms": round(full_load_time * 1000, 2),
"status_code": status_code,
"success": success,
}
except requests.exceptions.RequestException as e:
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": None,
"total_time_ms": None,
"status_code": None,
"success": False,
"error": str(e),
}
return result
# Beispielverwendung mit Proxys aus verschiedenen Ländern
endpoints = [
{"label": "Deutschland", "proxy": "http://user:[email protected]:port"},
{"label": "Brasilien", "proxy": "http://user:[email protected]:port"},
{"label": "Singapur", "proxy": "http://user:[email protected]:port"},
]
API_URL = "https://api.yourservice.com/health"
for ep in endpoints:
data = measure_api(API_URL, ep["proxy"], ep["label"])
print(data)
Für die Produktionsversion eines solchen Skripts sollten Sie die Ergebnisse in einer Datenbank (z. B. ClickHouse oder InfluxDB) speichern, eine Visualisierung über Grafana hinzufügen und Alarme über einen Telegram-Bot oder Slack-Webhook bei Überschreitung von Schwellenwerten einrichten. Es ist besser, das Skript über Cron oder einen Task-Planer mit einem Intervall von 5-15 Minuten für jedes Land auszuführen.
Wenn Sie eine schnelle Überprüfung ohne Programmierung benötigen, kann eine ähnliche Anfrage über cURL mit Zeitmessung durchgeführt werden:
curl -x http://user:[email protected]:port \
-o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
https://api.yourservice.com/healthWie man die Ergebnisse interpretiert
Nach der Erfassung von Daten aus allen Ländern über mindestens eine Woche hinweg entsteht ein Basisniveau (Baseline) für jede Region. Danach sollten Sie nicht auf die absoluten Zahlen achten, sondern auf Abweichungen von dieser Baseline. Wenn die Latenz aus Brasilien stabil bei 350 ms liegt – das ist für die Geografie normal, und Alarm sollte geschlagen werden, wenn der Wert plötzlich auf 1500 ms ansteigt. Ähnlich bei der Uptime: 99,5 % für eine komplexe Region mit instabilem Internet kann eine akzeptable Norm sein, während ein Rückgang auf 95 % bereits ein Signal für ein Problem beim Anbieter oder CDN sein könnte.
Besonderes Augenmerk sollte auf die Statuscodes 403 und 451 gelegt werden – diese weisen fast immer auf Geo-Blocking seitens WAF oder CDN hin, nicht auf ein Problem mit dem API selbst. Wenn solche Codes nur aus einem bestimmten Land und nur bei Verwendung eines bestimmten Proxytyps (z. B. Rechenzentrums-Proxys) auftreten, kann dies bedeuten, dass die Blockierung nach dem Kriterium „IP sieht aus wie ein Rechenzentrum“ und nicht nach der tatsächlichen Geolokalisierung eingerichtet ist – in diesem Fall wird ein Test mit Residential Proxys ein ehrlicheres Bild liefern.
Fertige Dienste vs. Eigenentwicklung
Wenn Sie kein eigenes Skript pflegen möchten, gibt es auf dem Markt fertige Dienste für synthetisches Monitoring mit Präsenzpunkten in verschiedenen Ländern: Pingdom, Uptrends, Site24x7, Checkly. Sie befreien von der Notwendigkeit, Infrastruktur einzurichten, sind jedoch in der Regel auf eine feste Anzahl von Standorten beschränkt und bieten keine Flexibilität bei der Auswahl des IP-Typs (residential, mobile, data center) für einen bestimmten Test.
Eine Eigenentwicklung auf Basis von Proxys bietet mehr Kontrolle: Sie können genau die Länder testen, die für Ihr Geschäft wichtig sind, zwischen IP-Typen für die Diagnose spezifischer Probleme (z. B. Geo-Blocking nach ASN) wechseln und Metriken direkt in Ihr Monitoring-System integrieren, ohne unnötige Zwischenhändler. Eine Kombination beider Ansätze ist ein vernünftiger Kompromiss: Fertige Dienste für grundlegendes SLA-Monitoring, eigenes Skript mit Proxys für gezielte Diagnosen von Problemen in bestimmten Regionen.
Fazit
Lokales Monitoring von einem Punkt zeigt nur einen Teil der Wahrheit über die Verfügbarkeit des APIs. Um ein realistisches Bild zu sehen, müssen Latenz, TTFB, DNS-Resolver-Zeit, Uptime und Unterschiede im Inhalt separat für jedes Land gemessen werden – und dies über eine IP, die tatsächlich über das Netzwerk der Zielregion geroutet wird. Ohne dies können Probleme übersehen werden, die einen Teil der Benutzer daran hindern, den Dienst zu nutzen, während das Dashboard „alles grün“ anzeigt.
Für den Aufbau eines solchen Monitorings sind Residential Proxys am besten geeignet, wenn es wichtig ist, dass das, was der echte Benutzer mit einem Heim-Internet in einem bestimmten Land sieht, sichtbar wird. Für eine günstigere und schnellere grundlegende Verfügbarkeitsprüfung sind Rechenzentrums-Proxys ausreichend, und zur Diagnose von Problemen bei der mobilen Zielgruppe sollte die Überprüfung über mobile Proxys hinzugefügt werden. Ein solcher kombinierter Ansatz bietet ein vollständiges Bild davon, wie Ihr API aus jedem Punkt der Welt aussieht und nicht nur aus dem Serverraum, in dem es bereitgestellt ist.