Revisited – Graphite-Web installation unter Debian 9

Erstmal wieso Revisited ?

Dies ist ein update meines älteren Blog Posts Blogpost 2016 welcher darauf einging das unter Debian 8.4 graphite-web wegen eines Fehlenden Eintrages in der Apache 2.4 Konfiguration nicht korrekt gestartet/aufgerufen werden konnte.
Es ist schon einige Zeit ins Land gegangen und ich habe weniger ein Auge darauf geworfen ob das weiterhin so Funktioniert.
Deshalb Revisited.

Here we Go again !

Ich gehe in diesem Fall von einer Debian Version der Nummer 9 aus und werde wie bei dem alten Blogpost. In der Grundannahme mal davon ausgehen das alles Funktioniert wie es soll:

Also hier die folgenden installationschritte:

#> apt-get install apache2 libapache2-mod-wsgi python-django python-django-tagging fontconfig python-tz python-pip python-dev python-twisted python-cairo
#> pip install carbon whisper graphite-web
#> pip install --upgrade twisted
#> cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
#> cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf
#> /opt/graphite/bin/carbon-cache.py start
#> /opt/graphite/bin/carbon-cache.py status
#> cp /opt/graphite/examples/example-graphite-vhost.conf /etc/apache2/sites-available/graphite.conf
#> cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
#> cp /opt/graphite/webapp/graphite/local_settings.py.example \ /opt/graphite/webapp/graphite/local_settings.py
#> python /opt/graphite/webapp/graphite/manage.py syncdb
#> chown www-data. -R /opt/graphite/storage
#> a2dissite 000-default
#> a2ensite graphite
#> a2enmod wsgi
#> service apache2 restart
#> chmod +x /etc/init.d/carbon-cache // Damit 'carbon-cache.py start' mit Systemstart erfolgt

Ergebnis davon ist -> Nichts funktioniert.

Back to the Roots

Ab hier kommt der Weg graphite-web auf einem Debian 9 (Stretch) in Betrieb zu nehmen.

Ausgangspunkt ist ein frisch installiertes Debian 9.

#> apt-get install vim -y
#> vim /etc/apt/sources.list

Wir müssen die Sources auf die Jessie Repositories setzen da zum Zeitpunkt dieses Blogposts die graphite-web Pakete nicht abrufbar sind.

Daher fügen wir folgendes hinzu in der sources.list
deb http://httpredir.debian.org/debian jessie main
Gefolgt von einem frischem #> apt-get update -y .

Nun installieren wir den großteil der Pakete welche wir benötigen.
#> apt-get install graphite-web graphite-carbon mysql-server python-mysqldb python-pymysql apache2 libapache2-mod-wsgi apt-transport-https ssl-cert python-pip -y

Es folgen ca. 300MB an Daten.
Daraufhin stürzen wir uns direkt auf die Konfig.

Wir fangen an folgende Datei zu editieren.
#> vim /etc/graphite/local_settings.py
Darin ändern wir folgende Settings Sinnvoll in etwas was wir für unsere Installation benötigen.

Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS setzen.

Danach muss in der folgenden Datei ein “true” gesetzt werden damit graphite & carbon gemeinsam starten.

#> vim /etc/default/graphite-carbon

Nun kommt der trickreichste Part wir sind leider dazu genötigt eine alte django Version zu installieren.

#> pip install "django==1.4"

Damit haben wir die Grundlage womit wir das folgende Kommando erfolgreich absetzen können.

#> graphite-manage syncdb
#> chown _graphite. /var/lib/graphite/graphitedb
HINWEIS ! Dies setzt erst mal die voreingestellte sqlitedb in Gang.
Wenn eine andere DB verwendet werden soll dann sollte dies bitte in der “local_settings.py” vorgenommen werden.

Wir sind fast am Ziel ein funktionierendes graphite-web zu haben.
Es fehlt nur etwas Apache2 Magie.

