Bekannte Probleme und Einschränkungen

Informieren Sie sich über die bekannten Probleme und Einschränkungen bei der Überwachbarkeit von „ IBM “ unter Instana.

Bekannte Probleme

Inkompatibilität des „ CrowdStrike Falcon “-Sidecars mit dem „ Instana “-Agenten

Der „ Instana “-Agent-Container ist nicht mit dem „ CrowdStrike Falcon “-Sidecar kompatibel. Sie können Falcon ausschließlich als „ DaemonSet “ nutzen.

Speicherproblem mit dem „ Instana “-Agenten auf dem „ Windows “-Server 2016

Auf Hosts mit „ Windows “ Server 2016 belegt eine vom „ Instana “-Agenten verwendete Bibliothek nach und nach Speicherplatz, ohne diesen ordnungsgemäß freizugeben, was auf den betroffenen „ Windows “-Systemen zu einem erhöhten Speicherverbrauch führen kann. Um den Speicherverbrauch unter Kontrolle zu halten, werden die Agenten von „ Instana “ automatisch neu gestartet. Die Funktion für automatischen Neustart soll verhindern, dass sich das Speicherproblem auf automatische Agentenaktualisierungen auswirkt. Alle „ Instana “-Agenten, die auf einem „ Windows “-Server 2016 installiert sind, werden standardmäßig alle 7 Tage zwischen 05:00 und 05:30 Uhr neu gestartet. Diese Funktion ist seit dem Agent-Bundle „ Instana “ ( 1.1.702 ) verfügbar. Die Version des Agent-Bundles kann in den Startprotokollen des „ Instana “-Agenten überprüft werden.

Um das Standardverhalten beim Neustart zu ändern, legen Sie die folgenden Umgebungsvariablen fest, bevor Sie den „ Instana “-Agenten starten.

Umgebungsvariablenname Standard Hinweis
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_ENABLED true Das Flag zum Aktivieren oder Inaktivieren des automatischen Neustarts.
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME 5:15 Der Zeitpunkt, zu dem der „ Instana “-Agent neu gestartet wird.
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN 30 Die Abweichung (in Minuten) zum Festlegen des Zeitbereichs, in dem der Agent erneut gestartet wird. Der Zeitabstand soll verhindern, dass die Agenten von „ Instana “ gleichzeitig neu gestartet werden. Die Neustartzeit wird zufällig innerhalb des angegebenen Bereichs ausgewählt. Um die Randomisierung der Neustartzeit zu ändern, setzen Sie einen Wert größer als 1. Der Zeitbereich für die Neustartzeit wird mit der Formel INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME -(INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN/2) und INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME + (INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN/2) berechnet. Wenn beispielsweise die Neustartzeit auf 0 5.15 Uhr mit einer Schwankungsbreite von 30 Minuten eingestellt ist, erfolgt der Neustart zwischen 05:00 und 05:30 Uhr.
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_MIN_INTERVAL_IN_DAYS 7 Das Intervall vor dem nächsten Neustart. Legen Sie einen Wert größer als null fest.

Konflikte bei der Agenten-ID aufgrund identischer MAC-Adressen

Wenn mehrere Systeme dieselbe MAC-Adresse verwenden, generieren sie identische Agenten-IDs, was zu Konflikten bei der Host-Identität führt. Dies führt dazu, dass die Agenten die Daten der anderen überschreiben, und Vorgänge eines Hosts werden möglicherweise fälschlicherweise einem anderen Host zugeordnet.

Um dieses Problem zu beheben, können Sie eine der folgenden Konfigurationsoptionen verwenden:

Option 1: FQDN an die Agenten-ID anhängen

Setzen Sie die Umgebungsvariable INSTANA_APPEND_FQDN_TO_AGENT_ID=true so, dass der FQDN in der Agent-ID enthalten ist. Diese Konfiguration stellt sicher, dass jede Agenten-ID eindeutig ist, auch wenn die MAC-Adressen identisch sind.

Verwenden Sie diese Option, wenn mehrere Hosts dieselbe MAC-Adresse haben, aber über eindeutige FQDNs oder Hostnamen verfügen.

Option 2: Host-spezifische ID beibehalten

