Citrix ADM zur Fehlerbehebung bei Citrix Cloud™ Native Networking verwenden

Übersicht

In diesem Dokument erfahren Sie, wie Sie Citrix ADM zur Bereitstellung und Überwachung von Kubernetes-Microservice-Anwendungen verwenden können. Wir gehen auch auf die Verwendung von CLI, Service-Graphen und Tracing ein, um den Plattform- und SRE-Teams die Fehlerbehebung zu ermöglichen.

Übersicht über Anwendungsleistung und Latenz

TLS-Verschlüsselung

TLS ist ein Verschlüsselungsprotokoll, das zur Sicherung der Internetkommunikation entwickelt wurde. Ein TLS-Handshake ist der Prozess, der eine Kommunikationssitzung beginnt, die TLS-Verschlüsselung verwendet. Während eines TLS-Handshakes tauschen die beiden kommunizierenden Seiten Nachrichten aus, um sich gegenseitig zu bestätigen, zu verifizieren, die verwendeten Verschlüsselungsalgorithmen festzulegen und sich auf Sitzungsschlüssel zu einigen. TLS-Handshakes sind ein grundlegender Bestandteil der Funktionsweise von HTTPS.

TLS- vs. SSL-Handshakes

SSL, oder Secure Sockets Layer, war das ursprüngliche Verschlüsselungsprotokoll, das für HTTP entwickelt wurde. TLS, Transport Layer Security, hat SSL vor einiger Zeit ersetzt. SSL-Handshakes werden heute als TLS-Handshakes bezeichnet, obwohl der Name „SSL“ immer noch weit verbreitet ist.

Wann findet ein TLS-Handshake statt?

Ein TLS-Handshake findet immer dann statt, wenn ein Benutzer über HTTPS zu einer Website navigiert und der Browser beginnt, den Ursprungsserver der Website abzufragen. Ein TLS-Handshake findet auch statt, wenn andere Kommunikationen HTTPS verwenden, einschließlich API-Aufrufen und DNS-over-HTTPS-Abfragen.

TLS-Handshakes erfolgen, nachdem eine TCP-Verbindung über einen TCP-Handshake geöffnet wurde.

Was passiert während eines TLS-Handshakes?

• Während eines TLS-Handshakes führen Client und Server gemeinsam Folgendes aus:
  • Geben Sie an, welche TLS-Version (TLS 1.0, 1.2, 1.3 usw.) sie verwenden.
  • Entscheiden Sie, welche Cipher Suites (siehe nächster Abschnitt) sie verwenden.
  • Authentifizierung der Identität des Servers über den öffentlichen Schlüssel des Servers und die digitale Signatur der SSL-Zertifizierungsstelle.
  • Generieren von Sitzungsschlüsseln zur Verwendung symmetrischer Verschlüsselung nach Abschluss des Handshakes.

Was sind die Schritte eines TLS-Handshakes?

• TLS-Handshakes sind eine Reihe von Datagrammen oder Nachrichten, die zwischen einem Client und einem Server ausgetauscht werden. Ein TLS-Handshake umfasst mehrere Schritte, da Client und Server die notwendigen Informationen austauschen, um den Handshake abzuschließen und eine weitere Kommunikation zu ermöglichen.

Die genauen Schritte innerhalb eines TLS-Handshakes variieren je nach Art des verwendeten Schlüsselaustauschalgorithmus und den von beiden Seiten unterstützten Cipher Suites. Der RSA-Schlüsselaustauschalgorithmus wird am häufigsten verwendet. Er läuft wie folgt ab:

1. Die „Client Hello“-Nachricht: Der Client initiiert den Handshake, indem er eine „Hello“-Nachricht an den Server sendet. Die Nachricht enthält die vom Client unterstützte TLS-Version, die unterstützten Cipher Suites und eine Zeichenfolge zufälliger Bytes, die als „Client Random“ bekannt ist.
2. Die „Server Hello“-Nachricht: Als Antwort auf die Client Hello-Nachricht sendet der Server eine Nachricht, die das SSL-Zertifikat des Servers, die vom Server gewählte Cipher Suite und das „Server Random“ enthält, eine weitere zufällige Zeichenfolge von Bytes, die vom Server generiert wird.
3. Authentifizierung: Der Client überprüft das SSL-Zertifikat des Servers bei der ausstellenden Zertifizierungsstelle. Dies bestätigt, dass der Server derjenige ist, der er vorgibt zu sein, und dass der Client mit dem tatsächlichen Eigentümer der Domäne interagiert.
4. Das Premaster Secret: Der Client sendet eine weitere zufällige Zeichenfolge von Bytes, das „Premaster Secret“. Das Premaster Secret wird mit dem öffentlichen Schlüssel verschlüsselt und kann nur mit dem privaten Schlüssel vom Server entschlüsselt werden. (Der Client erhält den öffentlichen Schlüssel aus dem SSL-Zertifikat des Servers.)
5. Privater Schlüssel verwendet: Der Server entschlüsselt das Premaster Secret.
6. Sitzungsschlüssel erstellt: Sowohl Client als auch Server generieren Sitzungsschlüssel aus dem Client Random, dem Server Random und dem Premaster Secret. Sie sollten zu den gleichen Ergebnissen kommen.
7. Client ist bereit: Der Client sendet eine „Finished“-Nachricht, die mit einem Sitzungsschlüssel verschlüsselt ist.
8. Server ist bereit: Der Server sendet eine „Finished“-Nachricht, die mit einem Sitzungsschlüssel verschlüsselt ist.
9. Sichere symmetrische Verschlüsselung erreicht: Der Handshake ist abgeschlossen, und die Kommunikation wird unter Verwendung der Sitzungsschlüssel fortgesetzt.

