Debugging-Informationen erfassen
In diesen Abschnitten wird beschrieben, wie Sie Logs und Konfigurationen für das Debugging erfassen.
Logs aus Operator-Pods abrufen
Führen Sie die folgenden Befehle aus, um Logs von den Operator-Pods abzurufen:
kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system
Datenbank-Pod-Logs abrufen
Führen Sie die folgenden Befehle aus, um Datenbank-Pod-Logs abzurufen:
kubectl logs al-<id-instance-name>-0 -n db
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster-name -c database -n db
Die folgenden Logs sind Beispiele für erfolgreiche Systemdiagnosen der Datenbank:
I1106 16:17:28.826188 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:28.826295 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:34.810447 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:34.834844 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:38.825843 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:38.825959 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
postgresql.log abrufen
Führen Sie den folgenden Befehl aus, um den postgresql.log abzurufen:
kubectl exec -it al-id-instance-name-0 -n db -c database -- cat /obs/diagnostic/postgresql.log
DBInstance-YAML-Datei abrufen
Führen Sie den folgenden Befehl aus, um die YAML-Datei für die DBInstance abzurufen:
kubectl get dbclusters.a <dbcluster-name> -n db -o yaml
Konfigurationen und Logs für HA-Szenarien abrufen
Führen Sie die folgenden Befehle aus, um Konfigurationen und Logs abzurufen, die sich speziell auf Szenarien mit hoher Verfügbarkeit (High Availability, HA) beziehen:
kubectl get replicationconfig -n <namespace>
kubectl get deletestandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get createstandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get failovers.alloydbomni.dbadmin.goog -n <namespace> -o yaml
Pod- und STS-Status abrufen
Führen Sie die folgenden Befehle aus, um den Status von Pods und StatefulSets (STS) abzurufen:
kubectl describe pod -n <namespace> <pod-name>
kubectl describe statefulset -n <namespace> al-<id-instance-name>
Fehler finden
In diesen Abschnitten wird beschrieben, wie Sie Fehler erkennen.
Nach Fehlerstatus und Fehlercodes suchen
Sehen Sie sich die DBCluster-YAML-Datei unter dem Status an, um den Fehlercode zu ermitteln. Weitere Informationen finden Sie in der Dokumentation zu Fehlercodes.
Führen Sie den folgenden Befehl aus, um die DBCluster-YAML-Datei abzurufen:
kubectl get dbclusters.a <dbcluster-name> -n <dbcluster-namespace> -o yaml
Achten Sie auf criticalIncidents. Dieser Abschnitt enthält den Fehlercode und einen Stacktrace.
Hier einige Beispiele für criticalIncidents:
status:
certificateReference:
certificateKey: ca.crt
secretRef:
name: dbs-al-cert-dr-mce
namespace: dr
conditions:
- lastTransitionTime: "2024-10-07T22:46:03Z"
...
criticalIncidents:
- code: DBSE0304
createTime: "2024-10-03T11:50:54Z"
message: 'Healthcheck: Health check invalid result.'
resource:
component: healthcheck
location:
group: alloydbomni.internal.dbadmin.goog
kind: Instance
name: bc0f-dr-mce
namespace: dr
version: v1
stackTrace:
- component: healthcheck
message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
= Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
Lag is 384837.296269 seconds, wanted 35 seconds'
Sie können den Status auch abrufen, indem Sie bestimmte Felder im JSON-Format extrahieren:
kubectl get dbcluster.${DBTYPE:?} -n "${PROJECT:?}" "${DBCLUSTER:?}" -o json -o jsonpath='{.status.criticalIncidents}' | jq
Die Ausgabe sieht etwa so aus:
[
{
"code": "DBSE0085",
"createTime": "2024-03-14T05:41:37Z",
"message": "Platform: Pod is unschedulable.",
"resource": {
"component": "provisioning",
"location": {
"group": "alloydb.internal.dbadmin.goog",
"kind": "Instance",
"name": "b55f-testdbcluster",
"namespace": "dbs-system",
"version": "v1"
}
},
"stackTrace": [
{
"component": "provisioning",
"message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
}
]
}
]
Wenn sich die Fehlermeldung auf den Datenbank-Pod bezieht, prüfen Sie die Instanzen und Pod-Ressourcen im selben Namespace:
kubectl get instances.a dbcluster_name -n dbcluster_namespace -o yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster_name -l alloydbomni.internal.dbadmin.goog/task-type=database -n dbcluster_namespace
Arbeitsspeicherprobleme beheben
In diesen Abschnitten wird beschrieben, wie Sie Speicherprobleme beheben.
Ausführen und Heap-Dump erstellen
Aktivieren Sie diese Funktion nur zur Fehlerbehebung. Denken Sie daran, die Funktion danach wieder zu deaktivieren.
So erstellen Sie einen Heapdump:
- Ändern Sie die Operatorbereitstellung im Namespace
alloydb-omni-systemmit dem Namenfleet-controller-managerundlocal-controller-manager. - Fügen Sie dem Pod
--pprof-address=:8642oder einem anderen verfügbaren Port das folgende Argument hinzu. - Warten Sie, bis der Controller-Pod neu gestartet wurde.
Leiten Sie den vorherigen Port weiter. Beispiel:
kubectl port-forward -n alloydb-omni-system fleet-controller-manager-pod-name 8642:8642Führen Sie in einem anderen Terminal
go tool pprof http://localhost:8642/debug/pprof/heapaus. Ändern Sie den Port so, dass er mit dem vorherigen Port übereinstimmt, wenn Sie8642nicht verwenden.Stellen Sie eine Verbindung zur Adresse her und führen Sie Befehle zur Fehlerbehebung aus. Beispiel:
top.Nach Abschluss der Fehlerbehebung machen Sie Schritt 1 rückgängig, indem Sie das Argument entfernen und warten, bis der Pod neu gestartet wird.
Anzahl der Ressourcen ermitteln, die vom Operator überwacht werden
Führen Sie die folgenden Befehle aus, um die verwendeten Ressourcen zu ermitteln:
kubectl get backuprepositories -A | wc -l
kubectl get failovers -A | wc -l
kubectl get instancebackupplans -A | wc -l
kubectl get instancebackups -A | wc -l
kubectl get instancerestores -A | wc -l
kubectl get instances -A | wc -l
kubectl get instanceswitchovers -A | wc -l
kubectl get lrojobs -A | wc -l
kubectl get replicationconfigs -A | wc -l
kubectl get sidecars -A | wc -l
kubectl get deployments -A | wc -l
kubectl get statefulsets -A | wc -l
kubectl get certificates.cert-manager.io -A | wc -l
kubectl get issuers.cert-manager.io -A | wc -l
kubectl get configmaps -A | wc -l
kubectl get persistentvolumeclaims -A | wc -l
kubectl get persistentvolumes -A | wc -l
kubectl get pods -A | wc -l
kubectl get secrets -A | wc -l
kubectl get services -A | wc -l
kubectl get storageclasses.storage.k8s.io -A | wc -l
Wenn die Anzahl der Secrets hoch ist, kann dies beispielsweise zu einem OOM-Fehler (Out Of Memory) führen.
kubectl get secrets -A | wc -l
Erweiterte HA-Fehlerbehebung
In diesem Abschnitt wird auf Ressourcen verwiesen, die interne Implementierungen sind. Diese können jederzeit geändert werden und es gibt keine Zusagen zur Abwärtskompatibilität. Wenden Sie manuelle Korrekturen nur auf Probleme in Nicht-Produktionsdatenbanken an. Wenn Sie diese Schritte ausführen, kann die Datenbank möglicherweise nicht mehr wiederhergestellt werden.
Die Einrichtung von AlloyDB Omni HA erfolgt in drei Phasen:
- Richten Sie die primäre Datenbank so ein, dass sie eine Verbindung von der Standby-Datenbank empfängt.
- Initialisieren Sie die Standby-Instanz und stellen Sie eine Verbindung zur primären Instanz her.
- Legen Sie die primären Einstellungen fest, um die Verbindung synchron zu gestalten.
Schritt 2 dauert in der Regel am längsten. Je nach Größe der Datenbank kann dies mehrere Stunden dauern.
Jeder Instanz, die repliziert wird, sollte ein replicationconfig zugeordnet sein. Beispiel:
bash
❯ k get replicationconfigs.alloydbomni.internal.dbadmin.goog
NAME PARENT TYPE ROLE READY HEALTHY
9f47-dbcluster-sample--7576-dbcluster-sample 9f47-dbcluster-sample Physical Upstream True True
ds-7576-dbcluster-sample 7576-dbcluster-sample Physical Downstream True True
In diesem Fall gilt Folgendes:
- Die Instanz
9f47-dbcluster-sampleist als physischer Upstream konfiguriert. - Die Instanz
7576-dbcluster-sampleist als physischer Downstream konfiguriert.
Die Spezifikation der Replikationskonfiguration gibt die beabsichtigten Einstellungen an, während der Status den tatsächlichen Zustand widerspiegelt, der aus der Datenbank gelesen wird. Wenn die Spezifikation und der Status nicht übereinstimmen, versucht der Controller weiterhin, die Änderung anzuwenden, oder es liegt ein Fehler vor, der verhindert, dass die Änderung angewendet wird. Dies würde sich in den Statusfeldern widerspiegeln.
Standby-Jobs
Es sollte zwei Gruppen interner Jobs geben, die den Workflow eines Standby-Geräts verfolgen:
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
Wenn die Einrichtung anscheinend nicht weitergeht, sehen Sie sich die Jobs an, die sich auf den Datenbankcluster (DBC) beziehen. Der Job enthält möglicherweise Fehlermeldungen, die den Status der Einrichtung erläutern. Jobs werden einige Zeit nach Abschluss automatisch bereinigt. Wenn also keine Jobs ausgeführt werden, werden möglicherweise auch keine angezeigt.
k get createstandbyjob
Die Ausgabe sieht etwa so aus:
apiVersion: alloydbomni.dbadmin.gdc.goog/v1
kind: CreateStandbyJob
metadata:
creationTimestamp: "2024-11-05T03:34:26Z"
finalizers:
- createstandbyjob.dbadmin.goog/finalizer
generation: 1804
labels:
dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
namespace: db
resourceVersion: "11819071"
uid: 1f24cedf-b326-422f-9405-c96c8720cd90
spec:
attempt: 3
cleanup: false
currentStep: SetupSynchronous
currentStepTime: "2024-11-05T03:45:31Z"
metadata:
dbc: foo-ha-alloydb1-clone1
primaryInstance: ac00-foo-ha-alloydb1-clone1
retryError: 'etcdserver: leader changed'
standbyInstance: 6036-foo-ha-alloydb1-clone1
requeueTime: "2024-11-05T18:33:03Z"
startTime: "2024-11-05T03:36:56Z"
Primäre Bestätigung
Prüfen Sie zuerst, ob die primäre Instanz richtig eingerichtet ist. Für jeden Standby-Server sollte ein Replikationsprofil vorhanden sein. Wenn isSynchronous in der Spezifikation und im Status „true“ ist, sollte die Einrichtung abgeschlossen sein. Wenn isSynchronous in der Spezifikation und im Status auf „false“ gesetzt ist, wurde Schritt 3 noch nicht erreicht. Sehen Sie sich die Standby-Jobs an, um festzustellen, ob Jobs ausgeführt werden und ob Fehlermeldungen vorliegen.
replication:
profiles:
- isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
password:
name: ha-rep-pw-dbcluster-sample
namespace: default
passwordResourceVersion: "896080"
role: Upstream
type: Physical
username: alloydbreplica
Prüfen Sie, ob die Annotation disableHealthcheck falsch ist. Sie sollte nur während eines Failovers oder Switchovers deaktiviert werden.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Abfragen
Um zu prüfen, ob die Ressourcen im DB-Pod richtig eingerichtet sind, melden Sie sich als Administratornutzer alloydbadmin in der Datenbank an. Führen Sie dann die folgenden Abfragen aus:
Replikationsslot
alloydbadmin=# select * from pg_replication_slots;
-[ RECORD 1 ]-------+---------------------------------------------
slot_name | d85d_dbcluster_sample
plugin |
slot_type | physical
datoid |
database |
temporary | f
active | t
active_pid | 250
xmin | 16318
catalog_xmin |
restart_lsn | 0/CA657F0
confirmed_flush_lsn |
wal_status | reserved
safe_wal_size |
two_phase | f
Ein guter Zustand ist das Vorhandensein eines Replikations-Slots mit demselben Namen wie die Standby-Instanz. Das Fehlen eines Replikations-Slots deutet darauf hin, dass der erste Einrichtungsschritt nicht erfolgreich abgeschlossen wurde.
Wenn active == t nicht zutrifft, bedeutet das, dass die Standby-Verbindung aus irgendeinem Grund nicht hergestellt wird (Netzwerk, Standby-Einrichtung nicht abgeschlossen usw.). Die Fehlersuche muss wahrscheinlich auf der Standby-Seite fortgesetzt werden.
Replikationsstatistiken
alloydbadmin=# select * from pg_stat_replication;
-[ RECORD 1 ]----+----------------------------------------------------------------
pid | 250
usesysid | 16385
usename | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr | 10.54.79.196
client_hostname | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port | 24914
backend_start | 2024-10-30 21:44:26.408261+00
backend_xmin |
state | streaming
sent_lsn | 0/CA64DA8
write_lsn | 0/CA64DA8
flush_lsn | 0/CA64DA8
replay_lsn | 0/CA64DA8
write_lag |
flush_lag |
replay_lag |
sync_priority | 2
sync_state | sync
reply_time | 2024-11-04 22:08:04.370838+00
Wenn diese nicht vorhanden ist, besteht keine aktive Verbindung. Der sync_state sollte sync lauten. Wenn es nicht sync ist, wurde der letzte Schritt der Einrichtung nicht abgeschlossen. Weitere Informationen finden Sie in den Logs oder Jobs.
Stand-by-Überprüfung
Das Standby-System sollte ein Replikationsprofil haben, das mit dem Profil des primären Systems übereinstimmt:
replication:
profiles:
- host: 10.54.79.210
isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
passwordResourceVersion: "896080"
port: 5432
role: Downstream
type: Physical
username: alloydbreplica
Wenn keine Verbindung vom Standby- zum primären Knoten besteht, gibt es zwei häufige Möglichkeiten:
- Der Standby-Modus wird noch eingerichtet.
- Beim Einrichten oder Verbinden des Standby-Modus ist ein Fehler aufgetreten.
Um zu prüfen, ob Option 1 zutrifft, rufen Sie die Datenbank-Pod-Logs ab und suchen Sie nach Log-Anweisungen mit dem Namen dbdaemon/setupPhysicalReplicationDownstream. Hier sind Beispiele für Protokolle einer erfolgreichen Einrichtung:
I1104 22:42:42.604871 103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590 103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403 103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440 103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749 103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783 103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565 103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621 103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689 103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838 103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732 103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
Wenn ein Verbindungsfehler auftritt, prüfen Sie die Logs des Datenbank-Pods sowie die Logdatei in der Datenbank unter /obs/diagnostic/postgresql.log, um die Fehlerursache zu ermitteln. Ein häufiger Fehler ist, dass keine Netzwerkverbindung zwischen dem Standby- und dem primären Gerät besteht.
Manuelle Korrekturen
Am einfachsten lassen sich HA-Probleme beheben, indem Sie HA deaktivieren und dann wieder aktivieren. Dazu setzen Sie numberOfStandbys auf 0 und dann auf die gewünschte Zahl. Wenn Stand-bys deaktiviert bleiben, führe die folgenden Schritte aus, um die HA-Einrichtung manuell zurückzusetzen:
- Löschen Sie die Standby-Instanzen manuell.
Stellen Sie eine Verbindung zur primären Datenbank her. Fragen Sie die aktuellen Replikationsslots ab und löschen Sie alle Replikationsslots von Standby-Instanzen, die Sie löschen möchten:
select pg_drop_replication_slot('<replication_slot_name_here>');Löschen Sie alle Replikationsprofile aus der primären Instanz, die Sie löschen möchten.
Wenn eine Instanz in letzter Zeit nicht abgeglichen wurde, können Sie den Annotationswert forceReconcile bearbeiten. Legen Sie einen beliebigen numerischen Wert fest. Das ist der Zeitstempel der letzten Aktualisierung der Anmerkung. Der einzige Zweck dieser Anmerkung besteht darin, ein Feld bereitzustellen, das wir aktualisieren können, um einen neuen Abgleich zu erzwingen.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Datenbank-Engine- und Audit-Logs erfassen
Die Datenbank-Engine-Logs und Audit-Logs sind als Dateien im Datenbank-Pod verfügbar (erfordert Root-Zugriff):
obs/diagnostic/postgresql.logobs/diagnostic/postgresql.audit
export NAMESPACE=dbcluster-namespace
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER} -l alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
kubectl exec -n ${NAMESPACE} ${DBPOD} -it -- /bin/bash
$ ls -la /obs/diagnostic/
-rw------- 1 postgres postgres 98438 Sep 25 20:15 postgresql.audit
-rw------- 1 postgres postgres 21405058 Sep 25 20:24 postgresql.log
Messwerte für Datenbanken und Datenbank-Pods erfassen
Der AlloyDB Omni-Operator bietet eine Reihe von grundlegenden Messwerten für die AlloyDB Omni-Engine und den Pod, auf dem sie gehostet wird. Die Messwerte sind als Prometheus-Endpunkte an Port 9187 verfügbar. Um auf die Endpunkte zuzugreifen, müssen Sie die Pod-Namen für den Datenbank-Pod und den Datenbanküberwachungs-Pod anhand der Labels „DBCluster“ und „task-type“ wie folgt ermitteln.
export NAMESPACE=default
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
export MONITORINGPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=monitoring -o jsonpath='{.items[0].metadata.name}'`
Auf AlloyDB Omni-Datenbankmesswerte zugreifen
kubectl port-forward -n ${NAMESPACE} ${MONITORINGPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
Auf Datenbank-Pod-Messwerte zugreifen
kubectl port-forward -n ${NAMESPACE} ${DBPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
Sie können Prometheus auch so konfigurieren, dass die Messwerte in Ihrem Kubernetes-Cluster erfasst werden. Weitere Informationen finden Sie unter Prometheus Kubernetes Service Discovery-Konfiguration.