Setzen Sie die Umgebungsvariable, INSTANA_PERSIST_HOST_UNIQUE_ID=true um eine eindeutige, auf einem Hash basierende Agenten-ID zu generieren und zu speichern. Der Agent generiert beim ersten Start eine eindeutige ID und speichert diese auf der Festplatte, wodurch sichergestellt wird, dass bei jedem Neustart des Agenten dieselbe ID verwendet wird.

Der Agent speichert die ID an den folgenden plattformspezifischen Speicherorten. Wenn der primäre Standort nicht erreichbar ist, versucht der Agent automatisch, auf Ausweichstandorte zurückzugreifen:

Linux oder Unix:
  • Primär: /proc/1/root/var/lib/instana/instana-agent-id (funktioniert in Containern und auf dem Host)
  • Ausweichlösung: /var/lib/instana/instana-agent-id
macOS:
  • Primär: ~/Library/Application Support/com.instana.agent/instana-agent-id (benutzerspezifisch)
  • Ausweichlösung: /Library/Application Support/com.instana.agent/instana-agent-id (systemweit)
Windows:
  • Primär: %LOCALAPPDATA%\Instana\agent\instana-agent-id
  • Alternativ: %APPDATA%\Instana\agent\instana-agent-id oder %PROGRAMDATA%\Instana\agent\instana-agent-id

Sie können diese Pfade überschreiben, indem Sie die INSTANA_AGENT_ID_FILE_PATH=/custom/path/to/instana-agent-idUmgebungsvariable setzen.

Verwenden Sie diese Option, wenn Sie eine stabile Agent-ID benötigen, die auch nach einem Neustart erhalten bleibt, oder wenn Sie in containerisierten Umgebungen arbeiten, in denen MAC-Adressen nur vorübergehend gültig sind.

Option 3: Statische Agenten-ID konfigurieren

Geben Sie in der Agentenkonfigurationsdatei manuell eine statische <instanaAgentDir>/etc/instana/com.instana.agent.main.config.Agent.cfg Agenten-ID an, indem Sie die folgende Zeile hinzufügen:
uniqueAgentId=SomeUniqueString
Ersetzen Sie SomeUniqueString durch Ihre gewünschte eindeutige Kennung. Zum Beispiel:
uniqueAgentId=prod-server-01-custom-id

Verwenden Sie diese Option, wenn Sie die volle Kontrolle über die Agenten-ID benötigen oder eine bestimmte Namenskonvention verwenden möchten.

Hinweis:

Wenn mehrere Konfigurationsoptionen festgelegt sind, wendet der Agent diese in der folgenden Reihenfolge an:

  1. Statische Agenten-ID (uniqueAgentId)
  2. Persistierte eindeutige ID (INSTANA_PERSIST_HOST_UNIQUE_ID)
  3. MAC-basierte ID mit FQDN (INSTANA_APPEND_FQDN_TO_AGENT_ID)
  4. Standard-ID auf MAC-Basis

CRI- API -Verbindungsfehler bei älteren Installationen von Kubernetes und containerd

In „ Kubernetes “-Umgebungen, in denen ältere oder angepasste Versionen von „ RKE2 “ und „Containerd“ ausgeführt werden, kann es vorkommen, dass der Überwachungsagent keine Kommunikation mit der Container-Laufzeitumgebung über die Container Runtime Interface (CRI) herstellen kann gRPC API.

Beispiele für Versionen:

  • Version der Container-Laufzeitumgebung: containerd://1.4.12-k3s1
  • Kubelet-Version: v1.21.8+rke2r1

Dieser Fehler äußert sich in Form von Meldungen wie:

io.grpc.StatusRuntimeException: UNIMPLEMENTED: unknown service runtime.v1.RuntimeService
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:268) ~[?:?]
 

Dieses Problem tritt auf, weil ältere Versionen von Kubernetes und Containerd die vom Agenten erwartete CRI- gRPC API möglicherweise nicht vollständig unterstützen, was zu Verbindungsfehlern bei der Interaktion mit der Container-Laufzeitumgebung führt.

Als Workaround sollten Sie die Umgebungsvariable INSTANA_USE_CONTAINERD_CRI_CLIENT=false auf dem Agenten setzen, um die Interaktion mit der Container-Laufzeitumgebung über den CRI-Client zu deaktivieren. Der Agent verwendet dann ctr zur Erfassung der Metriken.