Alle TLS-Handshakes verwenden asymmetrische Verschlüsselung (den öffentlichen und privaten Schlüssel), aber nicht alle verwenden den privaten Schlüssel bei der Generierung von Sitzungsschlüsseln. Ein ephemerer Diffie-Hellman-Handshake läuft beispielsweise wie folgt ab:

1. Client Hello: Der Client sendet eine Client-Hello-Nachricht mit der Protokollversion, dem Client-Zufallswert und einer Liste von Cipher Suites.
2. Server Hello: Der Server antwortet mit seinem SSL-Zertifikat, seiner ausgewählten Cipher Suite und dem Server-Zufallswert. Im Gegensatz zum im vorherigen Abschnitt beschriebenen RSA-Handshake enthält der Server in dieser Nachricht auch Folgendes (Schritt 3).
3. Digitale Signatur des Servers: Der Server verwendet seinen privaten Schlüssel, um den Client-Zufallswert, den Server-Zufallswert und seinen DH-Parameter* zu verschlüsseln. Diese verschlüsselten Daten fungieren als digitale Signatur des Servers und belegen, dass der Server den privaten Schlüssel besitzt, der mit dem öffentlichen Schlüssel des SSL-Zertifikats übereinstimmt.
4. Digitale Signatur bestätigt: Der Client entschlüsselt die digitale Signatur des Servers mit dem öffentlichen Schlüssel und überprüft so, ob der Server den privaten Schlüssel kontrolliert und die Identität besitzt, die er vorgibt. Client-DH-Parameter: Der Client sendet seinen DH-Parameter an den Server.
5. Client und Server berechnen das Premaster Secret: Anstatt dass der Client das Premaster Secret generiert und an den Server sendet, wie bei einem RSA-Handshake, verwenden Client und Server die ausgetauschten DH-Parameter, um ein übereinstimmendes Premaster Secret separat zu berechnen.
6. Sitzungsschlüssel erstellt: Nun berechnen Client und Server die Sitzungsschlüssel aus dem Premaster Secret, dem Client-Zufallswert und dem Server-Zufallswert, genau wie bei einem RSA-Handshake.
   • Client ist bereit: Wie bei einem RSA-Handshake
   • Server ist bereit
   • Sichere symmetrische Verschlüsselung erreicht

   *DH-Parameter: DH steht für Diffie-Hellman. Der Diffie-Hellman-Algorithmus verwendet exponentielle Berechnungen, um zum selben Premaster Secret zu gelangen. Server und Client stellen jeweils einen Parameter für die Berechnung bereit, und wenn diese kombiniert werden, ergeben sie auf jeder Seite eine unterschiedliche Berechnung mit gleichen Ergebnissen.

Um mehr über den Unterschied zwischen ephemeren Diffie-Hellman-Handshakes und anderen Arten von Handshakes sowie darüber, wie sie Forward Secrecy erreichen, zu erfahren, lesen Sie diese TLS-Protokolldokumentation.

Was ist eine Cipher Suite?

• Eine Cipher Suite ist eine Reihe von Verschlüsselungsalgorithmen, die zur Herstellung einer sicheren Kommunikationsverbindung verwendet werden. (Ein Verschlüsselungsalgorithmus ist eine Reihe mathematischer Operationen, die an Daten durchgeführt werden, um die Daten zufällig erscheinen zu lassen.) Es gibt verschiedene weit verbreitete Cipher Suites, und ein wesentlicher Bestandteil des TLS-Handshakes ist die Einigung darüber, welche Cipher Suite für diesen Handshake verwendet wird.

Zum Einstieg siehe Referenz: TLS-Protokolldokumentation.

Citrix Application Delivery Management SSL-Dashboard

Citrix Application Delivery Management (ADM) optimiert jetzt jeden Aspekt der Zertifikatsverwaltung für Sie. Über eine einzige Konsole können Sie automatisierte Richtlinien festlegen, um den richtigen Aussteller, die Schlüsselstärke und die korrekten Algorithmen sicherzustellen, während Sie gleichzeitig ungenutzte oder bald ablaufende Zertifikate genau im Auge behalten. Um das SSL-Dashboard von Citrix ADM und seine Funktionen nutzen zu können, müssen Sie verstehen, was ein SSL-Zertifikat ist und wie Sie Citrix ADM verwenden können, um Ihre SSL-Zertifikate zu verfolgen.

Ein Secure Socket Layer (SSL)-Zertifikat, das Teil jeder SSL-Transaktion ist, ist eine digitale Datenform (X509), die ein Unternehmen (Domäne) oder eine Einzelperson identifiziert. Das Zertifikat enthält eine öffentliche Schlüsselkomponente, die für jeden Client sichtbar ist, der eine sichere Transaktion mit dem Server initiieren möchte. Der entsprechende private Schlüssel, der sicher auf der Citrix Application Delivery Controller™ (ADC)-Appliance gespeichert ist, wird verwendet, um die asymmetrische Schlüssel-(oder Public-Key-)Verschlüsselung und -Entschlüsselung abzuschließen.

Sie können ein SSL-Zertifikat und einen Schlüssel auf eine der folgenden Arten erhalten:

• Von einer autorisierten Zertifizierungsstelle (CA)
• Durch Generieren eines neuen SSL-Zertifikats und Schlüssels auf der Citrix ADC-Appliance

