pixel
Select Page

NETWAYS Blog

Better Late than never – Graphite-Web-Installation unter Debian 10 – Part 2

This entry is part 2 of 2 in the series Graphite-Web

Willkommen zum zweiten Teil des Blogposts zur Graphite-Web-Installation unter Debian 10.

Wir springen hier direkt an die Stelle, an der wir aufgehört haben, und editieren die storage-schemas.conf unter /etc/go-carbon/

In der Storage-Schemas liegt das default-storage Schema:
Dadurch dass wir Icinga 2 installiert haben und auch dort Graphen generieren möchten, nehmen wir das folgende Schema:

[icinga_internals]
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d
[icinga_default]
pattern = ^icinga\.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

Damit haben wir die Konfiguration vom go-carbon in diesem Beispiel abgeschlossen.

Der nächste Schritt ist nun Whisper selbst und Graphite-Web.
Da das Graphite-Web immer noch Python-lastig ist, müssen wir einen kleinen Schritt im Voraus machen.

Wir definieren die Pfade im Voraus:

export PYTHONPATH="/opt/graphite/lib/:/opt/graphite/webapp/"

Danach erfolgt der allseits beliebte und gefürchtete pip-Aufruf:

pip install --no-binary=:all: https://github.com/graphite-project/whisper/tarball/1.1.6
pip install --no-binary=:all: https://github.com/graphite-project/graphite-web/tarball/1.1.6

Nach der Installation der beiden Komponenten wechseln wir in das /opt/graphite/webapp/graphite Verzeichnis und kopieren die local_settings.py.example, damit wir eine local_settings.py Datei haben, um die Einstellungen zu verändern.

SECRET_KEY = 'Sollte_durch_eine_zufällige_Zeichenkette_ersetzt_werden'
ALLOWED_HOSTS = [ '*' ]  // Für den Testzweck belassen wir es bei dem Asterisk, es sollte aber in Produktivumgebungen ersetzt werden durch die Maschinen welche mit dem Graphite sprechen dürfen.
TIME_ZONE = 'America/Los Angeles' // Die Zeitzone ist selbsterklärend
WHISPER_DIR = '/var/lib/graphite/whisper' // Das Whisper Datei Verzeichnis wo unserer Whisper Dateien liegen

Kleiner Hinweis wegen der Random-Zeichenkette:

Diese kann man mit dem folgenden Kommando erzeugen, wenn man möchte:

openssl rand -base64 32

Nun müssen wir noch den Ordner für unsere Whisper-Dateien anlegen und berechtigen.

mkdir -pv /var/lib/graphite/whisper
chown -Rf carbon. /var/lib/graphite/whisper

Daraufhin kopieren wir das Graphite.wsgi File um, damit es verwendbar ist.

cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi

An dieser Stelle kommt nun die Konfiguration des Apache2. Wenn jemand eine nginx-Konfiguration braucht, bitte ich diese Personen, sich in der Community zu melden, damit wir auswerten können, wie viele Anfragen es gibt, um eine ‘Standard’-Konfig für die nächste Iteration dieses Blogposts zu erstellen. 🙂

Wir erstellen im Apache-Verzeichnis eine graphite-web-ssl.conf und befüllen diese mit dem folgenden Beispielinhalt. Dieser ist je nach Umgebung anzupassen.

cd /etc/apache2/sites-available/
vi graphite-web-ssl.conf

Inhalt der graphite-web-ssl.conf:

# Enable virtualhosts, perhaps by adding this to your server's config somewhere,
# probably the main httpd.conf
# NameVirtualHost *:443

# This line also needs to be in your server's config.
# LoadModule wsgi_module modules/mod_wsgi.so

# You need to manually edit this file to fit your needs.
# This configuration assumes the default installation prefix
# of /opt/graphite/, if you installed graphite somewhere else
# you will need to change all the occurrences of /opt/graphite/
# in this file to your chosen install location.

LoadModule wsgi_module modules/mod_wsgi.so

# XXX You need to set this up!
# Read http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGISocketPrefix
# For example, create a directory /var/run/wsgi and use that.
WSGISocketPrefix /var/run/apache2/wsgi

