Ein Unternehmen aus dem Bereich Streaming & Media benötigte ein neues Monitoring-System für seine Oracle-Datenbank.
VORAUSSETZUNGEN
- Der Kubernetes-Cluster ist eingerichtet und läuft.
- Prometheus-Operator ist eingerichtet und funktioniert.
- Die Datenbank arbeitet auf einer separaten VM, auf Bare Metal oder auf einem Serviceangebot eines Cloud-Anbieters und verfügt über eine Art von Konnektivität zwischen K8s und der DB.
- SSH-Zugang zum DB-Host.
DIE HERAUSFORDERUNG
Wir alle wissen, was ein Prometheus-Operator ist und wie man ihn mehr oder weniger verwendet, um verschiedene Dienste in unserem Kubernetes-Cluster zu überwachen. Aber was ist, wenn wir eine Datenbank haben, die außerhalb des Clusters auf Bare Metal oder einer separaten virtuellen Maschine läuft?
Hier sind also einige Hinweise, wie man dies erreichen kann.
DIE LÖSUNG
Zuerst müssen Sie per SSH auf die Datenbank zugreifen und den neuesten Prometheus-Node-Exporter herunterladen:
und extrahieren Sie es:
# tar zxvf node_exporter-1.0.1.linux-amd64.tar.gz
einen systemd-Dienst vorbereiten:
# cat /etc/systemd/system/node_exporter.service
# [Unit]
# Description=Node Exporter
# Wants=network-online.target
# After=network-online.target
#
# [Service]
# User=root
# ExecStart=/opt/node_exporter/node_exporter
#
# [Install]
# WantedBy=default.target
#systemctl daemon-reload
Start and enable the service:
# systemctl start node_exporter
# systemctl enable node_exporter
So weit, so gut. Bei einigen Cloud-Anbietern kann Ihr Dienst dem öffentlichen Internet ausgesetzt sein, wenn die Firewall nicht korrekt konfiguriert ist. Prüfen Sie, ob Sie auf den Dienst zugreifen können, und wenn ja, überlegen Sie, wie Sie ihn absichern können. Wahrscheinlich wollen Sie nicht, dass er offengelegt wird, versuchen Sie es mit Firewall-Regeln (vom Cloud-Anbieter oder vom Host selbst). Beispielbefehl zum Hinzufügen einer Regel vom Host:
# iptables -I INPUT -p tcp -s [kubernetes_ip_in_cidr] -m tcp --dport 9100 -j ACCEPT
# service iptables save
# service iptables reload
Jetzt müssten wir einen Dienst vorbereiten, den Prometheus überprüfen kann. Aber wo ist der Unterwasserstein versteckt? Welchen Dienst sollten wir verwenden, da unsere Datenbank außerhalb des Kubernetes-Clusters läuft, und wie können wir auf ihn zugreifen? Hier kommt die Kubernetes-Dienstressource vom Typ "ExternalName" mit einer Kombination aus "Endpoints" und dem Standard-Prometheus-"Service Monitor" ins Spiel.
# ---
# apiVersion: v1
# kind: Service
# metadata:
# name: node-exporter
# namespace: monitoring
# labels:
# k8s-app: node-exporter
# spec:
# type: ExternalName
# externalName: [ip_address_of_the_db]
# clusterIP: ""
# ports:
# - name: metrics
# port: 9100
# protocol: TCP
# targetPort: 9100
# ---
# apiVersion: v1
# kind: Endpoints
# metadata:
# name: node-exporter
# labels:
# k8s-app: node-exporter
# subsets:
# - addresses:
# - ip: [ip_address_of_the_db]
# ports:
# - name: metrics
# port: 9100
# protocol: TCP
# ---
# apiVersion: monitoring.coreos.com/v1
# kind: ServiceMonitor
# metadata:
# labels:
# k8s-app: node-exporter
# release: prometheus
# name: node-exporter
# namespace: monitoring
# spec:
# endpoints:
# - honorLabels: true
# interval: 5s
# path: /metrics
# port: metrics
# relabelings:
# - action: labelmap
# regex: __meta_kubernetes_service_label_(.+)
# scheme: http
# scrapeTimeout: 3s
# jobLabel: node-exporter
# namespaceSelector:
# matchNames:
# - monitoring
# selector:
# matchLabels:
# k8s-app: node-exporter
Wichtig dabei ist, dass der Name des Dienstes und der Name des Endpunkts übereinstimmen, damit Kubernetes "weiß", wie der Datenverkehr über diesen Dienst geleitet werden soll. Es ist sinnvoll, diese Ressourcen in demselben Kubernetes-Namensraum zu erstellen, in dem Prometheus läuft (standardmäßig Überwachung). Rufen Sie Ihr Prometheus-Dashboard auf, und Sie sollten nach einer Weile Ihre neuen Datenbankmetriken sehen. Das sind die Host-Metriken, aber was ist mit den DB-Metriken? Wir können einige der offiziellen DB-Exporter von Prometheus verwenden, wie zum Beispiel: https://github.com/iamseth/oracledb_exporter. Schauen wir uns an, wie es läuft.
# ---
# apiVersion: apps/v1
# kind: Deployment
# metadata:
# name: oracledb-exporter
# namespace: monitoring
# spec:
# selector:
# matchLabels:
# app: oracledb-exporter
# strategy:
# type: Recreate
# template:
# metadata:
# labels:
# app: oracledb-exporter
# release: oci-exporter
# spec:
# containers:
# - env:
# - name: DATA_SOURCE_NAME
# value: [dbusername]/[dbpassword]@//[service_addres_of_the_database]:1521/[dbservice]
# image: iamseth/oracledb_exporter:latest
# imagePullPolicy: IfNotPresent
# name: oracldb-exporter
# ports:
# - containerPort: 9161
# name: scrape
# protocol: TCP
# ---
# apiVersion: v1
# kind: Service
# metadata:
# labels:
# app: oracledb-exporter
# name: oracledb-exporter
# namespace: monitoring
# spec:
# ports:
# - name: scrape
# port: 9161
# protocol: TCP
# targetPort: 9161
# selector:
# app: oracledb-exporter
# release: oci-exporter
# type: ClusterIP
# ---
# apiVersion: monitoring.coreos.com/v1
# kind: ServiceMonitor
# metadata:
# labels:
# release: prometheus
# name: oracledb-exporter
# namespace: monitoring
# spec:
# endpoints:
# - honorLabels: true
# interval: 15s
# path: /metrics
# port: scrape
# relabelings:
# - action: labelmap
# regex: __meta_kubernetes_service_label_(.+)
# scheme: http
# scrapeInterval: 15s
# scrapeTimeout: 10s
# jobLabel: oracledb-exporter
# namespaceSelector:
# matchNames:
# - monitoring
# selector:
# matchLabels:
# app: oracledb-exporter
Für alle Prometheus 'ServiceMonitor' ist es wichtig, dass die 'release: Prometheus' übereinstimmen, da dies die Bezeichnung ist, die der Operator erwartet, um Maßnahmen ergreifen zu können. Wenn Sie möchten, können Sie einige Grafana-Dashboards importieren, um sie mit beiden Exportern zu verwenden. Der Node-Exporter könnte so funktionieren, wie er ist, er fügt die Datenbank-Host-IP hinzu und sie sollte im Standard-Prometheus-Grafana-Dashboard über die Nodes auswählbar sein. Für den Datenbankexporter bräuchte man ein separates Dashboard und eine gewisse Feinabstimmung der Abfragen, die in das Standard-Docker-Image eingebaut sind, aber mit ein wenig DBA-Hilfe hätte man voll funktionsfähige DB-Abfragen. In diesem Fall ist die Einrichtung über ein Helm-Diagramm zur einfachen Aktualisierung der Bereitstellung vollständig automatisiert.
DIE SCHLUSSFOLGERUNG
Bitte verfolgen Sie unsere Überwachungsverfahren hier. Wenn Sie Fragen zu einzelnen Schritten unserer Konfiguration haben, können Sie sich an uns wenden, und wir werden Ihnen die Antworten geben.