Bekannte Einschränkungen

Elasticsearch 8.18 + Überwachungsfehler

Ab Version Elasticsearch 8.18.0 kann der Instana -Agent keine Verbindung zu Elasticsearch -JVMs herstellen. Dieser Fehler tritt auf, weil Elasticsearch 8.18.0 dauerhaft von Java SecurityManager auf das Entitlements-Sicherheitsframework umgestellt wurde. Weitere Informationen finden Sie unter Elasticsearch sowie in den Versionshinweisen zu 8.18.0.

Das Sicherheitsframework fängt sensible JDK-Operationen ab, die von dynamisch geladenem Code ausgeführt werden, und schränkt diese ein. Wenn der Instana Agent versucht, die Standard JVM -Attach- API zu verwenden, injiziert er eine Loader-Komponente in die Ziel JVM. Der Loader muss mehrere Vorgänge ausführen, um die Überwachung einzurichten, darunter das Erstellen eines „ ClassLoaders, “ mithilfe des Instrumentation- API s zur Änderung des Bytecodes, das Herstellen einer ausgehenden „ TCP “-Verbindung zum Agenten sowie das Starten von Hintergrund-Threads für die Datenerfassung.

Das Sicherheitsframework von Elasticsearch blockiert diese Vorgänge im Hintergrund. Infolgedessen kann der Loader weder seine Initialisierungssequenz abschließen noch die erforderliche Callback-Verbindung herstellen. Der Mitarbeiter wartet 90 Sekunden auf eine Antwort. Erhält er keine Antwort, markiert der Agent den „ JVM “ als ausgeschlossen und stellt alle Überwachungsversuche ein. Aufgrund dieses Verhaltens kann der Agent „ Instana “ die Prozesse unter Elasticsearch, 8.18 und Java nicht überwachen.

Hinweis: Die Versionen „ Elasticsearch “ ( 8.18 ) und höher werden ab der Agent-Version „ Instana “ ( 1.2.61 ) unterstützt, die unter dem Änderungs-Tag „ 2026.04.16.1110 “ veröffentlicht wurde. Dieses Update bietet durch Bytecode-Transformation Kompatibilität mit dem Berechtigungssystem von „ Elasticsearch “. Dadurch kann der „ Instana “-Agent ordnungsgemäß funktionieren, ohne Sicherheits- oder Berechtigungsverletzungen in „ Elasticsearch “ auszulösen.

Erkennung von Prozessorgruppen unter Windows

Auf „ Windows “-Servern der Modelljahre 2008 bis 2019, die über mehr als 64 Kerne verfügen, kann der „ Instana “-Agent nur die Kerne innerhalb der ihm zugewiesenen Prozessorgruppe überwachen. Diese Einschränkung ergibt sich daraus, dass die aktuelle Version des Agenten nicht prozessgruppenorientiert ist, was bedeutet, dass er die Kerne nicht erkennen kann, die nicht zur Prozessorgruppe gehören.

Analysieren von Traces und Aufrufen

Wenn Aufrufe nach log.level oder log.messagegruppiert werden, wird die spezielle Taggruppe Tag not present nicht auf dieselbe Weise wie andere Tags angezeigt.

Weitere Informationen zu dieser Funktion finden Sie unter „Traces und Aufrufe analysieren “.

Filtern mit dynamischem Fokus

Weitere Informationen zu dieser Funktion finden Sie unter „Filtern mit dynamischem Fokus“

