Viele Nutzer sind durch Herstellervorgaben, Verordnungen oder Arbeitsanweisungen dazu gezwungen, auf sämtlichen IT-Geräten Virenscanner zu betreiben. Diese Verallgemeinerung kann gerade dann, wenn es nicht um klassische Desktops oder Dateiserver geht, zu Problemen führen.

Nach landläufiger Auslegung des BSI Grundschutz ist dieser gewährleistet, wenn auf allen Systemen ein Virenscanner vorhanden ist und die Signaturen aktuell gehalten werden. Die Einhaltung der beiden Kriterien kann über ein klassisches Monitoring überwacht werden.

Probleme treten jedoch oft dann auf, wenn sogenannte On-Access-Scanner aktiv sind und in die Arbeit mit dem Dateisystem eingreifen. Die PostgreSQL^®-Entwickler raten sogar dringend von der Verwendung von Antivirensoftware ab!

Virenscanner

Was sind (On-Access-) Virenscanner und weshalb werden sie benötigt? Große Teile der verwendeten (Endanwender-) Software unterscheidet nicht klar zwischen Code und Daten. So enthält eine reine Textdatei ausschließlich Daten und keinen Programmcode, es besteht keine Notwendigkeit je einen Teil einer Textdatei als Code zu interpretieren und auszuführen. Leider wird diese Trennung nicht flächendeckend praktiziert. So können viele Dateien z.B. Office-Dokumente sowohl Daten als auch Code enthalten. Hierdurch ergibt sich ein Angriffsvektor. Angreifer können Code in Daten verstecken, der dann unbemerkt vom Nutzer ausgeführt wird.

Da das zugrundeliegende Problem aufwendig zu lösen und auch keine positive Tendenz ersichtlich ist, bieten Virenscanner in vielen Bereichen eine Linderung der Symptome. So ist es gängige Praxis und sinnvoll, eingehende Fremddaten und nicht vertrauenswürdige Nutzereingaben zu validieren und zu prüfen. Hierbei werden diese mit einer Blacklist von bekannten Angriffsmustern verglichen und im Falle einer Übereinstimmung entsprechend behandelt.

Auch wenn neue, maßgeschneiderte oder unbekannte Angriffe durch solche Systeme nicht erkannt werden können, kann die Kosten-Nutzen-Rechnung doch an einigen Stellen aufgehen.

Arbeiten mit dem Dateisystem

Möchte eine Anwendung (A) Daten lesen oder schreiben erfolgt die Interaktion mit dem Speichermedium (B) über Systemcalls. Die Anwendung übergibt die zu schreibenden Daten und erhält eine Bestätigung zurück, ob die Daten erfolgreich geschrieben wurden, bzw. im Fehlerfall einen entsprechenden Fehlercode.

Funktionsweise Echtzeitscanner

Ein Echtzeitscanner oder On-Access-Scanner greift nun in diesen Ablauf ein und setzt sich selbst als Man-in-the-Middle zwischen Applikation (A) und Hardware (B). Der Linux-Kernel bietet hierfür seit einiger Zeit die API fanotify. Verschiedene Hersteller verwenden aber oft eigene, nicht standardisierte Verfahren, um in den Datenstrom einzugreifen. Es gibt diverse mögliche Eingriffspunkte – z.B. die Applikationen selbst oder verwendete E/A-Bibliotheken. Auch Eingriffe in das Dateisystem werden verwendet.

Problem Performance

Durch den Eingriff in die E/A-Zugriffe werden diese deutlich aufwendiger! Je nach Eingriffspunkt und verwendeter Scanengine werden Speicherzugriffe um Größenordnungen langsamer. Auf Office-Desktopsystemen oder Applicationservern (stateless) sind auf Grund niedriger IO und weniger Writes oft keine starken Auswirkungen spürbar. Auf schreiblastigen Systemen können diese jedoch gravierend sein. Wenn viele kleine Bereiche beschreiben werden und es nicht nur auf den mittleren Datendurchsatz, sondern um das schnelle Abarbeiten einzelner Schreibvorgänge mit niedrigen Latenzen geht, ist mit großen Einbußen zu rechnen.

Durch ihre speziellen Nutzungsmuster und komplexe Dienstfunktionalität sind Datenbanksysteme besonders betroffen. Hinzu kommt noch, dass beim eigentlichen Scanvorgang auch CPU-Zeit benötigt wird. Je nach eingesetzter Antiviren-Lösung kann es auch hier zu Engpässen kommen.

Problem Datensicherheit

