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.
Mit der benutzerdefinierten Ressourcendefinition (CRD) von Prometheus ServiceMonitor können Sie deklarativ definieren, wie ein dynamischer Satz von Diensten überwacht werden soll. Die überwachten Dienste werden mithilfe von Kubernetes-Label-Selektoren definiert. Auf diese Weise kann eine Organisation Konventionen einführen, die regeln, wie Messgrößen offengelegt werden. Gemäß diesen Konventionen werden neue Dienste automatisch erkannt und Prometheus beginnt mit der Erfassung von Messdaten, ohne dass das System neu konfiguriert werden muss. ServiceMonitor
ist Teil des Prometheus Operators. Diese Ressourcen beschreiben und verwalten Überwachungsziele, die von Prometheus gescrapt werden sollen. Die Prometheus-Ressource stellt über ein ServiceMonitor-Selector-
Feld eine Verbindung zu ServiceMonitor
her. Prometheus kann leicht erkennen, welche Ziele zum Scraping markiert wurden. Dies gibt Ihnen mehr Kontrolle und Flexibilität, um ServiceMonitor-
Ressourcen in Ihrem Kubernetes-Cluster zu nutzen, um Lösungen wie NGINX Ingress Controller zu überwachen. Um die Dinge einfacher zu machen und sofort einsatzbereite Metriken für den NGINX Ingress Controller bereitzustellen, haben wir kürzlich die Möglichkeit hinzugefügt, Prometheus ServiceMonitor
zu unserem Helm-Diagramm zu verwenden. Dadurch können Metriken ganz einfach aktiviert werden, damit Prometheus direkt nach der Bereitstellung des NGINX Ingress Controller mit dem Scraping beginnen kann. Um diese Funktion zu verwenden, müssen wir einen zweiten Dienst hinzufügen, der speziell für die Metrikerfassung erstellt wurde und an den sich ServiceMonitor
„anhängt“. Dadurch wird dem Prometheus-Betreiber mitgeteilt, welchen Dienst er überwachen soll (anhand der Bezeichnungen in den Metadaten), sodass er weiß, was und wo gescrapt werden muss. Beispiel dafür, wie ein Dienst für den NGINX Ingress Controller aussehen würde, wenn er Teil der Bereitstellungs- oder Helmdateien wäre:
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
Es ist notwendig, eine Prometheus-Ressource zu erstellen, die so konfiguriert ist, dass sie nach den ServiceMonitor
-Ressourcen sucht. Dadurch erkennt Prometheus schnell und einfach, von welchen Endpunkten aus nach Metriken gesucht werden muss. In unserem Beispiel unten teilt diese Ressource Prometheus mit, welche Elemente gemäß der Spezifikation überwacht werden sollen. Im Folgenden überwachen wir spec.serviceMonitorSelector.matchLabels:
. Wir können sehen, dass Prometheus in jedem Namespace nach MatchLabels mit app.nginx-ingress-servicemonitor
sucht. Dies entspricht der ServiceMonitor
-Ressource, die von den Helm-Diagrammen und Helm des NGINX Ingress Controller bereitgestellt wird.
API-Version: monitoring.coreos.com/v1
Art: Prometheus
Metadaten:
Name: Prometheus
Labels:
Prometheus: Prometheus
Spezifikation:
Replikate: 1
serviceAccountName: prometheus
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector:
matchLabels:
app: nginx-ingress-servicemonitor
Ressourcen:
Anfragen:
Speicher: 500 Meilen
Hier ist ein Diagramm, das die verschiedenen Teile verbindet: Abbildung 1: Service-Monitor-Objektbeziehung
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
Sobald Prometheus und die Prometheus-CRDs im Cluster installiert sind, können wir unsere Prometheus-Ressource erstellen. Indem wir dies im Voraus bereitstellen, können wir unser Prometheus-Setup mit den Beschriftungen „vorbereiten“, die wir im Helm-Diagramm verwenden werden. Mit diesem Ansatz können wir Prometheus automatisch mit der Suche nach dem NGINX Ingress Controller und dem Scraping nach Metriken beginnen lassen. Unsere Prometheus-Ressource wird vor der Installation des NGINX Ingress Controller bereitgestellt. Dadurch kann der Prometheus-Operator
unseren NGINX-Ingress-Controller nach der Bereitstellung automatisch abrufen und durchsuchen und so schnell Messdaten bereitstellen.
API-Version: monitoring.coreos.com/v1
Art: Prometheus
Metadaten:
Name: Prometheus
Namespace: Standard
Labels:
Prometheus: Überwachung
Spezifikation:
Replikate: 1
serviceAccountName: prometheus
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector:
matchLabels:
app: nginx-ingress-servicemonitor
Ressourcen:
Anfragen:
Speicher: 500 Meilen
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.
„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
Zuletzt müssen wir den ServiceMonitor
erstellen. Wenn Sie dies auf „true“ setzen und die richtigen Beschriftungen hinzufügen, werden die Beschriftungen erstellt und hinzugefügt, die zu unserer Prometheus-Ressource passen.
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.
Helm
installieren.Nachdem wir unsere values.yaml
geändert haben, können wir mit der Installation des NGINX Ingress-Controllers fortfahren. helm install nic01 -n nginx-ingress --create-namespace -f values.yaml.
Nachdem wir NGINX Ingress Controller bereitgestellt haben, können wir das Prometheus-Dashboard öffnen und zum Statusmenü navigieren. Von dort aus können wir zu den Ansichten „Ziele“ und „Service Discovery“ navigieren. Sobald Prometheus unsere neue ServiceMonitor-Ressource gefunden hat, beginnt es mit dem Scraping des Endpunkts und sammelt Messdaten, die sofort im Prometheus-Dashboard angezeigt werden.
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
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."