# Base Configuration
ServerName localhost.local
DocumentRoot "/opt/graphite/webapp"

# Log Configuration
ErrorLog /opt/graphite/storage/log/webapp/error.log
CustomLog /opt/graphite/storage/log/webapp/access.log common

# SSL Configuration
SSLEngine On
SSLCertificateFile /etc/pki/tls/private/certificate.crt
SSLCertificateKeyFile /etc/pki/tls/private/certificate.key
SSLCertificateChainFile /etc/pki/tls/private/certificate.pem

# Graphite Related Configuration
# I've found that an equal number of processes & threads tends
# to show the best performance for Graphite (ymmv).
WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
WSGIProcessGroup graphite
WSGIApplicationGroup %{GLOBAL}
WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}

# XXX You will need to create this file! There is a graphite.wsgi.example
# file in this directory that you can safely use, just copy it to graphite.wgsi
WSGIScriptAlias / /opt/graphite/conf/graphite.wsgi

# XXX To serve static files, either:
# * Install the whitenoise Python package (pip install whitenoise)
# * Collect static files in a directory by running:
# django-admin.py collectstatic --noinput --settings=graphite.settings
# And set an alias to serve static files with Apache:
Alias /static/ /opt/graphite/static/

########################
# URL-prefixed install #
########################
# If using URL_PREFIX in local_settings for URL-prefixed install (that is not located at "/"))
# your WSGIScriptAlias line should look like the following (e.g. URL_PREFX="/graphite"

# WSGIScriptAlias /graphite /srv/graphite-web/conf/graphite.wsgi/graphite
# Alias /graphite/static /opt/graphite/webapp/content
# <Location "/graphite/static/">
# SetHandler None
#

# XXX In order for the django admin site media to work you
# must change @DJANGO_ROOT@ to be the path to your django
# installation, which is probably something like:
# /usr/lib/python2.6/site-packages/django
Alias /media/ "@DJANGO_ROOT@/contrib/admin/media/"

# The graphite.wsgi file has to be accessible by apache. It won't
# be visible to clients because of the DocumentRoot though.

Order deny,allow
Allow from all

= 2.4>
Require all granted

Order deny,allow
Allow from all

= 2.4>
Require all granted

Abschließend überprüfen wir die Konfig mit

apachectl -t

Hier erreichen wir nun den spannenden Teil (Cliffhanger) der Graphite-Web-Installation, und wie zuletzt um den Spannungsbogen zu erhöhen,
bitte ich um etwas Geduld, da im finalen und letzten spannenden Teil dieser Serie wir Graphite-Web initialisieren werden.

Bis dahin mit einem Servus

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Better Late than never – Graphite-Web-Installation unter Debian 10 – Part 1

This entry is part 1 of 2 in the series Graphite-Web

Hallo erstmal und vielen Dank für die Aufmerksamkeit.

Wie ich leider schon viel zu oft angekündigt hatte in den Kommentaren zu meinen häufig angeschauten Artikel Graphite mit Debian 9, reiche ich mit diesem Blogpost mein Versprechen mal ein.

Die Voraussetzungen sind fast die Gleichen wie im alten Blogpost, aber dank unserer Community und deren Mithilfe verfeinert. Ich verweise gern an dieser Stelle auf unsere Community, welche gern & freundlich weiterhilft: Icinga Community.

Nun aber zum Inhalt. Prämisse ist, dass wir eine Icinga2-Installation auf einem frischen Debian 10 (Codename Buster) haben. Die Installation von Icinga2 wird hier explizit nicht erklärt.

Ich liste die Schritte mit auf, werde aber im Gegenzug nur die Graphite-spezifischen Schritte erklären.

Beginnen wir mit der Basisinstallation, sprich den Paketen, welche man braucht und die relativ selbsterklärend sind.

apt-get update -y
apt install gnupg2 vim nagios-plugins-standard nagios-plugins-contrib apache2 -y
wget -O -https://packages.icinga.com/icinga.key | apt-key add -
echo -e "deb http://packages.icinga.com/debian icinga-buster main\ndeb-src http://packages.icinga.com/debian icinga-buster main\n" >> /etc/apt/sources.list
apt-get update -y
apt install python-dev libcairo2-dev libffi-dev build-essential python-pip python-sqlite libapache2-mod-wsgi golang -y
apt install icinga2 -y