Wenn zum Abfangen der E/A-Anfragen nur die kerneleigenen APIs verwendet werden, erhöht sich bereits die theoretische Fehlerwahrscheinlichkeit, da mehr Code ausgeführt wird und die Vorgänge komplexer werden. In der Praxis verkompliziert sich hierdurch zwar Debugging und Fehlersuche, mit deutlichen Einbußen in der Datensicherheit ist jedoch nicht zu rechnen, korrekte API-Verwendung vorausgesetzt. fanotify ist jedoch derzeit in den verbreiteten Antivirenlösungen nicht der Standard.

Durch die eigene Implementierung von E/A-Hooks bietet sich eine ganze Menge Fehlerpotenzial. So konnten wir bei der Ursachenermittlung eines korrupten Datenbanksystems sehen, dass die Antivirenlösung E/A-Fehler von Hardware und Treibern teils nicht weitergeleitet hat.

Fehlerbeispiel:

1. Die Datenbank sendet eine Schreib-Anforderung an das Dateisystems (8k-Block schreiben, Herausschreiben auf Platte)
2. write() wird von der Antivirenlösung abgefangen
3. Der Virenscanner überprüft die Daten (kein Fund)
4. write() wird an das Dateisystem weitergegeben
5. Das Dateisystem übermittelt die Daten per Treiber an die Hardware
6. Es tritt ein Hardwareproblem auf! Daten können nicht geschrieben werden!
7. Der Treiber meldet dem Dateisystem den Fehler
8. Das Dateisystem meldet dem Virenscanner den Fehler
9. Der Virenscanner “verschluckt” den Fehler und meldet der Datenbank das erfolgreiche Schreiben
10. Die Datenbank meldet dem Client die erfolgreiche Durchführung einer Transaktion

So entstand eine schleichender Datenverlust, der erst entdeckt wurde als den Nutzern der angeschlossenen Systeme Fehler in den Bestandsdaten auffielen. Der Virenscanner hat hier durch sein nicht standardkonformes Verhalten eine der Kernfunktionalität des Datenbanksystems sabotiert.

PostgreSQL^®

PostgreSQL^® praktiziert eine strikte Trennung zwischen Daten und Code. Einträge in Tabellen, auch in Binärblöcken, können designbedingt nicht ausgeführt werden.

Aufgrund dieser strikten Trennung ist es für PostgreSQL^® selbst nicht notwendig, den eigenen Datenbestand auf Viren zu untersuchen. Für weniger gut differenzierende Anwendungssoftware kann es jedoch sinnvoll sein, Teilmengen zu überprüfen. Werden in der Datenbank beispielsweise Emails oder Dateien, die Code enthalten (z.B. Office-Dokumente), abgelegt, kann es durchaus Mehrwert bieten, diese Spalten auf bekannte Schadsoftware hin zu überprüfen.

In der Praxis wird hier jedoch fast immer ein generischer Echtzeitscanner verwendet, der nicht nur die erforderlichen Bereiche prüft, sondern On-Access-Methoden verwendet, und daher sämtliche im ersten Teil angesprochenen Probleme mit sich bringt.

Schadsoftware gefunden, was nun?

Erschwerend kommt hinzu, dass die Bearbeitung von Schadsoftware-Funden bei einer externen Software sehr schwer ist. Was soll z.B. im Falle eines gefundenen trojanischen Pferds passieren?

Automatischer Eingriff

Auf einem Desktop-System möchte man beispielsweise, dass die betroffene Datei in Quarantäne verschoben oder gelöscht wird. Mit dem Betrieb eines Datenbank-Servers ist solches Verhalten jedoch nicht vereinbar. Da es sich bei den Dateien um die physische Repräsentation der Datenbasis handelt, wird durch diesen Mechanismus Datenkorruption verursacht, die sich z.B. als stiller Datenverlust oder auch Verletzung von Konsistenzbedingungen wie das Nichterkennen von Duplikaten äußern kann.

Alarmierung

In der Praxis ist es daher meist sinnvoll, nur Alarmierungen zu erzeugen, die dann von einem Administrator bearbeitet werden. Doch was ist das geeignete Vorgehen, wenn der Virenscanner gestern Nacht eine Infektion der Datei “/var/lib/postgresql/11/main/base/13090/1255” gemeldet hat?

• Wo ist der infizierte Code in der Datenbank?
• Wo kam er her?
• Ist die Meldung überhaupt richtig? False-Positive?

Gibt es bereits zufriedenstellende Lösungen?

Der beschriebene Status-Quo erfüllt offensichtlich nicht alle Anforderungen. Gibt es für Datenbanken (PostgreSQL^®) eine bessere Lösung?

Derzeit bleibt die Überprüfung in der Anwendung oder Fremdsystemen die verbreitetste Methode. Verschiedene Hersteller bieten auch Netzwerk-Virenscanner an, die den Netzwerkverkehr überwachen und durchsuchen. Aber auch hier gibt es viele der bereits angesprochenen konzeptionellen Schwächen, z.B. wie ein Fund behandelt wird.

