Fehlerbehebung

Typ der Überwachungsausgabe: java_8_unmonitored_version

Dieses Überwachungsproblem deutet darauf hin, dass Ihre Java-Anwendung auf einer nicht unterstützten virtuellen Java 8-Hotspot-Maschine mit einer früheren Version als 1.8.0_40 ausgeführt wird. Instana überwacht keine Java-Anwendungen, die auf einer solchen virtuellen Hotspot-Maschine laufen, da diese schwerwiegende Fehler aufweisen, die zu Inkompatibilitäten und Abstürzen führen.

Um das Problem zu beheben, aktualisieren Sie die JVM auf eine neuere Version, vorzugsweise JDK 8 252 oder höher, oder auf eine andere Version mit Langzeitunterstützung für Java.

Weitere Informationen zu den von Instana unterstützten JVMs finden Sie in der JVM-Support-Dokumentation.

Typ der Überwachungsausgabe: jvm_incompatible_agent_detected

Dieses Überwachungsproblem zeigt an, dass der Instana-Agent einen inkompatiblen Agenten entdeckt hat, der an die JVM angehängt ist. Um Probleme mit der JVM zu vermeiden, sammelt der Instana-Agent keine Tracing-Daten von der Anwendung, die innerhalb der JVM ausgeführt wird. Diese Unterbrechung kann zu fehlenden Daten führen, die sich auf Anwendungsperspektiven, Dienste und Endpunkte beziehen, sowie zu falschen Warnungen über unterbrochene Aufrufe von Anwendungsperspektiven, Diensten und Endpunkten.

Um das Problem zu beheben, entfernen Sie den inkompatiblen Agenten aus Ihrer JVM.

Typ der Überwachungsausgabe: jvm_attach_socket

Dieses Überwachungsproblem deutet darauf hin, dass die Attachment-Funktion der JVM feststeckt, was bekanntermaßen gelegentlich aufgrund von langjährigen Fehlern der JVM vorkommt. Infolgedessen ist die JVM nicht in der Lage, eine Verbindung zu einem während des dynamischen Anhängens verwendeten Kommunikationssocket herzustellen.

Um dieses Problem zu beheben, starten Sie die JVM neu.

Typ der Überwachungsausgabe: jvm_attach_network

Dieses Problem deutet darauf hin, dass die JVM-Instrumentierung aufgrund von Problemen mit der Netzwerksichtbarkeit der JVM und des Host-Agenten fehlschlägt. Um diesen Fehler zu vermeiden, stellen Sie sicher, dass der Host-Agent von der JVM aus erreichbar ist, wie in der Dokumentation zu den Netzwerkanforderungen beschrieben. Überprüfen Sie in Container-Umgebungen die Netzwerkrichtlinien und -konfigurationen, um dieses Problem zu vermeiden.

Typ der Überwachungsausgabe: jvm_attach_tools

Dieses Überwachungsproblem weist darauf hin, dass das JDK, das während des dynamischen Attachings verwendet wird, nicht den erforderlichen Attach-Code enthält. Weitere Informationen finden Sie in den Abschnitten Java 8 oder früher und Java 9 oder später.

Typ der Überwachungsausgabe: jvm_attach_directory

Dieses Problem zeigt an, dass der dynamische Anhang nicht funktioniert, weil das Anhangsverzeichnis nicht gefunden wurde.

Führen Sie eine der folgenden Aktionen durch, um dieses Problem zu beheben:

• Stellen Sie sicher, dass der JVM-Prozess des Host-Agenten und der Ziel-JVM-Prozess mit denselben Einstellungen für die Umgebungsvariablen gestartet werden, die den Speicherort der temporären Verzeichnisse steuern
• Weisen Sie den Ziel-JVM-Prozess an, Arbeitsdateien für dynamische Anhänge dort abzulegen, wo der Agent sie standardmäßig erwartet. Wenn IBM J9 auf einem POSIX -kompatiblen System verwendet wird, fügen Sie das folgende Befehlszeilenargument ein, wenn der Ziel-JVM-Prozess gestartet wird:

-Dcom.ibm.tools.attach.directory=/tmp/.com_ibm_tools_attach
 

Typ der Überwachungsausgabe: jvm_instrumentation_shared_absent

Dieses Überwachungsproblem zeigt an, dass die Datei /tmp/.instana/instrumentation-shared-<version>-<pid>-<string>.jar gelöscht wurde, wenn der Javaagent-Loader mit einer JVM verbunden ist. Diese Datei wird zur Laufzeit für bestimmte Konfigurationen benötigt. Ohne diese Datei funktioniert das Java-Tracing möglicherweise nicht richtig. Wenn die Datei zur Laufzeit gelöscht wird, gibt der Java-Tracer möglicherweise Warnungen aus und wird nicht mehr aktualisiert.

Der Agent schließt die Verbindung zur JVM von selbst und startet einen neuen Anhang, um dieses Problem zu lösen.

Typ der Überwachungsausgabe: jvm_custom_classloader_unsupported

Dieses Überwachungsproblem zeigt an, dass der Agent eine Ziel-JVM entdeckt hat, die mit einem "benutzerdefinierten Systemklassenlader" gestartet wurde. Dynamisches Attachment wird für solche JVMs nicht unterstützt, da der benutzerdefinierte Klassenlader das standardmäßige Klassenladeverhalten ändert, das für die Agenteninstrumentierung erforderlich ist.