#>a2dissite 000-default.conf
#>cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/
#> a2ensite apache2-graphite.conf
#> systemctl restart apache2

Voilà !

Es sollte nun auf dem Host System das graphite-web aufrufbar sein.

Danke für die Aufmerksamkeit !

David Okon

Autor: David Okon

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 glücklichen Menschen zu machen.

Icinga2 API und BitBar auf MacOs

preview1Wir wollen APIs, warum? Weil sie schnell, einfach zu integrieren und zu bedienen sind. Nun hat Icinga2 eine API und es entstehen ganz viele Möglichkeiten diese zu nutzen. Wir bauen uns Dashboards mit Dashing oder zeigen den Status von Hosts in Foreman an.

Ich bin letztens über ein Tool BitBar gestolpert, dieses Tool kann mit einfachen Skripten die eigene “Mac OS X menu bar” erweitern. Hierfür braucht es nur die richtige Formatierung der Ausgabe und BitBar generiert ein weiteres Dropdown Menu.

Ich hab mir die Icinga2 API zu nutze gemacht und eine kleine Erweiterung gebaut um mir den Status von Icinga2 in meiner Menubar anzuzeigen.
Im Menu wird dann der globale Status entweder in grün oder rot, abhängig davon ob Hosts “down” und “unhandled” sind, angezeigt.
Der Aufruf dafür kann der Adresszeile im Browser entnommen werden.
/icingaweb2/monitoring/list/hosts?host_state=1&sort=host_severity&host_unhandled=1

