Observability-Metriken von MongoDB Flex

In diesem Artikel erfahren Sie mehr über die Bedeutung der von MongoDB exportierten Observability-Metriken. Alle Metriken sind im OpenMetrics-Format verfügbar und können von Zeitreihendatenbanken wie Prometheus, VictoriaMetrics oder Grafana Mimir gesammelt werden.

In MongoDB gibt es derzeit einen bekannten Fehler, der die Genauigkeit der RAM- und CPU-Metriken beeinträchtigt. Die gemeldeten Werte spiegeln möglicherweise nicht die tatsächlichen Systemressourcen wider. Dieses Problem wird derzeit untersucht.

Serviceverfügbarkeit

mongodb_up

Gibt an, ob der letzte Scrape den Datenbank-Daemon erreichen konnte und dieser einen fehlerfreien Zustand gemeldet hat. (Typ: Gauge)

Expand

Label	Beschreibung	Werte
node_type	Typ des Datenbankknotens	0 = Primary, 1 = Secondary, 2 = Arbiter

Dies ist die wichtigste Metrik für das Alerting. Wenn der Wert 0 ist, sind alle anderen Metriken nicht verfügbar.

mongodb_uptimeMillis

Server-Uptime in Millisekunden (Typ: Counter)

Expand

Label	Beschreibung
rs_nm	Name des Replica Sets
rs_state	Zustand des Replica-Set-Members
node_type	Typ des Datenbankknotens

Kann zur Berechnung von Uptime-Prozentsätzen verwendet werden. Ein Zurücksetzen auf 0 deutet auf einen Server-Neustart hin.

Verbindungen

mongodb_connections

Anzahl der Verbindungen zum Server (Typ: Gauge)

Expand

Label	Beschreibung	Mögliche Werte
conn_type	Verbindungstyp	current, available
node_type	Typ des Datenbankknotens	0, 1, 2

Hohe current-Verbindungswerte deuten auf falsch konfigurierte Connection-Pools oder Connection-Leaks hin.

Speicher

mongodb_mem_resident

Vom MongoDB-Prozess verwendeter Speicher in Megabyte (Typ: Gauge)

Expand

Label	Beschreibung
node_type	Typ des Datenbankknotens

mongodb_mem_virtual

Vom MongoDB-Prozess verwendeter virtueller Speicher in Megabyte (Typ: Gauge)

Expand

Label	Beschreibung
node_type	Typ des Datenbankknotens

Virtueller Speicher ist aufgrund von Memory-Mapped-Dateien in der Regel viel größer als der residente Speicher.

Operationen

mongodb_opcounters_total

Gesamtzahl der Operationen nach Typ seit dem Serverstart (Typ: Counter)

Expand

Label	Beschreibung	Mögliche Werte
type	Operationstyp	insert, query, update, delete, getmore, command
node_type	Typ des Datenbankknotens	0, 1, 2

Verwenden Sie rate(), um die Operationen pro Sekunde zu berechnen. Hohe Raten bei hoher Latenz deuten auf Performance-Probleme hin.

Netzwerk

mongodb_network_bytes_total

Netzwerkverkehr in Bytes (Typ: Counter)

Expand

Label	Beschreibung	Mögliche Werte
type	Verkehrsrichtung	in, out
node_type	Typ des Datenbankknotens	0, 1, 2

Hardware-Metriken

Die folgenden Metriken repräsentieren Ressourcen auf Systemebene. Alle enthalten das Label node_type.

CPU

hardware_system_cpu_io_wait_milliseconds

Wartezeit für I/O-Operationen (Typ: Counter)

Berechnen Sie den normalisierten CPU-I/O-Wait: rate(hardware_system_cpu_io_wait_milliseconds[1m]) / 10 / hardware_platform_num_logical_cpus

hardware_platform_num_logical_cpus

Anzahl der logischen CPU-Kerne (Typ: Gauge)

Speicher

hardware_system_memory_mem_available_kilobytes

Verfügbarer Speicher in Kilobyte (Typ: Gauge)

Nützlicher als mem_free, da dieser Metrikwert rückforderbaren Cache-Speicher enthält.

hardware_system_memory_cached_kilobytes

In-Memory-Cache für Festplattendateien in Kilobyte (Typ: Gauge)

Hohe Werte sind normal und deuten auf eine effiziente Speichernutzung hin.

Festplatte

hardware_disk_metrics_disk_space_free_bytes / hardware_disk_metrics_disk_space_used_bytes

Speicherplatz in Bytes (Typ: Gauge)

Expand

Label	Beschreibung
disk_name	Name des Block-Devices
node_type	Typ des Datenbankknotens

hardware_disk_metrics_read_count / hardware_disk_metrics_write_count