Citrix ADM bietet eine zentralisierte Ansicht der SSL-Zertifikate, die auf allen verwalteten Citrix ADC-Instanzen installiert sind. Auf dem SSL-Dashboard können Sie Diagramme anzeigen, die Ihnen helfen, Zertifikatsaussteller, Schlüsselstärken, Signaturalgorithmen, abgelaufene oder ungenutzte Zertifikate usw. zu verfolgen. Sie können auch die Verteilung der SSL-Protokolle sehen, die auf Ihren virtuellen Servern ausgeführt werden, und die Schlüssel, die darauf aktiviert sind.

Sie können auch Benachrichtigungen einrichten, die Sie informieren, wenn Zertifikate kurz vor dem Ablauf stehen, und Informationen darüber enthalten, welche Citrix ADC-Instanzen diese Zertifikate verwenden.

Sie können die Zertifikate einer Citrix ADC-Instanz mit einem CA-Zertifikat verknüpfen. Stellen Sie jedoch sicher, dass die Zertifikate, die Sie mit demselben CA-Zertifikat verknüpfen, dieselbe Quelle und denselben Aussteller haben. Nachdem Sie die Zertifikate mit einem CA-Zertifikat verknüpft haben, können Sie die Verknüpfung wieder aufheben.

Informationen zum Einstieg finden Sie in der folgenden SSL-Dashboard-Dokumentation.

Integrationen von Drittanbietern

Die Anwendungslatenz wird in Millisekunden gemessen und kann je nach verwendeter Metrik zwei Dinge anzeigen. Die gebräuchlichere Methode zur Messung der Latenz wird als „Round-Trip Time“ (oder RTT) bezeichnet. RTT berechnet die Zeit, die ein Datenpaket benötigt, um von einem Punkt zu einem anderen im Netzwerk zu gelangen und eine Antwort an die Quelle zurückzusenden. Die andere Messung wird als „Time to First Byte“ (oder TTFB) bezeichnet, die die Zeit aufzeichnet, die von dem Moment an vergeht, in dem ein Paket einen Punkt im Netzwerk verlässt, bis zu dem Moment, in dem es sein Ziel erreicht. RTT wird häufiger zur Messung der Latenz verwendet, da es von einem einzigen Punkt im Netzwerk aus ausgeführt werden kann und keine Datenerfassungssoftware am Zielpunkt installiert werden muss (wie es bei TTFB der Fall ist).

Durch die Echtzeitüberwachung der Bandbreitennutzung und Leistung Ihrer Anwendung erleichtert der ADM-Dienst die Identifizierung von Problemen und die präventive Behebung potenzieller Probleme, bevor sie sich manifestieren und Benutzer in Ihrem Netzwerk beeinträchtigen. Diese flussbasierte Lösung verfolgt die Nutzung nach Schnittstelle, Anwendung und Konversation und liefert Ihnen detaillierte Informationen über die Aktivitäten in Ihrem Netzwerk.

Verwenden von Splunk-Tools

Infrastruktur- und Anwendungsleistung sind voneinander abhängig. Um das Gesamtbild zu sehen, bietet SignalFx eine nahtlose Korrelation zwischen der Cloud-Infrastruktur und den darauf laufenden Microservices. Wenn Ihre Anwendung aufgrund von Speicherlecks, einem „lauten Nachbar“-Container oder anderen infrastrukturbezogenen Problemen nicht richtig funktioniert, informiert Sie SignalFx darüber. Um das Bild zu vervollständigen, ermöglichen kontextbezogene Zugriffe auf Splunk-Protokolle und -Ereignisse eine tiefere Fehlerbehebung und Ursachenanalyse.

Weitere Informationen zu SignalFx Microservices APM und zur Fehlerbehebung mit Splunk finden Sie unter Splunk for DevOps.

MongoDB-Unterstützung

MongoDB speichert Daten in flexiblen, JSON-ähnlichen Dokumenten. Das bedeutet, dass Felder von Dokument zu Dokument variieren können und die Datenstruktur im Laufe der Zeit geändert werden kann.

Das Dokumentenmodell bildet die Objekte in Ihrem Anwendungscode ab, was die Arbeit mit Daten erleichtert.

On-Demand-Abfragen, Indizierung und Echtzeit-Aggregation bieten leistungsstarke Möglichkeiten, auf Ihre Daten zuzugreifen und sie zu analysieren.

MongoDB ist im Kern eine verteilte Datenbank, daher sind Hochverfügbarkeit, horizontale Skalierung und geografische Verteilung integriert und einfach zu verwenden.

MongoDB wurde entwickelt, um den Anforderungen moderner Apps gerecht zu werden, mit einer technologischen Grundlage, die Sie durch Folgendes unterstützt:

• Das Dokumenten-Datenmodell – es bietet Ihnen die beste Möglichkeit, mit Daten zu arbeiten.
• Ein verteiltes Systemdesign – das es Ihnen ermöglicht, Daten intelligent dort zu platzieren, wo Sie sie haben möchten.
• Eine einheitliche Erfahrung, die Ihnen die Freiheit gibt, überall zu arbeiten – so können Sie Ihre Arbeit zukunftssicher machen und die Anbieterbindung eliminieren.

Mit diesen Funktionen können Sie eine intelligente operative Datenplattform aufbauen, die auf MongoDB basiert. Weitere Informationen finden Sie in der MongoDB Documentation.

So wird der Ingress-Traffic zu TCP- oder UDP-basierten Anwendungen lastverteilt

In einer Kubernetes-Umgebung ist ein Ingress ein Objekt, das den Zugriff auf die Kubernetes-Dienste von außerhalb des Kubernetes-Clusters ermöglicht. Standard-Kubernetes-Ingress-Ressourcen gehen davon aus, dass der gesamte Traffic HTTP-basiert ist und unterstützen keine nicht-HTTP-basierten Protokolle wie TCP, TCP-SSL und UDP. Daher können kritische Anwendungen, die auf L7-Protokollen wie DNS, FTP, LDAP basieren, nicht über den Standard-Kubernetes-Ingress bereitgestellt werden.