Somit wären die ersten Vorarbeiten geleistet. Ab diesem Schritt werden wir für das Graphite-Web nun zuerst Zertifikate generieren.

Wir befinden uns im Jahr 2020. Da sollte zumindest jede sinnvolle Website ein Sicherheitszertifikat mitbringen, vor allem wenn es sich im freien Internet präsentiert. Ich promote hier an dieser Stelle auch nicht “Let’s Encrypt”, weil ich es nicht mag. Es gibt bereits 1001 und mehr Seiten, die bereits darauf eingehen und ich will/möchte mich da nicht einreihen.

Ich halte die händische Zertifikatsgenerierung mal hier als Alternative hoch.

Es fängt unter Debian schon mit der Erstellung der Ordner an.

mkdir -pv /etc/pki/tls/private

Innerhalb des Ordners erzeugen wir uns einen Zertifikatsschlüssel.

openssl genrsa -out certificate.key 2048

Hinweis: 4096 ist ein Wert, der akzeptabel ist. >4096 kann durchaus für die meisten internen Sicherheitsanforderungen nötig sein.

2048 ist hier also nur ein Beispielwert, kein Muss-Wert.

Danach erzeugen wir mit dem Schlüssel eine Signierungsanfrage für ein neues Zertifikat.

openssl req -new -key certificate.key -out certificate.csr -subj "/C=DE/ST=Somewhere1/L=Somewhere/O=Somewhere Company GmbH/OU=IT/CN=localhost.localdomain/emailAddress=admin@somewhere.com"

Wem nun die Frage nach den hier verwendeten Parametern kommt aus einem Ubuntu Guide aus der Community von mir selbst kopiert, hier die Erklärung:


Explanation of the -subj parameters:

Parameter Explanation
/C Country
/ST State
/L Location
/O Organization
/OU Organizational Unit
/CN Common Name
/emailAddress self explanatory

Mit den so erhaltenen Key & CSR erstellen wir nun ein Zertifikat.

openssl x509 -req -days 395 -in certificate.csr -signkey certificate.key -out certificate.crt

Damit hätten wir den Zertifikats-Part an dieser Stelle abgeschlossen. Nun geht es weiter zum Carbon-Teil dieses Blogposts.
Mir war es aktuell auch mit guten ‘Google-Fu’ nicht möglich, eine aktuellere Quelle zu finden als “https://github.com/lomik/go-carbon/”.
Aktuell ist auf der Graphite-Seite carbon 1.16, aber ich kann nicht sagen, ob beide “feature equal” sind.

Also wenn jemand etwas Neueres findet, bitte in der Community melden 🙂


wget https://github.com/lomik/go-carbon/releases/download/v0.14.0/go-carbon_0.14.0_amd64.deb
dkpg -i go-carbon_0.14.0_amd64.deb

Nach der Installation des Paketes muss natürlich die Konfiguration angepasst werden.

Also editieren wir die go-carbon.conf & storage-schemas.conf in /etc/go-carbon/.

go-carbon.conf:
max-cpu = 4 (default) // Sollte an die Möglichkeiten des Rechners angepasst werden
data-dir = "/var/lib/graphite/whisper" // Dies ist das Datenverzeichnis wo die Whisper Dateien abgelegt werden hier sollte man bedenken das dies im laufe der Zeit anwächst.
write-strategy = "max" // Um die CPU zu entlasten sollte hier "noop" gewählt werden.
\[udp\] = ... // In diesem Beispiel verwenden wir udp nicht also sollte der gesamte Block auskommentiert werden.
\[tcp\] = ... // Ist in diesem Beispiel unser Transport Protokoll
listen = ":2003" // Ist der Port auf den go-carbon hört sollte um die IP der Maschine ergänzt werden auf der er läuft `beispielhaft` hier "127.0.0.1:2003"

An der Stelle eine kleine Unterbrechung. Es geht weiter in dem folgenden Blogpost:Better Late than never – Graphite-Web-Installation unter Debian 10 – Part 2