Verarbeitete I/O-Operationen (Typ: Counter)

Expand

Label	Beschreibung
disk_name	Name des Block-Devices
node_type	Typ des Datenbankknotens

IOPS berechnen: rate(hardware_disk_metrics_read_count[30s]) + rate(hardware_disk_metrics_write_count[30s])

hardware_disk_metrics_read_time_milliseconds / hardware_disk_metrics_write_time_milliseconds

Wartezeit für I/O-Anfragen in Millisekunden (Typ: Counter)

Expand

Label	Beschreibung
disk_name	Name des Block-Devices
node_type	Typ des Datenbankknotens

Latenz berechnen: rate(hardware_disk_metrics_read_time_milliseconds[5m]) / rate(hardware_disk_metrics_read_count[5m])

hardware_disk_metrics_weighted_time_io_milliseconds

Gewichtete Zeit für I/O-Vorgänge – gibt die Warteschlangentiefe der Festplatte an (Typ: Counter)

Expand

Label	Beschreibung
disk_name	Name des Block-Devices
node_type	Typ des Datenbankknotens

Hohe Werte deuten darauf hin, dass das Storage-System Schwierigkeiten hat, mit den I/O-Anforderungen Schritt zu halten.

Best Practices

Wir empfehlen dringend, die folgenden Metriken zu überwachen:

• Disk IOPS: Der Schwellenwert für Disk IOPS hängt von der aktuellen IOPS-Zuweisung ab, die für den Tier und die Speicherkapazität des Clusters bereitgestellt wurde. Er ist die Summe aus hardware_disk_metrics_read_count und hardware_disk_metrics_write_count. Überwachen Sie, ob die Disk IOPS die maximal bereitgestellten IOPS erreichen, und stellen Sie fest, ob der Cluster zukünftige Workloads bewältigen kann.
• Normalized System CPU iowait: Diese Metrik gibt den Prozentsatz der Zeit an, in der die CPU im Leerlauf ist und auf den Abschluss von I/O-Operationen (Input/Output) wartet, skaliert auf einen Bereich von 0–100 % durch Division durch die Anzahl der CPU-Kerne. Diese Metrik hilft dabei, potenzielle Festplattenengpässe zu identifizieren. Es ist möglich, dass das System basierend auf der verfügbaren Kapazität seine aggregierten Durchsatzlimits für die Festplatte erreicht. In diesem Szenario bemerken Sie möglicherweise, dass die IOPS nicht ihre volle Kapazität erreichen, während Sie gleichzeitig einen hohen Normalized System CPU iowait beobachten, was auf eine Erschöpfung der I/O-Ressourcen hindeutet.
• Disk Queue Depth: Die Metrik Disk Queue Depth stellt die Anzahl der ausstehenden I/O-Operationen in der Festplattenwarteschlange dar. Sie bietet Einblick in das Volumen der ausstehenden Lese- und Schreibvorgänge, die auf die Verarbeitung durch das zugrunde liegende Storage-System warten. Ein hoher Wert für die Disk Queue Depth kann darauf hindeuten, dass das Storage-System Schwierigkeiten hat, mit dem Workload Schritt zu halten, was potenziell zu Performance-Problemen führt. Es ist jedoch wichtig zu beachten, dass ein „hoher“ Wert von verschiedenen Faktoren abhängt, wie z. B. Ihrem spezifischen Workload, dem Hardware-Setup und den Performance-Erwartungen. Generell gilt: Wenn die Disk Queue Depth konsistent einen Wert beibehält, der das 2- bis 4-fache der Anzahl der CPU-Kerne auf Ihrem Server übersteigt, könnte dies auf ein zugrunde liegendes Problem hindeuten. Dies deutet auf einen Überschuss an ausstehenden I/O-Operationen hin, die das Storage-System möglicherweise nicht effizient verarbeiten kann.
• Disk-Latenz: Zusätzlich zur Überwachung der beiden zuvor genannten Metriken empfehlen wir, einen Alert für die Disk-Leselatenz auf der Datenpartition und die Disk-Schreiblatenz auf der Datenpartition zu erstellen, ähnlich dem Schwellenwert, den Sie für Ihre Ausführungszeit definiert haben, was von der Cluster-Konfiguration und Ihrem spezifischen Workload abhängt. Beachten Sie, dass sich die akzeptable Festplattenlatenz je nach Faktoren wie dem Workload Ihrer Anwendung, der Komplexität Ihrer Abfragen, den Lese- und Schreibmustern und den allgemeinen Performance-Erwartungen erheblich unterscheiden kann.

Ressourcen

Wir bieten ein Template der wichtigsten Metriken an. Sie können es herunterladen und in STACKIT Observability importieren: metric_exporter.json.