Lösungsversuch

Wünschenswert wäre es, die Überprüfung auf Schadcode und auch die Behandlung von Funden im Datenbanksystem selbst abzuwickeln. Optimalerweise per SQL-Schnittstelle, so dass Entwickler oder DBAs die Funktionalität in den normalen Anwendungsbetrieb integrieren können.

So könnte genau definiert werden, wann welche Eingabe zu überprüfen ist. Positiv-Funde können dann über die gemeinen SQL-Fehlercodes gemeldet werden, und würden nicht länger die Dienstfunktionalität gefährden. Man könnte sich beispielsweise eine Tabelle mit einer Text-Spalte vorstellen, in der Usereingaben gespeichert werden. Nun kann vor jedem INSERT oder UPDATE überprüft werden, ob bekannter Schadcode vorliegt und die Eintragung per CONSTRAINT verhindert werden.

Um die Machbarkeit einer solch integrierten Antivirenlösung aufzuzeigen, hat credativ die PostgreSQL^®-Erweiterung pg_snakeoil veröffentlicht. Diese macht die Funktionen von ClamAV in der SQL-Welt zugänglich, und erlaubt eine Schadcode-Prüfung bei voller ACID-Konformität. pg_snakeoil wurde unter der PostgreSQL^®-Lizenz veröffentlicht und kann in der aktuellen Version bei Github gefunden werden.

Unterstützung

Falls Sie Unterstützung bei PostgreSQL^®, Malware-Prävention, IT-Grundschutz oder anderer Aspekte der IT-Infrastruktur benötigen, steht Ihnen unser Open Source Support Center zur Verfügung – Falls gewünscht auch 24 Stunden am Tag, an 365 Tagen im Jahr.

Wir freuen uns über Ihre Kontaktaufnahme.

Dieser Artikel wurde ursprünglich von Alexander Sosna verfasst.

In der aktuellen Ausgabe beschäftigt sich das Linux Magazin in einem sehr interessanten Artikel mit einer Frage, die derzeit in vielen Unternehmen intensiv diskutiert wird:

Betreibt man seine Datenbank auf der eigenen Hardware, oder verlagert man sie in die Cloud?

Um die einzelnen Vor- und Nachteile zu untersuchen, wurden Datenbanklösungen diverser Cloud-Anbieter mit einer lokalen PostgreSQL^®-Installation verglichen. Für die Tests auf der lokalen Installation wurde auch die von credativ entwickelte PostgreSQL^® Appliance „Elephant Shed“ verwendet.

Den vollständigen Artikel inklusive Testergebnissen findet man in der neuesten Ausgabe des Linux Magazins (10/18). Optional kann der Artikel auf der Seite des Linux-Magazins auch online erworben werden.

Über PostgreSQL^®

PostgreSQL^® ist eines der führenden Open-Source-Datenbanksysteme, mit einer weltweiten Community bestehend aus Tausenden von Nutzern und Mitwirkenden. Das PostgreSQL^® Projekt baut auf über 25 Jahre Erfahrung auf, beginnend an der University of California, Berkeley, und ist bald schon in der Version 11 verfügbar.

Für PostgreSQL^® bietet credativ umfangreiche Services und einen tiefgehenden Entwicklersupport an. Von der Konzeption, zur Datenbankmigration, Optimierungen und Tunings, bis hin zur Hochverfügbarkeit: Der gesamte PostgreSQL^®-Datenbank-Lifecycle wird durch credativ abgedeckt.

Um eine komfortablere und flexiblere Administration zu ermöglichen, hat credativ die Elephant Shed PostgreSQL^® Appliance entwickelt.

Über Elephant Shed

Elephant Shed ist eine vollständig freie, leistungsfähige Open Source-Lösung, die eine enorme Erleichterung für den Betrieb von PostgreSQL^® im Unternehmenseinsatz bietet.

Elephant Shed baut auf bewährten Komponenten auf, die ausschließlich unter anerkannten Open Source Lizenzen veröffentlicht werden – und bietet somit den vollständigen Softwarestack für die Administration, das Monitoring, die Erstellung von Backups, und vielem mehr für PostgreSQL^®-Datenbanken.

Weitere Informationen über PostgreSQL^® und Elephant Shed erhalten Sie auf der jeweiligen Projektseite.

Dieser Artikel wurde ursprünglich von Philip Haas geschrieben.

Neben der DebConf18 in Taiwan hat die credativ in den letzten Monaten drei aufeinanderfolgende Konferenzen im asiatischen Raum besucht: den Open Source Summit Japan, die LC3 China und die PG Open China.