Mit freundlichem Gruß

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Die drei großen Fragezeichen

Eine kleine Detektivgeschichte – oder: wer Centos beerbt. Als RedHat entschied, dass Centos 8 nach nur einem Jahr sein EOL (End of Life) erreicht hat, war das relativ umstritten. Wie bei großen reichen Familien versammelten sich alle, um das Erbe zu bekommen. Wie in allen Detektivgeschichten geht es um ein Warum, Wie und Wo. Ähnlich wie in Cluedo, nur dass hier als Protagonist nicht Colonel Mustard mit der Rohrzange jemanden im Salon ermordet. Diese Frage will ich heute an der Stelle hier aber gar nicht ausgraben. Der Täter ist in diesem Fall das Familienoberhaupt mit Namen RedHat Enterprise, die Tatwaffe ist Centos Stream und der Tatort, nunja, virtuell der Cyberspace.

Centos Stream ist halt ein Unstable Branch, der für viele Kunden nicht mehr die Stabilität garantiert, welche Sie vorher hatten. Redhat versucht hier, das lizenzpflichtige Produkt (den erstgeborenen Sohn) zu promoten – was nicht per se schlecht ist. RHEL 8.x ist weiterhin ein funktionierendes OS mit Support. Hingegen das Adoptivkind (Centos8) wird von der Burgzinne geworfen. In der Erbschaftsreihenfolge rückt der ungeliebte Neffe auf (Centos Stream). Allerdings wie sieht es mit den Alternativen aus? Ich habe mir heute 3 herausgepickt, welche ich in einem kurzen Abriss mal versuche mit einer Icinga Installation zu bestücken.

Als ersten im Ring haben wir Cloudlinux, welches sich als RHEL-kompatibel vermarktet und auch direkt die Clouduser ansprechen will. Hier eins vorweg: es ist kostenpflichtig. Nach Einlegen der ISO werden wir von einem Anaconda installer begrüsst, welcher auch durch eine Kickstart beantwortet werden kann. So weit, so gut… Der Abflauf der folgenden Installation ist wie immer unspektakulär. Kernel Version ist beim ersten Start 4.18 ohne Updates. Das initial Update wirft einen nach aktuellen Stand erstmal 141 Updates entgegen. Powertools sind schon von Haus aus dabei. Ein Blick in die SSHD Konfig zeigt, dass initial PasswordAuthentication auf ‘Yes’ steht. Das mögen nicht alle 🙁 – vor allem der Butler (Root) am wenigsten.
Nun gut. Wir gehen über in die Icinga installation (Detektei Simon & Simon), welche ich hier als Benchmark verwende; wie gut, es funktioniert, Stand Juni 2021.

Es erfolgt die Subscription, welche die Cloudlinux Repos freischaltet, das ist auch relativ unspannend. (Beschatten & stundenlang im Auto warten und Screenshots machen). Es kommt an der folgenden Stelle der Punkt, auf den es ankommt. (Der also, an dem unsere Informationsfitzel langsam den Plan offenlegen.)

#> dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
#> rpm --import https://packages.icinga.com/icinga.key
#> dnf install https://packages.icinga.com/epel/icinga-rpm-release-8-latest.noarch.rpm

Die Installation erfolgt relativ schmerzlos und wir haben ein laufendes Icinga auf einem Cloudlinux.


===========================================================
[root@localhost ~]# systemctl status icinga2
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-06-15 08:11:21 EDT; 9min ago
Main PID: 6298 (icinga2)
Tasks: 13 (limit: 5021) Memory: 14.4M
CGroup: /system.slice/icinga2.service ├─6298 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log ├─6313 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log └─6316 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Host. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 NotificationCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 12 Notifications. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 HostGroups. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Endpoint. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 FileLogger. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 235 CheckCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars' Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/cli: Closing console log. Jun 15 08:11:21 localhost.localdomain systemd[1]: Started Icinga host/service/network monitoring system. ===========================================================

Damit haben wir den ersten der drei Erben getestet. In den kommenden Posts werde ich mit den anderen versuchen, Icinga zu installieren.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Von Fackeln, elektrischen Schafen und Datenpunkten

