Verteilte Ablaufverfolgung

In Service Graph können Sie die Ansicht “Verteilte Ablaufverfolgung” verwenden, um:

• Analysieren Sie die gesamte Leistung des Dienstes.

• Visualisieren Sie den Kommunikationsfluss zwischen dem ausgewählten Dienst und seinen voneinander abhängigen Diensten.

• Identifizieren Sie, welcher Dienst auf Fehler hinweist, und beheben Sie den fehlerhaften Dienst

• Zeigen Sie Transaktionsdetails zwischen dem ausgewählten Service und dem jeweils voneinander abhängigen Service an.

Voraussetzungen

Um die Trace-Informationen für den Dienst anzuzeigen, müssen Sie:

• Stellen Sie sicher, dass eine Anwendung die folgenden Trace-Header verwaltet, während sie Ost-West-Verkehr sendet:

  

• Aktualisieren Sie für CIC-Builds vor 1.7.23 die CPX YAML-Datei mit NS_DISTRIBUTED_TRACING und Wert yes

  

• Für CIC-Builds, die später als 1.7.23sind, müssen Sie eine ConfigMap verwenden.

  ConfigMaps ermöglicht es Ihnen, Ihre Konfigurationen von Ihren Pods zu trennen und Ihre Workloads portabel zu machen. Mit ConfigMaps können Sie Ihre Workload-Konfigurationen einfach ändern und verwalten und den Bedarf an Hardcode-Konfigurationsdaten auf Pod-Spezifikationen reduzieren.

  Mit der ConfigMap-Unterstützung können Sie die Konfiguration automatisch aktualisieren und gleichzeitig den NetScaler Ingress Controller-Pod am Laufen halten. Sie müssen den Pod nach dem Update nicht neu starten. Weitere Informationen finden Sie unter ConfigMap-Unterstützung für den Ingress-Controller.

  Mit ConfigMap können Sie verteilte Ablaufverfolgung, Ereignisse, Überwachungsprotokolle usw. aktivieren oder deaktivieren. So verwenden Sie ConfigMap:

  1. Erstellen Sie eine YAML-Datei mit den erforderlichen Parametern.

     In der folgenden Beispiel-YAML-Datei ist die verteilte Ablaufverfolgung aktiviert und andere Variablen wie Audit-Logs, Ereignisse und Transaktionen deaktiviert:

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cic-configmap
       namespace: default
     data:
       LOGLEVEL: 'debug'
       NS_PROTOCOL: 'http'
       NS_PORT: '80'
       NS_HTTP2_SERVER_SIDE: 'ON'
       NS_ANALYTICS_CONFIG:
         distributed_tracing:
           enable: 'true'
           samplingrate: 100
         endpoint:
           server: <ADM-AgentIP> / <ADM-AppserverIP>
         timeseries:
           port: 5563
           metrics:
             enable: 'true'
             mode: 'avro'
           auditlogs:
             enable: 'false'
           events:
             enable: 'false'
         transactions:
           enable: 'false'
           port: 5557
     <!--NeedCopy-->
     

     Hinweis

     Sie können die Werte für Samplingrate zwischen 0 und 100 angeben. NetScaler ADM zeigt die erwähnte Anzahl von Trace-Transaktionen an.

  2. Stellen Sie die ConfigMap bereit, indem Sie Folgendes verwenden:

     kubectl create -f <configmap-yaml>.yaml

  3. Bearbeiten Sie die CPX YAML-Datei und verwenden Sie entweder envFrom oder args, um die folgenden Argumente anzugeben:

     envFrom:
      - configMapRef:
          name: cic-configmap
     <!--NeedCopy-->
     

     ODER

     

  4. Wenn Sie den Wert für eine Variable ändern möchten, bearbeiten Sie die Werte in der ConfigMap. In diesem Beispiel werden alle anderen Variablen von false in geändert true.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cic-configmap
       namespace: default
     data:
       LOGLEVEL: 'debug'
       NS_PROTOCOL: 'http'
       NS_PORT: '80'
       NS_HTTP2_SERVER_SIDE: 'ON'
       NS_ANALYTICS_CONFIG:
         distributed_tracing:
           enable: 'true'
           samplingrate: 100
         endpoint:
           server: <ADM-AgentIP> / <ADM-AppserverIP>
         timeseries:
           port: 5563
           metrics:
             enable: 'true'
             mode: 'avro'
           auditlogs:
             enable: 'true'
           events:
             enable: 'true'
         transactions:
           enable: 'true'
           port: 5557
       <!--NeedCopy-->
     

  5. Wenden Sie ConfigMap erneut mit dem folgenden Befehl an:

     kubectl apply -f <yaml-file>.yaml

Details zur Service-Ablaufverfolgung anzeigen