Syntaxeinschränkungen

  • Leerzeichen zwischen dem ! und der Abfrage, die negiert werden soll, sind nicht zulässig. Verwenden Sie stattdessen !<query> oder NOT <query> .
  • Wenn mehrere derselben Schlüsselwörter mit dynamischem Fokus (entity.application.name, entity.service.name, entity.endpoint.name) zusammen verwendet werden, können sie nur durch den Operator OR verknüpft werden. E.g. Die Abfragen werden entity.application.name:foo AND entity.application.name:barnicht unterstützt entity.application.name:foo entity.application.name:bar . Die Abfrage entity.application.name:foo OR entity.application.name:bar wird unterstützt.
  • Wenn mehrere verschiedene Schlüsselwörter mit dynamischem Fokus (entity.application.name, entity.service.name, entity.endpoint.name) zusammen verwendet werden, können sie nur durch den Operator AND verknüpft werden. E.g. Die Abfrage entity.application.name:foo OR entity.service.name:bar wird nicht unterstützt, wohingegen die Abfrage entity.application.name:foo AND entity.service.name:bar unterstützt wird.
  • Abfragen, die eine Negation von Anwendungs-, Service- oder Endpunktnamen enthalten, werden nicht unterstützt. Folglich sind weder NOT entity.application.name:foo, !entity.service.name:bar noch NOT entity.endpoint.name:foobar gültig. Das Ausfiltern von Ereignissen einer Anwendung, eines Service oder eines Endpunkts ist jedoch weiterhin möglich, indem stattdessen NOT event.entity.label:foo verwendet wird.
  • Dynamische Fokusabfragen entity.application.name:<term>, entity.service.name:<term> und entity.endpoint.name:<term> werden mithilfe der Zeichenfolge contains ausgewertet. Beispiel: Dynamische Fokusabfragen entity.application.name:shop stimmen ebenfalls mit entity.application.name:shop-frontendüberein.
  • Die Schlüsselwörter mit dynamischem Fokus entity.application.name, entity.service.name und entity.endpoint.name werden nur in booleschen Abfragen (siehe boolesche Logikeinschränkungen), Bedingungsabfragen, Wortfolgeabfragen und Präfixabfragen unterstützt.

Einschränkungen für Abfragen

  • Eine Abfrage mit dynamischem Fokus für event.text, die Bindestriche enthält, gibt möglicherweise unerwartete Ergebnisse zurück. Für z. event.text:"foo-bar-random" gibt aufgrund der Zerlegung des Lucene-Analyseprogramms auch Ereignisse zurück, die nur foo oder bar oder random enthalten.
  • Entitäten wie der folgende Docker -Container, wie z. B. Host oder Verfügbarkeitszone, können beim Scoping für die meisten Kubernetes -Schlüsselwörter nicht ausgewählt werden. Beispiel: Die Abfrage entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:host gibt keinen Host zurück. Im Gegensatz dazu gibt die Abfrage entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:docker alle Docker-Container zurück, die zur Implementierung gehören. Es gibt jedoch einige wenige Kubernetes-Schlüsselwörter, die verwendet werden können, um Host-Entitäten auswählen zu können, wie z. B. entity.kubernetes.cluster.* und entity.kubernetes.node.*. Beispiel: Die Abfrage entity.kubernetes.cluster.label:my-K8s-cluster AND entity.selfType:host gibt alle zugehörigen Hosts des Clusters zurück.

Infrastrukturmetriken

  • Aus Leistungsgründen können Entitäten in der Benutzeroberfläche von „ Instana “ maximal 3000 Metriken anzeigen. Dashboards mit mehr Metriken als dieser Grenzwert weisen fehlende Metriken auf.
  • Negative Metrikwerte werden nicht angezeigt.

Überwachung des ACE ( IBM App Connect Enterprise )

  • Wenn „ HTTPS “ für die Schnittstelle „ REST API “ aktiviert ist, müssen Sie die Parameter „keystore“ und „ keystorePassword “ <agent_install_dir>/etc/instana/configuration.yamlin der Datei angeben. Für den Keystore-Typ wird nur JKS oder P12 unterstützt.
  • Die ACE-User-Exit-Tracing-Methode unterstützt nur Konfigurationen mit einem einzigen Knoten. Hochverfügbarkeitskonfigurationen (HA) und Clusterumgebungen werden nicht unterstützt. Verwenden Sie bei HA-Bereitstellungen oder Cluster-Umgebungen die native Tracing-Unterstützung von „ OpenTelemetry “ anstelle der User-Exit-Methode.

Weitere Informationen zu dieser Funktion finden Sie unter „Überwachung von ACE ( IBM App Connect Enterprise )“

Überwachung der Anwendung „ IBM API Connect “

  • DataPower Die Nachverfolgung unterstützt nur das „ API “-Gateway und keine anderen Dienste wie das Multiprotokoll-Gateway oder den Webdienst-Proxy.

Weitere Informationen zu dieser Funktion finden Sie unter „Überwachung der Anwendung „ IBM API Connect