Open Source Summit Japan

Der Open Source Summit Japan wurde, wie im Jahr zuvor, im Ariake Conference Center auf Odaiba, in der Bucht von Tokio, abgehalten. Um die steigende Anzahl an Teilnehmern abzudecken, war die Veranstaltungsfläche um einige Räume erweitert worden und bot reichlich Platz für alle Besucher.

Neben einer Vielzahl von technischen Vorträgen die sich hauptsächlich um Containersoftware, Cloudinfrastruktur und Anwendungen im Automobilbereich drehten, gab es auch business- und strategieorientierte Talks. Jeder Besucher konnte so passende Themen für sich finden.

Besonders hervorzuheben sei der Vortrag “Is There an Open Source Business Model: YES or NO?” von Jeffrey Borek (IBM) und Stephen Walli (Microsoft). Hier konnten die Besucher mitdiskutieren und ihre Meinung einbringen, sodass die ohnehin provokante Streitfrage für viele Diskussionen innerhalb und außerhalb des Saales sorgte.

Weiterhin hervorzuheben sei der Vortrag unseres Geschäftsführers Dr. Michael Meskes, der mit seiner Frage “Is There a Future for Open Source” die Community mahnte, statt auf kommerzielle Open Source Lösungen, auf völlig offene Produkte zu setzen, die ohne Open Core und Vendor Lock-In auskommen.

Auch in diesem Jahr hat uns der Open Source Summit Japan sehr gut gefallen. Durch die sehr interessanten Vorträge sind wir wiederholt beeindruckt und überaus froh, dabei gewesen zu sein. Auch für das nächste Jahr gilt also die Prämisse: Wenn es die Chance gibt, werden wir da sein.

LC3 China

Die LC3 China (LinuxCon + ContainerCon + CloudOpen) wurde in Peking (Beijing) im China National Convention Center ausgerichtet. In direkter Umgebung des Olympic Green Olympia-Parks, welcher speziell für die Olympischen Spiele 2008 errichtet worden ist.

Der Großteil der Vorträge wurde auf Englisch gehalten, was eine sehr willkommene Geste war, die definitiv zu dem internationalen Charakter der Veranstaltung beitrug. Über die vier Konferenztage wurde eine große Anzahl an Vorträgen gehalten. Einen besonderen Charakter hatten die sogenannten “Office Hours” die einen eigenen Platz auf der Agenda erhielten. Hier konnten sich die Teilnehmer zusammen an einen Tisch setzen, Fragen stellen und Diskussionen führen.

Im Großen und Ganzen schien die LC3 eine Plattform für die größeren IT-Firmen Chinas zu sein, zeigte aber auch, dass Hackergruppen und Studentenzusammenschlüsse ihren eigenen Platz in der Community haben. Wir sind sehr froh mitwirken zu dürfen und sehen der nächsten Veranstaltung mit Freude entgegen.

PG Open China

Der wachsende Erfolg der freien Datenbanksoftware PostgreSQL^® und die gut besuchten PostgreSQL^®-Konferenzen, welche seit 2015 in China stattfinden, führten in diesem Jahr dazu, dass die erste PG Open China im Hotel Nikko New Century Beijing abgehalten wurde.

Das Ziel der PG Open China war es, einen Startpunkt für die chinesische PostgreSQL^® Community zu setzen und ihre Anbindung an die globale PostgreSQL^® Community zu verstärken. Zu diesem Zweck wurde ein internationales Kommitee gegründet, bestehend aus Bruce Momjian, Joshua D. Drake, Oleg Bartunov, Ray Feng und unserem Geschäftsführer Dr. Michael Meskes.

Nach der Vorstellung des Kommitees wurden die Veranstaltungsräume für Vorträge und Talks aus der chinesischen Community umfunktioniert. Joshua D. Drake und Oleg Bartunov hielten beide jeweils einen sehr interessanten Vortrag auf der PG Open China.

Die Besucherzahl der PG Open China war deutlich höher als ursprünglich angenommen, sodass sich jetzt schon das Wachstumspotential der chinesischen Community erahnen lässt. Vor allem durch den Anschluss an die internationale Community wird die Konferenz über die nächsten Jahre sicherlich deutlich wachsen. Mit hoher Wahrscheinlichkeit werden wir also auch nächstes Jahr wieder vor Ort vertreten sein. Wir sind sehr froh als einer der ersten bei der PG Open China dabei gewesen zu sein.

Die zweite Beta-Version von PostgreSQL^® 11, welche sich nun im Feature-Freeze befindet, ist kürzlich erschienen. Zeit also, einige Verbesserungen vorzustellen, die credativ zu dieser Version im Bereich Checksummen und Basebackups beigetragen hat.

