Verteiltes Tracing

Im Service-Graph 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 jeglicher Ost-West-Verkehr gesendet wird:

  

• 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 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 und so weiter 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: <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 angegebene 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 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: <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 die ConfigMap mit dem folgenden Befehl erneut an:

     kubectl apply -f <yaml-file>.yaml

Dienst-Trace-Details anzeigen

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

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

Die Trace-Zusammenfassung zeigt:

• 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 auszuwählen, z. B. 1 Stunde, 12 Stunden, 1 Tag, 1 Woche, 1 Monat und benutzerdefinierte Zeit (2).

• Das Diagramm „Zeitachsen-Details“, das es Ihnen ermöglicht, Ergebnisse für eine bestimmte Zeitdauer zu ziehen und auszuwählen (3).

• Das Filterpanel, 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. 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 den HTTP-Antwortcode 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 die Ergebnisse auch filtern, indem Sie Optionen aus jeder Metrik unter dem Filterpanel auswählen. Wenn Sie beispielsweise alle 5xx-Transaktionen anzeigen möchten, klicken Sie auf Antwortcode und wählen Sie 500.

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

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

• Anwendungs-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 von den Clients 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-Chiffrierstärke: Die Chiffrierstärke basierend auf der SSL-Zertifikatsschlüsselgröße, z. B. hoch, mittel und niedrig.

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

• Grund für SSL-Frontend-Fehler: Die Fehlermeldung des SSL-Handshakes am Frontend. Zum Beispiel: SSL CLIENTAUTH FAILURE.