F5 NGINX Ingress Controller mit Prometheus-Operator für Out-of-the-Box-Metriken

NGINX Ingress Controller von F5 NGINX in Kombination mit dem Prometheus-Operator ServiceMonitor CRD macht das Sammeln von Metriken aus NGINX Ingress Controller-Bereitstellungen mit Helm viel einfacher und schneller. Das Helmdiagramm des NGINX Ingress Controller unterstützt jetzt die Möglichkeit, Ihre vorhandene Prometheus- und Prometheus-Operator-Infrastruktur sofort zu nutzen. So können Sie NICs bereitstellen und sofort einsatzbereite Metriken mithilfe des Prometheus ServiceMonitor nutzen. In diesem Artikel erfahren Sie, was ServiceMonitor ist, wie Sie ihn installieren und wie Sie das Helm-Diagramm des NGINX Ingress Controllers verwenden können, um diese spezifischen Einstellungen zu definieren.

Prometheus ServiceMonitor

Mit der benutzerdefinierten Ressourcen-Definition (CRD) Prometheus ServiceMonitor können Sie deklarativ festlegen, wie ein dynamischer Dienstsatz überwacht werden soll. Die überwachten Dienste definieren Sie über Kubernetes Label-Selectoren. So können Sie verbindliche Vorgaben dafür einführen, wie Metriken bereitgestellt werden. Wenn Sie diese Vorgaben einhalten, erkennt Prometheus neue Dienste automatisch und sammelt deren Metriken, ohne dass Sie das System neu konfigurieren müssen. ServiceMonitor gehört zum Prometheus Operator. Diese Ressourcen beschreiben und verwalten Überwachungsziele, die Prometheus abfragt. Die Prometheus-Ressource verbindet sich über das Feld ServiceMonitor Selector mit ServiceMonitor. So erkennt Prometheus schnell, welche Ziele für das Abfragen markiert sind. Dadurch behalten Sie volle Kontrolle und nutzen ServiceMonitor-Ressourcen flexibel in Ihrem Kubernetes-Cluster, zum Beispiel um den NGINX Ingress Controller zu überwachen. Um Ihnen den Einstieg zu erleichtern und sofort einsatzfähige Metriken für den NGINX Ingress Controller zu bieten, haben wir kürzlich die Nutzung von Prometheus ServiceMonitor in unser Helm Chart integriert. So aktivieren Sie ganz einfach die Metrikenerfassung, die Prometheus direkt nach dem Bereitstellen des NGINX Ingress Controllers startet. Dazu fügen wir einen zweiten, speziell für die Metrikensammlung vorgesehenen Dienst hinzu, an den ServiceMonitor angehängt wird. Das zeigt dem Prometheus Operator, welchen Dienst er mit den Labels in den Metadaten überwachen soll – er weiß dann, wo und was er abfragen muss. So könnte ein Dienst für den NGINX Ingress Controller aussehen, wenn er Teil der Bereitstellung oder Helm-Dateien ist:

API-Version: v1
Art: Dienst
Metadaten:
Name: nginx-ingress-servicemonitor
Labels:
App: nginx-ingress-servicemonitor
Spezifikation:
Ports:
- Name: Prometheus
Protokoll: TCP-Port: 9113
Zielport: 9113
Selektor:
App: nginx-ingress

Das oben Genannte wird Teil der Bereitstellung sein. Die Bezeichnung app: nginx-ingress-servicemonitor „verbindet“ sich mit dem ServiceMonitor für das Prometheus-Metrik-Scraping. Unten sehen Sie ein Beispiel für einen ServiceMonitor , der auf den oben genannten Dienst mit dem Namen nginx-ingress-servicemonitor verweisen würde:

API-Version: monitoring.coreos.com/v1
Art: ServiceMonitor
Metadaten:
Name: nginx-ingress-servicemonitor
Labels:
App: nginx-ingress-servicemonitor
Spezifikation:
Selektor:
MatchLabels:
App: nginx-ingress-servicemonitor
Endpunkte:
- Port: Prometheus

