Taglinux

automatisch eine VM mit virt-install erstellen

Ab und an benötige ich eine Test VM um ein paar Dinge auszuprobieren.

Dank KVM kann ich das ganze auch ziemlich einfach auf meiner Monsterentwicklungsmaschine lokal machen ohne gleich den Computer anderer Leute (aka Cloud) zu nutzen.
Für bestimmte Sachen möchte ich aber so wenig wie möglich in einem automatischen Prozess eingreifen. In dem Falle … der Erstinstallation mit dem abfragen aller Parameter.

Dafür kann man fai (für debain) oder kickstart (für RedHat / CentOS) nutzen.

Continue reading

systemd, shutdown … What-the-fuck!?

Ich benutze seit Jahren einen Homerouter, der uns als zentraler Druckerservice oder als interner Nameserver zur Verfügung steht.

Auf normaler Hardware hätte ich da jetzt die Haus-und-Hof Distribution gentoo eingesetzt, aber der ist arg schwachbrüstig, also rennt dort ein einfaches debian. Und an sich bin ich damit zufrieden, die Kiste macht alles was sie soll.
Allerdings scheinen sich einige der systemd Spezifika (mal wieder?) anders zu verhalten, wie man es erwartet:
Um Strom zu sparen fuhr der Router jeden Abend gg. 23:00 runter und startete dann gg. 05:00 wieder (meine reguläre Zeit für das aufstehen).
Aus „Gründen“ funktioniert das aber nicht mehr. Selbst mit einem manuellen shutdown -h now war der Router nach ca. 2 Minuten wieder da.

Continue reading

Auslesen und verarbeiten von MBeans

Es gibt viele Möglichkeiten, die Leistung und den Status eines Java Applikations Clusters zu überwachen.
Aus historischen Gründen ist dabei JMX (Java Management Extensions) weit verbreitet.

Um diese Daten auslesen zu können, gibt es verschiedene Tools, die ich einmal kurz vorstellen möchte:

jmx4perl ist ein Befehlszeilenprogramm für einen einfachen Zugriff auf einen Anwendungsserver.
check_jmx4perl ist ein NRPE Plugin für die Überwachung von Java Anwendungen.
jmxdump ist ein Bestandteil der CoreMedia Toolsuite
jolokia ist ein REST Service, der einen erweiterten Zugriff auf die JMX Daten bietet.
jconsole / jmc sind grafische Frontends, welche direkt mit einem oder mehreren JMX Endpunkten verbunden sein können.
j4psh ist ein Frontend zu JMX::Jmx4Perl. Es bietet eine interaktive Shell für den Zugriff auf die JMX MBeans.
Continue reading

puppetize

Nach meinen ersten Posts bzgl. Icinga2 kamen mehrere Nachfragen, über meine puppet Konfiguration. Dem möchte ich mal kurz ein paar Zeilen widmen.

Puppet ist ein Konfigurationsmanagementsystem. Ähnlich wie Chef (das ehemalige puppet Entwickler initiiert haben) oder dem neuesten Hype: Ansible.
Puppet setzt auf eine Client-Server Struktur, wobei man ihn auch masterless betreiben kann. Das kommt vor allem dann zu tragen, wenn man seinen eigenen Puppetmaster sich selber provisionieren lässt.
Bei Puppet wird der SOLL-Zustand des Zielsystemes beschrieben, wie so ein puppet-Run dort hin kommt wird interne gelöst. Die abarbeitung der entsprechenden Module ist willkürlich. Man muss also in seinen eigenen puppet Modulen etwas Intelligenz für die Auflösung der Abhängigkeiten einarbeiten.

Ansible funktioniert da anders.
Dort beschreibt man den kompletten Weg mit allen seinen Einzelheiten.
Ich habe Ansible Playbooks gesehen, bei dem selbst der Ersteller nicht mehr auf Anhieb sah, was das alles macht. ;)
Continue reading

monitoringlove #6 – icinga2 – Notifications mit Telegram

Wenn man einen icinga2 Service betreibt, möchte man irgendwann auch erfahren, wenn sich ein Status eines Service ändert.
Über Jahre hin etabliert und auch (in Grenzen) ausfallsicher ist und bleibt eine SMS. Vor allem, weil man damit unabhängig vom Netzzuganges seines ISPs bleibt.
Dafür reicht es, ein altes GSM-Handy mit einer SIM Karte auszurüsten und dieses über einen USB-Anschluss mit dem Monitoring-Host zu verbinden.
Die Softwareseitige Integration sollte dann nicht mehr so kompliziert sein.
Das kann man aber nur machen, wenn man dem Server im eigenen Zugriff hat.