Klicken Sie im Service-Graph auf einen Service, und wählen Sie Informationen zur Ablaufverfolgungaus.

Die Seite “Ablaufverfolgungszusammenfassung” wird für den ausgewählten Service angezeigt.

Die Zusammenfassung der Ablaufverfolgung zeigt an:

• Eine erweiterte Suche, mit der Sie nach Transaktionen mit Vorschlägen und Operatoren suchen können (1). Weitere Informationen finden Sie unter Erweiterte Suche.

• Die Liste der Zeitdauer, mit der Sie die Zeitdauer auswählen können, z. B. 1 Stunde, 12 Stunden, 1 Tag, 1 Woche, 1 Monat und benutzerdefinierte Zeit (2).

• Das Diagramm “Zeitleistendetails”, mit dem Sie die Ergebnisse für eine bestimmte Zeitdauer durch Ziehen und Auswählen anzeigen können (3).

• Das Bedienfeld “Filter”, in dem Sie Optionen aus jeder Metrik auswählen können (4).

• Die Transaktionsdetails für den ausgewählten Dienst (5).

Zeigen Sie die Transaktionsdetails an

Klicken Sie auf eine Transaktion, um detaillierte Informationen zu erhalten. Sie können Transaktionsdetails für den ausgewählten Service anzeigen, z. B.:

• Startzeit

• Endzeit

• SSL-Metriken

• Kommunikation mit voneinander abhängigen Diensten (zusammen mit Fehlern und Reaktionszeit bei jedem Dienst).

Das folgende Beispiel weist auf einen Fehler von hin catalogue-store-service. Klicken Sie auf Verfolgungsdetails anzeigen, um weitere Informationen zu

Die Seite “Verfolgungsdetails” wird angezeigt.

1 — Zeigt die Startzeit, die Antwortzeit, die Gesamtzahl der Services und die gesamten Spannweiten für die Transaktion an.

2 — Zeigt die Details für den ausgewählten Dienst an, der mit seinen Interdependency-Diensten kommuniziert hat. Sie können auf jede Transaktion klicken, um Details anzuzeigen.

3 — Zeigt die Transaktionsdetails für jeden Service an.

Laut Beispielbild, zeigt catalogue-store-service einen Fehler an. Klicken Sie auf die verfügbare Transaktion catalogue-store-service.

Die Transaktionsdetails zwischen product-catalogue-service und catalogue-store-service geben die HTTP-Antwort als 500 an. Mit diesen Details können Sie als Administrator den fehlerhaften Dienst analysieren und Fehler in product-catalogue-service beheben.

Sie können Ergebnisse auch filtern, indem Sie Optionen aus jeder Metrik im Bereich Filter auswählen. Wenn Sie beispielsweise alle 5xx-Transaktionen anzeigen möchten, klicken Sie auf Antwortcode und wählen Sie 500aus.

• Client RTT: Die Zeitdauer für die Übertragung eines Pakets vom Client.

• Server-RTT: Die Zeitdauer, während der ein Paket vom Server übertragen wird.

• Reaktionszeit der App: Die durchschnittliche Antwortzeit der Anwendung

• Datenübertragungszeit: Die Datenübertragungsgröße und die Geschwindigkeit, mit der die Übertragung von/zu einem Dienst erfolgen kann.

• Standort: Der Kundenstandort

• Browser: Die von den Clients verwendeten Browsertypen. Zum Beispiel: Chrome, Firefox.

• Client-Betriebssystem: Das Clientbetriebssystem, das auf den Benutzeragentdetails aus dem Browser basiert.

• Gerät: Die Geräte, die auf den Benutzeragentdetails aus dem Browser basieren. Zum Beispiel: Tablet, Handy.

• Anforderungstyp: Der Transaktionsanforderungstyp Zum Beispiel: GET.

• Antwortcode: Der vom Server empfangene Antwortcode. Zum Beispiel: 501, 404, 200.

• Inhaltstyp der Antwort: Der Inhaltstyp der Transaktion. Wenn die Clientanforderung für text/html ist, muss die Antwort vom Server text/html lauten.

• SSL-Protokoll: Die von den Clients verwendete SSL-Protokollversion. Zum Beispiel: SSLv3.

• SSL-Verschlüsselungsstärke: Die Verschlüsselungsstärke basierend auf der Schlüsselgröße des SSL-Zertifikats, z. B. hoch, mittel und niedrig.

• SSL-Schlüsselstärke: Die SSL-Verschlüsselungsstärke wird anhand der Schlüsselgröße des SSL-Zertifikats berechnet. Die Schlüssellänge definiert die Sicherheit des SSL-Algorithmus. Zum Beispiel: 2048

• SSL Front-End-Grund: Die Fehlermeldung Front-End-SSL-Handshake. Beispiel: SSL CLIENTAUTH FAILURE