Jaeger Nachverfolgung

  • Die von Jaeger erfassten Tracedaten werden nicht mit den Tracedaten korreliert, die über AutoTrace erfasst werden. Dies hat separate Traces zur Folge, selbst dann, wenn die Systeme, die von Jaeger und Instana AutoTrace verfolgt werden, direkt miteinander interagieren.

  • Da die Trace-Daten von „ Jaeger “ keinen Hinweis darauf geben, welcher Prozess sie an den Host-Agenten sendet, ordnet „ Instana “ diese Traces dem Host zu, auf dem der Host-Agent läuft. Dadurch wird die Zuordnung zum Prozess und damit auch zur Container- und Plattformhierarchie (z. B. Pod, Namespace und Cluster unter Kubernetes ) verhindert.

  • Jaeger verfügt über keine Funktionen zur Nutzerüberwachung (auch wenn sich dies mit der Einführung von W3C TraceContext.md möglicherweise ändern wird); daher werden die mit Instana Website Monitoring erfassten Beacons nicht mit den von Jaeger erfassten Backend-Traces abgeglichen.

  • Der Hostagent unterstützt die Erfassung von Jaeger-Traces nur über HTTP. Das Protokoll UDP, das verwendet wird, wenn Sie die Umgebungsvariablen JAEGER_AGENT_HOST und JAEGER_AGENT_PORT konfigurieren, wird nicht unterstützt.

Weitere Informationen zu dieser Funktion finden Sie unter Jaeger

OpenTelemetry Nachverfolgung

  • OpenTelemetrylinks werden nicht unterstützt.
  • Die Kombination des Standard-Kontextpropagators von „ Instana “ mit anderen W3C Trace Context Kontextpropagatoren wird nicht unterstützt. W3C Trace Context ist der Standard-Kontextvermittler von OpenTelemetry.

Weitere Informationen zu dieser Funktion finden Sie unter „ OpenTelemetry -Tracing“

IBM MQ Nachverfolgung

Ein bekanntes Problem auf der Plattform „ Windows “ verhindert die gleichzeitige Verwendung der Zielwarteschlangen-Überwachungsebenen (IBMMQ_DEST_MONITOR_LEVEL_*) und der globalen Überwachungsebene (MONITOR_LEVEL).

Auf der AIX Plattform wird das OTLP gRPC -Protokoll (aktiviert, wenn Sie einstellen) OTLP_EXPORTER_GRPC_ENDPOINT ) ist nicht verfügbar, daher wird standardmäßig HTTP verwendet.

Zipkin Nachverfolgung

  • Die von Zipkin erfassten Tracedaten werden nicht mit den Tracedaten korreliert, die über AutoTrace erfasst werden. Dies hat separate Traces zur Folge, selbst dann, wenn die Systeme, die von Zipkin und Instana AutoTrace verfolgt werden, direkt miteinander interagieren.

  • Zipkin verfügt über keine Funktionen zur Nutzerüberwachung (auch wenn sich dies mit der Einführung von W3C TraceContext.md möglicherweise ändern wird); daher werden die mit Instana Website Monitoring erfassten Beacons nicht mit den von Zipkin erfassten Backend-Traces abgeglichen.

  • Der Hostagent unterstützt die Erfassung von Zipkin-Traces nur über HTTP, was der Einstellung COLLECTOR_HTTP_ENABLED von Zipkin entspricht.

Weitere Informationen zu dieser Funktion finden Sie unter Zipkin

Containerd überwachen

Die Metriken CPU Total Normalized und Memory Working Set Usage % sind nur auf Systemen verfügbar, die die Steuergruppe v1 (cgroupv1) verwenden.

Amazon MSK überwachen

Der Amazon MSK-Sensor unterstützt die Überwachung nur für den bereitgestellten MSK-Clustertyp. Der serverunabhängige Clustertyp wird nicht unterstützt.

ALPN-Unterstützung

Der Agent und das Backend von „ Instana “ unterstützen die ALPN-Verbindung (Application-Layer Protocol Negotiation), sofern die folgenden Voraussetzungen erfüllt sind:

  • Netty 4.1.49.Final oder höher
  • Java Entwicklungsumgebung (JDK) 1.8.0_251 oder höher