Hallo und Willkommen im Jahr 2021! sheep

Damit sind wir offiziell 2 Jahre nach dem originalen Zeitablauf von Blade Runner welcher 2019 spielt.
Hmm, nirgends sind Nexus 6 Modelle die Rumlaufen und von elektrischen Schafen träumen.
(Auch keine Flugautos) *seufz*. Egal !!

Kommen wir zu dem eigentlichen Thema diese Woche.
Ich würde euch gern im neuen Jahr kurz erklären wie ihr mit einfachen Bordmitteln & wenig Aufwand aus den den meisten APIs Prometheus Daten exportiert ohne Zusatzsoftware zu installieren.

Explainer!! Was macht man mit den Fackeln https://prometheus.io/ ist eine Software welche mit ihrer eigenen Time Series Database auch Graphen Zeichnen kann und einen ziemlichen Erfolg hat, https://prometheus.io/docs/prometheus/latest/storage/ wenn man allerdings aus seiner Allerweltsapplikation Daten nach Prometheus exportieren will ist man leicht Aufgeschmissen. Viele Anbieter verkaufen teuer Plugins welche dies für Software tun oder es gibt halt keine Schnittstelle.

Ich versuche in meinem Beispiel aufzuzeigen wie man sich selbst einen Prometheus Output baut und ihn mit dem Prometheus node_exporter zu der Haupt Prometheus Instanz bringt.

Was brauchen wir an Software dafür machen wir einen kleinen Einkaufszettel 🙂

Die Zutaten:
1x Software welche eine API zur verfügung stellt – als Beispiel nehmen wir Icinga 2 kann aber eine Software eurer Wahl sein
1x Prometheus node_exporter (muss man leider zusätzlich installieren)
1x crontab – bringt hoffentlich eure Linux Distro von Haus aus mit
1x curl – hoffentlich auch schon von “Werk” ab mit an Bord
1x awk – same here auch hoffentlich schon mit an Bord
1x jq – Okay .. ich geb zu das muss man nachinstallieren (ich versuche mich gerade unter dem Schreibtisch zu verstecken)
https://stedolan.github.io/jq/download/

Nun wo wir die Zutaten kennen kommen wir zu dem eigentlichen Rezept.
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status | jq '.results[1].status.active_host_checks_1min' | awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'} > /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom

Was habe Ich da in der Zeile über dieser eigentlich verbrochen?
Dröseln wir das doch auf, Schritt für Schritt.

Step 1:
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status
Ich gehe im Crontab jede Minute her und greife mir aus der lokalen icinga 2 Instanz per Api den Status per JSON.

Step 2:
| jq '.results[1].status.active_host_checks_1min'
Dann gebe ich den JSON Output an jq weiter. Dies lass ich auf einen Wert aus dem JSON parsen. Idealerweise ein Zahlenwert welchen einen schönen Datenpunkt abgibt.

Step 3:
| awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'}
Dies reicht leider für Prometheus nicht aus wir müssen das etwas aufbereiten das Prometheus das auch als Datenquelle akzeptiert. Der Inhalt eines .prom Files muss in folgenderweise Formatiert sein. Hier kommt awk für die Aufbereitung ins Spiel.

Was nach dem awk Befehl rauskommt sieht formatiert ungefähr so aus node_icinga2_active_checks1m{active="/checks1m"} 607.

Ich hab mal aus Beschreibungsgründen den vorderen Teil node_icinga2_active_checks1m genannt. Könnte aber auch node_raspberrypi15_active_tempsensor30s sein. Danach folgt {active="/checks1m"} 607 welches nochmal auf den Key=Value + Wert Part hinweist. Ich bin aber ehrlich hier schwimme ich selbst etwas. Wenn mir jemand hier Aufschlüsseln kann was hier “Notwendig” ist wäre ich sehr Dankbar.

Step 4:
> /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom
Danach wird der von awk aufbereitete String in eine active_checks.prom Datei geschrieben.

