Istio-Überwachung mit Elastic Observability

Istio ist ein Open Source Service Mesh, mit dem Entwickler und Betreiber ihre Dienste als verteilte Microservices erfolgreich kontrollieren, schützen und miteinander verbinden können. Istio ist ein leistungsstarkes Tool für Teams, aber es ist für Administratoren auch wichtig, umfassende Einblicke in seine Integrität zu haben. In diesem Blogeintrag befassen wir uns damit, wie wir Istio und die zugehörigen Microservices mit Elastic Observability überwachen können.

Ein Auszug aus der Istio-Dokumentation:

Mit Istio können Sie mit nur wenigen oder gar keinen Änderungen im Dienstcode mühelos ein Netzwerk aus bereitgestellten Diensten mit Lastenausgleich, Dienst-zu-Dienst-Authentifizierung, Überwachung und mehr erstellen. Sie fügen die Istio-Unterstützung zu Ihren Diensten hinzu, indem Sie einen speziellen Sidecar-Proxy in Ihrer Umgebung bereitstellen, der sämtliche Netzwerkkommunikation zwischen Microservices abfängt. Anschließend konfigurieren und verwalten Sie Istio über die Steuerungsebene mit den folgenden Funktionen:

• Automatischer Lastenausgleich für HTTP-, gRPC-, WebSocket- und TCP-Datenverkehr.
• Differenzierte Steuerung des Datenverkehrsverhaltens mit umfassenden Routingregeln, Wiederholungen, Failovers und Fault Injection.
• Die mit Plug-Ins erweiterbare Richtlinienebene und die Konfigurations-API unterstützen Zugriffskontrollen, Durchsatzlimits und Kontingente.
• Automatische Metriken, Logs und Traces für sämtlichen Datenverkehr in einem Cluster, inklusive des ein- und ausgehenden Datenverkehrs für den Cluster.
• Sichere Kommunikation zwischen Diensten in einem Cluster mit starker, identitätsbasierter Authentifizierung und Autorisierung.

Vor Version 1.5 basierte Istio auf einer Microservice-Architektur, und die Steuerungsebene und die Verwaltungskomponenten bestanden aus verschiedenen Microservices: Pilot, Mixer, Galley und Citadel.

Diese Microservices konnten bereits mit Metricbeat überwacht werden, aber seit Version 1.5 verwendet Istio eine monolithische Architektur, und die Steuerungsebene besteht aus einer einzigen Anwendung namens istiod. Pilot, Galley und Citadel gehören jetzt zu istiod. Mixer war bisher für die Erfassung von Datenverkehrsmetriken von den Envoy-Proxys verantwortlich. Diese Funktion wird jetzt von den Istio-Proxys direkt ausgeführt. Die aktuelle Istio-Architektur sieht wie folgt aus:

Erstellen einer Überwachungslösung mit Elastic

Ältere Versionen als 1.5 wurden bereits von verschiedenen Metricsets des Istio-Metricbeat-Moduls unterstützt. In diesem Blogeintrag befassen wir uns dagegen mit der Unterstützung für die neueren Versionen bei der Ausführung von Istio in Kubernetes.

Metriken für die Steuerungsebene

Wie Sie in der oben gezeigten Istio-Architektur sehen, haben wir nur eine Ressource, von der wir Metriken für die Steuerungsebene sammeln können. Istio stellt einen Prometheus-Exporter bereit, aus dem wir Prometheus-Metriken sammeln können.

Um die Metriken aus dem Prometheus-Endpunkt nutzen zu können, müssen wir sie zunächst mit einem Metricset sammeln, herausfiltern und passend speichern. Dazu können wir ein leichtgewichtiges Metricset auf Basis des Prometheus-Moduls erstellen und leistungsstarke Optionen wie die Metrikfilterung sowie Histogramme und Typen verwenden.