Die Standard-Kubernetes-Lösung besteht darin, einen Dienst vom Typ LoadBalancer zu erstellen. Weitere Informationen finden Sie unter Service Type LoadBalancer in Citrix ADC.

Die zweite Option ist die Annotation des Ingress-Objekts. Der Citrix Ingress Controller ermöglicht Ihnen den Lastausgleich von TCP- oder UDP-basiertem Ingress-Verkehr. Er bietet die folgenden Annotationen, die Sie in Ihrer Kubernetes Ingress-Ressourcendefinition verwenden können, um den TCP- oder UDP-basierten Ingress-Verkehr auszugleichen:

• ingress.citrix.com/insecure-service-type: Die Annotation ermöglicht L4-Lastausgleich mit TCP, UDP oder ANY als Protokoll für Citrix ADC.
• ingress.citrix.com/insecure-port: Die Annotation konfiguriert den TCP-Port. Die Annotation ist hilfreich, wenn der Zugriff auf Mikrodienste über einen nicht standardmäßigen Port erforderlich ist. Standardmäßig ist Port 80 konfiguriert.

Weitere Informationen finden Sie unter Lastausgleich von Ingress-Verkehr zu TCP- oder UDP-basierten Anwendungen

Leistung Ihrer TCP- oder UDP-basierten Anwendungen überwachen und verbessern

Anwendungsentwickler können den Zustand von TCP- oder UDP-basierten Anwendungen mithilfe umfangreicher Monitore (wie TCP-ECV, UDP-ECV) in Citrix ADC genau überwachen. Die ECV-Monitore (Extended Content Validation) helfen dabei zu überprüfen, ob die Anwendung den erwarteten Inhalt zurückgibt oder nicht.

Auch die Anwendungsleistung kann durch die Verwendung von Persistenzmethoden wie Source IP verbessert werden. Sie können diese Citrix ADC-Funktionen über Smart Annotations in Kubernetes nutzen. Das folgende ist ein solches Beispiel:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

Citrix Application Delivery Management (ADM) Service

Der Citrix ADM Service bietet die folgenden Vorteile:

• Agil – Einfach zu bedienen, zu aktualisieren und zu nutzen. Das Servicemodell des Citrix ADM Service ist über die Cloud verfügbar, wodurch die bereitgestellten Funktionen einfach zu bedienen, zu aktualisieren und zu nutzen sind. Die Häufigkeit der Updates, kombiniert mit der automatischen Update-Funktion, verbessert schnell Ihre Citrix ADC-Bereitstellung.
• Schnellere Wertschöpfung – Schnellere Erreichung von Geschäftszielen. Im Gegensatz zur traditionellen lokalen Bereitstellung können Sie Ihren Citrix ADM Service mit wenigen Klicks nutzen. Sie sparen nicht nur Installations- und Konfigurationszeit, sondern vermeiden auch Zeit- und Ressourcenverschwendung durch potenzielle Fehler.
• Multi-Site-Management – Eine zentrale Oberfläche für Instanzen über Multi-Site-Rechenzentren hinweg. Mit dem Citrix ADM Service können Sie Citrix ADCs verwalten und überwachen, die in verschiedenen Bereitstellungstypen vorhanden sind. Sie haben eine zentrale Verwaltung für Citrix ADCs, die lokal und in der Cloud bereitgestellt werden.
• Betriebliche Effizienz – Optimierte und automatisierte Methode zur Erzielung höherer betrieblicher Produktivität. Mit dem Citrix ADM Service werden Ihre Betriebskosten gesenkt, indem Sie Zeit, Geld und Ressourcen für die Wartung und das Upgrade traditioneller Hardware-Bereitstellungen sparen.

Service-Graph für Kubernetes-Anwendungen

Mithilfe der Service-Graph-Funktion für Cloud-native Anwendungen in Citrix ADM können Sie:

• Sicherstellen der End-to-End-Gesamtleistung der Anwendung
• Engpässe identifizieren, die durch die gegenseitige Abhängigkeit verschiedener Komponenten Ihrer Anwendungen entstehen
• Einblicke in die Abhängigkeiten verschiedener Komponenten Ihrer Anwendungen gewinnen
• Dienste innerhalb des Kubernetes-Clusters überwachen
• Überwachen, welcher Dienst Probleme hat
• Die Faktoren überprüfen, die zu Leistungsproblemen beitragen
• Detaillierte Sichtbarkeit von HTTP-Transaktionen des Dienstes anzeigen
• Die HTTP-, TCP- und SSL-Metriken analysieren

Durch die Visualisierung dieser Metriken in Citrix ADM können Sie die Ursache von Problemen analysieren und notwendige Fehlerbehebungsmaßnahmen schneller ergreifen. Der Service-Graph zeigt Ihre Anwendungen in verschiedenen Komponentendiensten an. Diese Dienste, die innerhalb des Kubernetes-Clusters ausgeführt werden, können mit verschiedenen Komponenten innerhalb und außerhalb der Anwendung kommunizieren.

Um zu beginnen, siehe Einrichten des Service-Graphen.

Service-Graph für 3-Tier-Webanwendungen

Mithilfe der Service-Graph-Funktion im Anwendungs-Dashboard können Sie Folgendes anzeigen:

• Details zur Konfiguration der Anwendung (mit Content Switching Virtual Server und Load Balancing Virtual Server)
  • Für GSLB-Anwendungen können Sie Rechenzentren, ADC-Instanzen, CS- und LB-virtuelle Server anzeigen
