Einführung
Die meisten zukunftsorientierten Unternehmen arbeiten heute in einer API-first-Umgebung, in der Anwendungen keine eigenständigen Einheiten sind, sondern miteinander verbundene Netze von Microservices. Mit dieser Veränderung haben sich die API-Zustandsprüfungen von einfachen Endpunkt-Pings zu einer facettenreichen Beobachtungsmöglichkeit entwickelt. Unternehmen können einen reaktiven Überwachungsansatz wählen und Probleme beheben, sobald sie auftauchen, oder in eine proaktive Strategie investieren, die durch erweiterte Überwachungssignale und OpenTelemetry-Unterstützung unterstützt wird.
Der reaktive Weg ist oft die Basis. Sofort einsatzbereite Lösungen, die von modernen Überwachungsplattformen unterstützt werden, bieten jedoch eine ganzheitlichere Präventionsstrategie. Um diese Tools optimal zu nutzen, müssen jedoch mehrere Faktoren berücksichtigt werden.
In diesem Artikel befassen wir uns mit den wichtigsten Funktionen von API-Überwachungstools, warum sie wichtig sind und wie sie Ihre allgemeine Überwachungsstrategie unterstützen können.
Die acht unverzichtbaren Funktionen moderner API-Überwachungstools
Die folgende Tabelle fasst die acht wichtigsten Funktionen zusammen, die DevOps-Ingenieure von modernen API-Überwachungstools erwarten. Beachten Sie, dass grundlegende Funktionen, die von jedem Überwachungstool erwartet werden, wie z. B. Dashboards, Berichte und Alarme, nicht in dieser Liste enthalten sind, da wir sie als Standard voraussetzen.
API-Beobachtungssignale
Die Beobachtung von APIs versetzt Teams in die Lage, die Leistung aller API-Typen - privat, partnerschaftlich oder öffentlich - zu maximieren. Wesentlich dafür sind Beobachtungssignale - Metriken, Ereignisse, Protokolle und Traces -, die zusammen ein differenziertes Verständnis des API-Verhaltens ermöglichen.
Jede der vier Telemetriearten ist für sich genommen wertvoll; ihre gemeinsame Analyse liefert jedoch einen ganzheitlichen Überblick über den Zustand und die Leistung der API.
Spurensuche
Traces bilden den Transaktionsverlauf Ihres Systems ab und bieten tiefe Einblicke in das Verhalten Ihrer API-Endpunkte, indem einzelne API-Aufrufe mit bestimmten Aktionen verknüpft werden. Stellen Sie sich vor, ein Anstieg des Benutzerverkehrs löst eine automatische Pod-Skalierung in Kubernetes aus. Die Ablaufverfolgung zeigt, wie sich die Anfrage durch den Load Balancer, den API-Server und dann zu den neu erstellten Pod-Instanzen bewegt und hilft schließlich dabei, Latenz oder Fehler bei der automatischen Skalierung zu identifizieren.
Ein einzelner Trace besteht aus mehreren Spans, die sich jeweils über verschiedene Microservices oder Systemkomponenten erstrecken. Um dies besser zu verstehen, betrachten Sie jeden Vorgang als einen Span und eine Sammlung von Spans als eine Spur.
Achten Sie bei der Bewertung von API-Überwachungslösungen auf die Ausgereiftheit und Flexibilität ihrer Ablaufverfolgungsfunktionen. Bei der erweiterten Ablaufverfolgung kann jeder Bereich auch Kontext einbetten, z. B. die aufgerufenen SQL-Abfragen oder den Zustand des CPU-Cache. Diese Spans sind mit Metriken und Protokollen verknüpft, so dass ein umfassendes Trace-Diagramm entsteht. Vergewissern Sie sich, dass die Visualisierungsfunktionen des Tools diese Daten nutzen, um Service-Interaktionen genau abzubilden und so potenzielle Engpässe und Service-Ineffizienzen aufzuzeigen. Vergewissern Sie sich, dass die Tracing-Lösung alle Programmiersprachen und Datenbanktechnologien unterstützt, die in Ihrem Anwendungsstapel verwendet werden, um blinde Flecken zu vermeiden und ein originalgetreues Tracing zu liefern. Eine ausführlichere Erklärung von Spans und Traces wird im nächsten Abschnitt gegeben.
Metriken
Metriken werden in bestimmten Intervallen - von Millisekunden bis Stunden - gemessen oder gesammelt, um den Zustand der API zu erfassen. Sie können auch die Echtzeit-Telemetrie jeder Anfrage sein, wie z. B. die Verbindungszeit zu einem bestimmten API-Endpunkt. Dieser duale Ansatz ermöglicht sowohl eine Momentaufnahme als auch eine kontinuierliche Ansicht und bietet die umfassendste Darstellung der Leistung Ihrer API. Sie werden oft in Kategorien unterteilt, um eine differenzierte Analyse zu ermöglichen, die Ihnen hilft, sowohl das Was als auch das Warum zu beurteilen.
Das Aggregieren ist immer eine Option, aber das Deaggregieren von Durchschnittswerten liefert nur Näherungswerte. Je mehr Rohdaten erfasst werden, desto höher ist die Auflösung Ihrer Analyse. Während Sie mit Stichproben eine ungefähre Grundgesamtheit erhalten, ermöglicht die Erfassung der Leistungskennzahlen jeder einzelnen Anfrage eine genaue Bewertung von Augenblick zu Augenblick.
Beispielsweise können einige der in der nachstehenden Tabelle aufgeführten Metriken die Leistung einer API direkt/indirekt beeinflussen.
{{banner-28="/design/banners"}}
Sobald Sie die Metriken zur Hand haben, besteht der nächste logische Schritt darin, diese disparaten Metriken in besser handhabbaren und aufschlussreichen Formen zu konsolidieren. Der Einsatz von Aggregationsmethoden verfeinert die Rohdatenpunkte, um spezifische Leistungsfragen zu beantworten. Einige Standard-Aggregationsmethoden sind:
- Summe: Addiert alle Werte. Hilfreich beim Zählen der gesamten API-Aufrufe.
- Durchschnitt: Der Mittelwert aller metrischen Werte. Bietet einen ausgewogenen Überblick, ist aber anfällig für Ausreißer.
- Median: Der mittlere Wert (entspricht dem 50. Perzentil). Ergibt eine stabilere zentrale Tendenz als Durchschnittswerte.
- Perzentile: Zeigt einen Bereich an, in den ein bestimmter Prozentsatz der beobachteten Werte fällt. Hilft dabei, Ausreißer und das Systemverhalten bei unterschiedlichen Belastungen zu verstehen.
Die Verwendung von Histogrammen zusammen mit Aggregationsmethoden kann Ihrer API-Überwachung eine weitere Ebene der Granularität hinzufügen. Ein Histogramm gruppiert Datenpunkte in Bereiche oder "Bins" und bietet eine Ansicht der Häufigkeitsverteilung. Wenn Sie beispielsweise die Latenzzeit betrachten, könnte ein Perzentil zeigen, dass die meisten Ihrer Anfragen schnell sind, aber ein Histogramm zeigt eine kleine, aber signifikante Anzahl von sehr langsamen Anfragen, die untersucht werden müssen.
Die Ausgereiftheit des Tools bei der Verwaltung von Metriken, der Anwendung verschiedener Aggregationsmethoden und der Nutzung von Histogrammen sollte ein entscheidender Faktor bei Ihrer Auswahl sein.
Protokolle
Protokolle bieten granulare Details, die erschöpfend sind. Ein Standard-API-Protokolleintrag kann beispielsweise die Anforderungs-ID, die aufgerufene serverlose Berechnungsfunktion (z. B. AWS Lambda), die Cache-Hit/Miss-Rate und sogar relevante Datenbankabfragen enthalten. Eine solche Granularität hilft bei der Korrelation von Ereignisprotokollen und einer präzisen Sicherheitsbewertung.
Prüfen Sie bei der Bewertung eines API-Überwachungstools, ob es eine zentralisierte Protokollaggregation bietet. Diese Funktion vereinheitlicht Protokolle über Ihre API-Gateways, Endpunkte und Dienstebenen hinweg. Sie ermöglicht es Ihnen, den Weg eines einzelnen API-Aufrufs über mehrere Dienste hinweg zu verfolgen, was die Fehlersuche vereinfacht und die Lösung von Problemen beschleunigt. Die Zentralisierung kontextbezogener Daten hilft auch bei der Unterscheidung zwischen API-spezifischen Problemen und allgemeineren systemischen Problemen.
Betrachten Sie zum Beispiel die folgenden Protokolleinträge:
Fehler bei der Dienstabhängigkeit
Die obige Abbildung zeigt einen Fehler, der in einem abhängigen Dienst bei der Verarbeitung einer GET-Anfrage aufgetreten ist. Zentralisierte Protokolle können schnell einen Einblick in kaskadierende Fehler und deren Auswirkungen auf Ihre API geben.
Raten-Limit überschritten
Eine Anfrage an /api/v1/trekkers hat das Ratenlimit überschritten. Mit zentralisierten Protokollen können Sie schnell feststellen, wer für die übermäßigen Anrufe verantwortlich ist, und Abhilfemaßnahmen ergreifen.
Es ist erwähnenswert, dass die Speicherung von Protokollen aufgrund ihres schieren Speicherbedarfs mit hohen Kosten verbunden ist. Ein häufiger Fehler ist es, alle Arten von Protokollen von allen Geräten zu jeder Zeit zu sammeln, während ein strategischerer Ansatz darin besteht, Protokolle nach ihrem Wert für die Fehlerbehebung und ihrer Relevanz für Produktionsumgebungen auszuwählen.
{{banner-29="/design/banners"}}
Mehrstufige Tests
Herkömmliche Tests prüfen meist isolierte Endpunkte. Achten Sie bei der Auswahl eines API-Überwachungstools auf dessen Fähigkeit, mehrstufige Lasttests zu implementieren, die reale Interaktionen und nicht nur isolierte Aufrufe simulieren, um die Funktionsfähigkeit einer API sicherzustellen.
Eine umfassende API-Teststrategie würde die meisten (wenn nicht alle) der folgenden Anwendungsfälle umfassen:
Sichere und vielfältige Authentifizierungsmethoden
GewährleistenSie die Effizienz Ihrer API in verschiedenen Sicherheitskontexten. Achten Sie auf die Unterstützung virtueller Benutzer und verschiedener Authentifizierungsmethoden wie OAuth oder JWT, um komplexe Systemanforderungen zu replizieren. Der mehrstufige Test muss diese unterschiedlichen Authentifizierungsmechanismen unterstützen, um reale Nutzererfahrungen genau nachzubilden.
Konsistenz über geografische Standorte hinweg
Um die globale Zuverlässigkeit einer API zu gewährleisten, sollten mehrstufige Tests von verschiedenen geografischen Standorten aus durchgeführt werden. So wird sichergestellt, dass jeder Nutzer das gleiche Serviceniveau erhält, unabhängig davon, von wo aus er sich verbindet.
Angebot für verschiedene Benutzerplattformen
Auf APIs wird über eine Vielzahl von Clients zugegriffen, von mobilen Anwendungen bis hin zu Desktop-Browsern. Mehrstufige Tests sollten dieser Vielfalt Rechnung tragen und die Möglichkeit bieten, Interaktionen über diese verschiedenen Plattformen hinweg zu emulieren und ein umfassenderes Bild der Gesamtleistung der API zu erfassen.
Überwachung des gesamten Transaktionspfads
Ein großes Versäumnis bei der API-Überwachung ist der enge Fokus auf Komponenten, die innerhalb der Grenzen des Netzwerks eines Unternehmens liegen. Bedenken Sie, dass APIs in der Regel auf mehrere externe Berührungspunkte angewiesen sind, darunter Dienste von Drittanbietern und verschiedene Elemente im öffentlichen Internet, um eine Transaktion abzuschließen.
Ziehen Sie Überwachungstools in Betracht, mit denen Sie den gesamten Transaktionspfad und den Einfluss des öffentlichen Internets und verschiedener Drittanbieterkomponenten auf Ihre API-Antwortzeiten analysieren können.
Synthetische und reale Benutzerüberwachung (RUM): Simulation und Überprüfung der Realität
Wir haben bereits Überwachungstechniken wie die Ablaufverfolgung erörtert, die dabei helfen, Probleme entlang des Transaktionspfads zu isolieren. In diesem Abschnitt werden wir die synthetische und die Real-User-Überwachung (RUM) erörtern, die sich darauf bezieht, was die Endbenutzer im Gegensatz zur Leistung der Anwendungsumgebung tatsächlich erleben. Die Messung der Endbenutzererfahrung hilft, Szenarien zu vermeiden, in denen die bekannten API-Endpunkte erwartungsgemäß funktionieren, die Endbenutzer jedoch aufgrund unvorhergesehener Probleme entlang des Transaktionspfads eine langsame Reaktionszeit der Benutzeroberfläche erleben.
Die synthetische Überwachung dient auch als Kontrollexperiment in Ihrer API-Landschaft und ermöglicht es Ihnen, Was-wäre-wenn-Szenarien mit wechselndem Benutzerverkehr durchzuführen. In Zeiten geringer oder keiner Arbeitsbelastung simuliert dieser Ansatz API-Aufrufe, um Leistungsdaten zu generieren. So erhalten Sie eine konsistente Basislinie, die Sie messen können, wenn das System unter Stress steht oder sogar, wenn der Benutzerverkehr minimal oder vorübergehend nicht vorhanden ist. Die synthetische Überwachung bietet eine zuverlässige und wiederholbare Transaktionsemulation, die die Möglichkeit ausschließt, dass fehlerhaft arbeitende Endbenutzer-Clientgeräte (z. B. ein langsamer Desktop-Computer) die Messwerte verfälschen.
Noch wichtiger ist, dass bei Anwendungen, auf die von verschiedenen Netzwerken aus zugegriffen wird, die synthetische Überwachung Anrufe von verschiedenen geografischen Standorten und Providernetzwerken emulieren kann und Ihnen hilft, die Leistung der API über diese verschiedenen Pfade zu testen. Während synthetische Tests geskriptete Erkenntnisse liefern, hilft die Verwendung von Real User Monitoring (RUM) bei der Erfassung nicht geskripteter, realer Interaktionen. Synthetische Tests könnten beispielsweise zeigen, dass eine API in Nordamerika optimal funktioniert, in Asien jedoch Latenzzeiten aufweist; RUM könnte dies bestätigen, indem es Nutzerbeschwerden oder langsamere Transaktionszeiten in der letzteren Region aufzeigt. Mit dieser Mischung erhalten Sie einen umfassenden internen und externen Überblick über die Leistung Ihrer API und stellen sicher, dass alle Ihre Nutzer eine konsistente und optimale API-Leistung erfahren, unabhängig davon, wo sie sich weltweit verbinden.
{{banner-30="/design/banners"}}
Benutzerzentrierte Überwachung: Jenseits von Plattform- und Browser-Variabilität
Es kommt häufig vor, dass eine API auf einem modernen Webbrowser reibungslos funktioniert, während sie auf einer älteren Version oder einem weniger verbreiteten Browser Probleme hat. Wie bei modernen Versionen interpretieren und führen verschiedene Plattformen und Browser den Code unterschiedlich aus. Einige verfügen möglicherweise über schnellere JavaScript-Engines, bessere Caching-Mechanismen oder effizientere Rendering-Pipelines.
Wählen Sie ein Tool, das User-Agent-Parsing einsetzt, um die Metriken nach Browser und Betriebssystem aufzuschlüsseln, was letztendlich zur Bereicherung Ihres Datenpools beiträgt. Achten Sie auf Funktionen, mit denen Sie Metriken nach verschiedenen Dimensionen segmentieren können, um sie gezielt zu optimieren. Können Sie Leistungsdaten nach der Menge des verfügbaren Speichers auf dem Gerät eines Nutzers filtern? Können Sie zwischen städtischen und ländlichen Nutzererfahrungen unterscheiden? Eine solche mehrdimensionale Analyse macht die Daten übersichtlicher und erleichtert die Suche nach einem Leistungsproblem, das sich auf ein bestimmtes Nutzersegment auswirkt. Das gewählte Tool sollte auch ein clientseitiges Real User Monitoring (RUM) ermöglichen, um von der tatsächlichen Nutzung durch den Endnutzer abgeleitete Metriken wie Ladezeit und Transaktionserfolgsrate nach Plattform und Browsertyp zu erfassen.
Navigieren durch unsichtbare Verzögerungen: DNS, ISPs und CDNs
Langsame DNS-Suchvorgänge, verzögerte Routen durch ISPs oder nicht reagierende Content Delivery Networks (CDNs) führen zu unerwarteten Latenzzeiten bei Ihren API-Antworten. Ziehen Sie Tools in Betracht, die intelligente Warnmeldungen anbieten, um Probleme wie Verzögerungen bei der DNS-Ausbreitung oder CDN-Cache-Verfehlungen zu erkennen. Dazu sollten auch Traceroute-Diagnosen gehören, die helfen, Engpässe im Netzwerk bei jedem Hop zu visualisieren.
Unterstützung für das Open-Source-Framework OpenTelemetry
Während Signale für die Beobachtbarkeit von grundlegender Bedeutung sind, legt die Instrumentierung den Grundstein dafür, den internen Zustand des Systems durch Traces, Metriken und Protokolle als Telemetriedaten offenzulegen.
OpenTelemetry, das 2019 von der Cloud Native Computing Foundation (CNCF) ins Leben gerufen und 2021 in den vollen Projektstatus erhoben wurde, ist ein einheitliches Observability-Framework zum Sammeln, Generieren, Exportieren und Speichern von Telemetriedaten. Diese Daten werden dann an ein Observability-Backend zur weiteren Analyse gesendet. Das OpenTelemetry-Toolkit erfüllt in diesem Zusammenhang zwei wesentliche Funktionen:
- Eigentum an den Daten: Sie sind von proprietären Datenformaten oder Tools befreit und haben die vollständige Kontrolle über die generierten Telemetriedaten. Damit entfällt auch das Risiko von Anbieterbindungen oder die Zahlung eines Aufpreises für eine proprietäre Überwachungslösung, was Ihnen letztendlich die Flexibilität gibt, das beste API-Überwachungstool für Ihren Anwendungsfall auszuwählen und zu portieren.
- Standardisierung und Erweiterbarkeit: Förderung eines einheitlichen Satzes von APIs und Konventionen zur Vereinfachung der Lernkurve für Teams. Unabhängig davon, ob Sie Traces, Metriken oder Protokolle betrachten, vereinfacht die Einhaltung der OpenTelemetry-Formate die Dateneingabe in verschiedene Observability-Tools, ohne die zugrunde liegende Architektur zu ändern.
In einer typischen OpenTelemetry-Konfiguration erzeugt der instrumentierte Anwendungscode über die OpenTelemetry-API Spans und Metriken. Während Spans verwendet werden, um den Fluss von Anfragen durch ein verteiltes System zu verfolgen, werden Metriken verwendet, um die Leistung eines Systems zu messen. Generierte Spans und Metriken bieten Rohdaten, die für die Messung der API-Leistung, die Verfolgung von Anfragen und das Verständnis von Latenzzeiten unglaublich nützlich sein können. Die Stärke des Frameworks liegt jedoch nicht nur in der Datengenerierung.
Das OpenTelemetry SDK wendet auch Stichprobenregeln an und leitet die Daten durch verschiedene Prozessoren. Stichprobenregeln reduzieren die Menge der erfassten Daten, während Prozessoren die Daten umwandeln und anreichern, bevor sie exportiert werden.
Sobald diese Daten in ein Beobachtungs-Backend exportiert wurden, können Sie sie analysieren, um den Zustand der API zu überwachen, Leistungsmetriken zu verfolgen und Warnmeldungen für Anomalien festzulegen. Der Vorteil ist die Möglichkeit einer einheitlichen Observability-Plattform, auf der Sie Traces und Metriken aus verschiedenen Teilen eines Systems, einschließlich APIs, anzeigen, analysieren und korrelieren können.
{{banner-31="/design/banners"}}
Unterstützung für Dienstkataloge und API-Dokumentation
Ein Dienstkatalog bietet in der Regel eine umfassendere Ansicht, in der die verschiedenen verfügbaren Dienste (einschließlich APIs) beschrieben werden, wer auf sie zugreifen kann und wie sie mit anderen Diensten interagieren. Achten Sie bei der Bewertung von API-Überwachungstools auf die Kompatibilität und Integration zwischen Ihrem Servicekatalog und der OpenAPI-Spezifikation (OAS). Beurteilen Sie, wie gut sie die Erstellung, Verwaltung und Echtzeitänderung von APIs unterstützen.
Die OpenAPI-Spezifikation (OAS) ermöglicht eine doppelte Zweckbestimmung für HTTP-basierte APIs, die sowohl Entwicklern als auch Maschinen dienen. Diese Doppelfunktionalität geht über die API-Dokumentation hinaus und ermöglicht die Aktualisierung der Implementierungslogik, die Erstellung von SDKs und das Testen mit Hilfe von Mock-Servern, die alle von einer einzigen OpenAPI-Datei orchestriert werden. Die Übernahme von OpenAPI in Ihre Überwachungsstrategie bietet das Potenzial für die automatische Generierung von Überwachungsprüfungen und die explizite Versionierung aus der OAS-Beschreibungsdatei. Dadurch wird sichergestellt, dass auch dunkle APIs - veraltete oder ältere API-Versionen - nicht unüberwacht bleiben.
Da die OpenAPI-Datei alle Details über API-Endpunkte und Anfrage-/Antwort-Strukturen enthält, stellt sie im Wesentlichen alle Informationen bereit, die ein Überwachungswerkzeug benötigt, um das API-Verhalten zu überprüfen. Das Tool konfiguriert diese Prüfungen automatisch auf der Grundlage Ihrer OpenAPI-Spezifikationen und stellt so sicher, dass Ihre APIs immer optimal und innerhalb akzeptabler Zeitrahmen funktionieren.
Es ist wichtig, ein API-Überwachungstool zu wählen, das mit OpenAPI integriert werden kann, um zu vermeiden, dass separate Inseln von Kataloginformationen entstehen, die im Laufe der Zeit auseinanderlaufen können, wenn eine einzige Quelle der Wahrheit fehlt.
Integriert in CI/CD-Pipelines
Wenn Ihr Unternehmen eine kontinuierliche Bereitstellung für die Freigabe von Code für die Produktion praktiziert, sollte Ihr API-Überwachungstool in eine kontinuierliche Bereitstellungsplattform wie Jenkins integriert werden. Ein Shift-Links-Ansatz für die Überwachung ermöglicht das gleichzeitige Rollout von Überwachungskonfigurationen während der Sprint-Planung. Die Linksverschiebung stellt sicher, dass die Endpunkte von neuen oder aktualisierten APIs sofort überwacht werden, wodurch das Zeitfenster, in dem Probleme unbemerkt bleiben könnten, verringert wird. Achten Sie auf die folgenden Funktionen in Ihren API-Überwachungstools.
Neue APIs sofort erkennen
Sobald eine neue API in das Code-Repository übertragen und über die CI/CD-Pipeline bereitgestellt wird, sollte das Überwachungstool in der Lage sein, diese Änderung zu erkennen. Wenn die API unter Verwendung der OpenAPI-Spezifikation (OAS) entwickelt wurde, kann das Tool seine Prüfungen auf der Grundlage der bereitgestellten OAS-Datei automatisch konfigurieren.
Aktualisierung bei API-Änderungen
Der Code einer Anwendung entwickelt sich ständig weiter. Änderungen an API-Versionen, die Einführung neuer Endpunkte oder Änderungen an bestehenden Endpunkten sollten sofort über die CI/CD-Pipeline an das Überwachungstool weitergeleitet werden. Diese frühzeitige Sichtbarkeit ist entscheidend für sofortige und genaue Anpassungen der Überwachungskonfigurationen.
Automatisches Hinzufügen neuer Endpunkte
Jedes Mal, wenn neue Endpunkte eingeführt oder durch die CI/CD-Pipeline entdeckt werden, werden sie automatisch dem Überwachungstool hinzugefügt, damit sie beobachtet werden können. Auf diese Weise wird sichergestellt, dass alle Endpunkte vor der Inbetriebnahme überprüft werden, und Sie reduzieren blinde Flecken in Ihrer Überwachungsstrategie.
Dashboard & Warnungen
Frühe Integration bedeutet auch frühe Warnungen. Als Teil der CI/CD-Integration können Dashboards automatisch aktualisiert werden, um die neu bereitgestellten oder geänderten APIs zu berücksichtigen. Sie sollten in der Lage sein, automatisch Warnregeln auf der Grundlage vordefinierter Bedingungen einzurichten, um Echtzeit-Benachrichtigungen über Webhooks für alle Anomalien zu gewährleisten.
Die Integrationsphilosophie vertritt im Wesentlichen das Konzept "Überwachung als Code" - eine Praxis der gleichzeitigen Entwicklung einer robusten, proaktiven API-Überwachungsstrategie, während Sie Ihren Code schreiben, testen und bereitstellen.
{{banner-32="/design/banners"}}
Unterstützung für alle Arten von API
In einem Microservices-Framework wird Ihre Anwendung wahrscheinlich verschiedene API-Typen verwenden - SOAP für Legacy-Dienste, REST für Webdienste, HTTP für grundlegende Aufrufe und GraphQL für speziellere Datenanforderungen. Für jeden dieser Fälle umfasst die manuelle Instrumentierung in der Regel die Einbettung einer Überwachungslogik für jeden API-Endpunkt. Dieser Ansatz bietet eine granulare Kontrolle, wenn auch auf Kosten von Zeit und potenziellen menschlichen Ungenauigkeiten.
Ein API-Überwachungsdienst, der als Software Development Kits (SDK) gebündelt ist, bietet einen effizienteren Weg. Wenn diese vorkompilierten Bibliotheken in Ihren Tech-Stack integriert werden, wird die erforderliche Überwachungslogik automatisch in Ihre Codebasis integriert. Die meisten SDKs bieten heute auch sofortige Unterstützung für verschiedene API-Typen und können auf der Grundlage von OAS automatisch konfiguriert werden. Durch diese Automatisierung werden menschliche Fehler und Einrichtungszeit reduziert und die Konsistenz der Überwachungskonfigurationen sichergestellt.
Tools, die OpenTelemetry unterstützen, profitieren sowohl von manueller als auch von automatischer Instrumentierung für verschiedene Programmiersprachen. Der gemischte Ansatz rationalisiert die Telemetrieerfassung durch das Angebot von APIs und SDKs für benutzerdefinierte Instrumentierungsanwendungen. Eine typische Konfiguration kann von der Definition von Umgebungsvariablen bis hin zu sprachspezifischen Systemeigenschaften reichen. Diese Optionen bieten insgesamt die Flexibilität, Datenquellen, Exporteure und Ressourcennutzung zu konfigurieren, um die Telemetriedaten anzureichern. Nativ instrumentierte Bibliotheken können automatisch OpenTelemetry-APIs aufrufen, so dass keine benutzerdefinierte Codierung erforderlich ist.
Für diejenigen, die dies nicht tun, bietet OpenTelemetry sprachspezifische Instrumentierungsbibliotheken, um die Telemetrieintegration universell zugänglich zu machen.
Unterstützung für Microservices und serverloses Computing
In einer modernen API-first-Landschaft funktionieren APIs nicht mehr isoliert. Stattdessen sind sie Teil eines größeren Ökosystems von voneinander abhängigen Diensten, von denen jeder seinen eigenen Satz von APIs hat. Unternehmen sollten sich jetzt auf eine systemweite Beobachtbarkeit konzentrieren, die dieser Komplexität entspricht.
Nehmen Sie zum Beispiel Microservices. Diese modularen Dienste kommunizieren über REST-APIs, von denen jeder eine eigene Funktion erfüllt, aber gemeinsam zu einer Transaktion beiträgt. Eine einzelne Transaktion kann über mehrere solcher Dienste laufen, von denen jeder seine eigene API hat. Darüber hinaus interagieren Microservices häufig über gRPC, ein leistungsstarkes Open-Source-Framework, das mehrere Arten der Kommunikation ermöglicht. Wenn Ihr Überwachungstool nicht in der Lage ist, jeden Aufruf in einem solchen Framework zu verfolgen, wird die Lösung von Problemen zu einer enormen Herausforderung.
Service-Meshes wie Istio, Consul von Hashicorp und Linkerd bieten eine weitere Komplexitätsebene. Sie steuern, wie verschiedene Teile einer Anwendung Daten und Dienste gemeinsam nutzen, und fügen eine Abstraktionsschicht für eine sichere, zuverlässige und schnelle Kommunikation zwischen Diensten hinzu. Die fehlende Möglichkeit, diese Schicht zu überwachen, ist ein weiterer blinder Fleck in Ihrer Beobachtungslandschaft.
Und wenn Sie eine serverlose Architektur nutzen, beachten Sie, dass die Abhängigkeit von APIs zur Aktivierung von Funktionen grundlegend ist. Beispielsweise dient AWS API Gateway als Kanal zwischen serverlosen Funktionen wie AWS Lambda und dem breiteren System. Dieser Service geht über die einfache Weiterleitung von Anfragen hinaus und bietet Funktionen wie Datenverkehrsmanagement und API-Komposition.
Überwachung der Infrastruktur auf mehreren Ebenen
Einige Unternehmen schätzen den Zusammenhang zwischen der Beobachtbarkeit der Infrastruktur und der API-Überwachung falsch ein. Sie konzentrieren sich ausschließlich auf die API-Endpunkte und übersehen dabei oft die darunter liegenden Infrastrukturebenen, die sich auf die API-Leistung auswirken.
Da jede Abstraktionsebene ihre eigene Komplexität und ihre eigenen Metriken mit sich bringt, besteht die Herausforderung darin, Daten über diese verschiedenen Ebenen hinweg miteinander zu verknüpfen, um eine integrierte Ansicht zu erhalten. Der Einsatz spezialisierter Tools, die in der Lage sind, Probleme zu diagnostizieren, die sich über mehrere Ebenen Ihres Infrastruktur-Stacks erstrecken, ist entscheidend.
Ziehen Sie ein Tool in Betracht, das einen integrierten Überblick über verschiedene Technologieebenen bietet. Spezialisierte Tools , die eine mehrstufige Überwachung ermöglichen, sind aus zwei Gründen wichtig: Sie helfen bei der Diagnose von Problemen über abstrahierte Schichten hinweg und bieten eine umfassende Momentaufnahme des Zustands Ihrer API.
Beginnen Sie mit den Servern, die Ihre API hosten. Zu den wichtigsten Metriken, auf die Sie sich konzentrieren sollten, gehören die CPU-Auslastung, die JVM-Heap-Größe, die Anzahl der Threads und die Netzwerklatenz. Jegliche Spitzen in diesem Bereich können sich direkt auf die Reaktionsfähigkeit Ihrer API auswirken und zu erhöhten Latenzzeiten und verringertem Durchsatz führen.
Die nächste Ebene umfasst Datenbanken und Drittanbieterdienste, mit denen Ihre API interagiert. Abfrageausführungszeit, API-Antwortzeiten, Fehlerraten, Verbindungspooling und Caching-Mechanismen sind wichtige Messgrößen, die Frühwarnzeichen für eine träge Endbenutzererfahrung anzeigen können.
Im Gegensatz zu traditionellen Überwachungsansätzen auf Hypervisor- und VM-Ebene bringen containerisierte Umgebungen zusätzliche Schichten in das Ökosystem ein. Stellen Sie sicher, dass Ihr ausgewähltes Tool Orchestrierungssysteme wie Kubernetes überwacht. Metriken wie Pod-Status, Ressourcenkontingente und Container-Zustandsprüfungen bieten verschiedene Einblicke in die API-Leistung.
Schlussfolgerung
Der wahre Wert eines API-Überwachungstools geht über das reine Sammeln von Daten und das Anbieten von Erkenntnissen, auf die Sie reagieren können, hinaus. Es sollte flexibel genug sein, um sich an unterschiedliche API-Verhaltensweisen anzupassen, komplexe Metriken interpretieren zu können und sich nahtlos in Ihre DevOps-Pipelines zu integrieren.
Obwohl fortschrittliche Funktionen wie mehrstufige Tests, Histogramme und zentralisierte Protokollaggregation Ihrer API-Überwachung mehr Tiefe verleihen, sind sie keine Garantie gegen jede Anomalie. Dies untergräbt jedoch nicht die Bedeutung der Einführung dieser Strategien.
CatchpointDas Observability-Framework geht über die grundlegenden Metriken hinaus und führt API-Transaktionen aus, die die Funktionalität testen, Nutzdaten ausführen und die erwarteten Antworten analysieren. Die Plattform Catchpoint überwacht auch Ihr Netz von API-Endpunkten und integriert die API-Metriken mit den durch synthetisches und Real-User-Monitoring (RUM) gemessenen Metriken für die Endbenutzererfahrung und korreliert sie mit DNS- und CDN-Leistungsmetriken, die den End-to-End-Transaktionspfad beeinflussen. Dies fügt Ihrer API-Überwachung eine weitere Dimension hinzu, verkürzt die Fehlersuche und bietet eine proaktive Problemlösung.
Um mehr darüber zu erfahren, wie Catchpoint einen ganzheitlichen Ansatz für die API-Beobachtung bietet, der über die reine Überwachung hinausgeht, sehen Sie sich hier eine Demo an.