Sehen wir uns nun die Definition dieses neuen leichtgewichtigen Metricsets an:

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /metrics 
    metrics_filters: 
      include: ["citadel_*", "galley_*", "pilot_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

Wir definieren den Pfad, unter dem das Collector-Metricset die Metriken sammelt und nicht benötigte Metriken herausfiltert. Außerdem aktivieren wir Raten und Typen, um die Daten korrekt in Elasticsearch zu speichern und anschließend optimal nutzen zu können.

Beim Bereitstellen von Metricbeat in einem Kubernetes-Cluster konfigurieren wir dieses Metricset wie folgt:

- module: istio 
  metricsets: ['istiod'] 
  period: 10s 
  hosts: ['istiod.istio-system:15014']

istiod ist dabei der Name des Kubernetes-Diensts, der den Istiod-Pod bereitstellt, und istio-system ist der Namespace, in dem die Bereitstellung erfolgt.

Und das ist schon alles! Das istiod metricset, das die Metriken aus istiod sammelt, enthält bereits ein vorab erstelltes Dashboard mit einer Übersicht über die Steuerungsebene des Service Mesh sowie verschiedenen Visualisierungen, die Sie in Ihren eigenen individuellen Dashboards verwenden können:

Metriken für die Datenebene

Nachdem wir also Metriken für die Steuerungsebene mit dem istiod-Metricset sammeln, können wir unsere Überwachung erweitern, indem wir auch Metriken für die Datenebene sammeln. Damit erhalten wir eine umfassende Übersicht über den Datenverkehr zwischen den von Istio verwalteten Diensten.

Wie bereits erwähnt war Mixer früher als Microservice dafür zuständig, diese Metriken für die Datenebene zu sammeln und bereitzustellen. Seit Version 1.5 werden diese Metriken jedoch direkt von den Istio-Proxys erfasst und mit einem Prometheus-Exporter bereitgestellt.

Um diese zusätzlichen Metriken zu erfassen, müssen wir lediglich ein weiteres leichtgewichtiges Metricset angeben, ähnlich wie für istiod:

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /stats/prometheus 
    metrics_filters: 
      include: ["istio_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

Wie auch im vorherigen Beispiel legen wir metrics_path fest, behalten nur die gewünschten Metriken und speichern sie mit Typen. 

Allerdings fehlt uns etwas: Wir wissen nicht, wie wir diese Proxy-Container erreichen, da wir ihre IP-Adressen nicht kennen. Selbst wenn wir die IPs dieser Container bei der Bereitstellung von Metricbeat kennen, können wir keine Daten von Diensten sammeln, die nach dem Starten von Metricbeat bereitgestellt werden. Wir brauchen eine Möglichkeit, um diese Container automatisch zu identifizieren und die Metriken direkt nach ihrem Start zu erfassen. Für diese Aufgabe ist das autodiscover-Feature von Metricbeat perfekt geeignet. Wir definieren also eine autodiscover-Bedingung, um diese Container zu identifizieren. Wenn ein neuer Sidecar-Container mit einem Istio-Proxy erkannt wird, aktiviert Metricbeat das Proxy-Metricset automatisch und beginnt mit der Datensammlung.

Hier ist ein Beispiel für eine solche autodiscover-Konfiguration:

metricbeat.autodiscover: 
  providers: 
    - type: kubernetes 
      node: ${NODE_NAME} 
      templates: 
        - condition: 
            contains: 
              kubernetes.annotations.prometheus.io/path: "/stats/prometheus" 
          config: 
            - module: istio 
              metricsets: ["proxy"] 
              hosts: "${data.host}:15090"

Geschafft! Damit sammeln wir Metriken von allen Istio-Sidecar-Containern im Cluster und können neue Container dynamisch identifizieren. Dazu verwenden wir das proxy-Metricset des Istio-Moduls, das ebenfalls ein vorab erstelltes Dashboard enthält:

Außerdem können wir die Graph-Analytics in Kibana nutzen, um Korrelationen zwischen unseren Daten und den Diensten zu erkunden. Im folgenden Diagramm sehen wir beispielsweise eine Übersicht darüber, wie unsere Dienste miteinander verbunden sind und wie stark sie mit HTTP-Statuscodes verknüpft sind. Eine starke Beziehung zwischen einem Dienst und einem 500-Statuscode deutet vermutlich auf ein Problem hin, das wir untersuchen sollten.

Istio noch heute überwachen

Falls Sie Ihr Istio Service Mesh überwachen möchten, laden Sie Metricbeat 7.11 herunter und fangen Sie damit an, Ihre Metriken mit Elasticsearch und Kibana effizient zu erkunden. Mit einer kostenlosen Testversion des Elasticsearch Service können Sie im Handumdrehen Ihr eigenes Cluster bereitstellen. Und falls Sie Fragen haben, helfen wir Ihnen jederzeit gerne in den Diskussionsforen.