Infrastrukturkorrelation
Auf dieser Seite wird beschrieben, wie Anwendungsüberwachung und Infrastrukturüberwachung integriert werden.
Weitere Informationen finden Sie unter „Anwendungsüberwachung“ und „Infrastrukturüberwachung “.
Obwohl sich viele Benutzer fast nur auf die Anwendungsüberwachung konzentrieren, ist es manchmal nützlich, ein besseres Verständnis davon zu erhalten, wie die logische Ebene der physischen Ebene zugeordnet wird. Manchmal ist es dies sogar erforderlich, nämlich wenn es um die Behebung von Problemen geht, die auf Anwendungsebene erkannt werden, deren Ursache jedoch auf Infrastrukturebene liegt.
Instana ermöglicht die bidirektionale Navigation in der Benutzeroberfläche zwischen der Anwendungs- und der Infrastrukturüberwachung:
- Von Anwendungen und Services bis hin zur Infrastrukturüberwachung
- Von Aufrufen zur Infrastrukturüberwachung
- Von der Infrastrukturüberwachung bis zur Anwendungsüberwachung
Infrastrukturelle Korrelation spielt auch eine wichtige Rolle bei Folgendem:
Ebenso sind die Anwendungsüberwachung und die Website-Überwachung miteinander integriert, wie hier näher erläutert wird.
Navigation von Services aus
In seiner einfachsten Form wird ein Service von einem einzigen Prozess ausgeführt, z. B. einer Spring Boot-Anwendung. Allerdings kommt es ziemlich häufig auch vor, dass er von mehreren Prozessen ausgeführt wird, um verschiedene Anwendungsfälle zu unterstützen:
- zum Steigern des Durchsatzes und der Belastbarkeit, je mehr Prozesse desto besser
- zum Aufteilen der Arbeit auf verschiedene Tenants oder Konfigurationen
- zum Ausführen verschiedener Versionen dieses Service, in der Regel in verschiedenen Umgebungen
Das bedeutet, dass Sie von einem Service aus in der Regel zu einem oder mehreren zugrunde liegenden Prozessen und dazugehörigen Entitäten wie Hosts, Containern, Kubernetes-Pods usw. navigieren können.
Ein Einstiegspunkt ist die Stapelauf der Registerkarte "Infrastruktur", die alles darüber informiert, welche Teile der Infrastruktur für die Ausführung des Service sorgen, einschließlich ihres Zustands und wichtiger Metriken wie CPU-oder Hauptspeicherbelegung.
Ein anderer Einstiegspunkt ist die Registerkarte 'Infrastruktur' eines Servicedashboards, das Ihnen eine andere Aufgliederung als der Stack bietet und zusätzlich Tracing-Messdaten bereitstellt wie Aufrufanzahl, Fehlerrate und mittlere Latenzzeit. Diese Messdaten reichen von der Hostebene bis hin zur Prozessebene.
Beide vorangegangenen Widgets bieten „ Kubernetes “ und „Pivotal Cloud Foundry “ als vollwertige Komponenten an, die Ihnen direkten Zugriff auf zugehörige Entitäten wie „ Kubernetes “-Dienste oder PCF-Anwendungen ermöglichen.
Beispiel eines Stacks für einen Service, der in Kubernetes ausgeführt wird:
Beispiel einer Infrastruktur für einen Service, der in Kubernetes ausgeführt wird:
Navigation von Aufrufen aus
Im Allgemeinen werden Traces mit Infrastrukturentitäten verknüpft. Genauer gesagt kann ein Aufruf mit bis zu 2 Prozessen verknüpft werden: mit der Quelle, die den Aufruf einleitet, und mit dem Ziel, das diesen Aufruf verarbeitet. Ein NodeJS-Prozess leitet zum Beispiel einen HTTP-Aufruf an einen PHP-Prozess ein.
In der Traceansichtkönnen Sie einen beliebigen Aufruf zum Öffnen der Anrufdetailsauswählen. Sowohl über den Abschnitt zur Quelle als auch über den Abschnitt zum Ziel können Sie erfahren, welche Teile der Infrastruktur beteiligt sind.
In diesem Beispiel ist die Quelle ein PHP-Prozess, während das Ziel eine Spring Boot-Anwendung ist (Java-Prozess):
In einigen Fällen ist die Korrelation zur Infrastruktur nicht möglich, was in der Regel bedeutet, dass der zugrunde liegende Prozess nicht von Instana überwacht wird.
Dies ist immer beim Rootaufruf eines Trace der Fall, da ein externer, nicht überwachter Client die ursprüngliche Anforderung stellt. Hier wird der Service shipping von einer Instanz aufgerufen, die von Instana nicht überwacht wird:
Ein weiterer Fall besteht, wenn abgehende Aufrufe auf einen externen Service anderer Anbieter abzielen. Hier ruft der Service payment den externen Service www.paypal.com auf.
Navigation von der Infrastruktur aus
Wenn Sie sich Entitäten der Infrastruktur oder Plattform ( Kubernetes, Pivotal Cloud Foundry und vSphere ) ansehen, können Sie mithilfe des Stacks eine Liste der von ihnen ausgeführten Dienste und der Anwendungen, zu denen sie gehören, sowie Metriken wie die Anzahl der Aufrufe und Fehler abrufen.
Vorgeschaltet/Nachgeschaltet ermöglicht Ihnen den Zugriff auf Services und Anwendungen, die jeweils von der aktuellen Infrastrukturentität aufgerufen und aufgerufen werden.
Funktionsweise
Zunächst einmal ist es wichtig zu verstehen, dass die Anwendungs- und Infrastrukturüberwachung auf zwei unterschiedlichen Datenpipelines basiert:
Anwendungsüberwachung: Die Daten (Traces und „ calls.md “) stammen von den Tracern von Instana oder von Tracern von Drittanbietern.
Infrastrukturüberwachung: Die Daten (Tags und metrics.md ) stammen von den Sensoren unter Instana.
Diese beiden Welten verschmelzen nahtlos dank eines Mechanismus, den wir 'Infrastrukturverknüpfung' nennen und bei dem Aufrufe mit überwachten Infrastrukturentitäten verknüpft werden. Die Verknüpfung erfolgt, wenn eine gemeinsame Kennung auf beiden Seiten gefunden wird.
Instrumentierte Services
Tracer instrumentieren Ihre Prozesse, um eingehende und abgehende Aufrufe zu erfassen. Diese Aufrufe werden dann an das Instana-Back-End gemeldet, wo versucht wird, die Quelle und das Ziel dieser Aufrufe mit einigen bekannten Infrastrukturentitäten zu verknüpfen. Wenn der Quellenprozess (oder Zielprozess) instrumentiert wird, impliziert dies notwendigerweise, dass der Quellenprozess (oder der Zielprozess) auch von einem Instana-Sensor überwacht wird, der über alle erforderlichen Daten verfügt. Da der Tracer und der Sensor benachbart sind, kennen beide den Host und den Prozess, was die Infrastrukturverknüpfung möglich macht.
Beispiel: Ein Python-Prozess wird durch den Python-Tracer instrumentiert, der alle eingehenden und abgehenden Aufrufe erfasst. In der Zwischenzeit wurden mehrere Sensoren auf dem Host aktiviert, auf dem dieser Prozess ausgeführt wird: die Host-, Prozess- und Python-Sensoren. Sowohl der Tracer als auch die Sensoren senden Daten separat an das Instana-Back-End, aber beide enthalten die gleiche Kennung für den Prozess. Es ist daher möglich, das Ziel der eingehenden Aufrufe und die Quelle der abgehenden Aufrufe mit dem Python-Prozess zu verknüpfen.
Dienste, die mit „ OpenTelementry “ implementiert wurden
In vielen Fällen kann die Infrastrukturkorrelation auch für Dienste durchgeführt werden, die mit „ OpenTelemetry “ statt mit den nativen Tracern von „ Instana “ instrumentiert sind. Weitere Informationen und bewährte Verfahren finden Sie unter „ OpenTelemetry -Dienstzuordnungen und Infrastrukturkorrelation “.
Datenbanken, Nachrichtenübertragungssysteme und Cloudservices
Instana Tracer werden nicht in Datenbanken, Messaging-Systemen oder Cloud-Diensten eingesetzt. Prozesse, die diese nicht protokollierten Systeme aufrufen, werden jedoch instrumentiert, sodass ausgehende Anfragen korrekt den Aufrufen zugeordnet werden. Der Tracer „ Java “ protokolliert beispielsweise ausgehende Anfragen eines Prozesses unter Java an eine Datenbank unter MySQL. Diese Anfragen werden als Aufrufe analysiert, deren Quelle der Prozess „ Java “ und deren Ziel die Datenbank „ MySQL “ ist. Solche Anrufe sind unter Instana einsehbar, und ihre Empfänger sind häufig mit der Infrastruktur-Entität verknüpft, die den Anruf entgegennimmt. Diese Zuordnung ist nur möglich, wenn „ Instana “ die Adressinformationen aus der ausgehenden Client-Anfrage eindeutig der überwachten Infrastruktur zuordnen kann:
Zum einen überwacht Instana die Datenbank oder das Nachrichtenübertragungssystem über einen der Instana-Sensoren und erkennt daher den Prozess, den zugehörigen Port und den Host. Zum anderen analysiert Instana eine abgehende Anforderung, die möglicherweise genügend Informationen enthält, um den Zielprozess zu erraten. In der Regel sind das der Hostname oder die IP sowie der genutzte Port, die z. B. in der Verbindungszeichenfolge übertragen werden.
Eine abgehende Anforderung an eine MySQL-Instanz könnte beispielsweise die Verbindungszeichenfolge
jdbc:mysql://10.128.0.6:3306 enthalten.
Bei der Infrastrukturüberwachung wurde ein entsprechender MySQL-Prozess festgestellt, der den Port 3306
angibt und auf einem Host ausgeführt wird, der wiederum die IP 10.128.0.6 angibt.
Da sowohl die IP als auch der Port übereinstimmen, werden die Aufrufe und die MySQL-Instanz miteinander verknüpft:
Instana unterstützt auch Verbindungszeichenfolgen, die einen Kubernetes-Servicenamen enthalten, wie z. B.
jdbc:mysql://mysql-svc. Hinter den Kulissen wird versucht, den Servicenamen vollständig zu qualifizieren, um
den Service über alle Namensbereiche und Cluster hinweg eindeutig zu identifizieren. Das Ergebnis ist ein Aufruf, dessen Ziel mit
dem Kubernetes-Service anstelle des endgültigen Prozesses verknüpft ist.
Bei Cloudservices gibt es keine Prozesse, aber die Idee ist dieselbe: Sie suchen eine gemeinsame Kennung, die vom überwachten Cloudservice und von der abgehenden Anforderung an diesen Service gemeinsam genutzt wird. Dies könnte z. B. eine Ressourcenkennung wie AWS ARN sein.
Es ist nicht immer möglich, die Adressinformationen der Anfrage mit den bekannten Infrastrukturdaten abzugleichen. In einigen Fällen wird bei Datenbank-, Messaging- oder Cloud-Diensten die Infrastruktur als „nicht überwacht“ angezeigt, obwohl die Zielsysteme mit Überwachungsinstrumenten ausgestattet sind, wie die folgenden Beispiele zeigen:
Bei einigen überwachten Datenbanken, Messaging-Systemen oder Cloud-Technologien wird die Infrastrukturkorrelation nicht unterstützt, da die Tracer nicht genügend Adressinformationen aus den Aufrufen extrahieren, um die Zielinfrastruktur eindeutig zu identifizieren. Beispielsweise lässt sich bei der Nachverfolgung von Messaging-Aufrufen wie „ Kafka “ oft nur der Name der Zielwarteschlange oder des Zielthemas ermitteln, nicht jedoch der tatsächliche Messaging-Cluster oder -Server.
Die Verknüpfung von Aufrufen mit der Infrastruktur ist manchmal nicht möglich, wenn der Host oder die IP in der Verbindungszeichenfolge keinem der Hosts oder keiner der IPs entspricht, die von der Infrastrukturüberwachung her bekannt sind. Dies ist in der Regel bei einer Dereferenzierung der Fall, wenn der Prozess, der die ferne Datenbank (oder den Nachrichtenübertragungsservice oder den Cloudservice) aufruft, einen Hostnamen verwendet, bei dem es sich um das Folgende handelt:
- ein Eintrag in der
/etc/hostsSystemdatei - ein DNS-CNAME-Eintrag
- ein Zeiger zu einem Proxy oder einer Lastausgleichsfunktion
- ein Alias, der von einem Service Discovery-Service wie Consul oder Zookeeper vergeben wurde
Zudem ist die Verknüpfung von Anrufen mit der Infrastruktur nicht möglich, wenn die Adressdaten des Clients mit mehr als einer Infrastruktureinheit übereinstimmen. Diese Situation tritt häufig in Hochverfügbarkeits-Datenbankkonfigurationen auf, bei denen mehrere Datenbankinstanzen dieselbe Adresse für den Client-Zugriff verwenden. Da die Datenbank selbst nicht instrumentiert ist, kann „ Instana “ nicht feststellen, welches der möglichen Ziele den Datenbankaufruf tatsächlich ausgeführt hat.
Externe Services
Externe Services werden per Definition nicht von Instana überwacht und sind daher auf der Seite der Infrastrukturüberwachung nicht einmal sichtbar. Da nichts über sie bekannt ist, sind Aufrufe gegenüber diesen Services nicht mit bekannten Infrastrukturentitäten verknüpft.
Auf der Registerkarte 'Infrastruktur' können Sie diese Aufrufe als 'Nicht überwacht' identifizieren:
Infrastrukturkorrelation bei der Zuordnung von Anwendungen und Diensten
Welche Rolle spielt die Infrastrukturkorrelation bei der Zuordnung von Anwendungen und Diensten?
Bei der Analyse von Traces und Aufrufen wird das Instana-Back-End sie zunächst
mit bekannten Infrastrukturentitäten verknüpfen und diese mit Infrastrukturtags wie host.name, springboot.name oder
docker.label erweitern. Anhand dieser Tags werden diese Aufrufe dann anhand vordefinierter oder benutzerdefinierter Regeln automatisch den entsprechenden Diensten zugeordnet. Beispiel: Ein Aufruf, der mit einem Spring Boot-Prozess verknüpft ist, wird einem Service zugeordnet, der seinen Namen aus dem
Spring Boot-Anwendungsnamen abruft. Oder Sie könnten ein Label „ service-namedocker “ definieren, mit dem Sie eine benutzerdefinierte Regel zur Dienstzuordnung erstellen könnten, um die meisten Ihrer in „ Docker “ ausgeführten Dienste zu benennen.
Das Gleiche gilt für das Anwendungs-Mapping, bei dem Sie diese Infrastruktur-Tags zur Definition von Anwendungen verwenden können, beispielsweise mit dem kubernetes.namespace Tag:
Wenn keine Infrastrukturverknüpfung möglich ist, kann die Servicezuordnung nicht auf Infrastrukturtags aufbauen und
nutzt stattdessen sogenannte Fallback-Regeln, die mit Aufruftags wie call.http.host oder
call.database.schema definiert werden.
Infrastrukturkorrelation und Vorfälle
Ein Vorfall gruppiert verwandte Ereignisse mithilfe des dynamischen Graphen. Die Möglichkeit zum Verknüpfen von Aufrufen (und damit Anwendungen und Services) mit Infrastrukturentitäten bereichert das dynamische Diagramm mit zusätzlichen Verbindungen, die die beiden Welten überbrücken und somit zu Vorfällen mit umfangreicheren Angaben und einer schnelleren Ursachenanalyse führen.