• End-to-End-Transaktionen vom Client zum Dienst
• Der Standort, von dem aus der Client auf die Anwendung zugreift
• Der Name des Rechenzentrums, in dem die Client-Anfragen verarbeitet werden, und die zugehörigen Citrix ADC-Metriken des Rechenzentrums (nur für GSLB-Anwendungen)
• Metrikdetails für Client, Dienst und virtuelle Server
• Ob die Fehler vom Client oder vom Dienst stammen
• Der Dienststatus wie Kritisch, Überprüfen und Gut. Citrix ADM zeigt den Dienststatus basierend auf der Dienstantwortzeit und der Fehleranzahl an.
  • Kritisch (rot) – Zeigt an, wenn die durchschnittliche Dienstantwortzeit > 200 ms UND die Fehleranzahl > 0 ist
  • Überprüfen (orange) – Zeigt an, wenn die durchschnittliche Dienstantwortzeit > 200 ms ODER die Fehleranzahl > 0 ist
  • Gut (grün) – Zeigt an, wenn kein Fehler vorliegt und die durchschnittliche Dienstantwortzeit < 200 ms ist
• Der Client-Status wie Kritisch, Überprüfen und Gut. Citrix ADM zeigt den Client-Status basierend auf der Client-Netzwerklatenz und der Fehleranzahl an.
  • Kritisch (rot) – Zeigt an, wenn die durchschnittliche Client-Netzwerklatenz > 200 ms UND die Fehleranzahl > 0 ist
  • Überprüfen (orange) – Zeigt an, wenn die durchschnittliche Client-Netzwerklatenz > 200 ms ODER die Fehleranzahl > 0 ist
  • Gut (grün) – Zeigt an, wenn kein Fehler vorliegt und die durchschnittliche Client-Netzwerklatenz < 200 ms ist
• Der Status des virtuellen Servers wie Kritisch, Überprüfen und Gut. Citrix ADM zeigt den Status des virtuellen Servers basierend auf dem App-Score an.
  • Kritisch (rot) – Zeigt an, wenn der App-Score < 40 ist
  • Überprüfen (orange) – Zeigt an, wenn der App-Score zwischen 40 und 75 liegt
  • Gut (grün) – Zeigt an, wenn der App-Score > 75 ist

Hinweise:

• Nur virtuelle Server für Lastenausgleich (Load Balancing), Inhaltsumschaltung (Content Switching) und GSLB werden im Service-Graph angezeigt.
• Wenn kein virtueller Server an eine benutzerdefinierte Anwendung gebunden ist, sind die Details im Service-Graph für die Anwendung nicht sichtbar.
• Sie können Metriken für Clients und Dienste im Service-Graph nur anzeigen, wenn aktive Transaktionen zwischen virtuellen Servern und der Webanwendung stattfinden.
• Wenn keine aktiven Transaktionen zwischen virtuellen Servern und der Webanwendung verfügbar sind, können Sie Details im Service-Graph nur basierend auf den Konfigurationsdaten wie Lastenausgleich, Inhaltsumschaltung, GSLB-Virtual-Servern und Diensten anzeigen.
• Aktualisierungen in der Anwendungskonfiguration können bis zu 10 Minuten dauern, bis sie im Service-Graph angezeigt werden.

Weitere Informationen finden Sie unter Service-Graph für Anwendungen.

Informationen zum Einstieg finden Sie unter Service-Graph-Dokumentation.

Fehlerbehebung für Citrix ADC-Teams

Lassen Sie uns einige der häufigsten Attribute zur Fehlerbehebung der Citrix ADC-Plattform besprechen und wie diese Fehlerbehebungstechniken auf die Tier-1-Bereitstellungen für Microservices-Topologien angewendet werden.

Der Citrix ADC verfügt über eine Befehlszeilenschnittstelle (CLI), die Befehle in Echtzeit anzeigt und nützlich ist, um Laufzeitkonfigurationen, Statistiken und Richtlinienkonfigurationen zu bestimmen. Dies wird durch den Befehl „SHOW“ ermöglicht.

SHOW – ADC-CLI-Operationen ausführen:

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

SSL-Statistiken anzeigen

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

SSL-Statistiken anzeigen(/de-de/advanced-concepts/media/show-ssl-statistics.png)

Der Citrix ADC verfügt über einen Befehl zur Auflistung von Statistiken für alle Objekte, basierend auf einem Zählerintervall von sieben (7) Sekunden. Dies wird über den Befehl „STAT“ ermöglicht.

Hochgradig granulare L3-L7-Telemetrie durch Citrix ADC

• Systemebene: CPU- und Speicherauslastung des ADC.
• HTTP-Protokoll: #Anfragen/Antworten, GET/POST-Aufteilung, HTTP-Fehler für N-S und O-W (nur für Service Mesh Lite, Sidecar bald verfügbar).
• SSL: #Sitzungen und #Handshakes für N-S- und O-W-Verkehr nur für Service Mesh Lite.
• IP-Protokoll: #Empfangene/gesendete Pakete, #Empfangene/gesendete Bytes, #Abgeschnittene Pakete und #IP-Adresssuche.
• Citrix ADC AAA: #Aktive Sitzungen
• Schnittstelle: #Gesamtzahl Multicast-Pakete, #Gesamtzahl übertragener Bytes und #Empfangene/gesendete Jumbo-Pakete.
• Virtueller Lastausgleichsserver und virtueller Content-Switching-Server: #Pakete, #Treffer und #Empfangene/gesendete Bytes.

STAT – ADC-CLI-Operationen ausführen:

>Statistics
“stat ssl”
<!--NeedCopy-->

SSL starten(/de-de/advanced-concepts/media/start-ssl.png)

