Workshop: Open Source-Tipp

Im Cockpit

Performance-Tuning und Monitoring sind zwei Themen, die eng miteinander verzahnt sind. Auf dem Markt tummeln sich eine Vielzahl unterschiedlichster Tools für diesen Zweck. In der letzten Zeit rückt das Framework "Performance Co-Pilot" immer mehr in den Vordergrund.
In der April-Ausgabe hat sich IT-Administrator die Netzwerksicherheit zum Schwerpunkt gesetzt. Wir zeigen, wie Sie mit Honeypots auf Hacker-Jagd im Netzwerk ... (mehr)

Performance-Tuning galt lange Zeit als die schwarze Magie der System-Administration. Wer wusste, an welchen Enden und Ecken die passenden Metriken zu finden waren, konnte diese über einen gewissen Zeitraum überwachen und bei Bedarf anpassen. Sehr gute Kentnisse der eigenen Systemlandschaft waren hierfür unabdingbar. Sollten die eingesammelten Informationen dann auch noch grafisch aufbereitet werden, musste man sich zusätzlich auch mit Tools wie sed und awk zum Filtern und gnuplot zum Visualisieren der Daten auseinandersetzen. Diese Tools sollten zwar sowieso von jedem versierten Systemverantwortlichen beherrscht werden, jedoch kostet deren Einsatz meistens eine gewisse Zeit und diese ist heutzutage ja bekanntermaßen immer und überall knapp bemessen.

Zum Glück gibt es mittlerweile eine Vielzahl moderner und leicht zu bedienender Tools, die den Admistratoren das Leben erleichtern. Die meisten umfassen ein Webfrontend, das die eingesammelten Daten grafisch aufbereitet. Solche Lösungen schießen aber in vielen Fällen über das Ziel hinaus, wenn es lediglich darum geht, über einen gewissen Zeitraum bestimmte Performance-Metriken von einer Handvoll Hosts einzusammeln. Für diesen Zweck existieren Tools wie beispielsweise der System Activity Reporter, besser bekannt unter dem Namen sar [1]. Er sammelt in regelmäßigen Abständen eine Vielzahl von Informationen über das lokale System ein und speichert diese in einer binären Archiv-Datei ab. Über die Client-Anwendung sar lassen sich die gespeicherten Informationen auch wieder abrufen.

Leider ist das Format der Archiv-Datei nicht zwischen allen Versionen von sar identisch, sodass es schon mal Probleme bereiten kann, die Daten eines anderen Hosts auf dem eigenen System auszuwerten. Eine leistungsfähige Alternative zu Sar ist der Performance Co-Pilot.

Entwickelt von SGI

Das Framework Performance Co-Pilot (PCP) existiert schon recht lange. Entwickelt wurde es Anfang der 90er Jahre von SGI und war lange Zeit lediglich unter einer proprietären Lizenz erhältlich. Erst ab Anfang 2000 wurden die einzelnen Software-Komponenten unter die GNU-LGPL-Lizenz gestellt, was letztendlich zu einer weiteren Verbreitung des Tools führte. In den letzten Jahren hat sich sogar eine sehr aktive Community um das Framework versammelt und es sind eine Vielzahl von neuen Funktionen hinzugekommen. Mittlerweile hat PCP auch den Sprung in die Enterprise-Editionen von Red Hat und SuSE geschafft und ist ebenfalls in vielen anderen Linux-Distributionen enthalten. Darüber hinaus unterstützt das Framework natürlich andere Unix-Varianten und es existieren auch Versionen für OS X und Windows.

PCP besteht aus mehreren Komponenten: Jedes System, das Performance-Daten zur Verfügung stellt, muss über eine aktive Instanz des Performance Metrics Collector Daemon (PMCD) verfügen. Er ist dafür verantwortlich, Metriken einzusammeln und sie den anfragenden Clients zur Verfügung zu stellen. Bei den Clients kann es sich um ganz unterschiedliche Tools handeln. Hierzu zählen beispielsweise Anwendungen, die Benutzer interaktiv aufrufen, um sich ein Bild vom aktuellen Zustand eines Systems zu machen, oder aber auch Tools, die die gewonnenen Daten speichern und diese somit für spätere Abfragen archivieren.

Die Daten selbst werden über sogenannte Performance Metrics Domain Agents (PMDAs) zur Verfügung gestellt. Hierbei handelt es sich um spezielle Agenten, die für Subsysteme oder Applikationen eines Systems verantwortlich sind und von ihnen Performance-Daten einsammeln. So existieren beispielsweise PMDAs für den Linux-Kernel oder für Applikationen wie Postfix und Apache. Insgesamt stehen mittlerweile weit über 1.000 PMDAs zur Verfügung. Einige wenige hiervon sind serienmäßig eingeschaltet und liefern Daten an den PMCD, andere lassen sich bei Bedarf aktivieren. Auch das Entwickeln eigener PMDAs gelingt mit wenigen Zeilen Code. APIs existieren beispielsweise für Python, Perl und natürlich C.

Bild 1: Mit pmchart können Sie sehr leicht Grafiken auf Basis der Performance-Daten erzeugen.

PCP installieren und starten