Sie müssen eine Prometheus-Ressource erstellen, die so eingerichtet ist, dass sie nach serviceMonitor-Ressourcen sucht. So erkennt Prometheus schnell und unkompliziert, welche Endpunkte es für Metriken erfassen muss. In unserem folgenden Beispiel zeigt diese Ressource Prometheus, welche Elemente unter der Spezifikation überwacht werden sollen. Im Folgenden überwachen wir spec.serviceMonitorSelector.matchLabels:. Wir sehen, dass Prometheus in jedem Namespace nach matchLabels mit app.nginx-ingress-servicemonitor sucht. Das entspricht der serviceMonitor-Ressource, die durch die Helm-Charts und Helm des NGINX Ingress Controllers bereitgestellt wird.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  labels:
    prometheus: prometheus
spec:
  replicas: 1
  serviceAccountName: prometheus
  serviceMonitorNamespaceSelector:  {}
  serviceMonitorSelector:
    matchLabels:
      app: nginx-ingress-servicemonitor
  resources:
    requests:
      memory: 500Mi

Hier ist ein Diagramm, das die verschiedenen Teile verbindet: Abbildung 1: Service-Monitor-Objektbeziehung

Installieren von Prometheus, Prometheus-Operator und Grafana

Wir werden den Prometheus-Community-/Kube-Prometheus-Stack verwenden, um die vollständige Bereitstellung zu installieren. Dadurch werden Prometheus, Prometheus-Operator und Grafana installiert. Wir werden auch angeben, dass wir dies zur Isolierung im Überwachungsnamespace installieren möchten. So können wir mit Helm installieren: helm install metrics01 prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

Prometheus-Ressource anlegen und einrichten

Sobald Prometheus und die Prometheus-CRDs im Cluster installiert sind, erstellen wir unsere Prometheus-Ressource. Indem wir sie im Voraus bereitstellen, können wir unser Prometheus-Setup mit den Labels vorab konfigurieren, die wir im Helm-Chart verwenden. So startet Prometheus automatisch die Suche nach dem NGINX Ingress Controller und beginnt, Metriken zu erfassen. Wir stellen unsere Prometheus-Ressource vor der Installation des NGINX Ingress Controllers bereit. Dadurch kann der prometheus-operator unseren NGINX Ingress Controller nach der Bereitstellung automatisch erfassen und Metriken schnell bereitstellen.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: default
  labels:
    prometheus: monitoring
spec:
  replicas: 1
  serviceAccountName: prometheus
  serviceMonitorNamespaceSelector:  {}
  serviceMonitorSelector:
    matchLabels:
      app: nginx-ingress-servicemonitor
  resources:
    requests:
      memory: 500Mi

Unser obiges Beispiel ist ein einfaches Beispiel. Der Schlüsselteil ist der von uns angegebene spec.serviceMonitorSelector.matchLabels -Wert. Diesen Wert werden wir verwenden, wenn wir den NGINX-Ingress-Controller mit dem Helm-Diagramm bereitstellen. Wir möchten sofort einsatzbereite Prometheus-Metriken bereitstellen. Zu diesem Zweck verwenden wir das Helmdiagramm des NGINX Ingress Controller.

Änderungen am NGINX Ingress Controller-Helm „values.yaml“

Wir können die Datei values.yaml für das Helm-Diagramm überprüfen. Es gibt einen Prometheus-Abschnitt, auf den wir uns konzentrieren möchten, da dieser die erforderlichen Teile enthält, um Prometheus zu aktivieren, den erforderlichen Dienst zu erstellen und eine ServiceMonitor- Ressource zu erstellen. Im Abschnitt „Prometheus“ sollten wir mehrere Einstellungen sehen: „prometheus.service“ und „prometheus.serviceMonitor“. Wir werden beide oben genannten Einstellungen aktivieren, um den erforderlichen Dienst und ServiceMonitor bei Verwendung des Helm-Diagramms zu generieren. Hier ist der spezielle Abschnitt, in dem wir den Dienst aktivieren, serviceMonitor aktivieren und die Beschriftungen im Abschnitt serviceMonitor definieren:

`servicemonitor`-Unterstützung wurde kürzlich zum Helm-Chart des NGINX Ingress-Controllers hinzugefügt. 
prometheus:
## NGINX- oder NGINX Plus-Metriken im Prometheus-Format verfügbar machen.
create: true

## Konfiguriert den Port zum Scrapen der Metriken.
port: 9113

secret: ""

## Konfiguriert das verwendete HTTP-Schema.
scheme: http

service:
## Erfordert prometheus.create=true
create: true

serviceMonitor:
create: true
labels: { app: nginx-ingress-servicemonitor } 

Aufschlüsselung der Werte aus dem Obigen:

prometheus:
## NGINX- oder NGINX Plus-Metriken im Prometheus-Format bereitstellen.
create: true

Informiert Helm, dass Sie den NIC-Prometheus-Endpunkt aktivieren möchten. Zusätzlich können Sie bei Bedarf einen Port, ein Schema und ein Geheimnis definieren. Wenn Sie den Wert von prometheus.service.create auf „true“ setzen, erstellt Helm automatisch den NIC ServiceMonitor-Dienst.

Dienst:
## Erstellt einen ClusterIP-Dienst, um Prometheus-Metriken intern verfügbar zu machen
## Erfordert prometheus.create=true
create: true

Zum Abschluss erstellen wir den ServiceMonitor. Wenn Sie ihn auf true setzen und die passenden Labels hinzufügen, erstellen und fügen wir die Labels hinzu, die mit Ihrer Prometheus-Ressource übereinstimmen.

serviceMonitor:
## Erstellt einen serviceMonitor, um Statistiken zu den Kubernetes-Pods anzuzeigen.
create: true
## Kubernetes-Objektbezeichnungen, die an das serviceMonitor-Objekt angehängt werden sollen.
labels: { app: nginx-ingress-servicemonitor } 

Das Label verweist zurück auf den Namen des Dienstes. Labels: { app: nginx-ingress-servicemonitor } Zusammenfassend. Aktivieren Sie Prometheus. Dadurch wird die Prometheus-Exportfunktion von NIC verfügbar gemacht. Definieren Sie ein Serviceobjekt. Auf diese Weise erkennt der Prometheus ServiceMonitor NIC-Prometheus-Export-Endpunkte. Definieren Sie ein ServiceMonitor-Objekt. Dies weist Prometheus ServiceMonitor an, dieses Ding zu überwachen.

Jetzt können wir NGINX Ingress Controller mit Helm installieren.

Nachdem wir unsere values.yaml angepasst haben, können Sie den NGINX Ingress Controller installieren. helm install nic01 -n nginx-ingress --create-namespace -f values.yaml . Wenn Sie NGINX Ingress Controller ausrollen, öffnen Sie das Prometheus-Dashboard und gehen zum Status-Menü. Dort navigieren Sie zu den Ansichten für Ziele und Serviceerkennung. Sobald Prometheus Ihre neue ServiceMonitor-Ressource gefunden hat, startet es das Abrufen der Endpunkt-Metriken, die sofort im Dashboard erscheinen.

Abbildung 2: Prometheus-Diensterkennung

Abbildung 3: Prometheus-Ziel

Abbildung 4: Prometheus NGINX-Abfrage

Wir sehen, dass die Verwendung nativer Kubernetes-Tools wie Helm und Prometheus mit NGINX Ingress Controller das Sammeln von Metriken zu Beginn der Bereitstellung erheblich vereinfachen kann, indem sofort einsatzbereite Metriken bereitgestellt werden. Hier sind Referenzdokumente zur Installation von Prometheus-Operator : https://prometheus-operator.dev/ https://github.com/prometheus-operator/prometheus-operator