Checksummen-Überprüfung während Basebackups

Checksummen für den Tabellen und Indexen zugeordneten Dateien können seit Version 9.3 beim Anlegen einer PostgreSQL^®-Instanz verwendet werden und warnen bei Bitfehlern in einzelnen Daten-Pages. Sie ermöglichen damit die frühzeitige Erkennung von Storage-Problemen. Allerdings wurden diese bisher nur im Rahmen von Abfragen geprüft, wenn auf den entsprechenden Datensatz zugegriffen wurde. Eine explizite Prüfung ist erst ab Version 11 mit dem neuen pg_verify_checksums Tool möglich, welches allerdings nur bei ausgeschalteter Instanz funktioniert.

Unsere Änderung erlaubt nun Checksummen beim Erstellen eines Basebackups zu überprüfen. Da bei einem Basebackup naturgemäß alle Datenblöcke gelesen werden müssen, ist dies eine gute Gelegenheit deren Konsistenz zu überprüfen. Checksummen-Fehler werden dabei als Warnungen und nicht als Fehler geloggt, damit nicht das gesamte Basebackup abgebrochen werden muss. Dem normalerweise für die Erstellung von Basebackups bzw. Standby Clones verwendeten Programm pg_basebackup wurde eine Option --no-verify-checksums hinzugefügt, die optional diese Überprüfung abschaltet.

Replikations-Slots bei Basebackups

Die zweite Änderung betrifft die Behandlung von Replikations-Slots von pg_basebackup bei der Erstellung von Standby-Servern. Diese erlauben es einem Primary, die für den im Slot spezifizierten Standby benötigten Transaktionslogs vorzuhalten, auch wenn dieser temporär nicht verfügbar ist. Zwar konnte man pg_basebackup einen Replikations-Slot nennen, welcher dann während des Basebackups verwendet wird, allerdings musste dieser bereits vorher manuell angelegt worden sein, da es ansonsten zu einer Fehlermeldung kommt. Unsere Änderung erlaubt nun mit der neuen Option -C bzw. --create-slot in einem Kommando einen Standby-Clone inklusive Verwendung von Replikations-Slots zu erstellen:

$ pg_basebackup -v -h primary.lan -D data --slot=standby1 --create-slot --write-recovery-conf
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1D000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created replication slot "standby1"
pg_basebackup: write-ahead log end point: 0/1D0000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
$ cat data2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=postgres passfile=''/var/lib/postgresql/.pgpass'' host=primary.lan
  port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'standby1'

Danach muss nur noch der Standby gestartet werden und repliziert nun automatisch.

Darüberhinaus wurden einige weitere kleine Verbesserungen an pg_basebackup bzw. dessen Tests von uns umgesetzt.

Paralleler Dump nach /dev/null

Einen Patch, der es nicht in das Release schaffte, wollen wir aber dennoch vorstellen: Paralleler pg_dump nach /dev/null im Directory-Format. Grund hierfür ist die gebräuchliche Verwendung von pg_dump für die Überprüfung von PostgreSQL^®-Instanzen auf Fehler, wobei als Zielort /dev/null verwendet wird, sodass kein zusätzlicher Speicherplatz benötigt wird. Das Problem hierbei ist, dass /dev/null nur im Custom-Format verwendet werden kann, welches aber keine Parallelität erlaubt. Das Directory-Format erlaubt zwar mehrere Prozesse gleichzeitig zu verwenden, allerdings nicht in Verbindung mit /dev/null; letzteres wird durch unseren vorgeschlagenen Patch ermöglicht.

Die Begründung für die Ablehnung war nicht technischer Natur, sondern das pg_dump kein Diagnose-Werkzeug ist und deswegen keine spezielle Unterstützung hierfür eingebaut werden sollte. Nichtsdestotrotz funktioniert der vorgeschlagene Patch und wird auch bei Kunden von uns eingesetzt. Versionen des Patches für PostgreSQL^® 9.3, 9.4, 9.5, 9.6 und 10 sind verfügbar.

Elephant Shed bündelt und integriert bewährte Komponenten, die für das Management eines PostgreSQL^®-Servers benötigt werden. Dabei werden erprobte Tools für alle relevanten Bereiche bereits vorinstalliert und vorkonfiguriert. Die Mehrzahl dieser Tools kann über eine komfortable Weboberfläche gesteuert werden. Selbst gestandene PostgreSQL^®-Administratoren werden kaum einen Bereich finden, der von Elephant Shed nicht abgedeckt wird.

