Überwachung einer virtuellen Maschine von Java ( JVM )
Mit Instana können Sie Ihre virtuelle Maschine von Java ( JVM ) umfassend überwachen, um Engpässe zu erkennen und die Leistung zu optimieren. Um „ JVM “ zu überwachen, installieren Sie den Host-Agenten „ Instana “. Nach der Installation des Agenten wird der Sensor „ Instana “ ( Java ) automatisch aktiviert und erfasst Echtzeit-Metriken sowie Trace-Daten, die Sie in der Benutzeroberfläche von „ Instana “ einsehen können.
Der „ Java “-Sensor bietet automatisierte Code-Instrumentierung für unterstützte Technologien, eine konfigurationsfreie Zustandsüberwachung von „ JVM “-Instanzen sowie durchgängige Ablaufverfolgung von Anfragen über alle Systeme hinweg.
Zusätzliche Informationen
Der „ Java “-Sensor unterstützt die folgenden Sprachen, Betriebssysteme und Laufzeitumgebungen:
Unterstützte Sprachen
Der Sensor unterstützt die folgenden Sprachen:
- Clojure
- Java
- Kotlin
- Scala
Unterstützte Betriebssysteme
Der Sensor „ Java “ unterstützt die Betriebssysteme, die den Anforderungen der jeweiligen Host-Agenten entsprechen. Diese können im Abschnitt „Unterstützte Betriebssysteme“ des jeweiligen Host-Agenten überprüft werden, beispielsweise unter „Unterstützte Betriebssysteme für Unix “.
Unterstützte „ Java “-Distributionen und Laufzeitumgebungen
Informationen zu den unterstützten „ Java “-Distributionen und -Laufzeitumgebungen finden Sie unter „Unterstützte „ JVM “-Distributionen “.
Unterstützte Frameworks und Bibliotheken für die Ablaufverfolgung
Der „ Java “-Sensor integriert mehrere Frameworks und Bibliotheken für die Ablaufverfolgung. Weitere Informationen finden Sie unter „Instrumentierte Frameworks und Bibliotheken “. Informationen zur veralteten Laufzeitumgebung von „ Java “ 6 finden Sie unter „Instrumentierte Frameworks und Bibliotheken für die veraltete Laufzeitumgebung von „ Java “ 6“
Systemvoraussetzungen
Bevor Sie den „ Instana “-Agenten installieren, stellen Sie sicher, dass die erforderlichen Systemvoraussetzungen erfüllt sind. Weitere Informationen finden Sie unter „Systemanforderungen “.
Instanzagenten installieren
Um „ JVM “ zu überwachen, müssen Sie den Host-Agenten „ Instana “ installieren. Weitere Informationen finden Sie unter „Installieren von Host-Agenten “. Der Agent führt die Bereitstellung, Konfiguration und Installation des „ Java “-Sensors automatisch durch. Um sicherzustellen, dass Ihre „ Java “-Anwendungen instrumentiert sind, vergewissern Sie sich, dass Ihre „ JVM “-Distribution unterstützt wird.
JVMs von der Überwachung ausschließen
Um zu verhindern, dass der Agent „ Instana “ an einen „ JVM “ angehängt wird, können Sie die INSTANA_IGNORE Umgebungsvariable in Ihrer „ trueJVM “-Umgebung auf setzen.
Optional: Konfiguration des Sensors
Nach der Installation des „ Instana “-Agenten wird der „ Java “-Sensor automatisch installiert und konfiguriert. Obwohl Sie keine Konfiguration für sofort einsatzfähige Metriken und verteilte Traceerstellung benötigen, können Sie einzelne Komponenten des Sensors konfigurieren.
Weitere Informationen zur Konfiguration des Sensors finden Sie unter „Konfigurieren des Sensors ‚ Java ‘“.
Sobald der Sensor „ Java “ konfiguriert ist, beginnt er automatisch mit der Erfassung von Metriken aus dem „ JVM “. Sie können diese Kennzahlen in der Benutzeroberfläche von „ Instana “ einsehen. Der „ Java “-Sensor unterstützt zudem weitere Funktionen von „ Instana “, wie beispielsweise automatisches Tracing, benutzerdefiniertes Tracing und automatisches Profiling.
Messdatenerfassung
Der Sensor „ Java “ überwacht die Instanz „ JVM “ und erfasst daraus die folgenden Metriken:
- Konfigurationsdaten
- Leistungsmesswerte
- Signaturen Allgemeinzustand
- Angepasste Messdaten
- Andere Metriken
Führen Sie die folgenden Schritte aus, um diese Metriken anzuzeigen:
- Wählen Sie in der Seitenleiste der Benutzeroberfläche von „ Instana “ die Option „Infrastruktur“ aus.
- Klicken Sie auf einen bestimmten überwachten Host.
Das Dashboard „ JVM “ zeigt alle erfassten Metriken für die Instanz „ JVM “ an.
Konfigurationsdaten
Die folgende Tabelle enthält die Konfigurationsdaten, die von der Instanz „ JVM “ erfasst werden:
| Konfiguration | Beschreibung |
|---|---|
| Java-Version | Die von JVM verwendete Version von „ Java “ |
| Java Runtime | Die Implementierung der Java -Laufzeitumgebung (JRE) |
| Maximaler Heapspeicher | Maximale Heap-Größe für den „ JVM “ |
| Klassenpfad | Der in der Datei „ JVM “ festgelegte Klassenpfad-Parameter |
| JVM-Argumente | Die an den ` JVM ` übergebenen Startoptionen und Konfigurationsparameter |
| Services | Logische Dienstnamen, die von Instana identifiziert und überwacht werden |
Leistungsmetriken
Die folgenden Leistungskennzahlen werden aus der Instanz „ JVM “ erfasst:
Speichermetriken
Die folgende Tabelle fasst die Speicherkennzahlen zusammen, die zur Messung der Speichernutzung im „ JVM “ verwendet werden:
| Leistungsmesswert | Beschreibung | Datenquelle | Einheiten |
|---|---|---|---|
| Belegter Speicher | Gesamtspeicher, der derzeit vom „ JVM “ belegt wird | java.lang.Runtime#totalMemory |
Byte |
| Heapspeicher | Maximale Heap-Größe, die für den „ JVM “ verfügbar ist – Verwendeter Heap-Speicher: Differenz zwischen java.lang.Runtime#totalMemory und java.lang.Runtime#freeMemory. – Maximale Heap-Größe: Wird durch Auswerten des -Xmx Befehlszeilenparameters bestimmt oder aus abgerufen java.lang.Runtime#maxMemory. – Prozentsatz des verwendeten Heap-Speichers: (Verwendeter Heap-Speicher / Gesamter Heap-Speicher) * 100 |
java.lang.Runtime Methoden |
Bytes oder Prozent (%) |
| Speicherpool | Speicherauslastung von Heap- und Nicht-Heap-Pools, dargestellt als Diagramm für einen ausgewählten Zeitraum | ManagementFactory#getMemoryPoolMXBeans |
Byte |
| In Verw. | Größe des derzeit vom „ JVM “ belegten Heap-Speichers (Auslastung und Belegung) | java.lang.management.MemoryUsage |
Verwendung: „ MiB “ (Verwendung: Prozent (%)) |
| Schwimmbad | Name des Speicherbereichs, der vom „ JVM “ verwaltet wird | ManagementFactory#getMemoryPoolMXBeans |
— |
| Frühe Jahre | Anfangsgröße des beim Start von „ JVM “ zugewiesenen Speichers | getInit |
Byte |
| Max | Maximale Speichergröße, die der „ JVM “ diesem Pool zuweisen kann | getMax |
Byte |
| Wert | Derzeit belegter Speicherplatz | getUsage |
Byte |
Thread-Metriken
Die folgende Tabelle fasst die Informationen zu den Thread-Metriken zusammen:
| Leistungsmesswert | Beschreibung | Datenquelle | Einheiten |
|---|---|---|---|
| Threads | Anzahl der Threads, die sich in unterschiedlichen Zuständen befinden, dargestellt in einem Diagramm über einen ausgewählten Zeitraum: new, runnable, timed-waiting, waiting, oder blocked |
java.lang.management.ThreadMXBean#getAllThreadIds |
Anzahl |
| Neu | Anzahl der erstellten, aber noch nicht gestarteten Threads | ThreadMXBean#getThreadInfo |
Anzahl |
| Umsetzbar / umsetzbar | Anzahl der Threads, die ausführbar sind und für die CPU-Ausführung in Frage kommen | ThreadMXBean#getThreadInfo |
Anzahl |
| Zeitverzögert-Warten | Anzahl der Threads, die eine bestimmte Zeit lang warten | ThreadMXBean#getThreadInfo |
Anzahl |
| Wartet | Anzahl der Threads, die eine bestimmte Zeit lang warten | ThreadMXBean#getThreadInfo |
Anzahl |
| Blockiert | Anzahl der Threads, die beim Warten auf eine Sperre blockiert wurden | ThreadMXBean#getThreadInfo |
Anzahl |
Kennzahlen zur Garbage Collection (GC)
Die folgende Tabelle fasst die Informationen zu den Metriken der Garbage Collection zusammen:
| Leistungsmesswert | Beschreibung | Datenquelle | Einheit |
|---|---|---|---|
| Garbage-Collection | Aktivierung der Garbage Collection und Laufzeittwerte, dargestellt in einem Diagramm über einen ausgewählten Zeitraum | - Informationen zur Garbage Collection: ManagementFactory#getGarbageCollectorMXBeans - Werte des Graphen: java.lang.management.GarbageCollectorMXBean |
— |
| PS: Zeit zum Aufräumen | Gesamtzeit für die GC in der Region Young (Eden + Survivor) (kleine GC) | getCollectionTime |
Millisekunden |
| PS: Zeit nach MarkSweep | Gesamtdauer der GC in der Region „Old“ (Haupt-GC) | getCollectionTime |
Millisekunden |
| PS-Scavenge-Aufrufe | Anzahl der kleinen GC-Läufe | getCollectionCount |
Anzahl |
| PS: Anrufe von „ MarkSweep “ | Anzahl der umfangreichen GC-Durchläufe | getCollectionCount |
Anzahl |
- `getCollectionTime` und die Werte von ` `getCollectionCount` ` sind die berechnete Differenz über ein Intervall von ` 1‑second `.
- `getCollectionTime` ist die ungefähre verstrichene Zeit in Millisekunden für die kumulierte Garbage Collection.
- `getCollectionCount` ist die Anzahl der Aufrufe.
Anwendungsmetriken
Die folgende Tabelle fasst Informationen zu den Kennzahlen zur Anwendungsleistung zusammen:
| Leistungsmesswert | Beschreibung | Datenquelle | Einheit |
|---|---|---|---|
| Aussetzung / Unterbrechung | Verzögerung bei der Anwendungsausführung aufgrund von „ JVM “, des Betriebssystems oder der CPU-Planung in der letzten Sekunde. | Berechnet gemäß dem Thread zur Messung von „ Instana “ in der App. | Millisekunden |
Abgeleitete Metriken
In der folgenden Tabelle sind die verfügbaren Kennzahlen aufgeführt, die auf der Grundlage der Leistungskennzahlen abgeleitet werden, welche aus einer „ JVM “-Instanz berechnet werden:
| Leistungsmetriken | Beschreibung | Datenquelle | Metrikname |
|---|---|---|---|
| Speicher nach der Garbage Collection | Die Speichermenge, die eine Anwendung nach dem Ausführen einer Garbage Collection (GC) belegt. Wenn der Sensor „ JVM “ einen globalen Aufruf der Garbage Collection meldet, wird der zu diesem Zeitpunkt vorliegende Speicherwert zur Meldung des Werts „Memory After GC“ herangezogen. | Statistiken zur Speichernutzung und Ereignisse der Garbage Collection | memory.gc.after |
| Speicher vor der Garbage Collection | Die Speichermenge, die eine Anwendung belegt, bevor ein Garbage-Collection-Vorgang (GC) stattfindet. Wenn der Sensor „ JVM “ einen globalen Aufruf der Garbage Collection meldet, wird der Speicherwert vor diesem Aufruf verwendet, um den Wert „Memory Before GC“ anzugeben. | Statistiken zur Speichernutzung und Ereignisse der Garbage Collection | memory.gc.before |
| Speicherbelegung nach GC in Prozent | Der Anteil des gesamten verfügbaren Speichers, den eine Anwendung nach einem Garbage-Collection-Vorgang (GC) belegt. Dies ist der Prozentsatz des nach einer globalen Garbage Collection belegten Speichers im Verhältnis zum maximalen Speicher, den der „ JVM “ genutzt hat. | Statistik zur Speicherauslastung, maximal genutzter Speicher und Statistiken zur Garbage Collection | memory.gc.afterPercentage |
| Speicher vor GC in Prozent | Der Anteil des gesamten verfügbaren Speichers, den eine Anwendung vor einem Garbage-Collection-Vorgang (GC) belegt. Dies ist der Prozentsatz des vor einer globalen Garbage Collection belegten Speichers im Verhältnis zum maximalen Speicher, den der „ JVM “ genutzt hat. | Statistik zur Speicherauslastung, maximal genutzter Speicher und Statistiken zur Garbage Collection | memory.gc.beforePercentage |
Signaturen für Allgemeinzustand
Jeder Sensor verfügt über eine kuratierte Wissensbasis mit Zustandssignaturen, die kontinuierlich anhand der eingehenden Metriken ausgewertet werden. Diese Statussignaturen werden verwendet, um Probleme oder Vorfälle auszulösen, die von Benutzerauswirkungen abhängen.
Vordefinierte Ereignisse lösen Probleme oder Vorfälle aus, wenn die Zustandssignaturen von Entitäten nicht den Vorgaben entsprechen, während benutzerdefinierte Ereignisse Probleme oder Vorfälle auslösen, wenn die Schwellenwerte einer einzelnen Metrik einer beliebigen Entität überschritten werden.
Weitere Informationen zu den integrierten Ereignissen für den Sensor „ Java “ finden Sie in der Referenz zu integrierten Ereignissen.
Angepasste Messdaten
Instana unterstützt einige gängige Bibliotheken für die Messung von Web- Java. Wenn Sie die folgenden Bibliotheken verwenden, können Sie Ihren Anwendungscode manuell instrumentieren, um benutzerdefinierte Metriken zu erfassen:
Weitere Informationen finden Sie unter „Benutzerdefinierte Ablaufverfolgung “.
Verwendung von „ Dropwizard “-Metriken für die Überwachung von „ JVM “
Wenn der „ JVM “ die M etrikbibliothek „ Dropwizard “ lädt, werden benutzerdefinierte Metriken erfasst und im Dashboard „ JVM “ angezeigt. Um eine Überlastung des Back-Ends zu verhindern, gilt ein Standardgrenzwert von 200 Messdaten.
Um die Erfassung von Metriken zu deaktivieren oder deren Begrenzung anzupassen, verwenden Sie die folgende Konfiguration:
com.instana.plugin.java:
dropwizardMetricCollection:
enabled: false
limit: 200
Wenn Sie „ Dropwizard “-Metriken als Teil des „ Dropwizard “-Frameworks verwenden, lesen Sie den Abschnitt „Überwachung“ unter Dropwizard.
Andere Metriken
Neben Konfigurations-, Leistungs- und benutzerdefinierten Metriken erfasst der Sensor „ Java “ auch weitere Metriken, wie beispielsweise Live-Thread-Dumps und Heap-Dumps.
Live-Thread-Speicherauszug
Klicken Sie auf Threadspeicherauszug abrufen, um einen Live-Thread-Speicherauszug für die JVM anzuzeigen.
Heapspeicherauszug
Klicken Sie auf Heapspeicherauszug abrufen, um einen Heapspeicherauszug für die JVM zu erstellen. Um den Heap-Dump zu speichern, geben Sie einen Speicherort an, der sich lokal auf dem „ JVM “ befindet.
Verfolgung von „ Java “-Anwendungen
Der Sensor „ Java “ in „ Instana “ nutzt die folgenden Methoden, um Anwendungen unter Java zu überwachen:
- Instana AutoTrace : Automatische Ablaufverfolgung von „ Java “-Anwendungen ohne manuelle Konfiguration oder Codeänderungen.
- Benutzerdefinierte Ablaufverfolgung : Manuelle Instrumentierung bestimmter Teile des Anwendungscodes von „ Java “, um benutzerdefinierte Metriken zu erfassen und tiefere Einblicke zu gewinnen.
- Instana AutoProfile : Die automatische Profilerstellung von „ Java “-Anwendungen liefert detaillierte Informationen zu Leistung, CPU-Auslastung, Speicherbelegung und anderen Systemressourcen.
Instana AutoTrace
Standardmäßig überwacht der Sensor „ Java “ alle Anfragen und erstellt für jede davon automatisch eine verteilte Ablaufverfolgung. Diese verteilte Ablaufverfolgung umfasst die host- und sprachübergreifende Ablaufverfolgung. Weitere Informationen finden Sie unter Instana AutoTrace™.
Sie können diese Traces in der Benutzeroberfläche von „ Instana “ anzeigen. Weitere Informationen finden Sie unter „Traces und Aufrufe analysieren “.
Protokollierung
Sie können nur Protokolle anzeigen, die der Stufe WARN und höher angehören.
Wenn Log4j, Log4j2 oder Logback verwendet wird, um eine präzisere Korrelation von Protokollierung und Ablaufverfolgung zu ermöglichen, füllt Instana den Mapped Diagnostic Context (MDC) automatisch mit der Trace-ID. Der MDC-Variablenname lautet instana.trace.id. Weitere Informationen zur Verwendung der Protokollierungsframeworks in Formatzeichenfolgen finden Sie in der Dokumentation zu Ihrem Protokollierungsframework.
Angepasstes Tracing
Der „ Java “-Sensor bietet eine vollautomatische, sofort einsatzbereite Tracing-Instrumentierung. In manchen Fällen möchten Sie jedoch vielleicht lieber benutzerdefinierte Traces an Ihr „ Instana “-Dashboard senden. Sie können die folgenden Methoden verwenden, um angepasstes Tracing zu implementieren:
Java-Trace-SDK
Wenn Sie ein Framework instrumentieren möchten, das von Instana noch nicht unterstützt wird, oder die Anfragen einer benutzerdefinierten Anwendung überwachen möchten, verwenden Sie das Java Trace SDK und sehen Sie sich das Repository GitHub an.
Bevor Sie mithilfe des SDK eine benutzerdefinierte Ablaufverfolgung implementieren, lesen Sie bitte die Best Practices zur Ablaufverfolgung.
Konfigurationsbasiertes Java-Trace-SDK
Es kann vorkommen, dass der Einsatz des „ Java Trace SDK“, der eine Bearbeitung des Quellcodes oder die Hinzuziehung einer entsprechenden Fachkraft erfordert, nicht möglich oder nicht wünschenswert ist. Verwenden Sie in diesen Fällen das konfigurationsbasierte „ Java Trace SDK “. Das konfigurationsbasierte „ Java “- Trace-SDK bietet zwar weniger Funktionen als das programmatische „ Java “-Trace-SDK, ermöglicht jedoch eine deklarative Konfiguration von Spans und Tags, die viele gängige Anwendungsfälle abdeckt.
Bevor Sie die benutzerdefinierte Ablaufverfolgung mithilfe des konfigurationsbasierten „ Java “-Trace-SDK implementieren, lesen Sie bitte die Best Practices zur Ablaufverfolgung.
Java OpenTracing API
Um Traces zu erfassen, die über die „ OpenTracing “ ( API ) beschrieben werden, müssen Sie „ Java “ ( OpenTracing ) verwenden. Weitere Informationen finden Sie unter OpenTracing.
OpenCensus-Trace-Exportfunktion von Instana
Instana bietet einen „ OpenCensus -Trace-Exporter“ für Anwendungen, die in „ Java “ geschrieben sind. Instana leitet die von Anwendungen, die mit Census instrumentiert sind, exportierten Traces über die „ Instana “-Agentenprozesse als Proxy an sein Backend weiter.
Weitere Informationen finden Sie unter „ OpenCensus -Exporter “.
Instana AutoProfile
Profile sind für das Feststellen von Leistungsengpässen und Engpässen auf Codeebene unerlässlich. Sie sind maßgeblich an der Verringerung der Ressourcennutzung und der Verbesserung der Leistung beteiligt.
Instana AutoProfile™ erstellt Prozessprofile und übermittelt diese an Instana. Im Gegensatz zu Profilern für die Entwicklungsphase und On-Demand-Profilern, bei denen Sie das Profiling manuell starten müssen, plant „ AutoProfile™ “ das Profiling automatisch und führt es kontinuierlich durch – genau wie es für kritische Produktionsumgebungen erforderlich ist.
Weitere Informationen finden Sie unter Instana AutoProfile™.
Ohne JVMs
Sie können die INSTANA_IGNORE Umgebungsvariable in Ihrer „ trueJVM “-Umgebung auf setzen, um zu verhindern, dass der „ Instana Agent“ an „ JVM “ angehängt wird.
Fehlerbehebung
Bei „ Instana “ können möglicherweise Probleme bei der Überwachung auftreten. Weitere Informationen finden Sie unter Fehlerbehebung.