Anwendungen überwachen
Instana stellt die nächste Generation von APM vor, mit einer Anwendungshierarchie aus Diensten, Endpunkten und den dazugehörigen Anwendungsperspektiven. Das Hauptziel ist die Vereinfachung der Überwachung der Servicequalität Ihres Unternehmens. Auf der Grundlage der Daten, die aus Traces und Komponentensensoren erfasst werden, ermittelt „ Instana “ Ihre Anwendungslandschaft direkt anhand der implementierten Dienste.
Bei traditionellen APM-Lösungen ( Application Performance Management ) geht es um die Verwaltung der Leistung und Verfügbarkeit von Anwendungen.
Eine Anwendung für APM-Tools ist eine statische Sammlung von Laufzeitumgebungen (z. B.. JVM oder CLR), die mithilfe eines Agenten überwacht werden. Gewöhnlich wird die Anwendung für jeden Agenten als Konfigurationsparameter definiert.
Dieses Konzept, das ein gutes Modell für klassische 3-Stufen-Anwendungen war, funktioniert bei modernen Mikroserviceanwendungen nicht mehr. Ein Service gehört nicht immer zu genau einer Anwendung. Nehmen wir zum Beispiel einen Kreditkartenzahlungsdienst, der sowohl im Online-Shop eines Unternehmens als auch an dessen Verkaufsstellen genutzt wird. Die Definition jedes Dienstes als Anwendung könnte dieses Problem lösen, bringt jedoch folgende neue Herausforderungen mit sich:
- Zu viele Anwendungen, die überwacht werden müssen : Wenn man jeden Dienst als Anwendung betrachtet, entstehen Hunderte oder Tausende von Anwendungen. Die Überwachung von Anwendungen mithilfe von Dashboards wird aufgrund der Datenflut unpraktisch.
- Kontextverlust : Wenn jeder Dienst separat betrachtet wird, ist es schwierig, Abhängigkeiten oder die Rolle des Dienstes im Gesamtkontext eines Problems zu verstehen.
Zusammenfassung
Latenzverteilung
Das Diagramm zur Latenzverteilung eignet sich ideal zur Untersuchung von Latenzproblemen bei Ihren Anwendungen, Diensten oder Endpunkten. Sie können im Diagramm einen Latenzbereich auswählen und über das Menü „In Analytics anzeigen“ die jeweiligen Aufrufe in Unbounded Analytics genauer untersuchen.
Infrastrukturprobleme und -änderungen
Auf der Registerkarte „Zusammenfassung“ werden Infrastrukturprobleme und -änderungen angezeigt, die mit Ihren Anwendungen, Diensten oder Endpunkten in Zusammenhang stehen. Diese Informationen helfen Ihnen dabei, Zusammenhänge mit auffälligen Veränderungen bei den Anwendungsmetriken zu erkennen, wie beispielsweise einem Anstieg der Fehlerquote bei Aufrufen oder der Latenz.
Wenn Sie mehr über bestimmte Probleme oder Änderungen erfahren möchten, wählen Sie im Diagramm einen gewünschten Zeitraum aus und klicken auf den Menüpunkt Ereignisse anzeigen , um die Ansicht Ereignisse aufzurufen.
Verarbeitungszeit
Die Grafik „Verarbeitungszeit“ veranschaulicht, wie viel Zeit für die eigentliche Verarbeitung in einer Anwendung, einem Dienst oder einem Endpunkt selbst aufgewendet wird und wie viel Zeit für den Aufruf der nachgelagerten Abhängigkeiten benötigt wird.Self Diese Werte sind nach Aufruftyp aufgeschlüsselt, z. B. Http Database,, Messaging, Rpc SDK,, usw.
Wenn beispielsweise die Latenz eines Aufrufs an die Shop Service ist 1000ms, Die Shop Der Dienst sendet einen HTTP Aufruf an die Payment Service, der 300ms und dann ein weiterer Datenbankaufruf an die Catalog Service, der 200ms, die Selbstverarbeitungszeit der Shop Service ist 1000-300-200=500ms Die
Zeitverschiebung
Um Kennzahlen mit früheren Zeiträumen zu vergleichen, können Sie die Funktion „Zeitverschiebung“ nutzen, wie in der Abbildung gezeigt. Beachten Sie, dass die Genauigkeit beim Vergleich von Kennzahlen mit historischen Daten geringer ist.
Zuordnung von Anwendungsabhängigkeiten
Die Abhängigkeitszuordnung ist für jede Anwendung verfügbar und bietet folgende Funktionen:
- eine Übersicht über die Serviceabhängigkeiten in Ihrer Anwendung.
- eine visuelle Darstellung von Aufrufen zwischen Services, um Kommunikationspfade und Durchsatz zu verstehen.
- verschiedene Layouts, um schnell ein Verständnis für die Architektur der Anwendung zu gewinnen.
- Bequemer Zugriff auf Serviceansichten (Dashboards, Abläufe, Aufrufe und Probleme).
Fehlernachrichten
Fehlermeldungen sind Meldungen, die aufgrund von Fehlern erfasst werden, die während der Ausführung des Codes eines Dienstes aufgetreten sind. Wenn beispielsweise während der Verarbeitung eine Ausnahme ausgelöst und vom Anwendungscode nicht abgefangen oder behandelt wird, wird sie auf der Registerkarte „Fehlermeldungen“ aufgeführt. Ein Beispiel hierfür ist eine nicht behandelte Ausnahme in der Methode doGet eines Servlets, die dazu führt, dass die Anforderung mit HTTP 500 beantwortet wird.
Protokollnachrichten
Protokollmeldungen werden aus instrumentierten Protokollierungsbibliotheken oder -Frameworks erfasst. Siehe beispielsweise den Abschnitt „Protokollierung“ in der Liste der unterstützten Bibliotheken. Wenn ein Dienst über eine Protokollierungsbibliothek eine Protokollmeldung mit dem Schweregrad WARN oder höher schreibt, wird die Meldung auf der Registerkarte „Protokollmeldungen“ angezeigt. Außerdem werden die erfassten Protokollmeldungen in den Trace-Details im Kontext ihres jeweiligen Traces angezeigt. Wenn eine Protokollmeldung mit dem Schweregrad ERROR oder höher geschrieben wurde, wird sie als Fehler markiert. Protokollmeldungen mit einem Schweregrad unter WARN werden nicht erfasst.
Infrastruktur
Von der Ansicht „Anwendungsperspektive“ oder dem Dashboard „Dienste“ aus kann man zu der entsprechenden Infrastrukturkomponente navigieren, die in der Ansicht „Infrastrukturüberwachung“ angezeigt wird.
Infrastrukturkomponente 'Nicht überwacht'
Die Liste der Infrastrukturkomponenten für eine Anwendung oder einen Dienst kann manchmal auch „nicht überwachte“ Hosts, Container oder Prozesse enthalten.
Die Komponente „Nicht überwacht“ bedeutet, dass es bei einigen oder allen Aufrufen eines Dienstes nicht möglich war, diese mit einer bestimmten Infrastrukturkomponente zu verknüpfen. Dienste sind „logische“ Einheiten und werden in der Regel über den überwachten Prozess mit Infrastrukturkomponenten verknüpft. Dies gilt nicht für Webdienste von Drittanbietern, die zwar nicht überwacht werden, bei denen jedoch weiterhin Dienste und Endpunkte auf der Grundlage von Hostname und Pfad angelegt werden. Da kein Host und kein Prozess bekannt ist, werden diese Dienste der Infrastrukturkomponente „Unbekannt“ zugeordnet.
Smart Alerts
Zeigen Sie eine Liste aller konfigurierten Smart Alerts an. Klicken Sie auf einen Alert, um seine Konfiguration anzuzeigen, zu ändern oder das Revisionsprotokoll anzuzeigen. Falls erforderlich, können Sie den Alert auch inaktivieren oder entfernen.
Informationen zum Hinzufügen einer Benachrichtigung finden Sie in der Dokumentation zu Smart Alerts.
Einstellung des Zeitraums
Der in den Dashboards oder Analysen von „ Instana “ verwendete Zeitbereich kann geringfügig vom im Zeitauswahlfeld ausgewählten Zeitbereich abweichen. Das Dashboard oder der Analysezeitbereich schließt das erste und das letzte Teilbucket aus. Wenn Sie beispielsweise am 20. Januar um 15:15 Uhr im Zeitauswahlfeld die Voreinstellung „Letzte 24 Stunden“ auswählen, wird der Zeitraum auf 19. January–3:00 Uhr, angepasst. Diese Anpassung erfolgt, da die entsprechende Diagrammgranularität 30 Minuten beträgt. Die Anpassung des Zeitbereichs stellt die Konsistenz zwischen verschiedenen Widgets auf derselben Seite sicher und verhindert eine falsche Interpretation von Teilbuckets als unerwarteten Metriktrend, z. B. eine Abnahme der Anzahl von Aufrufen.
Ungefähre Daten
Wenn Sie in Analytics ein Dashboard aufrufen oder eine Abfrage für einen bestimmten Zeitraum durchführen, der über die letzten sieben Tage hinausgeht, wird in verschiedenen Widgets möglicherweise der Hinweis „Ungefähre Daten“ angezeigt. Dieser weist darauf hin, dass „ Instana “ zur Bearbeitung der Abfragen auf eine reduzierte Anzahl statistisch signifikanter Traces und Aufrufe zurückgreift. Beispiel:
Traces und Aufrufe, die selten auftreten, werden in solchen Szenarios möglicherweise nicht dargestellt.
Hinweis zur Stichprobengenauigkeit bei Kennzahlen auf Anrufebene
Das System nutzt eine Zufallsauswahl auf Basis des Hashwerts der Trace-ID, wodurch eine konsistente Stichprobenauswahl auf Trace-Ebene gewährleistet wird. Dies hat jedoch Auswirkungen auf die Analyse von Kennzahlen auf Aufrufebene:
- Die Stichprobenentnahme erfolgt pro Trace und nicht pro Aufruf. Wenn sich die Trace-Größen erheblich unterscheiden (beispielsweise die Anzahl der Aufrufe pro Trace), können die Daten auf Aufrufebene verzerrt werden.
- Beispielsweise kann ein einzelner Trace mit mehr als 2.4 Millionen Aufrufen erhebliche Auswirkungen auf die Metriken auf Aufrufebene haben, wenn das System ihn in die Stichprobe einbezieht.
- Dies ist das erwartete Verhalten, kein Fehler. Es veranschaulicht, wie die spurbasierte Probenahme funktioniert.