Lassen Sie mich ein Thema erörtern, das nicht von Natur aus PostgreSQL-spezifisch ist, dem ich aber regelmäßig begegne, wenn ich Probleme auf Kundensystemen untersuche, die „Unterstützbarkeit“ dieser Systeme bewerte usw. Es ist die Wichtigkeit, eine Überwachungslösung für Systemmetriken zu haben und sie vernünftig zu konfigurieren , und warum sar ist immer noch mit Abstand mein Lieblingstool (zumindest unter Linux).
Über die Bedeutung der Überwachung
Erstens ist die Überwachung grundlegender Systemmetriken (CPU, E/A, Speicher) äußerst wichtig. Es ist ein bisschen seltsam, dies in Diskussionen mit anderen Ingenieuren ansprechen zu müssen, aber ich würde sagen, dass 1 von 10 Ingenieuren denkt, dass sie nicht wirklich überwacht werden müssen. Die Argumentation geht normalerweise in diese Richtung:
Es ist wahr, dass die Überwachung Overhead hinzufügt, daran besteht kein Zweifel. Aber es ist wahrscheinlich vernachlässigbar im Vergleich zu dem, was die Anwendung tut. Eigentlich sar fügt nicht wirklich zusätzliche Instrumente hinzu, sondern liest lediglich Zähler aus dem Nernel, berechnet Deltas und schreibt diese auf die Festplatte. Es kann etwas Speicherplatz und I/O benötigen (abhängig von der Anzahl der CPUs und Festplatten), aber das war es auch schon.
Beispielsweise erzeugt das Sammeln von Statistiken pro Sekunde auf einem Computer mit 32 Kernen und mehreren Festplatten ~ 5 GB Rohdaten pro Tag, aber es lässt sich extrem gut komprimieren, oft auf ~ 5-10 %). Und es ist in top kaum sichtbar . Die Auflösung pro Sekunde ist etwas extrem, und die Verwendung von 5 oder 10 Sekunden wird den Overhead weiter reduzieren.
Also nein, es stellt sich heraus, dass der Overhead tatsächlich kein triftiger Grund ist, die Überwachung nicht zu aktivieren.
Kosten vs. Nutzen
Noch wichtiger ist jedoch:„Wie viel Overhead eliminiere ich, wenn ich die Überwachung nicht aktiviere?“ ist die falsche Frage. Stattdessen sollten Sie fragen:„Welchen Nutzen habe ich aus der Überwachung? Überwiegen die Vorteile die Kosten?“
Wir wissen bereits, dass die Kosten (Overhead) ziemlich gering oder völlig vernachlässigbar sind. Was sind die Vorteile? Meiner Erfahrung nach ist es von unschätzbarem Wert, Überwachungsdaten zu haben.
Erstens ermöglicht es Ihnen, Probleme zu untersuchen – das Betrachten einer Reihe von Diagrammen und das Suchen nach plötzlichen Änderungen ist überraschend effektiv und führt Sie oft direkt zum richtigen Problem. Ebenso ist der Vergleich der aktuellen Daten (erfasst während des Problems) mit einer Basislinie (erfasst, wenn alles in Ordnung ist) sehr nützlich und unmöglich, wenn Sie die Überwachung nur aktivieren, wenn etwas kaputt geht.
Zweitens ermöglicht es Ihnen, Trends zu bewerten und potenzielle Probleme zu identifizieren, bevor sie Sie tatsächlich treffen. Wie viel CPU verwenden Sie? Wächst die CPU-Auslastung mit der Zeit? Gibt es einige verdächtige Muster bei der Speichernutzung? Sie können diese Fragen nur beantworten, wenn Sie die Überwachung eingerichtet haben.
Warum sar ist mein Lieblingstool
Nehmen wir an, ich habe Sie davon überzeugt, dass Überwachung wichtig ist und Sie es auf jeden Fall tun sollten. Aber warum ist sar unser Lieblingstool, wenn es verschiedene ausgefallene Alternativen gibt, sowohl On-Premise als auch Cloud-basiert?
- Es ist in allen Distributionen enthalten und lässt sich einfach installieren/einrichten. Dies macht es ziemlich einfach, Leute davon zu überzeugen, es zu aktivieren.
- Es ist direkt auf der Maschine. Wenn Sie sich also per SSH mit der Maschine verbinden, können Sie auch die Überwachungsdaten abrufen.
- Es verwendet eine einfache Textausgabe. Triviale Verarbeitung der Daten – Importieren Sie sie in eine Datenbank, analysieren Sie sie, hängen Sie sie an ein Support-Ticket an. Das ist ziemlich schwierig mit anderen Tools, die es Ihnen im Allgemeinen nicht erlauben, die Daten einfach zu exportieren, nur Diagramme anzuzeigen und/oder die Analysemöglichkeiten, die Sie durchführen können, erheblich einzuschränken usw.
Ich gebe zu, dass einiges davon auf die Tatsache zurückzuführen ist, dass ich für ein Unternehmen arbeite, das PostgreSQL-Dienste für andere Unternehmen anbietet (sei es 24×7-Support oder Remote-DBA). Daher haben wir normalerweise nur einen sehr begrenzten Zugriff auf Kundensysteme (meistens nur Datenbankserver). und nicht mehr).Das bedeutet, dass es äußerst bequem ist, alle wichtigen Daten auf dem Datenbankserver selbst zu haben, auf den über einfaches SSH zugegriffen werden kann, und eliminiert unnötige Roundtrips, nur um ein anderes Datenelement von einem anderen System anzufordern.Das spart sowohl Zeit als auch Verstand auf beiden Seiten.
Wenn Sie viele Systeme verwalten müssen, bevorzugen Sie wahrscheinlich eine Überwachungslösung, die Daten von vielen Maschinen an einem einzigen Ort sammelt. Aber für mich, sar immer noch gewinnt.
Also, wie konfiguriere ich es?
Ich erwähnte die Installation und Aktivierung von sar (oder besser gesagt sysstat , das ist das Paket, das sar enthält ) ist ganz einfach. Leider ist die Standardkonfiguration etwas schlecht. Nach der Installation von sysstat , finden Sie so etwas in /etc/cron.d/sysstat (oder wo auch immer Ihre Distribution cron speichert Konfiguration):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Dies sagt effektiv den sa1 Der Befehl wird alle 10 Minuten ausgeführt und erfasst eine einzelne Probe über 1 Sekunde. Hier gibt es zwei Probleme. Erstens sind 10 Minuten eine ziemlich niedrige Auflösung. Zweitens deckt das Sample nur 1 Sekunde von 600 ab, sodass die restlichen 9:59 nicht wirklich darin enthalten sind. Dies ist für langfristige Trendanalysen in Ordnung, bei denen eine Zufallsstichprobe mit niedriger Auflösung ausreicht. Für andere Zwecke müssen Sie stattdessen wahrscheinlich so etwas tun:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Das sammelt eine Probe pro Minute, und jede Probe deckt eine Minute ab. Das -S XALL bedeutet, dass alle Statistiken gesammelt werden sollten, einschließlich Interrupts, einzelne Blockgeräte und Partitionen usw. Siehe man sadc für weitere Details.
Zusammenfassung
Also, um diesen Beitrag in ein paar einfachen Punkten zusammenzufassen:
- Sie sollten eine Überwachung haben, auch wenn Sie denken, dass Sie sie nicht brauchen. Sobald Probleme auftreten, ist es zu spät.
- Die Kosten für die Überwachung sind wahrscheinlich vernachlässigbar, aber sicherlich viel geringer als die Vorteile der Überwachungsdaten.
sarist bequem und sehr effizient. Vielleicht verwenden Sie in Zukunft etwas anderes, aber es ist ein guter erster Schritt.- Die Standardkonfiguration ist nicht besonders gut (niedrige Auflösung, 1-Sekunden-Samples). Erwägen Sie, die Auflösung zu erhöhen.
Eine Sache, die ich nicht erwähnt habe, ist sar befasst sich nur mit Systemmetriken – CPU, Festplatten, Speicher, Prozesse, nicht mit PostgreSQL-Statistiken. Natürlich sollten Sie auch diesen Teil des Stapels überwachen.