Der Citrix ADC verfügt über eine Protokollarchivstruktur, die die Suche nach Statistiken und Zählern bei der Fehlerbehebung spezifischer Fehler über den Befehl „NSCONMSG“ ermöglicht.

NSCONMSG – Hauptprotokolldatei (ns-Datenformat)

    Cd/var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

Befehlsablauf(/de-de/advanced-concepts/media/command-flow.png)

Nstcpdump

Sie können nstcpdump zur Fehlerbehebung auf niedriger Ebene verwenden. nstcpdump sammelt weniger detaillierte Informationen als nstrace. Öffnen Sie die ADC-CLI und geben Sie shell ein. Sie können Filter mit nstcpdump verwenden, aber keine Filter, die spezifisch für ADC-Ressourcen sind. Die Dump-Ausgabe kann direkt im CLI-Bildschirm angezeigt werden.

STRG + C – Drücken Sie diese Tasten gleichzeitig, um ein nstcpdump zu beenden.

nstcpdump.sh dst host x.x.x.x – Zeigt den an den Zielhost gesendeten Datenverkehr an.

nstcpdump.sh -n src host x.x.x.x – Zeigt den Datenverkehr vom angegebenen Host an und konvertiert IP-Adressen nicht in Namen (-n).

nstcpdump.sh host x.x.x.x – Zeigt den Datenverkehr zu und von der angegebenen Host-IP an.

NSTRACE – Paket-Trace-Datei

NSTRACE ist ein Low-Level-Paket-Debugging-Tool zur Fehlerbehebung in Netzwerken. Es ermöglicht Ihnen, Erfassungsdateien zu speichern, die Sie mit den Analysetools weiter analysieren können. Zwei gängige Tools sind Network Analyzer und Wireshark.

Sobald die NSTRACE-Erfassungsdatei in /var/nstrace auf dem ADC erstellt wurde, können Sie die Erfassungsdatei für die Paketerfassung und Netzwerkanalyse in Wireshark importieren.

SYSCTL – Detaillierte ADC-Informationen: Beschreibung, Modell, Plattform, CPUs und so weiter

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug – Offene Pipe für Authentifizierungs-Debug-Informationen

Weitere Informationen zur Behebung von Authentifizierungsproblemen über ADC oder ADC Gateway mit dem aaad.debug-Modul finden Sie in diesem aaad.debug Support-Artikel.

Es besteht auch die Möglichkeit, Leistungsstatistiken und Ereignisprotokolle direkt für den ADC abzurufen. Weitere Informationen dazu finden Sie in diesem ADC Support-Dokument.

Fehlerbehebung für SRE- und Plattformteams

Kubernetes-Datenflüsse

Nord/Süd:

• Nord/Süd-Verkehr ist Datenverkehr, der vom Benutzer in den Cluster über den Ingress fließt.

Ost/West:

• Ost/West-Verkehr ist Datenverkehr, der innerhalb des Kubernetes-Clusters fließt: Dienst-zu-Dienst oder Dienst-zu-Datenspeicher.

Wie Citrix ADC CPX den Ost-West-Datenfluss in einer Kubernetes-Umgebung lastverteilt

Nachdem Sie den Kubernetes-Cluster bereitgestellt haben, müssen Sie den Cluster in ADM integrieren, indem Sie die Details der Kubernetes-Umgebung in ADM angeben. ADM überwacht die Änderungen an Kubernetes-Ressourcen wie Diensten, Endpunkten und Ingress-Regeln.

Wenn Sie eine ADC CPX-Instanz im Kubernetes-Cluster bereitstellen, registriert sie sich automatisch bei ADM. Im Rahmen des Registrierungsprozesses erfährt ADM die IP-Adresse der CPX-Instanz und den Port, über den sie die Instanz erreichen kann, um sie mithilfe von NITRO REST APIs zu konfigurieren.

Die folgende Abbildung zeigt, wie ADC CPX den Ost-West-Datenfluss in einem Kubernetes-Cluster lastverteilt.

In diesem Beispiel,

Knoten 1 und Knoten 2 der Kubernetes-Cluster enthalten Instanzen eines Front-End-Dienstes und eines Back-End-Dienstes. Wenn die ADC CPX-Instanzen in Knoten 1 und Knoten 2 bereitgestellt werden, werden die ADC CPX-Instanzen automatisch bei ADM registriert. Sie müssen den Kubernetes-Cluster manuell in ADM integrieren, indem Sie die Kubernetes-Clusterdetails in ADM konfigurieren.

Wenn ein Client den Front-End-Dienst anfordert, gleicht die Ingress-Ressource die Last der Anforderung zwischen den Instanzen des Front-End-Dienstes auf den beiden Knoten aus. Wenn eine Instanz des Front-End-Dienstes Informationen von den Back-End-Diensten im Cluster benötigt, leitet sie die Anfragen an die ADC CPX-Instanz in ihrem Knoten weiter. Diese ADC CPX-Instanz gleicht die Last der Anfragen zwischen den Back-End-Diensten im Cluster aus und sorgt so für einen Ost-West-Verkehrsfluss.

ADM-Dienstdiagramm für Anwendungen

Die Dienstdiagrammfunktion in Citrix ADM ermöglicht es Ihnen, alle Dienste in einer grafischen Darstellung zu überwachen. Diese Funktion bietet auch eine detaillierte Analyse und nützliche Metriken. Sie können Dienstdiagramme anzeigen für:

• Anwendungen, die über alle Citrix ADC-Instanzen konfiguriert sind
• Kubernetes-Anwendungen
• 3-Tier-Webanwendungen

Weitere Informationen finden Sie in den Details zum Dienstdiagramm.

Zähler für Microservice-Anwendungen anzeigen

