Dies ist die mehrseitige Druckansicht dieses Abschnitts. .
Metriken
etcd verwendet Prometheus zur Bereitstellung von Metriken. Sie lassen sich für Echtzeitüberwachung und Fehlersuche nutzen. etcd speichert seine Metriken nicht dauerhaft; beim Neustart eines Mitglieds werden sie zurückgesetzt.
Die verfügbaren Metriken lassen sich am einfachsten mit cURL am Metrikendpunkt /metrics abrufen. Das Format wird in der Prometheus-Dokumentation
beschrieben.
Mit der Prometheus-Einstiegsanleitung lässt sich ein Prometheus-Server zum Sammeln von etcd-Metriken starten.
Die Benennung der Metriken folgt den empfohlenen bewährten Verfahren von Prometheus
. Ein Metrikname enthält etcd oder etcd_debugging als Namensraumpräfix sowie ein Präfix für das Subsystem (zum Beispiel wal und etcdserver).
Metriken im Namensraum etcd
Metriken mit dem Präfix etcd dienen der Überwachung und Alarmierung. Sie sind stabile Metriken auf hoher Abstraktionsebene. Änderungen an diesen Metriken werden in den Versionshinweisen aufgeführt.
Metriken zu etcd2 sind im v2-Metrikleitfaden dokumentiert.
Server
Diese Metriken beschreiben den Zustand des etcd-Servers. Um Ausfälle oder Probleme für die Fehlersuche zu erkennen, sollten die Servermetriken jedes etcd-Clusters im Produktivbetrieb genau überwacht werden.
Alle diese Metriken haben das Präfix etcd_server_
| Name | Beschreibung | Typ |
|---|---|---|
| has_leader | Ob ein Leader vorhanden ist. 1 bedeutet vorhanden, 0 bedeutet nicht vorhanden. | Gauge |
| leader_changes_seen_total | Anzahl der beobachteten Leader-Wechsel. | Counter |
| proposals_committed_total | Gesamtzahl der festgeschriebenen Konsensvorschläge. | Gauge |
| proposals_applied_total | Gesamtzahl der angewendeten Konsensvorschläge. | Gauge |
| proposals_pending | Aktuelle Anzahl der ausstehenden Vorschläge. | Gauge |
| proposals_failed_total | Gesamtzahl der beobachteten fehlgeschlagenen Vorschläge. | Counter |
has_leader zeigt an, ob das Mitglied einen Leader hat. Ohne Leader ist ein Mitglied vollständig nicht verfügbar. Hat kein Mitglied im Cluster einen Leader, ist der gesamte Cluster vollständig nicht verfügbar.
leader_changes_seen_total zählt die Leader-Wechsel, die das Mitglied seit seinem Start beobachtet hat. Häufige Leader-Wechsel beeinträchtigen die Leistung von etcd erheblich. Sie weisen auch auf einen instabilen Leader hin, möglicherweise aufgrund von Netzwerkverbindungsproblemen oder übermäßiger Last auf dem etcd-Cluster.
proposals_committed_total erfasst die Gesamtzahl der festgeschriebenen Konsensvorschläge. In einem funktionsfähigen Cluster sollte dieser Gauge-Wert mit der Zeit steigen. Mehrere funktionsfähige Mitglieder eines etcd-Clusters können zum selben Zeitpunkt unterschiedliche Gesamtzahlen festgeschriebener Vorschläge haben. Mögliche Gründe dafür sind das Nachholen von Daten von Peers nach dem Start, ein Rückstand gegenüber dem Leader oder die Rolle als Leader, der deshalb die meisten Commits hat. Wichtig ist, diese Metrik über alle Clustermitglieder hinweg zu beobachten: Ein dauerhaft großer Rückstand eines einzelnen Mitglieds gegenüber seinem Leader deutet darauf hin, dass das Mitglied langsam oder nicht funktionsfähig ist.
proposals_applied_total erfasst die Gesamtzahl der angewendeten Konsensvorschläge. Der etcd-Server wendet jeden festgeschriebenen Vorschlag asynchron an. Der Unterschied zwischen proposals_committed_total und proposals_applied_total sollte normalerweise gering sein (selbst unter hoher Last innerhalb weniger Tausend). Steigt die Differenz weiter an, weist dies auf eine Überlastung des etcd-Servers hin. Das kann bei aufwendigen Abfragen geschehen, etwa umfangreichen Bereichsabfragen oder großen txn-Operationen.
proposals_pending zeigt an, wie viele Vorschläge zum Festschreiben anstehen. Eine steigende Zahl ausstehender Vorschläge deutet auf hohe Clientlast hin oder darauf, dass das Mitglied Vorschläge nicht festschreiben kann.
proposals_failed_total hängt normalerweise mit zwei Problemen zusammen: vorübergehenden Fehlern während einer Leader-Wahl oder längeren Ausfällen durch den Verlust des Quorums im Cluster.
Datenträger
Diese Metriken beschreiben den Zustand der Datenträgeroperationen.
Alle diese Metriken haben das Präfix etcd_disk_.
| Name | Beschreibung | Typ |
|---|---|---|
| wal_fsync_duration_seconds | Latenzverteilungen der von wal aufgerufenen fsync-Operationen | Histogram |
| backend_commit_duration_seconds | Latenzverteilungen der vom Backend aufgerufenen commit-Operationen. | Histogram |
wal_fsync wird aufgerufen, wenn etcd seine Protokolleinträge auf dem Datenträger dauerhaft speichert, bevor es sie anwendet.
backend_commit wird aufgerufen, wenn etcd einen inkrementellen Snapshot seiner neuesten Änderungen auf dem Datenträger festschreibt.
Hohe Latenzen bei Datenträgeroperationen (wal_fsync_duration_seconds oder backend_commit_duration_seconds) weisen häufig auf Datenträgerprobleme hin. Sie können hohe Anfragelatenzen verursachen oder den Cluster instabil machen.
Netzwerk
Diese Metriken beschreiben den Zustand des Netzwerks.
Alle diese Metriken haben das Präfix etcd_network_
| Name | Beschreibung | Typ |
|---|---|---|
| peer_sent_bytes_total | Gesamtzahl der an den Peer mit der ID To gesendeten Bytes. |
Counter(To) |
| peer_received_bytes_total | Gesamtzahl der vom Peer mit der ID From empfangenen Bytes. |
Counter(From) |
| peer_sent_failures_total | Gesamtzahl der Sendefehler zum Peer mit der ID To. |
Counter(To) |
| peer_received_failures_total | Gesamtzahl der Empfangsfehler vom Peer mit der ID From. |
Counter(From) |
| peer_round_trip_time_seconds | Histogramm der Umlaufzeiten zwischen Peers. | Histogram(To) |
| client_grpc_sent_bytes_total | Gesamtzahl der an gRPC-Clients gesendeten Bytes. | Counter |
| client_grpc_received_bytes_total | Gesamtzahl der von gRPC-Clients empfangenen Bytes. | Counter |
peer_sent_bytes_total zählt die Gesamtzahl der an einen bestimmten Peer gesendeten Bytes. Normalerweise sendet das Leader-Mitglied mehr Daten als andere Mitglieder, da es die replizierten Daten überträgt.
peer_received_bytes_total zählt die Gesamtzahl der von einem bestimmten Peer empfangenen Bytes. Normalerweise empfangen Follower-Mitglieder nur Daten vom Leader-Mitglied.
gRPC-Anfragen
Diese Metriken werden über go-grpc-prometheus bereitgestellt.
Metriken im Namensraum etcd_debugging
Die Metriken mit dem Präfix etcd_debugging dienen der Fehlersuche. Sie hängen stark von der Implementierung ab und ändern sich häufig. In neuen etcd-Versionen können sie ohne Vorwarnung geändert oder entfernt werden. Einige dieser Metriken können zum Präfix etcd wechseln, sobald sie stabiler sind.
Snapshot
| Name | Beschreibung | Typ |
|---|---|---|
| snapshot_save_total_duration_seconds | Verteilungen der Gesamtlatenz der von snapshot aufgerufenen save-Operationen | Histogram |
Eine ungewöhnlich lange Snapshot-Dauer (snapshot_save_total_duration_seconds) weist auf Datenträgerprobleme hin und kann den Cluster instabil machen.
Von Prometheus bereitgestellte Metriken
Die Prometheus-Clientbibliothek stellt zahlreiche Metriken in den Namensräumen go und process bereit. Einige sind besonders interessant.
| Name | Beschreibung | Typ |
|---|---|---|
| process_open_fds | Anzahl offener Dateideskriptoren. | Gauge |
| process_max_fds | Maximale Anzahl offener Dateideskriptoren. | Gauge |
Prozessmetriken wie process_open_fds und process_max_fds werden derzeit auf Darwin-Systemen (macOS) nicht unterstützt.
Eine hohe Nutzung von Dateideskriptoren (process_open_fds), also nahe am Limit des Prozesses (process_max_fds), weist auf eine mögliche Erschöpfung der Dateideskriptoren hin. Sind keine Dateideskriptoren mehr verfügbar, kann etcd mit einer Panic abbrechen, weil es keine neuen WAL-Dateien erstellen kann.