Nachdem Sie PCP auf einem aktuellen Linux-System (wir verwenden in den Beispielen Fedora 20) aus dessen Software-Repository installiert haben, aktivieren Sie das Framework über die folgenden Befehle:

systemctl enable pmcd.service
systemctl start pmcd.service

Um die eingesammelten Daten dauerhaft zu archivieren, muss zusätzlich auch der Performance Metric Logger laufen:

systemctl enable pmlogger.service
systemctl start pmlogger.service

Der PMCD öffnet beim Starten den TCP-Port 44321. Sie sind gut beraten, den Zugriff auf diesen Port einzuschränken, damit nicht die ganze Welt Zugriff auf Ihre Daten erhält. Über die Datei »/etc/pcp/pmcd/pmcd.conf« definieren Sie, wer mit dem Daemon in welcher Form agieren darf.

Laufen die beiden Services »pmcd« und »pmlogger« , zeigt der Aufruf von »pcp« (Listing 1) einige Informationen zur Konfiguration an. Interessant ist hier vor allem, welche PMDAs aktiv sind. Im Verzeichnis »/var/lib/pcp/pmdas/« finden Sie weitere solcher Agenten, die Sie bei Bedarf installieren können. Dies geschieht meistens durch den Aufruf eines Install-Skripts im jeweiligen Verzeichnis des Agenten. Wollen Sie ihn wieder los werden, rufen Sie einfach das entsprechende Remove-Skript im gleichen Verzeichnis auf.

Listing 1: pcp zeigt aktive Monitoring Agenten



# pcp
Performance Co-Pilot configuration on tiffy.tuxgeek.de:
   platform: Linux tiffy.tuxgeek.de 3.17.6-200.fc20.x86_64 #1 SMP Mon Dec 8 15:21:05 UTC 2014 x86_64
   hardware: 4 cpus, 1 disk, 1 node, 7867MB RAM
   timezone: CET-1
   services: pmcd
      pmcd: Version 3.10.1-1, 7 agents
      pmda: pmcd proc xfs linux mmv postfix jbd2

Über das Tool pminfo können Sie sich nun einen Überblick darüber verschaffen, welche Informationen die einzelnen Agenten zur Verfügung stellen. In der Standardinstallation sind das über 1.200 verschiedene Metriken. Zum Glück unterstützt das Framework die Bash-Completion, sodass Sie nicht den genauen Namen einer Metrik kennen müssen. Ein Druck auf die Tab-Taste zeigt alle möglichen Metriken auf Basis der bisherigen Eingabe an.

Das folgende Beispiel zeigt die Load auf dem lokalen System an:

 

pminfo -f kernel.all.load

 

kernel.all.load
         inst [1 or "1 minute"] value 0.16
         inst [5 or "5 minute"] value 0.31999999
         inst [15 or "15 minute"] value 0.56999999

Können Sie mit der Ausgabe nicht viel anfangen, zeigt das Tool »pminfo« , mit »-t« aufgerufen, einen kurzen Hilfetext zu dieser Metrik an. Über die Option »-T« erhalten Sie eine ausführliche Hilfe.

Interessieren Sie sich für die Load auf einem entfernten System, rufen Sie »pminfo« einfach mit der Option »-h« , gefolgt vom Rechnernamen auf. Das Tool verbindet sich dann mit dem »pmcd« -Service des entfernten Rechners, um den entsprechenden Wert auf diesem System zu ermitteln. Statt auf pminfo können Sie auch auf das Tool »pmval« zurückgreifen. Es zeigt die Metriken in Intervallen an, statt einen einzelnen Wert zurückzuliefern (Listing 2).

Listing 2: Metriken-Intervalle mit pmval



# pmval -h ernie.tuxgeek.de kernel.all.load
metric:       kernel.all.load
host:          ernie.tuxgeek.de
semantics: instantaneous value
units:         none
samples:    all
       1 minute          5 minute          15 minute
          0.1500             0.1800               0.3300
          0.1500             0.1800               0.3300
          0.1500             0.1800               0.3300

Anstatt Live-Daten des Systems abzufragen, können Sie natürlich auch auf Archive zurückgreifen, die zuvor von »pmlogger« geschrieben wurden. Diese befinden sich im Verzeichnis »/var/log/pcp/pmlogger/« . Ein entsprechender Aufruf hierfür könnte beispielsweise wie folgt lauten:

 

pmval -a /var/log/pcp/pmlogger/tiffy.tuxgeek.de/20150126.0 proc.nproc

Zum Schluss sei noch erwähnt, dass das Tool »pmchart« auf Basis der Live- oder Archiv-Daten hübsche Grafiken erzeugt (Bild 1). Die umfangreiche Dokumentation auf der PCP-Website [2] beschreibt dieses wie auch alle anderen Tools in großer Ausführlichkeit.

(of)

Link-Codes

[1] Performance-Monitoring mit Sar: http://it-a.eu/F4P91/

[2] PCP-Website: http://it-a.eu/F4P92/

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

ADMIN-Tipp: Beobachtungsstation

Wer sar nützlich findet, um Performancedaten zu sammeln und aufzubereiten, für den lohnt sich ganz bestimmt ein Blick auf PCP.

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018