Das Dienstdiagramm zeigt auch alle Microservice-Anwendungen an, die zu den Kubernetes-Clustern gehören. Bewegen Sie den Mauszeiger über einen Dienst, um die Metrikdetails anzuzeigen.

Sie können Folgendes anzeigen:

• Den Dienstnamen
• Das vom Dienst verwendete Protokoll, z. B. SSL, HTTP, TCP, SSL über HTTP
• Treffer – Die Gesamtzahl der vom Dienst empfangenen Treffer
• Dienstantwortzeit – Die durchschnittliche Antwortzeit des Dienstes. (Antwortzeit = Client-RTT + Anforderung letztes Byte – Anforderung erstes Byte)
• Fehler – Die Gesamtfehler, wie 4xx, 5xx usw.
• Datenvolumen – Das gesamte Datenvolumen, das vom Dienst verarbeitet wird
• Namespace – Der Namespace des Dienstes
• Clustername – Der Clustername, auf dem der Dienst gehostet wird
• SSL-Serverfehler – Die gesamten SSL-Fehler des Dienstes

Diese spezifischen Zähler und Transaktionsprotokolle können über den Citrix Observability Exporter (COE) mithilfe einer Reihe unterstützter Endpunkte extrahiert werden. Weitere Informationen zu COE finden Sie in den folgenden Abschnitten.

Exporter für Citrix ADC-Statistiken

Dies ist ein einfacher Server, der Citrix ADC-Statistiken abruft und diese über HTTP an Prometheus exportiert. Prometheus kann dann als Datenquelle zu Grafana hinzugefügt werden, um die Citrix ADC-Statistiken grafisch anzuzeigen.

Um die Statistiken und Zähler von Citrix ADC-Instanzen zu überwachen, kann citrix-adc-metric-exporter als Container oder Skript ausgeführt werden. Der Exporter sammelt Citrix ADC-Statistiken wie die Gesamtzahl der Zugriffe auf einen virtuellen Server, die HTTP-Anfragerate, die SSL-Verschlüsselungs-/Entschlüsselungsrate usw. von den Citrix ADC-Instanzen und hält sie vor, bis der Prometheus-Server die Statistiken abruft und mit einem Zeitstempel speichert. Grafana kann dann auf den Prometheus-Server verweisen, um die Statistiken abzurufen, sie zu plotten, Alarme einzustellen, Heatmaps zu erstellen, Tabellen zu generieren usw., um die Citrix ADC-Statistiken zu analysieren.

Details zur Einrichtung des Exporters für die Arbeit in einer Umgebung, wie in der Abbildung dargestellt, werden in den folgenden Abschnitten beschrieben. Es wird auch erläutert, welche Citrix ADC-Entitäten/Metriken der Exporter standardmäßig abruft und wie dies geändert werden kann.

Weitere Informationen zum Exporter für Citrix ADC finden Sie im Metrics Exporter GitHub.

ADM Service Distributed Tracing

Im Dienstgraphen können Sie die verteilte Ablaufverfolgung verwenden, um:

• Die Gesamtleistung des Dienstes analysieren.
• Den Kommunikationsfluss zwischen dem ausgewählten Dienst und seinen voneinander abhängigen Diensten visualisieren.
• Identifizieren Sie, welcher Dienst Fehler anzeigt, und beheben Sie die Probleme des fehlerhaften Dienstes.
• Zeigen Sie Transaktionsdetails zwischen dem ausgewählten Dienst und jedem voneinander abhängigen Dienst an.

Voraussetzungen für ADM Distributed Tracing

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

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

• Aktualisieren Sie die CPX YAML-Datei mit NS_DISTRIBUTED_TRACING und dem Wert YES. Informationen zum Einstieg finden Sie unter Distributed Tracing.

Citrix Observability Exporter (COE) Parsing

Citrix Observability Exporter ist ein Container, der Metriken und Transaktionen von Citrix ADCs sammelt und diese in geeignete Formate (wie JSON, AVRO) für unterstützte Endpunkte umwandelt. Sie können die vom Citrix Observability Exporter gesammelten Daten an den gewünschten Endpunkt exportieren. Durch die Analyse der an den Endpunkt exportierten Daten erhalten Sie wertvolle Einblicke auf Mikroservice-Ebene für Anwendungen, die von Citrix ADCs proxied werden.

Weitere Informationen zu COE finden Sie im COE GitHub.

COE mit Elasticsearch als Transaktionsendpunkt

Wenn Elasticsearch als Transaktionsendpunkt angegeben ist, konvertiert Citrix Observability Exporter die Daten in das JSON-Format. Auf dem Elasticsearch-Server erstellt Citrix Observability Exporter stündlich Elasticsearch-Indizes für jeden ADC. Diese Indizes basieren auf Daten, Stunde, UUID des ADC und dem Typ der HTTP-Daten (http_event oder http_error). Anschließend lädt der Citrix Observability Exporter die Daten im JSON-Format unter den Elasticsearch-Indizes für jeden ADC hoch. Alle regulären Transaktionen werden in den http_event-Index und alle Anomalien in den http_error-Index platziert.

Unterstützung für verteiltes Tracing mit Zipkin

In einer Microservice-Architektur kann eine einzelne Endbenutzeranfrage mehrere Microservices umfassen, was die Nachverfolgung einer Transaktion und die Behebung von Fehlerursachen erschwert. In solchen Fällen können herkömmliche Methoden zur Leistungsüberwachung nicht genau feststellen, wo Fehler auftreten und was die Ursache für die schlechte Leistung ist. Sie benötigen eine Möglichkeit, Datenpunkte zu erfassen, die für jeden Microservice, der eine Anfrage bearbeitet, spezifisch sind, und diese zu analysieren, um aussagekräftige Erkenntnisse zu gewinnen.