Damit haben wir ein valides Prometheus File welches wir dem node_exporter (Prometheus) übergeben können.
Was hat es nun mit /var/lib/node_exporter/textfile_collector/active_checks.prom auf sich .. Der oben in der Zutatenliste erwähnte Prometheus node_exporter ist im Grunde die Datenschleuder welche konfiguriert, in einem selbst definierten Intervall (scrape_intervall) die active_checks.prom Datei in Richtung Prometheus Hauptinstanz wirft. Die dann wiederum die Werte in ihre Time Series Database einträgt und den Graphen zeichnet.

Da der Prometheus node_exporter selbst unterschiedliche Möglichkeiten hat Daten entgegenzunehmen, wir aber in "textform" Daten ihm liefern legen wir die .prom Datei unter dem Pfad /var/lib/node_exporter/textfile_collector/ ab.

Damit der node_exporter weiß wann er in welchem Intervall die von uns Aufbereiteten Daten an das Haupt Prometheus übergeben soll.
Muss Konfig ihm sagen wann (kurzer Abriss der /etc/prometheus/prometheus.yml)
...
## Add Node Exporter
- job_name: 'icinga2'
   scrape_interval: 60s
   static_configs:
      - targets: ['x.x.x.x:9100'] <= Adresse der Haupt Prometheus Instanz welche in dem Screenshot unten uns dann einen Graphen zeichnet.

Im Prometheus (Hauptinstanz) haben wir dann so einen Graphen wie im Screenshot unten, dies kann man auch noch schöner in Grafana zeichnen lassen sprich wenn man in seiner Software ein Grafana Fenster eingebunden hat kann man diese Graphen da hinein verlinken.

Ich hoffe ich konnte euch etwas den Einstieg in das neue Jahr verschönern mit meinem Versuch euch einen Prometheus Datenexport nahe zubringen und ich freue mich über euer Feedback.
Servus bis zum nächsten Mal !

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

GTD ohne Equipment

 

Hallo Miteinand !

Ich wollte eigentlich aus dem Homeoffice nicht einen üblichen Home Office Blogpost veröffentlichen aber ich wollte euch kurz daran teilhaben lassen, wie man mit minimalsten Gegebenheiten doch noch sein Arbeitspensum ggf. durch die Tür bekommt.

Ich hatte das grosse Pech das mein privates Macbook Pro aus dem Jahr 2016 den Weg allen irdischen gegangen ist und sich mit einer kombi aus exhausted Battery und Display/Grafikkarten Fehler + Wlan Modul Tod verabschiedet hat. Die Batterie ist ersetzbar, aber die anderen Sachen wären aktuell nicht mehr rechtfertigbar. So kurz vor dem Release neuer Hardware.

Ich musste also 2 Tage bis mein Firmenersatzlaptop kam etwas Zeit überbrücken. Das funkionierte sogar besser als geplant und an einigen Stellen schlechter.

Als Ersatz hatte ich nicht viel zur Hand. Ich hatte mein privat genutztes IPad Pro (IOs 13.x) eine Tastatur + Maus der Marke Logitech. IOs 13 wegen dem Maussupport welcher brauchbar ist als OS auf dem IPad. Alternativ läge hier auch noch ein Kindle Fire 7 rum welcher auch seinen Dienst getan hätte.

Keyboard

Keyboard


Das Keyboard ist das K380 in weiss + eine M171 Funkmaus. Man kann das ganze wenn man einen aktuellen Screen hat gemütlich per USB-C verbinden damit wenigstens von der Bildschirmgrösse etwas mehr sichtbar ist. Das ist aber schon purer Luxus.

Das Tablet kann man aber auch durch ein beliebiges Android Tablet der Marke X austauschen. Ich versuche hier Software bzw. Hardware Agnostisch zu sein. Für Office schreibsachen bin ich auf Office 365 Web zurückgefallen. Was Datenschutztechnisch für eine menge Leute nicht in Frage kommt. Es gibt aber auch die dedizierten Apps für IOs und Android somit muss nichts in die Cloud geladen werden.

