Verteilte Ablaufverfolgung

• 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

• Sicherstellen, dass eine Anwendung die folgenden Trace-Header beibehält, während sie Ost-West-Verkehr sendet:
  
• Für CIC-Builds vor 1.7.23 aktualisieren Sie die CPX-YAML-Datei mit NS_DISTRIBUTED_TRACING und dem Wert als yes
  
• 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. Mit 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-Protokolle usw. aktivieren oder deaktivieren. So verwenden Sie die ConfigMap:
  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-Protokolle, 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
     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
     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 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
  5. Wenden Sie die ConfigMap mit dem folgenden Befehl erneut an:
     kubectl apply -f <yaml-file>.yaml

Servicetrace-Details anzeigen

• Eine erweiterte Suche, mit der Sie Transaktionen mit Vorschlägen und Operatoren durchsuchen können (1). Weitere Informationen finden Sie unter Erweiterte Suche.
• Die Liste der Zeitdauer, mit der Sie die Zeitdauer wie 1 Stunde, 12 Stunden, 1 Tag, 1 Woche, 1 Monat und benutzerdefinierte Zeit auswählen können (2).
• Das Diagramm „Zeitachsen-Details“, mit dem Sie ziehen und auswählen können, um Ergebnisse für eine bestimmte Zeitdauer anzuzeigen (3).
• Das Filterfenster, mit dem Sie Optionen aus jeder Metrik auswählen können (4).
• Die Transaktionsdetails für den ausgewählten Dienst (5).

Transaktionsdetails anzeigen

• Startzeit
• Endzeit
• SSL-Metriken
• Kommunikation mit voneinander abhängigen Diensten (zusammen mit Fehlern und Antwortzeit bei jedem Dienst).

• Client-RTT: Die Zeitdauer, die ein Paket vom Client benötigt.
• Server-RTT: Die Zeitdauer, die ein Paket vom Server benötigt.
• 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 Standort des Clients
• 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.
• Anforderungstyp: Der Transaktionsanforderungstyp. Zum Beispiel: GET.
• Antwortcode: Der vom Server empfangene Antwortcode. Zum Beispiel: 501, 404, 200.
• Antwort-Inhaltstyp: Der Transaktions-Inhaltstyp. Wenn die Client-Anforderung 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 Schlüsselgröße des SSL-Zertifikats, z. B. hoch, mittel und niedrig.
• SSL-Schlüsselstärke: Die SSL-Chiffrierstä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 Frontend-SSL-Handshakes. Zum Beispiel: SSL CLIENTAUTH FAILURE