Verteiltes Tracing begegnet dieser Herausforderung, indem es eine Möglichkeit bietet, eine Transaktion End-to-End zu verfolgen und zu verstehen, wie sie über mehrere Microservices hinweg verarbeitet wird.

OpenTracing ist eine Spezifikation und ein Standardsatz von APIs für das Design und die Implementierung von verteiltem Tracing. Verteilte Tracer ermöglichen es Ihnen, den Datenfluss zwischen Ihren Microservices zu visualisieren und helfen, die Engpässe in Ihrer Microservice-Architektur zu identifizieren.

Citrix Observability Exporter implementiert verteiltes Tracing für Citrix ADC und unterstützt derzeit Zipkin als verteilten Tracer.

Derzeit können Sie die Leistung auf Anwendungsebene mit Citrix ADC überwachen. Mit Citrix Observability Exporter und Citrix ADC erhalten Sie Tracing-Daten für Microservices jeder Anwendung, die von Ihrem Citrix ADC CPX, MPX oder VPX proxied wird.

Um zu beginnen, siehe den GitHub Observability Exporter.

Zipkin für die Anwendungsfehlerbehebung

Zipkin ist ein Open-Source verteiltes Tracing-System, basierend auf Dappers Paper von Google. Dapper ist Googles System für sein verteiltes Tracing in der Produktion. Google erklärt dies in ihrem Paper: „Wir haben Dapper entwickelt, um den Entwicklern von Google mehr Informationen über das Verhalten komplexer verteilter Systeme zu liefern.“ Das System aus verschiedenen Blickwinkeln zu beobachten, ist bei der Fehlerbehebung entscheidend, insbesondere wenn ein System komplex und verteilt ist.

Die folgenden Zipkin-Tracing-Daten identifizieren insgesamt 5 Spans und 5 Services, die mit der Beispielanwendung Watches zusammenhängen. Die Tracing-Daten zeigen die spezifischen Span-Daten über die 5 Microservices hinweg.

Um zu beginnen, siehe das folgende Zipkin.

Beispiel-Zipkin-Span, der die Anwendungslatenz für die anfängliche Seitenladeanforderung zeigt:

Kibana zum Anzeigen von Daten

Kibana ist eine offene Benutzeroberfläche, mit der Sie Ihre Elasticsearch-Daten visualisieren und den Elastic Stack navigieren können. Von der Verfolgung der Abfragelast bis zum Verständnis, wie Anfragen durch Ihre Apps fließen, ist alles möglich.

Ob Sie Analyst oder Administrator sind, Kibana macht Ihre Daten durch die Bereitstellung der folgenden drei Schlüsselfunktionen nutzbar:

• Eine Open-Source-Analyse- und Visualisierungsplattform. Verwenden Sie Kibana, um Ihre Elasticsearch-Daten zu erkunden und dann ansprechende Visualisierungen und Dashboards zu erstellen.
• Eine Benutzeroberfläche zur Verwaltung des Elastic Stack. Verwalten Sie Ihre Sicherheitseinstellungen, weisen Sie Benutzerrollen zu, erstellen Sie Snapshots, rollen Sie Ihre Daten zusammen und vieles mehr – alles bequem über eine Kibana-Benutzeroberfläche.
• Eine zentrale Anlaufstelle für die Lösungen von Elastic. Von der Protokollanalyse über die Dokumentensuche bis hin zu SIEM ist Kibana das Portal für den Zugriff auf diese und andere Funktionen.

Kibana ist darauf ausgelegt, Elasticsearch als Datenquelle zu verwenden. Stellen Sie sich Elasticsearch als die Engine vor, die die Daten speichert und verarbeitet, wobei Kibana darauf aufsetzt.

Von der Startseite aus bietet Kibana diese Optionen zum Hinzufügen von Daten:

• Daten mit dem File Data visualizer importieren.
• Richten Sie einen Datenfluss zu Elasticsearch mithilfe unserer integrierten Tutorials ein. Wenn kein Tutorial für Ihre Daten existiert, gehen Sie zur Beats Overview, um mehr über andere Datenversender in der Beats-Familie zu erfahren.
• Fügen Sie einen Beispieldatensatz hinzu und testen Sie Kibana, ohne selbst Daten laden zu müssen.
• Indizieren Sie Ihre Daten in Elasticsearch mit REST APIs oder Client Libraries.

Kibana verwendet ein Indexmuster, um festzulegen, welche Elasticsearch-Indizes durchsucht werden sollen. Wenn Sie eine Datei hochladen, ein integriertes Tutorial ausführen oder Beispieldaten hinzufügen, erhalten Sie kostenlos ein Indexmuster und können sofort mit der Erkundung beginnen. Wenn Sie Ihre eigenen Daten laden, können Sie ein Indexmuster in Stack Management erstellen.

Schritt 1: Indexmuster für Logstash konfigurieren

Schritt 2: Index auswählen und Traffic generieren, um ihn zu füllen.

Schritt 3: Anwendung aus den unstrukturierten Daten aus Protokoll-Feeds generieren.

Schritt 4: Kibana formatiert die Logstash-Eingabe, um Berichte und Dashboards zu erstellen.

• Zeitbereich
• Tabellarische Ansicht
• Trefferanzahl basierend auf der Anwendung.
  • Zeit, IP, Agent, Machine.OS, Antwortcode (200), URL
  • Nach Werten filtern

Schritt 5: Die Daten in einem Aggregationsbericht visualisieren.

• Ergebnisaggregation in einem Diagrammbericht (Kreisdiagramm, Grafik und so weiter)