Ist dieser jedoch gemietet und steht mit Dutzend anderen in einem Rechenzentrum, was sich dann auch noch in einem anderen Land befindet, muss man sich nach einer Alternative umsehen.
Diverse Messagingservices bieten sich da förmlich an. Icinga2 ist da flexibel genug aufgebaut, man kann so ziemlich alles befeuern.
Es gibt sogar einen Twitteraccount, in dem Notifications landen.

Continue reading

monitoringlove #5 – icinga2 und der LiveStatus

Wenn man ein großes Setup betreut in dem häufig eine neue Software ausgerollt wird, wird es vor kommen, dass man Downtimes dynamisch definieren und ausrollen möchte.
Im Idealfall auch nicht per Hand sondern von außen angetriggert … man ist ja ein wenig faul. ;)

Vor Version 2.4.0 von Icinga2 musste man auf die Nutzung von LiveStatus zurückgreifen, das man ja noch von Nagios kennen sollte.

(Wie man den LiveStatus über puppet aktiviert hatte ich bereits in einem vorherigen Blogpost beschrieben)

Mit dem LiveStatus ist man allerdings auf ein Set festgelegter Kommandos beschränkt. Und hierbei ist beschränkt auch ernst zu nehmen.

Für das herumprobieren kann man sich die folgende Beispiele ansehen und damit herumprobieren. Continue reading

monitoringlove #4 – icingaweb2 mit puppet

Während wir unseren Icinga2-Core mittlerweile funktionsfähig haben, wollen wir auch mal einen Blick auf unsere Checks werfen.

Hier hat man dann die Wahl zwischen dem klassischen UI, welches man noch von Nagios oder Icinga1 kennt, oder dem moderneren IcingaWeb2.
Ich empfehle hier IcingaWeb2. Nicht nur wegen dem fancy Aussehen, sondern weil es auch noch ein CLI Tool mitbringt. :)

IcingaWeb2 ist eine PHP basierte Webanwendung.
Wir benötigen also neben dem reinen IcingaWeb Paket auch noch einen Webserver und PHP.
Da ich mich mittlerweile vom Apache abgewandt und vermehrt nginx einsetze, werde ich das auch hier nutzen.

Beim schreiben ist mir aufgefallen, dass dieser eine Part doch umfangreicher als gedacht geworden ist.
Ich werde also ggf. einen zweiten Teil schreiben müssen, da mir selbst ein paar Dinge fehlen.

Falls jemand Anregungen haben sollte, der kann gern die Kommentarfunktion nutzen, oder mir einfach eine EMail schreiben.

Continue reading

monitoringlove #3 – icinga2 checks mit puppet (update)

Aufbauend auf dem vorherigen Teil, möchte ich hier beschreiben, wie man Host- und Servicechecks über puppet definiert und ausrollt.

Das zusammenführen von Host- und Servicechecks ist mittels apply Regel in icinga2 geradezu kinderleicht geworden.
Da haben sich die Jungs echt was tolles ausgedacht!

Aber genug des Smalltalks!
Continue reading

monitoringlove #2 – icinga2 mit puppet (update)

Wenn man sich – so wie ich – mit einer Großzahl an zu überwachenden Servern beschäftigt, macht man sich ziemlich schnell Gedanken darüber, wie man das ganze einfach, schnell und nachvollziehbar etabliert.
Ich begann in einem früheren Post bereits über meine Erfahrungen zu schreiben und möchte hiermit fortfahren.

Diesmal geht es um die Grundinstallation des icinga2-Core mittels puppet.
Hilfreich sind dabei Grundkenntnisse in puppet, der Konfiguration und dem logischen Aufbau von hiera.
Des weiteren nutzen wir ein Ruby Feature namens deep_merge. Das müsste ggf. noch mittels gem install deep_merge / emerge dev-ruby/deep_merge installiert werden.
Ich gehe bewusst nicht auf die von mir genutzte hiera-Struktur ein, da jeder seinen eigenen Weg verfolgt.
So bald ich das ganze hier aber herunter geschrieben habe, werde ich eine lauffähige Konfiguration in meinem github Account packen. Versprochen! ;)

Continue reading

monitoringlove #1 – java Applikationen (update)

Okay, der Artikel greift massiv vorweg, ist aber schneller zusammen geschrieben! :)

Ich möchte hier die unterschiedlichen Möglichkeiten des Monitorings von Applikationen beschreiben.

Wobei mein Schwerpunkt auf Tomcat und Java liegen wird.

Das ganze habe ich auch in ein (spezialisiertes) puppet-Modul einfließen lassen, was man sich bei github ansehen und forken kann. Über Pull-Request oder Anregen freue ich mich natürlich ebenso!

Continue reading

Older posts