Verteiltes Tracing

Im Service-Graphen können Sie die Ansicht für verteiltes Tracing verwenden, um:

• Die Gesamtleistung des Dienstes zu analysieren.

• Den Kommunikationsfluss zwischen dem ausgewählten Dienst und seinen voneinander abhängigen Diensten zu visualisieren.

• Zu identifizieren, welcher Dienst Fehler anzeigt, und den fehlerhaften Dienst zu beheben.

• Transaktionsdetails zwischen dem ausgewählten Dienst und jedem seiner voneinander abhängigen Dienste anzuzeigen.

Voraussetzungen

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

• Sicherstellen, dass eine Anwendung die folgenden Trace-Header beibehält, während sie Ost-West-Traffic sendet:

  

• Für CIC-Builds vor 1.7.23 die CPX-YAML-Datei mit NS_DISTRIBUTED_TRACING und dem Wert yes aktualisieren.

  

• Für CIC-Builds nach 1.7.23 müssen Sie eine ConfigMap verwenden.

  ConfigMaps ermöglichen es Ihnen, Ihre Konfigurationen von Ihren Pods zu trennen und Ihre Workloads portabel zu machen. Mithilfe von ConfigMaps können Sie Ihre Workload-Konfigurationen einfach ändern und verwalten und die Notwendigkeit reduzieren, Konfigurationsdaten in Pod-Spezifikationen fest zu codieren.

  Mit der ConfigMap-Unterstützung können Sie die Konfiguration automatisch aktualisieren, während der NetScaler Ingress Controller-Pod läuft. Sie müssen den Pod nach dem Update nicht neu starten. Weitere Informationen finden Sie unter ConfigMap-Unterstützung für den Ingress-Controller.

  Mithilfe der ConfigMap können Sie verteiltes Tracing, Ereignisse, Audit-Logs usw. aktivieren oder deaktivieren. Um die ConfigMap zu verwenden:

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

     Die folgende Beispiel-YAML-Datei hat das verteilte Tracing 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: <Console-AgentIP> / <Console-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 Console zeigt die angegebene Anzahl von Trace-Transaktionen an.

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

     kubectl create -f <configmap-yaml>.yaml
     <!--NeedCopy-->
     

  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

  

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

     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: <Console-AgentIP> / <Console-AppserverIP>
         timeseries:
           port: 5563
           metrics:
             enable: 'true'
             mode: 'avro'
           auditlogs:
             enable: 'true'
           events:
             enable: 'true'
         transactions:
           enable: 'true'
           port: 5557
     <!--NeedCopy-->
     

  2. Wenden Sie die ConfigMap mit dem folgenden Befehl erneut an:

     kubectl apply -f <yaml-file>.yaml
     <!--NeedCopy-->
     

Dienst-Trace-Details anzeigen

Klicken Sie im Service-Graphen auf einen Dienst und wählen Sie Trace Info aus.

Die Seite “Trace-Zusammenfassung” wird für den ausgewählten Dienst angezeigt.

Die Trace-Zusammenfassung zeigt an:

• Eine erweiterte Suche, die es Ihnen ermöglicht, Transaktionen mit Vorschlägen und Operatoren zu durchsuchen (1). Weitere Informationen finden Sie unter Erweiterte Suche.

• Die Liste der Zeitdauern, die es Ihnen ermöglicht, die Zeitdauer wie 1 Stunde, 12 Stunden, 1 Tag, 1 Woche, 1 Monat und benutzerdefinierte Zeit auszuwählen (2).

• Das Diagramm “Timeline-Details”, das es Ihnen ermöglicht, per Drag & Drop Ergebnisse für eine bestimmte Zeitdauer anzuzeigen (3).

• Das Filter-Panel, das es Ihnen ermöglicht, Optionen aus jeder Metrik auszuwählen (4).

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

Transaktionsdetails anzeigen

Klicken Sie auf eine Transaktion, um detaillierte Informationen anzuzeigen. Sie können Transaktionsdetails für den ausgewählten Dienst anzeigen, wie zum Beispiel:

• Startzeit

• Endzeit

• SSL-Metriken

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

Das folgende Beispiel zeigt einen Fehler vom catalogue-store-service an. Klicken Sie auf Trace-Details anzeigen für weitere Details.

Die Seite “Trace-Details” wird angezeigt.

1 – Zeigt die Startzeit, Antwortzeit, Gesamtzahl der Dienste und Gesamtzahl der Spans für die Transaktion an.

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

3 – Zeigt die Transaktionsdetails für jeden Dienst an.

Gemäß dem Beispielbild zeigte der catalogue-store-service einen Fehler an. Klicken Sie auf die für den catalogue-store-service verfügbare Transaktion.

Die Transaktionsdetails zwischen product-catalogue-service und catalogue-store-service zeigen eine HTTP-Antwort von 500 an. Mit diesen Details können Sie als Administrator den fehlerhaften Dienst analysieren und den product-catalogue-service als Lösung beheben.

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

• Client-RTT: Die Zeitdauer, die ein Paket benötigt, um vom Client zu reisen.

• Server-RTT: Die Zeitdauer, die ein Paket benötigt, um vom Server zu reisen.

• App-Antwortzeit: Die durchschnittliche Antwortzeit der Anwendung.

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

• Standort: Der Client-Standort.

• Browser: Die vom Client verwendeten Browsertypen. Zum Beispiel: Chrome, Firefox.

• Client-Betriebssystem: Das Client-Betriebssystem basierend auf den User-Agent-Details des Browsers.

• Gerät: Die Geräte basierend auf den User-Agent-Details des Browsers. Zum Beispiel: Tablet, Mobiltelefon.

• Anfragetyp: Der Transaktionsanfragetyp. Zum Beispiel: GET.

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

• Antwort-Content-Typ: Der Transaktions-Content-Typ. Wenn die Client-Anfrage für text/html ist, muss die Antwort vom Server text/html sein.

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

• SSL-Cipher-Stärke: Die Cipher-Stärke basierend auf der Schlüsselgröße des SSL-Zertifikats, wie hoch, mittel und niedrig.

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

• SSL-Frontend-Fehlerursache: Die Fehlermeldung des SSL-Handshakes am Frontend. Zum Beispiel: SSL CLIENTAUTH FAILURE.