Behebung einer hohen CPU-Auslastung

Eine hohe CPU-Auslastung wird bei Hot Spot-basierten Agenten mit Agentencontainer 1.263.3 und früher beobachtet. Installieren Sie den Agenten erneut, um dieses Problem zu lösen. Die Größe des reservierten Code-Cache wurde erhöht, um eine hohe CPU-Auslastung zu unterstützen. Entfernen Sie für die Agenten, die in einer Hostumgebung ausgeführt werden, den Agenten und installieren Sie ihn erneut.

Wenn Sie Kubernetes (k8s) oder OpenShift Container Platform (OCP) verwenden, führen Sie die folgenden Schritte durch:

  1. Agenten deinstallieren:

    kubectl delete agents.instana.io instana-agent -n instana-agent --wait; helm uninstall instana-agent -n instana-agent; kubectl delete crd agents.instana.io; kubectl delete namespace instana-agent
     
  2. Agenten installieren:

    Um den „ Instana “-Agenten zu installieren, verwenden Sie das Diagramm „ Helm “ unter Kubernetes oder OpenShift Container Platform.

Synthetische Testmerkmale

„Jest“ als „ scriptType “ wird für die Tests „Browser Simple“, „ API Script“ und „ API Simple“ auf der Benutzeroberfläche sowie unter API nicht unterstützt. „Jest“ als „ scriptType “ kann nur bei Browser-Skript-Tests verwendet werden.

Einige Attribute für synthetische Tests werden in der Benutzeroberfläche von „ Instana “ nicht unterstützt. Um diese Attribute festzulegen, verwenden Sie den Open- API us oder das synctl Tool. Die nicht unterstützten Attribute in der Benutzeroberfläche von „ Instana “ sind in der folgenden Tabelle aufgeführt:

Testattribut Browser-Script Browser Simple Einfache API API-Script
Browser Nicht zutreffend Nicht zutreffend
expectExists Nicht zutreffend Nicht zutreffend Nicht zutreffend
expectNotEmpty Nicht zutreffend Nicht zutreffend Nicht zutreffend
ScriptType Nicht zutreffend Nicht zutreffend
HEAD (Betrieb) Nicht zutreffend Nicht zutreffend Nicht zutreffend
DELETE (Operation) Nicht zutreffend Nicht zutreffend Nicht zutreffend
OPTIONEN (Bedienung) Nicht zutreffend Nicht zutreffend Nicht zutreffend
PATCH (Operation) Nicht zutreffend Nicht zutreffend Nicht zutreffend
POST (Betrieb) Nicht zutreffend Nicht zutreffend Nicht zutreffend
PUT (Operation) Nicht zutreffend Nicht zutreffend Nicht zutreffend

Das Symbol ☒ zeigt an, dass das Attribut in der Benutzeroberfläche von „ Instana “ nicht unterstützt wird.

N/V gibt an, dass das Attribut für den Testtyp nicht anwendbar ist.

Geschäftsprozesse

Eine bekannte Einschränkung in bestimmten Versionen von „ Business Automation Workflow “ (BAW), die auf dem „ IBM “ laufen J9 JVM, kann die Funktionen der Geschäftsprozesse beeinträchtigen. Dieses Problem kann dazu führen, dass einige oder alle Prozesse im System nicht mehr sichtbar oder nicht mehr zugänglich sind.

Geschäftsperspektiven

Die Registerkarte „Geschäftsperspektiven“ ist deaktiviert, wenn „ Instana “ keine verbundenen Agenten erkennt. Um Ihre Geschäftsperspektiven anzuzeigen, stellen Sie sicher, dass mindestens ein Agent verbunden ist.

Canvas-Rendering

Bestimmte Canvas-Elemente werden in der Benutzeroberfläche von „ Instana “ möglicherweise nicht korrekt dargestellt, wenn Safari verwendet wird. Dazu gehören:

  • Die Abbildung der Geschäftsprozesse
  • Die Infrastruktur-Grafik
  • Die Topologie der wahrscheinlichen Grundursache des Ereignisses
  • Das Diagramm des Konfigurationseditors für den „ OTel “-Collector

Verwenden Sie andere Browser wie Chrome oder Firefox, um eine bessere Darstellung zu erzielen.