Neu in Version 1.2 ist die Unterstützung von Ubuntu Bionic (18.04), neben der bisherigen Unterstützung für Debian Stretch (9). Beide Distributionen sind für die Architekturen amd64 (x86_64) und ppc64el (IBM POWER) verfügbar.

Nach Rückmeldungen durch Benutzer wurde für die Version 1.2 das Grafana-Dashboard überarbeitet. Verschiedene PostgreSQL^®-Cluster pro Maschine werden nun durch den Cluster-Namen wie „10/main“ unterschieden. Alle Metrikpanels benutzen nun korrekte Einheiten, d.h. die Achsen sind nun mit „Bytes pro Sekunde“ oder „Operationen pro Minute“ beschriftet. Grafana wurde auf Version 5 aktualisiert.

Die Prometheus-Timeseries-Datenbank wurde auf Version 2 aktualisiert, mit besserer Performance und kompakterer Datenhaltung. Leider ist das Speicherformat nicht kompatibel, alte Monitoring-Daten werden nicht erhalten.

Bug-Fixes und Verbesserungen:

• prometheus-sql-exporter: Die automatische Erkennung von PostgreSQL^®-Clustern und Datenbanken wurde neu geschrieben und ist nun stabiler
• Prometheus nutzt nun den Host- und Cluster-Namen in Timeseries-Labels
• prometheus-node-exporter wurde auf Version 0.15 aktualisiert
• pgBadger: Handhabung von log_line_prefix korrigiert

Die aktualisierten Pakete stehen über packages.credativ.com zum Download bereit. Wer Elephant Shed bereits installiert hat, kann die Updates wie gewohnt über apt einspielen.

Elephant Shed ist ein Open-Source-Projekt, entwickelt und gepflegt von credativ. Für Elephant Shed bietet die credativ einen umfassenden technischen Support mit garantierten Service Level Agreements, der optional auch an 365 Tagen im Jahr rund um die Uhr zur Verfügung steht.

Unsere PostgreSQL^®-Appliance Elephant Shed bringt fertig konfiguriertes Datenbank- und System-Monitoring mit. Wir setzen dabei auf Grafana und Prometheus. Hier stellen wir die Grundlagen vor, auf denen diese Monitoring-Architektur basiert.

Im Vordergrund steht hier Performance-Monitoring, d.h. die Sammlung quantitativer Metriken über die Zeit, z.B. den Verlauf der Zahl der Transaktionen pro Sekunde. Qualitative Metriken wie „ist die Festplatte vollgelaufen“ und Alerting können von Grafana und Prometheus ebenfalls erfasst werden, sollen hier aber nicht behandelt werden.

Prometheus-Exporter

Prometheus als Timeseries-Datenbank bildet die Zentrale des Monitorings. Metriken haben hier einen Namen und verschiedene Labels, z.B. sql_pg_stat_database mit Labels datname=“omdb“ und col=“xact_commit“.

Prometheus bezieht seine Daten von sogenannten Exportern, die periodisch (z.B. alle 30 s) abgefragt werden. Wohl in jeder Installation zu finden ist der Node-Exporter, der System-Daten wie Dateisystem-Füllstand, CPU-Auslastung und Speicherbelegung auswertet. Für die PostgreSQL^®-Überwachung setzen wir den SQL-Exporter in einer von uns gepatchten Version ein.

Im SQL-Exporter sind SQL-Abfragen konfiguriert, die in allen PostgreSQL^®-Clustern und -Datenbanken auf dem System ausgeführt werden. Dabei ist es üblich, immer absolute Werte abzufragen, z.B. Transaktionen seit Systemstart, und nicht schon vorzuverarbeiten. Ein Wert wie „Transaktionen pro Sekunde“ wird dann durch Prometheus aus den Rohdaten berechnet.

# SELECT datname, xact_commit, xact_rollback
  FROM pg_stat_database
  WHERE datname !~ 'template(0|1)'
  ORDER BY datname;
 
 datname  | xact_commit | xact_rollback
----------+-------------+---------------
 foo      |        8881 |             0
 omdb     |       29149 |         18926
 postgres |       43780 |          1754
(3 Zeilen)

Das Ergebnis stellt der Exporter dann per http auf localhost:9237 zur Verfügung:

sql_pg_stat_database{col="xact_commit", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 29149
sql_pg_stat_database{col="xact_rollback", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 18926

Prometheus-Abfrage

Im Webinterface von Prometheus können die gesammelten Daten dann abgefragt werden. Im einfachsten Fall besteht eine Prometheus-Query einfach aus dem Namen der Timeseries:

sql_pg_stat_database{col=~'xact_commit|xact_rollback',datname='omdb',host=':5432'}

Die Graphik zeigt die steigende Zahl von durchgeführten Transaktionen. Um nun auf die Rate der Transaktionen pro Sekunde zu kommen, benutzt man die Funktion rate(), wobei über ein angegebenes Intervall gemittelt wird, hier 1 Minute:

rate(sql_pg_stat_database{col=~'xact_commit|xact_rollback',datname='omdb',host=':5432'}[1m])

Grafana

Grafana dient nun dazu, die von Prometheus gesammelten Daten hübsch formatiert in Dashboards anzuzeigen. Für jedes „Panel“ im Dashboard werden Prometheus-Queries hinterlegt und Achsenbeschriftungen und andere Grapheigenschaften konfiguriert. Dabei passiert das Rendering der Daten vollständig im Browser, Grafana stellt lediglich Umgebung zur Verfügung, der Browser bezieht dann die Timeseries-Werte direkt als JSON von Prometheus.

Elephant Shed

Das von uns für Elephant Shed entwickelte PostgreSQL^®-Dashboard kann natürlich auch für andere Setups genutzt werden. Alle benötigten Dateien finden sich im Git-Repository.

In diesem Jahr ist es endlich wieder soweit – Die PGConf.DE öffnet am 13. April 2018 ihre Pforten!

Mit ca. 200 Besuchern ist die PGConf.DE die deutschlandweit größte PostgreSQL^® Veranstaltung, und findet in diesem Jahr in Berlin statt. Zuletzt wurde die PGConf.DE 2015 in Hamburg ausgetragen.

credativ ist natürlich wieder mit dabei – in diesem Jahr als Platin-Sponsor. Insgesamt halten unsere Kollegen drei Vorträge:

• PostgreSQL^®-Monitoring mit Grafana und Prometheus – von Christoph Berg
  • „PostgreSQL^® liefert eine Vielzahl von Performance-Metriken. In diesem Vortrag zeigen wir, wie man diese Daten von PostgreSQL^®-Clustern mit Prometheus-Exportern abruft und als Graphen in Grafana darstellt. Die Präsentation erläutert die Monitoring-Grundlagen, und in einer Live-Demo werden neue Graphen in das Grafana-Dashboard eingefügt.“
• PostgreSQL^® und alles was dazugehört – Elephant Shed – von Adrian Vondendriesch und Alexander Sosna
  • „PostgreSQL^® ist für viele Nutzer heute ein zentrales Element ihrer IT-Infrastruktur, oder auf dem Weg dahin. Für einen reibungslosen Betrieb wird jedoch eine entsprechende leistungsfähige Umgebung benötigt. Im Vortrag wird eine Stand-Alone-Datenbankserver-Umgebung vorgestellt, die für Entwicklung und Produktion verwendet werden kann und sowohl PostgreSQL^®-Neueinsteigern, -Umsteigern, als auch Veteranen das Leben möglichst einfach macht.“
    Elephant Shed ist eine von credativ entwickelte, leistungsfähige PostgreSQL^® Appliance, die vollständig als freie Open Source-Lösung zum Download zur Verfügung steht.
• Hat Open Source eine Zukunft? – von Dr. Michael Meskes

Das vollständige Vortragsprogramm kann auf der Veranstaltungswebsite eingesehen werden.

Wir freuen uns auf Euren Besuch an unserem Stand und in den Vorträgen! Wenn Ihr noch nicht registriert seid, müsst Ihr schnell sein – Laut Veranstalter werden die Tickets bereits knapp.

Weitere Informationen erhaltet Ihr auf der Veranstaltungswebsite PGConf.DE

Neben den Vortragenden beschäftigt die credativ viele Mitglieder der PostgreSQL^®-Community. Einige Mitarbeiter waren schon vor Firmengründung an dem Projekt beteiligt und leisten auch heute noch einen wichtigen Beitrag für die Software. Auch daraus entstand für die credativ eine enge und langjährige Verbundenheit mit dem PostgreSQL^®-Projekt und der Community.

Dieser Artikel wurde ursprünglich von Philip Haas geschrieben.

Elephant Shed ist nun auch als Vagrant-Box verfügbar. Damit kann die PostgreSQL^® Appliance sehr einfach getestet und erprobt werden.

Vagrant ist ein Open-Source-Tool zum Erstellen von portablen virtuellen Software-Umgebungen. Skript-gesteuert können damit leicht virtuelle Maschinen erzeugt werden, in denen eine Softwarekomponente zum Testen installiert ist. Vagrant selbst ist dabei nur der Manager, für die eigentliche Virtualisierung können verschiedenste Backends wie Virtualbox oder Cloud-Provider eingesetzt werden.

Für die Entwicklung von Elephant Shed haben wir von Anfang an auf Vagrant gesetzt. Diese „Box“ ist nun auch in der Vagrant Cloud erhältlich.

Zur Benutzung dieser Box müssen Vagrant und VirtualBox installiert sein. Das Host-Betriebssystem ist dabei unerheblich (Linux/MacOS/Windows), in der Box läuft Debian Stretch. Die Box wird dann von Vagrant automatisch heruntergeladen:

vagrant init credativ/elephant-shed
vagrant up

Dies erstellt eine virtuelle Maschine, in der Elephant Shed in VirtualBox auf Ihren Computer läuft.

• Default-User: admin
• Default-Passwort: admin
• Das Webinterface hört auf Port 4433: https://localhost:4433
• PostgreSQL^® hört auf Port 55432: psql -h localhost -p 55432 -U admin

Wir freuen uns über Feedback!

Weitere Informationen finden Sie auf unserer Elephant Shed-Projektseite, sowie auf Github.

Unsere PostgreSQL^®-Appliance Elephant Shed ist nun in Version 1.1 verfügbar. Die aktualisierten Pakete für Debian Stretch sind auf packages.credativ.com verfügbar.

Die Änderungen sind im Wesentlichen Anpassungen und Bugfixes im Monitoring-Dashboard von Grafana. So zeigt z.B. der Check „Next Freeze“ eine Warnung (Orange) erst, wenn ein anstehender Freeze 10% überfällig, bzw noch nicht abgeschlossen ist. Der Graph „Dead Tuples“ zeigt nun die korrekten Werte an. An dieser Stelle noch einmal vielen Dank für die Nutzer-Hinweise!

Die Dokumentation wurde auf Sphinx umgestellt, da sie mittlerweile die Größe einer README-Datei überschritten hatte. Sie wird mit den Paketen ausgeliefert und ist über das Webinterface verfügbar. Auch online ist immer die aktuelle Version hinterlegt: elephant-shed.io/doc

Elephant Shed

Elephant Shed ist eine leistungsfähige PostgreSQL^® Appliance, die vollständig als freie Open Source-Lösung zum Download zur Verfügung steht. Die Appliance bietet eine enorme Erleichterung für den Betrieb von PostgreSQL^® im Unternehmenseinsatz. Elephant Shed baut auf bewährten Komponenten auf, die ausschließlich unter anerkannten Open Source Lizenzen veröffentlicht werden. Diese Tools sind eine wirkungsvolle Unterstützung für das Management eines PostgreSQL^® Servers. Alle verwendeten Komponenten sind vorinstalliert und in die integrale Automatisierung eingebunden. Die langfristige Pflege der Appliance wird durch die PostgreSQL^®-Experten der credativ übernommen.

Elephant Shed steht auch als vorinstallierte Hardware-Appliance zur Verfügung, die von unserem Partner, der Thomas-Krenn.AG, angeboten wird. Für Elephant Shed bietet die credativ einen umfassenden technischen Support mit garantierten Service-Level-Agreements, der optional auch an 365 Tagen im Jahr rund um die Uhr zur Verfügung steht. Eine Unterstützung bei der Installation und Integration, sowie eine Einführung in Elephant Shed ist selbstverständlich auch Bestandteil der Services von credativ. Für Fragen zu Elephant Shed und unseren Service- und Supportleistungen stehen wir Ihnen gern zur Verfügung.

Weitere Informationen finden Sie auf unserer Elephant Shed-Projektseite, sowie auf Github.

Dieser Artikel wurde ursprünglich von Philip Haas geschrieben.

Das Herzstück unserer PostgreSQL^®-Appliance „Elephant Shed“ ist das Datenbank-Administrationstool pgAdmin 4. Für die Appliance stand das Tool bisher in der Version 1.5 zur Verfügung.

Seit dem 25. Januar ist pgAdmin 4 in der neuen Version 2.1 auch im Repository apt.postgresql.org enthalten. credativ hat hierfür die bislang noch nicht in Debian enthaltenen Python-Pakete erstellt und nach Debian und apt.postgresql.org hochgeladen. pgAdmin 4 ist auf apt.postgresql.org für Debian stretch und jessie, sowie die Entwicklungszweige buster und sid verfügbar. Bei Ubuntu werden die LTS-Releases xenial und bionic (letzteres wird im kommenden April released) unterstützt. Selbstverständlich ist die neue Version auch mit dem Elephant Shed kompatibel.

In Debian selbst ist pgAdmin 4 leider noch nicht enthalten. Die benutzten JavaScript-Bibliotheken sind zwar alle Open Source, aber etliche Komponenten sind noch nicht als eigenständiges Debian-Paket vorhanden, was Voraussetzung für einen Upload ist. credativ ist hier weiter am Ball, um die aktuelle Version auch in Debian einzubringen.