Kommen wir zum Codehacking Part. Nun da man schlecht direkt auf dem IPad eine virtuelle Maschine mit Vagrant hochziehen kann musste ich wohl oder übel auf gehostete Services zurückgreifen. Zum einen unser einges (https://cloud.netways.de) welches es mir ermöglichte per Openstack Teststellungen zu bauen und testen. Als auch Azure (Terraform) und Bernds Schmuddelkind Nummer eins (AWS). Keines machte grossartig Zicken per Safari. Dies sollte auch per Android (Chrome) keine Probleme darstellen. Es braucht aber einen Sinnvollen SSH Client für das jeweilige Tablett damit man sich in der gehosteten VM zumindest Anmelden kann Ich benutze Termius (https://www.termius.com/) auf IOs. Es hat auch bezahl Features welche ich eigentlich aber gar nicht brauche (SFTP). Die funktionale Alternative auf Android ist Juice (https://juicessh.com/).

Termius Screenshot


Oh natürlich kommt nun die Frage auf wie man nun denn Code editiert. Klar ich muss mir von der VM die Sachen nochmal ziehen oder auf den virtuellen Desktop was aber per dedizierter VNC Viewer App (IOs/Android) (https://www.realvnc.com/en/connect/download/viewer/ios/) oder dem Microsoft Remote Desktop gut gelingt. (https://apps.apple.com/de/app/microsoft-remote-desktop/id714464092?l=en) 
Auch die anderen Remote Desktop Tools sind vertreten wie der bei uns benutzte Anydesk Client (https://anydesk.com/en/downloads/ios) und das nicht Todzubekommende Webex ist am Start (https://apps.apple.com/de/app/cisco-webex-meetings/id298844386?l=en). Beide Tools sind natürlich auch in einer Android Version erhältlich.

Aber zurück zu dem Editor. Ich muss gestehen das ist der Part welcher mich am meisten begrenzt hat. Mit Begrenzt meine ich nicht das es keine Auzwahl gibt. Ich bin eher ein barebones Nutzer der nicht viele Ansprüche hat. Ich brauch keine Codeergänzung, keine Autokorrektur usw. Ich gestehe ich bin mit Vim auf den VMs vollkommen zufrieden gewesen. Auch mit git welches in den VMs installiert war.

Ich würde aber zu cloud9 tendieren (Bernd ist sicher begeistert 🙂 ) (https://aws.amazon.com/cloud9/). Die alten Hasen von Panic Software haben noch Coda 2 zur Hand. (https://www.panic.com/coda/). Wobei mir deren Preisgestaltung bitter aufstösst.

Last But not least gibt es sicher auch noch für Selbsthoster Eclipse CHE. (https://www.eclipse.org/che/). Zu der kann ich leider nichts sagen, keinerlei Erfahrung meinerseits im Handling.
Gitlab hat auch eine Web IDE welche aber einen seltsamen Workflow hat. Man muss die einzelnen Files nach änderung mergen :S.

Die üblichen Kollaborationstools wie Slack, Rocketchat, Microsoft Teams gibt es auch bzw. Funktionieren auch auf mobile Geräten relativ Problemlos. Wenn alles versagt muss man halt sich per Handy in die Online Telko einwählen was manchmal doch erstaunliche Sprachqualitaet zu Tage fördert. (NO More VBR in VOIP).

Fazit:
So bin ich bis mein Arbeitslaptop da war per UPS gut durch die Zeit gekommen und konnte meinen Aufgaben gerecht werden.
Ich würde einen nativen USB-C Monitor favorisieren und ggf. Im Nachblick mir einen Browser wünschen welcher an einem externen Monitor die seitlichen schwarzen 4:3 Balken verschwinden lässt. (IOs Problem)(Lost Screen Estate) und eine IDE welche entweder als App mit frei einhängbaren Online Speicher funktioniert oder eine simpel funktionierende Web IDE.

Ich freue mich wenn ihr mir Sagen würdet  wie ihr so etwas überbrückt.

Gruss

David

Nachtrag:
Just als ich den Blogpost fertig hatte fand ich die folgende App.
Shiftscreen (https://apps.apple.com/de/app/shiftscreen/id1498683180?l=en) scheint zumindest teilweise das Black Bars Problem (IOs) zu beheben.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Trainings

Web Services

Events