Wenn wir am Ende dann ein “&format=json” an die URL hängen, haben wir ein gängiges Format um das Ergebnis in jeglichen Applikationen zu verwenden.
[{"host_icon_image":"","host_icon_image_alt":"","host_name":"web01","host_display_name":"web01","host_state":"1","host_acknowledged":"0","host_output":"DOWN","host_attempt":"1\/3","host_in_downtime":"0","host_is_flapping":"0","host_state_type":"1","host_handled":"0","host_last_state_change":"1474556541","host_notifications_enabled":"1","host_active_checks_enabled":"0","host_passive_checks_enabled":"1"},

Mehr dazu gibts auf Github unter icinga2_api_examples oder natürlich in der Icinga2 Dokumentation.

Thilo Wening

Autor: Thilo Wening

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

atexit, oder wie man Python-Dienste nicht beenden sollte

Wer schon einmal einen Dienst mit Python realisiert hat, wird bereits vor der Aufgabe gestanden haben die Aufgaben die er verrichtet sauber und geordnet zu beenden. Python bietet einem hier vielerlei Lösungen an, darunter auch das atexit Modul. Für schnelle und simple Aufräum-Arbeiten ist dieses Modul wunderbar geeignet, nicht jedoch wenn Thread-Synchronisation und externe Kommunikation im Spiel ist. Warum das so ist und was die saubere Alternative ist, darum geht es heute in diesem Blogpost.

Wie der Name des Moduls und dessen Dokumentation bereits sagt, werden registrierte Routinen ausgeführt kurz bevor der Interpreter angehalten wird. Klingt erst einmal nicht besonders problematisch, ist es doch gerade was man haben möchte. Und es funktioniert sogar, solange keine Threads laufen. Dann werden die registrierten Routinen nicht aufgerufen. Das liegt daran, dass “normale” Threads explizit beendet werden müssen, sonst verhindern diese den Stopp des Interpreters. Damit das nicht passiert, kommt man möglicherweise auf folgende Idee:

t = threading.Thread(target=func)
t.daemon = True  # Avoids that python hangs during shutdown
t.start()

Ganz schlecht. Das mag möglicherweise den gewünschten Effekt haben und die Aufräum-Routinen können ihre Arbeit verrichten. Aber tatsächlich ist dies nur eine Lösung für ein Symptom, das eigentliche Problem ist noch immer nicht gelöst. Das wird einem spätestens klar, wenn es nicht mehr nur darum geht Threads zu beenden, sondern auch noch mit anderen über das Netzwerk verbundenen Diensten/Klienten eine saubere Unterbrechung der Kommunikation einzuleiten.

Denn was genau passiert wenn der Interpreter angehalten wird?

  1. Der MainThread wird sofort angehalten
  2. Offene File-Handles werden geschlossen
  3. Es wird gewartet dass alle nicht-Daemon Threads beendet wurden
  4. Die atexit-Routinen werden ausgeführt
  5. Garbage Collection
  6. Der Prozess wird beendet

Der zweite Punkt lässt einige vielleicht bereits aufhorchen, denn sockets sind nichts anderes als File-Handles. Wer nun immer noch denkt er könne in einem daemon-Thread die Netzwerk-Kommunikation mit seinem Gegenüber sauber beenden, ist auf dem Holzweg. Zum Zeitpunkt zu dem die atexit-Routinen laufen, sind bereits alle sockets unwiderruflich geschlossen.

Angenommen der Stopp des Dienstes wird ganz normal über SIGTERM initiiert, so könnte man nun alle atexit-Routinen in einen Signal-Handler verlagern. Dadurch würden sie laufen noch bevor der Interpreter angehalten wird, allerdings kommt man so sehr schnell wieder in die Bredouille, je nachdem welche Art von Arbeit der MainThread verrichtet. Denn da Signal-Handler asynchron im MainThread ausgeführt werden, ist das Risiko für ein Deadlock sehr groß. Kommen wir also zur erwähnten, sauberen Alternative: Feuer mit Feuer bekämpfen.

Was vormals in etwa so aussah:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...

    def _sigterm(self, signum, frame):
        sys.exit(0)

    def _atexit(self):
        # Alle Aufräum-Arbeiten

Kann ganz einfach, mit durchschlagendem Erfolg, so umgebaut werden:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...

    def _sigterm(self, signum, frame):
        threading.Thread(target=self._cleanup, name='CleanupThread').start()

    def _cleanup(self):
        # Komplexe Aufräum-Arbeiten

    def _atexit(self):
        # Einfache Aufräum-Arbeiten

Der “CleanupThread” sollte selbstverständlich keine Arbeit verrichten die unkontrolliert blockt. Denn dann sieht das ganze am Ende wieder so aus:

    def _sigterm(self, signum, frame):
        t = threading.Thread(target=self._cleanup, name='CleanupThread')
        t.daemon = True
        t.start()

Und der ganze Spaß geht von vorne los..

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Bottle – Klein aber fein

Vor einiger Zeit war es notwendig für ein Kunden-Projekt dessen Umgebung bei uns nachzubilden. Es war von vornherein klar, dass es keine 1:1 Nachbildung sein muss (kann) und somit war es nur notwendig einige wenige Bestandteile einer REST Api zu simulieren. Da REST rein HTTP basiert ist und die zu simulierenden Aktionen nur GET waren, kam uns erst gar nicht in den Sinn ein großartiges PHP-Projekt ins Leben zu rufen und entschieden uns daher für eine schnelle Lösung mittels eines Standalone Python Skriptes.

Mir war Bottle schon seit einigen Jahren bekannt und deshalb noch als Werkzeug für schnelle und einfache Lösungen in Erinnerung. Tatsächlich eingesetzt hatte ich es allerdings noch nie, weshalb dies die Chance war es endlich einmal zu tun. Gesagt getan, runtergeladen und ausgeführt. Da Bottle allein auf der Standard-Library von Python basiert und mit Python 2.6+ wie auch Python 3.2+ kompatibel ist, funktionierte das sofort ohne Probleme. Und es hält was es verspricht!

Allein das erste Beispiel auf seiner Webseite zeigt bereits wie schnell ein Web-Server mit dynamischem Routing und Inhalten aufgesetzt wird:

from bottle import route, run, template

@route('/hello/<name>')
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)

run(host='localhost', port=8080)

Ja sogar Basic Authentication beherrscht es:

from bottle import route, run, template, auth_basic

def authenticate(username, password):
    return username == 'max' and password == 'mustermann'

@route('/hello/<name>')
@auth_basic(authenticate)
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)

run(host='localhost', port=8080)

Ist das nicht toll? Ich nehme stark an, dass da noch mehr geht, aber für den Moment bin ich vollauf zufrieden. 🙂

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Braintower SMS Gateway – Icinga Plugin verfügbar!

icinga_logo_200x69Trotz Weihnachten und dem bevorstehenden Jahreswechsel sind wir natürlich nicht untätig und stehts dabei unser Portfolio an Plugins weiter auszubauen. Heute möchte ich die Gelegenheit nutzen, um zum Jahresende ein nützliches Plugin für die Überwachung unserer Braintower Geräte mit Icinga vorzustellen.
Das kleine Python-Plugin bedient sich dabei der Statusseite des Gateways und liefert unter anderem Informationen über die Failed-Queue, die Signalstärke sowie die Uptime.

Will man das Gateways überwachen, ruft man das Plugin einfach mit folgenden Parametern auf:

./check_braintower -H 192.168.1.1 --signal-warning -85 --signal-critical -90

Die Werte der Parameter muss natürlich jeder auf seine Bedürfnisse anpassen 🙂

Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:

BRAINTOWER OK - que: 0 failed: 0 signal: -83db total: 0 state: Idle load: 0;0.03;0.05 time: 1451320254 disk free: 647569408 uptime: 9 min, 0 users

Selbstverständlich kann man nicht nur die Signalstärke überwachen, sondern eine Vielzahl von Parametern. Mit –help erhält man hier eine schöne Erklärung über die Möglichkeiten:


usage: check_braintower [-h] -H HOSTNAME [-T TIMEOUT] [-Q QUEUE] [-F FAIL] [--signal-warning SIGNAL_WARNING] [--signal-critical SIGNAL_CRITICAL]

optional arguments:

-h, –help show this help message and exit
-H HOSTNAME, –hostname HOSTNAME The host address of the SMS Gateway
-T TIMEOUT, –timeout TIMEOUT Seconds before connection times out (default 10)
-Q QUEUE, –queue QUEUE The warning threshold for the amount of queued SMS (default 1)
-F FAIL, –fail FAIL The critical threshold for failed SMS (default 1)
–signal-warning SIGNAL_WARNING The warning threshold for the minimum signal strength (in db, default 0)
–signal-critical SIGNAL_CRITICAL The critical threshold for the minimum signal strength (in db, default 0)

 

Wer das Plugin ausprobieren möchte, kann dies natürlich gerne tun – wir freuen uns über Feedback! Verfügbar ist es auf Icinga Exchange und in unserem NETWAYS Git.

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Monthly Snap November: OSMC, Icon Fonts & Jaspersoft Studio

November presented an exciting 10th OSMC, featured Jasper reporting and offered DevOps tips for sys admins, developer and tinkerer.weekly snap

Beginning with events, our 10th Open Source Monitoring Conference with many special guests took place and Daniela reported on day one and Dirk summarized the other days of the conference while Jean-Marcel gave us an overview of his two favorite presentations.

Eric then described how to create Icon-Fonts and Alexander explained how to upgrade python-driven servers.

Lastly, Christoph looked at Jaspersoft Studio and Kay shared a guide to control home automation components with Rasperry PI and a web interface.

Stephanie Kotilge

Autor: Stephanie Kotilge

Steffi kümmert sich bei NETWAYS ums Office-Management und ist die gute Seele der Fabrik. Auch unsere Kunden kommen an ihr nicht vorbei und wollen dies natürlich auch nicht. Da sie ein überdurchschnittliches sprachliches Talent besitzt und neben Deutsch noch fliessend in Englisch und Französisch unterwegs ist, kümmert sie sich auch um einen Großteil der Übersetzungen. In diesem Sinn ... Merci