Die JVM wird in diesem Fall typischerweise mit dem folgenden Argument gestartet:

-Djava.system.class.loader=com.sas.app.AppClassLoader

Diese Option ersetzt den standardmäßigen System Class Loader durch eine benutzerdefinierte Implementierung, die verhindern kann, dass der Agent zur Laufzeit Klassen instrumentiert oder injiziert. Infolgedessen werden diese JVMs vor dem Anhängen ausgeschlossen, und dieses Überwachungsereignis wird ausgelöst

Typ der Überwachungsausgabe: insufficient_disk_space_for_storing_temp_files

Während der Laufzeit erstellt der Instana-Host-Agent temporäre JAR-Dateien im Verzeichnis $TMP/.instana . Diese JAR-Dateien sind für die JVM-Überwachung erforderlich. Dieses Problem weist darauf hin, dass die erforderlichen JAR-Dateien aufgrund der begrenzten Speicherkapazität nicht auf das Hostsystem oder in die Anwendungscontainer geladen werden können, die der Agent zu überwachen versucht.

Sie können dieses Problem entschärfen, indem Sie ein Flag IN_MEMORY_CLASSLOADER=true als Systemeigenschaft oder als Umgebungsvariable setzen. Nachdem Sie diese Option aktiviert haben, wird der erforderliche Speicherplatz für die JVM-Überwachung auf 3.5 MB reduziert. Weitere Informationen finden Sie unter Umgebungsvariablen - Host Agent.

Typ der Überwachungsausgabe: default_agent_port_unavailable

Dieses Überwachungsproblem zeigt an, dass der Agent sich nicht an den Standardport 42699 binden kann. Infolgedessen fallen verschiedene Sensoren aus, und eine Überwachung mit voller Kapazität ist möglicherweise nicht möglich. Weitere Informationen finden Sie unter Netzwerkanforderungen.

Um das Problem zu beheben, stellen Sie sicher, dass der Port 42699 verfügbar ist, und starten Sie den Agenten neu, um die vollständige Überwachung wiederherzustellen.

Typ der Überwachungsausgabe: jvm_attach_container_command

Dieses Überwachungsproblem zeigt an, dass der Befehl zum dynamischen Anhängen an eine containerisierte JVM nicht erfolgreich war.

Weitere Informationen finden Sie im Exit-Code der jeweiligen Ereignisbeschreibung.

Typ der Überwachungsausgabe: ibm_jvm_class_sharing_enabled

Dieses Überwachungsproblem zeigt an, dass die Klassenfreigabefunktion für diese JVM aktiviert ist. Daher können Sie keine Pfändung vornehmen und keine Urkunde erstellen. Weitere Informationen zur Behebung dieses Problems finden Sie unter IBM J9 limitations.

Typ der Überwachungsausgabe: jvm_attach_generic

Dieses Überwachungsproblem zeigt an, dass ein unbekanntes Problem mit der JVM verbunden ist. Daher kann dieser Prozess nicht nachverfolgt werden und es können keine JVM-Metriken erfasst werden. Die Agentenprotokolle müssen genauere Angaben über den Grund für das Scheitern der Verbindung enthalten. Um dieses Problem zu lösen, reichen Sie ein Ticket ein und fügen Sie die Protokolle bei.

Die Erfassung von Stack Traces für Anwendungen mit tieferen Stacks oder Anfragen mit mehreren Spans kann die Anwendungsleistung beeinträchtigen. Um die Leistung zu optimieren, müssen Sie die Aufzeichnung von Stack Traces deaktivieren. Weitere Informationen finden Sie unter Deaktivieren der Stack-Trace-Aufzeichnung. `

Wenn sowohl Log4j als auch SLF4J Abhängigkeiten in Ihrem Klassenpfad vorhanden sind, können Sie zwei Spannen für eine einzelne Protokollmeldung beobachten, eine für jedes Protokollierungs-Framework. Dieses Verhalten tritt besonders häufig auf, wenn Sie die Abhängigkeit spring-boot-starter-log4j2 verwenden, was zu doppelten Protokollspannen führt.

Um doppelte Protokollierungsspannen zu vermeiden, führen Sie einen der folgenden Schritte aus:

• Schließen Sie eine der Logging-Abhängigkeiten aus der Datei pom.xml aus.
• Deaktivieren Sie eines der Plugins für die Protokollierung, wie im folgenden Beispiel gezeigt:

  com.instana.plugin.javatrace:
  instrumentation:
    plugins:
      Slf4jExit: false
   

  Diese Konfiguration deaktiviert das SLF4J Plugin und behält nur die Log4j Ablaufverfolgung bei, wodurch sichergestellt wird, dass nur ein einziger Bereich pro Protokollmeldung erzeugt wird.

Die folgenden Einschränkungen gelten bei der Verwendung von Instana-Tracern in Java-Umgebungen:

• Instana-Tracer erfassen ausgehende Anrufe nur, wenn ein aktiver Eintragsbereich existiert. Wenn erwartete Aufrufe ausbleiben, kann das daran liegen, dass zu diesem Zeitpunkt kein aktiver Trace lief.

• In Java kann die Methode public static void main nicht instrumentiert werden, da sie die Ausführung beginnen oder beenden könnte, bevor der Tracer bereit ist, sich anzuhängen.

• Java-Tracing unterstützt nicht die Aktivierung von Root-Exit-Spans durch die Verwendung der Umgebungsvariablen INSTANA_ALLOW_ROOT_EXIT_SPAN .