Verstärkte Zusammenarbeit mit Icinga

Wir sind stolz darauf, Ihnen mitteilen zu können, dass icinga.com nun auch Hardware-Integrationen zur Überwachung von Umgebungssensoren und zur Alarmierung per SMS anbietet. Die Geräte der unter Icinga Integrations aufgeführten Hersteller können mit Hilfe von Plugins, die auf Icinga Exchange verfügbar sind, problemlos in Ihr Icinga-Monitoring integriert werden.

 

Alarme per Text Message

Grundsätzlich gibt es zwei Arten von Geräten, die sich am besten für die Integration mit Icinga eignen. Die erste Gruppe davon sind Gateways für den Versand von SMS als Alarmmeldungen. Diese Gateways arbeiten mit Standard-SIM-Karten und können auf Bändern in 4G-, 3G- und 2G-Netzen betrieben werden. Diese Geräte bieten auch mehr Funktionalität als nur das Senden von Nachrichten: Sie sind auch in der Lage, SMS in E-Mail zu konvertieren oder umgekehrt sowie Filter und Routing für das Senden von Nachrichten an nur eine bestimmte Person oder Personengruppe anzuwenden (Telefonbuchfunktion). Darüber hinaus verfügen die Gateways über einen eigenen Monitoring-Server, so dass sie z.B. bei einem Verbindungsabbruch zum Netzwerk automatisch Benachrichtigungen senden können.

Um diese Gateways reibungslos in die eigenen Produktionsprozesse einzubinden, gibt es z.B. Plugins für die direkte Verbindung zu Ihrem Microsoft Exchange zur vollumfänglichen Nutzung der E-Mail zu SMS Konvertierung. Integriert in Icinga 2 können Sie nicht nur das Gerät selbst überwachen, sondern es auch nutzen, um von Icinga generierte Benachrichtigungen weiterzuleiten. Die beiden Haupthersteller dieser Gateways sind Braintower mit Sitz in Deutschland und SMSEagle mit Sitz in Polen.

 

Monitoring Ihrer Umgebung

Die zweite Art von integrierbaren Geräten ist hauptsächlich für die Messung und Überwachung bestimmt. Diese bestehen meist aus einer Basiseinheit und mehreren Ports für den Anschluss von Sensoren. Die Basiseinheiten können entweder direkt über LAN oder bei entfernten Standorten über GSM kommunizieren. Für eine vollständige Umgebungsüberwachung gibt es eine Vielzahl von Sensortypen, die angeschlossen werden können:

  • Temperatur
  • Luftfeuchtigkeit
  • Kombination von Temperatur und Luftfeuchtigkeit
  • Luftdruck
  • Luftstrom
  • Spannung
  • Wasser und Leckagen
  • Rauch und Gas
  • Pegelstände von Flüssigkeiten
  • Bewegung, Vibration und Öffnen von Türen

Die wichtigsten Hersteller für Messgeräte sind derzeit AKCP, GUDE, HW group und Tinkerforge. Für all diese finden Sie Monitoring Plugins auf Icinga Exchange. Insbesondere der Hersteller GUDE bietet auch Steckdosenleisten an, die nicht nur die Spannung überwachen, sondern auch Stecker und Geräte remote steuern können.

 

Integration von Tinkerforge mit Icinga

Um genauer anzuschauen, wie diese Geräte in Icinga 2 integriert werden können, ist Tinkerforge eines der besten Beispiele. Das gesamte Plugin-Projekt ist unter https://exchange.icinga.com/netways/check_tinkerforge zu finden und zeigt nicht nur die Integration, sondern bietet auch einen Einblick in die Funktionalitäten des Gerätes.

Für die Verwendung des check_tinkerforge Plugins ist es erforderlich, Python 2.7+ auszuführen und die tinkerforge Python-Bibliothek von Pypi installieren zu lassen. Danach erfolgt die Installation mit pip install tinkerforge und das Verschieben des Plugins in die Icinga PluginDir Position.

Lassen Sie uns nun einen Blick auf die Optionen des Plugins werfen:

$ ./check_tinkerforge.py --help
usage: check_tinkerforge.py [-h] [-V] [-v] -H HOST [-P PORT] [-S SECRET]
[-u UID] -T TYPE [-w WARNING] [-c CRITICAL]
[-t TIMEOUT]
optional arguments:
-h, --help show this help message and exit
-V, --version show program's version number and exit
-v, --verbose
-H HOST, --host HOST The host address of the Tinkerforge device
-P PORT, --port PORT Port (default=4223)
-S SECRET, --secret SECRET Authentication secret
-u UID, --uid UID UID from Bricklet
-T TYPE, --type TYPE Bricklet type. Supported: 'temperature', 'humidity', 'ambient_light', 'ptc'
-w WARNING, --warning WARNING Warning threshold. Single value or range, e.g. '20:50'.
-c CRITICAL, --critical CRITICAL Critical threshold. Single vluae or range, e.g. '25:45'.
-t TIMEOUT, --timeout TIMEOUT Timeout in seconds

 

Da das TinkerForge-Gerät Sensoren für Temperatur oder Luftfeuchtigkeit sowie andere Typen unterstützt, müssen wir mit dem Operator -T oder --type angeben, welcher Sensor überprüft werden soll:

check_tinkerforge.py -H 10.0.10.163 -T temperature -w 23 
WARNING - Tinkerforge: Temperature is 24.75 degrees celcius|'temperature'=24.75

Wenn Sie mehrere Sensoren eines Typs haben, müssen Sie die UID mit dem Operator -u oder --uid angeben, um den betreffenden Sensor korrekt zu identifizieren. Darüber hinaus können Schwellenwerte entweder als Einzelwerte oder Wertebereiche und mit den üblichen Operatoren für warning und critical angegeben werden.

Um die Sensoren in Ihre Icinga 2-Konfiguration zu integrieren, müssen Sie wie bei anderen Check-Plugins ein CheckCommand Objekt erstellen. Das Gerät selbst wird als Host Objekt angelegt und alle Sensoren sollten mit einem apply Service versehen werden. Zusätzlich finden Sie hier eine Beispielkonfiguration für TinkerForge. Dieses Beispiel kann direkt verwendet werden, es ist nur notwendig, die Parameter zu ändern und, falls Sie mehrere Sensoren eines Typs haben, die UIDs hinzuzufügen.

Alle in diesem Blogbeitrag genannten Hersteller finden Sie auf der Website der Icinga integrations mit Informationen über die Unternehmen, die Geräte und die Links zu den entsprechenden Monitoring-Plugins sowie in unserem Online Shop.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Monitor das Monitoring_by_ssh

Quelle: https://medium.com/

Hellow,

heute möchte ich euch zeigen, wie man schnell und einfach mit Icinga 2 seine bestehende Icinga 2 Infrastruktur monitoren kann.

Jeder der sich damit schon mal befasst hat, wird schnell zu dem Ergebnis kommen: “Hey warte mal den Master kann ich ja nicht auf den anderen Master drauf packen.”, falls nicht, ist das die Tatsache. Zitat “Henne-Ei-Problem”.

Die Lösung dieses Problems ist allerding recht simpel. Nachdem wir den jeweiligen Icinga 2 Core nicht heranziehen können, machen wir ganz einfach gebrauch von check_by_ssh. Somit können wir völlig unabhängig der Icinga 2 Infrastruktur entlang unsere Monitoring Instanzen monitoren.

Hierfür verwende ich zwei Vagrant Boxen die aus einer aktuellen CentOS 7 und Icinga 2 Installation besteht. Box #1 ist der Icinga 2 Core und Box #2 der “Monitor the Monitoring”.

Auf der Box #1 muss zunächst ein Benutzer angelegt werden:

# Benutzer icinga hinzufügen
useradd -m icinga

# Temporäres Kennwort vergeben
passwd icinga

Auf der Box #2 müssen vorbereitend folgende Schritte ausgeführt werden:

# Shell für den icinga Benutzer aktivieren:
usermod --shell /bin/bash icinga

# SSH-Key für den icinga Benutzer erzeugen.
ssh-keygen -b 4096 -t rsa -C "icinga@$(hostname) user for check_by_ssh" -f $HOME/.ssh/id_rsa

# SSH-Key auf die Box #1 kopieren
ssh-copy-id -i $HOME/.ssh/id_rsa icinga@master1.int.mbp.local

# Anschließend prüfen ob das ganze geklappt hat
ssh -i $HOME/.ssh/id_rsa icinga@master1.int.mbp.local

Nun haben wir sämtliche Vorbereitungen abgeschlossen, nur noch eben aufräumen:

# Auf der Box #1 wird die Passwortanmeldung des icinga Benutzers deaktiviert
passwd -l icinga
# Auf der Box #2 wird die Shell des icinga Benutzers wieder in den Default Zustand gebracht
usermod -s /sbin/nologin icinga

Das Ziel liegt nun nicht mehr all zu fern, wir begeben uns auf Box #2 und erzeugen Icinga 2 Konfiguration:

# Man legt zwei Verzeichnisse unter "/etc/icinga2/zones.d" an
mkdir -pv /etc/icinga2/zones.d/{global-templates,master}

# Wechseln in das "global-templates" Verzeichnis und kopieren von Github die Check-Commands für check_by_ssh
cd /etc/icinga2/zones.d/global-templates
wget https://raw.githubusercontent.com/lbetz/icinga-commands/master/commands-ssh.conf

# Nun wechseln wir in das "master" Verzeichnis und legen dort ein Konfiguration für die Box #1 an
cd /etc/icinga2/zones.d/master
touch master1.int.mbp.local.conf

# Folgende Konfiguration enthält das Host Objekt "master1"

object Host "master1.int.mbp.local" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "hostalive"

    display_name = "master1"
    address = "127.28.128.11"
}

object Service "LIN load" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_load"

    host_name = "master1.int.mbp.local"
}

object Service "LIN disk" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_disk"

    host_name = "master1.int.mbp.local"
}

object Service "LIN swap" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_swap"

    host_name = "master1.int.mbp.local"
}

object Service "LIN time" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_ntp_time"

    host_name = "master1.int.mbp.local"
}

object Service "LIN proc icinga" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_procs"

    host_name = "master1.int.mbp.local"

    vars.by_ssh_arguments = {
        "-u" = "$procs_user$"
        "-w" = "$procs_warning$"
        "-c" = "$procs_critical$"
    }
    vars.procs_user = "icinga"
    vars.procs_warning = "250"
    vars.procs_critical = "0:300"
}

object Service "LIN proc mysql" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_procs"

    host_name = "master1.int.mbp.local"

    vars.by_ssh_arguments = {
        "-u" = "$procs_user$"
        "-c" = "$procs_critical$"
    }
    vars.procs_user = "mysql"
    vars.procs_critical = "0:1"
}

object Service "LIN port 5665" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "tcp"

    host_name = "master1.int.mbp.local"

    vars.tcp_port = "5665"
}

# Anschließend Konfiguration Prüfen und den Icinga 2 Core neustarten
icinga2 daemon -C
systemctl restart icinga2

Nun dauert es einen Moment und dann sollten sämtliche Werte und Dienste des Icinga 2 Masters überwacht werden.

Damit verabschiede ich mich auch schon wieder und wünsche wie immer Spass beim basteln!

P.S.: Wem das noch nicht genüge sollte, dem kann ich noch das check_mysql_health in Kombination mit der Icinga 2 IDO auf dem Weg geben.

Max Deparade
Max Deparade
Consultant

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn...
Ansible + Icinga 2 = #monitoringlove

Ansible + Icinga 2 = #monitoringlove

Nein, ich bin nicht auf den Hype als solchen mit aufgesprungen. Es ist nur so… Ansible ist extrem nützlich. Und genau das werde ich anhand eines konkreten Beispiels aufzeigen: Ein Icinga 2 Cluster, vollständig aufgesetzt mit Ansible.

Vorkenntnisse

Wer noch nicht weiß, was zum Geier ein Icinga 2 Cluster und/oder Ansible ist, sollte sich vor dem Weiterlesen entsprechend einarbeiten, am besten im Rahmen einer entsprechenden Schulung in unserem Hause:

Alternativ ginge auch das wesentlich mühseligere Selbststudium:

Umgebung

So ein bisschen sensationell soll der Cluster schon sein, aber mit zunehmenden VMs wird es auch zunehmend eng auf meinem Arbeitsgerät. Wie praktisch, dass wir bei NWS einen OpenStack haben, dem ich mal schnell mit Terraform 14 VMs reindrücken kann (2 Master, 2 Satelliten und 10 Agents):

resource "openstack_compute_instance_v2" "aklimov-icinga2" {
	count = 14
	name = "aklimov-icinga2-${count.index}"
	image_name = "Centos 7"
	flavor_name = "s1.small"
	network { name = "${var.tenant_network}" }
	security_groups = [ "default", "Icinga" ]
	key_pair = "${var.openstack_keypair}"
}

Mit einem kleinen Skript in der Sprache meiner Wahl erstelle ich mir anhand der Terraform-Daten mehr oder weniger automatisch ein Ansible-Inventory (inventory.txt):

aklimov-icinga2-5 ansible_host=10.77.27.54 ansible_user=centos
aklimov-icinga2-4 ansible_host=10.77.27.45 ansible_user=centos
aklimov-icinga2-7 ansible_host=10.77.27.51 ansible_user=centos
aklimov-icinga2-9 ansible_host=10.77.27.40 ansible_user=centos
aklimov-icinga2-12 ansible_host=10.77.27.28 ansible_user=centos
aklimov-icinga2-13 ansible_host=10.77.27.18 ansible_user=centos
aklimov-icinga2-10 ansible_host=10.77.27.12 ansible_user=centos
aklimov-icinga2-1 ansible_host=10.77.27.34 ansible_user=centos
aklimov-icinga2-6 ansible_host=10.77.27.20 ansible_user=centos
aklimov-icinga2-3 ansible_host=10.77.27.49 ansible_user=centos
aklimov-icinga2-11 ansible_host=10.77.27.19 ansible_user=centos
aklimov-icinga2-0 ansible_host=10.77.27.21 ansible_user=centos
aklimov-icinga2-2 ansible_host=10.77.27.46 ansible_user=centos
aklimov-icinga2-8 ansible_host=10.77.27.50 ansible_user=centos

Auf die Plätze, fertig, Ansible!

Zunächst verifiziere ich die Funktionalität der VMs und sammle nebenbei deren öffentliche SSH-Schlüssel ein:

ansible all -i inventory.txt -m ping \
--ssh-common-args='-o StrictHostKeyChecking=no'

Ist das getan, geht es auch schon los mit dem Ansible-Playbook (playbook.yml):

---
- name: Icinga 2
  hosts: all
  become: yes
  become_method: sudo
  tasks:
  - name: EPEL repo
    yum:
      name: epel-release
  - name: Icinga repo key
    rpm_key:
      key: https://packages.icinga.com/icinga.key
  - name: Icinga repo
    yum:
      name: https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm
  - name: Icinga 2 package
    yum:
      name: icinga2
  - name: Monitoring plugins
    yum:
      name: nagios-plugins-all
  - name: Icinga 2 service
    service:
      name: icinga2
      state: started
      enabled: yes
# (...)

Ein paar Repositories, ein paar Pakete – und Icinga ist auch schon einsatzbereit. Fehlt nur noch der eigentliche Cluster:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
  hosts: aklimov-icinga2-0
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone master
      --listen 0.0.0.0,5665
      --cn {{ inventory_hostname }}
      --master
      --disable-confd;
      rm -f /var/cache/icinga2/icinga2.vars
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  - name: /var/cache/icinga2/icinga2.vars
    shell: icinga2 daemon -C
    args:
      creates: /var/cache/icinga2/icinga2.vars
  - name: Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    shell: >
      icinga2 pki ticket --cn {{ item }}
      >/var/cache/icinga2/{{ item }}.ticket
    args:
      creates: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    fetch:
      dest: .tempfiles
      src: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 master cert
    fetch:
      dest: .tempfiles
      src: '/var/lib/icinga2/certs/{{ inventory_hostname }}.crt'
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted
# (...)

Zuerst wird der Knoten eingerichtet, der allen anderen Tickets und später SSL/TLS Zertifikate ausstellt. Dann werden auch schon die Tickets ausgestellt, nachdem /var/cache/icinga2/icinga2.vars dafür neu erstellt wurde. Diese Tickets und das Zertifikat des Knotens werden danach in das Verzeichnis .tempfiles heruntergeladen. Die anderen Knoten brauchen diese Dateien, um sich automatisch an den Cluster anzuschließen:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
# (...)
- name: Icinga cluster nodes
  hosts: 'all:!aklimov-icinga2-0'
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga master cert
    copy:
      dest: /var/cache/icinga2/trusted.crt
      owner: icinga
      group: icinga
      mode: '0644'
      src: .tempfiles/aklimov-icinga2-0/var/lib/icinga2/certs/aklimov-icinga2-0.crt
  - name: Icinga PKI ticket
    copy:
      dest: /var/cache/icinga2/my.ticket
      owner: icinga
      group: icinga
      mode: '0600'
      src: '.tempfiles/aklimov-icinga2-0/var/cache/icinga2/{{ inventory_hostname }}.ticket'
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone {{ inventory_hostname }}
      --endpoint aklimov-icinga2-0,{{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_host {{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_zone master
      --listen 0.0.0.0,5665
      --ticket `cat /var/cache/icinga2/my.ticket`
      --trustedcert /var/cache/icinga2/trusted.crt
      --cn {{ inventory_hostname }}
      --accept-config
      --accept-commands
      --disable-confd
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted

Und ab dafür:

ansible-playbook -i inventory.txt playbook.yml

Voilà!

(...)

PLAY RECAP *******************************************************************************************************
aklimov-icinga2-0          : ok=14   changed=12   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-1          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-10         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-11         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-12         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-13         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-2          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-3          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-4          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-5          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-6          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-7          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-8          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-9          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Jetzt fehlt nur noch die Icinga-Konfiguration. Aber diese überlasse ich keinem geringeren als dem Icinga Director.

Fazit

Was man nicht alles von A bis Z automatisieren kann!

Viel Spaß beim Nachmachen in der NWS Cloud!

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Icinga Web 2 – More Goodies for Developers

Tuesday version 2.7 of Icinga Web 2 has been released and introduced some interesting new functionality for module developers. Now I’d like to tell you, my fellow colleague, some more details about this.

 

jQuery v3 – Migration Required

First a friendly warning. We’ve upgraded the jQuery version we ship to v3.4.1. This has previously been v2.1.0 so now with this major upgrade some deprecated methods and interfaces are gone.

Though, don’t worry, you don’t need to hurry to avoid everyone complaining your module is incompatible with v2.7. We also ship jQuery migrate now which ensures that the usage of removed methods/interfaces still works. It also emits console warnings if it detects such a usage. The warnings are not active by default. They only appear when using the non-minimized javascript code. Put _dev in your address bar to instruct Icinga Web 2 to serve the non-minimized version. (e.g. /icingaweb2/dashboard?_dev)

Then start using the front-end as usual. Interact with all widgets you’ve written your own Javascript for and look for console entries starting with JQMIGRATE. Any of these messages will only appear once, repeated usages are not reported. If you’ve got a warning then, consult jQuery migrate’s warnings.md in order to get hints how to solve it.

jQuery migrate will be removed with Icinga Web 2 version 2.8.0. While this is still some time ahead, this (and the note in the upgrade documentation) is probably the only warning.

 

Persistence and Collapsible Containers

While we’re at it, let’s stay with the topic of Javascript. If you don’t already know about the localStorage and sessionStorage, it’s now time to inform yourself. (That’s an entire blogpost if described thoroughly)

There’s now an abstraction layer for this shipped with Icinga Web 2. It hides all the handling of complex datatypes and conflicts with other apps using the storage from you. That’s the object Icinga.Storage which utilizes the localStorage by default but also supports the sessionStorage. Take a look here to see how this is used for Icinga Web 2’s sidebar.

Though, this is only the basic stuff. If you need to store more complex data and want to benefit from a storage’s event processing, take a look at the object Icinga.Storage.StorageAwareMap. This is a proxy for Map and allows to subscribe to change events of particular keys in the map. It also keeps track of a key’s age and removes it automatically if it hasn’t been accessed for 90 days.

Another new addition are collapsible HTML containers. This is provided by a behavior which makes use of the StorageAwareMap, a perfect example use-case.

Making a container collapsible is as easy as possible. Just apply the CSS class collapsible and you’re done. If you’re not satisfied with the default height, apply the data attribute data-visible-height and give it the desired height in pixels. (For table‘s and ul‘s or ol‘s there is also data-visible-rows.) Then, if you fancy a custom control by which users expand or collapse the container you can pass a CSS selector to data-toggle-element which (if a direct descendant of the container) then acts as the toggle.

 

Custom XHR Without Dirty Hacks

Have you ever wanted/tried to process link clicks or form submissions by yourself? Well, I have and it was a nightmare every single time. Most of Icinga Web 2’s processing is fine. But of course there ever is this single behavior or side-effect which keeps getting in the way. This has now come to an end.

Meet data attribute data-no-icinga-ajax which does exactly what it’s name suggests. Applied to an element it causes Icinga Web 2 to ignore click and submit events triggered by the element itself and all descendants.

Couldn’t be more simple, can it?

 

Hooks For Everyone

Previously hooks were only processed for logged-in users with the permission to access the module providing the hook. This for example prevented the audit module to register logins from users without the permission module/audit and also didn’t allow to log failed logins.

When providing a hook it is now possible to have it run always. ($this->provideHook($name, $implementation = null, $alwaysRun = false);)

Another case of hooks not being processed was the issue that, unlike in the web front-end, enabled modules were not loaded automatically on the CLI. Thus also their hooks were not registered. Now this has changed and also on the CLI all enabled modules are automatically loaded. If you’ve previously loaded the modules explicitly this is not required anymore. If you don’t need any other modules and want to avoid the overhead of loading them, you can disable this of course.

If you still don’t have enough of this, there’s also an entirely new hook available: ConfigFormEventsHook This hook enables you to influence every configuration form of Icinga Web 2. Extending a form’s validation or doing additional work once submission succeeded is now on the table.

 

That’s it. I hope these things are as useful to you as they were to us. And remember, we don’t mind any suggestions to further improve the integration of modules. You are the developer, you’ll know best what’s… best.

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.
DEV stories: Icinga Core trainees in the making

DEV stories: Icinga Core trainees in the making

When my dev leads approached me with the idea to guide a trainee in the Icinga core topic, I was like … wow, sounds interesting and finally a chance to share my knowledge.

But where should I start and how can it be organized with my ongoing projects?

 

Prepare for the unexpected

My view on the code and how things are organized changed quite a bit since then. You cannot expect things, nor should you throw everything you know into the pool. While working on Icinga 2.11, I’ve collected ideas and issues for moving Henrik into these topics. In addition to that, we’ve improved on ticket and documentation quality, including technical concepts and much more.

My colleagues know me as the “Where is the test protocol?” PR reviewer. Also, reliable configuration and steps on reproducing the issues and problems are highly encouraged. Why? The past has proven that little to zero content in ticket makes debugging and problem analysis really hard. Knowledge transfer is an investment in the future of both NETWAYS and Icinga.

Some say, that documentation would replace their job. My mission is to document everything for my colleagues to make their life easier. Later on, they contribute to fixing bugs and implement new features while I’m moving into project management, architecture and future trainees. They learn what I know, especially “fresh” trainees can be challenged to learn new things and don’t necessarily need to change habits.

 

Clear instructions?

At the beginning, yes. Henrik started with the C++ basics, a really old book from my studies in 2002. C++11 is a thing here, still, the real “old fashioned” basics with short examples and feedback workshops prove the rule. Later on, we went for an online course and our own requirements.

Since Icinga 2 is a complex tool with an even more complex source code, I decided to not immediately throw Henrik into it. Instead, we had the chance to work with the Tinkerforge weather station. This follows the evaluation from our Startupdays and new product inside the NETWAYS shop. The instructions were simple, but not so detailed:

  • Put the components together and learn about the main functionality. This is where the “learn by playing” feeling helps a lot.
  • Explore the online documentation and learn how to use the API bindings to program the Tinkerforge bricks and sensors.
  • Use the existing check_tinkerforge plugin written in Python to see how it works
  • Write C++ code which talks to the API and fetches sensor data

Documentation, a blog post and keeping sales updated in an RT ticket was also part of the project. Having learned about the requirements, totally new environment and communication with multiple teams, this paves the way for future development projects.

 

Freedom

In order to debug and analyse problems or implement new features, we need to first understand the overall functionality. Starting a new project allows for own code, experiences, feedback, refactoring and what not. Icinga 2 as core has grown since early 2012, so it is key to understand the components and how everything is put together.

Where to start? Yep, visit the official Icinga trainings for a sound base. Then start with some Icinga cluster scenarios, with just pointing to the docs. This takes a while to understand, so Henrik was granted two weeks to fully install, test and prepare his findings.

With the freedom provided, and the lessons learned about documentation and feedback, I was surprised with a Powerpoint presentation on the Icinga cluster exercises. Essentially we discussed everything in the main area in our new NETWAYS office. A big flat screen and the chance that colleagues stop by and listen or even add to the discussion. Henrik was so inspired to write a blogpost on TLS.

 

Focus on knowledge

In the latest session, I decided to prove things and did throw a lot of Icinga DSL exercises at Henrik, also with the main question – what’s a DSL anyways?

Many things in the Icinga DSL are hidden gems, with the base parts documented, but missing the bits on how to build them together. From my experience, you cannot explain them in one shot, specific user and customer questions or debugging sessions enforce you to put them together. At the point when lambda functions with callbacks were on the horizon, a 5 hour drive through the DSL ended. Can you explain the following snippet? 😘

object HostGroup "hg1" { assign where host.check_command == "dummy" }
object HostGroup "hg2" {
  assign where true
//  assign where host.name in Cities
 }

object Host "runtime" {
  check_command = "dummy"
  check_interval = 5s
  retry_interval = 5s

  vars.dummy_text = {{
    var mygroup = "hg2"
    var mylog = "henrik"
  //  var nodes = get_objects(Host).filter(node => mygroup in node.groups)

    f = function (node) use(mygroup, mylog) {
      log(LogCritical, "Filterfunc", mylog+node.name )
      return mygroup in node.groups
    }
    var nodes = get_objects(Host).filter(f)

    var nodenames = nodes.map(n => n.name)
    return nodenames.join(",")
   // return Json.encode(nodes.map(n => n.name))
  }}

}

We also did some live coding in the DSL, this is now a new howto on the Icinga community channels: “DSL: Count check plugin usage from service checks“. Maybe we’ll offer an Icinga DSL workshop in the future. This is where I want our trainees become an active part, since it also involves programming knowledge and building the Icinga architecture.

 

Code?

Henrik’s first PR was an isolated request by myself, with executing a check in-memory instead of forking a plugin process. We had drawn lots of pictures already how check execution generally works, including the macro resolver. The first PR approved and merged. What a feeling.

We didn’t stop there – our NETWAYS trainees are working together with creating PRs all over the Icinga project. Henrik had the chance to review a PR from Alex, and also merge it. Slowly granting responsibility and trust is key.

Thanks to trainees asking about this, Icinga 2 now also got a style guide. This includes modern programming techniques such as “auto”, lambda functions and function doc headers shown below.

/**
 * Main interface for notification type to string representation.
 *
 * @param type Notification type enum (int)
 * @return Type as string. Returns empty if not found.
 */
String Notification::NotificationTypeToString(NotificationType type)
{
	auto typeMap = Notification::m_TypeFilterMap;

	auto it = std::find_if(typeMap.begin(), typeMap.end(),
		[&type](const std::pair<String, int>& p) {
			return p.second == type;
	});

	if (it == typeMap.end())
		return Empty;

	return it->first;
}

 

 

Learn and improve

There are many more things in Icinga: The config compiler itself with AST expressions, the newly written network stack including the REST API parts, feature integration with Graphite or Elastic and even more. We’ll cover these topics with future exercises and workshops.

While Henrik is in school, I’m working on Icinga 2.11 with our core team. Thus far, the new release offers improved docs for future trainees and developers:

This also includes evaluating new technologies, writing unit tests and planning code rewrites and/or improvements. Here’s some ideas for future pair programming sessions:

  • Boost.DateTime instead of using C-ish APIs for date and time manipulation. This blocks other ideas with timezones for TimePeriods, etc.
  • DSL methods to print values and retrieve external data
  • Metric enhancements and status endpoints

 

Trainees rock your world

Treat them as colleagues, listen to their questions and see them “grow up”. I admit it, I am sometimes really tired in the evening after talking all day long. On the other day, it makes me smile to see a ready-to-merge pull request or a presentation with own ideas inspired by an old senior dev. This makes me a better person, every day.

I’m looking forward to September with our two new DEV trainees joining our adventure. We are always searching for passionate developers, so why not immediately dive into the above with us? 🙂 Promise, it will be fun with #lifeatnetways and #drageekeksi ❤️

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Sommerhitze & Powershell 3 kleine Tipps

Hallo Netways Follower,

Ich melde mich dies mal mit einem kurzen aber meist vergessenen Thema nämlich wie kriegt man unter Windows diese vermaledeiten Powershell Skripts korrekt zum laufen.

Wenn man bei einem normalen Icinga2 Windows Agenten diese in ‘Betrieb’ nehmen will benötigt es etwas Handarbeit und Schweiß bei diesen Sommertagen um dies zu bewerkstelligen.

Trotzdem hier ein paar Tipps:

1) Tipp “Powershell Skripte sollten ausführbar sein”

Nachdem der Windows Agent installiert und funktional ist sollte man sich auf der Windows Maschine wo man das Powershell Skript ausführen möchte in die Powershell (nicht vergessen mit Administrativer Berechtigung) begeben.

Um Powershell Skripts ausführen zu können muss dies erst aktiviert werden dazu gibt es das folgende Kommando

Set-ExecutionPolicy Unrestricted
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Restricted

Hier sollte zumeist RemoteSigned ausreichend sein, aber es kommt wie immer auf den Anwendungsfall an. More Info here.

Nach der Aktivierung kann man nun überprüfen ob man Powershell Skripts ausführen kann.
Hierzu verwende ich meist das Notepad um folgendes zu schreiben um anschließend zu prüfen ob das oben aktivierte auch klappt.

Also ein leeres Windows Notepad mit dem folgenden befüllen:

Write-Host "Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul. "

Das ganze dann als ‘test.ps1’ speichern.

Nun wieder in die Powershell zurück und an dem Platz wo man das Powershell Skript gespeichert hat es mit dem folgenden Kommando aufrufen.
PS C:\Users\dave\Desktop> & .\test.ps1
Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

Sollte als Ergebnis angezeigt werden damit Powershell Skripts ausführbar sind.

2) Tipp “Das Icinga2 Agent Plugin Verzeichnis”

In der Windows Version unseres Icinga2 Agents ist das standard Plugin Verzeichnis folgendes:
PS C:\Program Files\ICINGA2\sbin>

Hier liegen auch die Windows Check Executables.. und ‘.ps1’ Skripte welche auf dem Host ausgeführt werden sollten/müssen auch hier liegen.

3) Tipp “Powershell 32Bit & 64Bit”

Wenn ein Skript relevante 64Bit Sachen erledigen muss kann auch die 64er Version explizit verwendet werden in den Check aufrufen.

Das heißt wenn man den object CheckCommand “Mein Toller Check” definiert kann man in dem Setting:

command = [ "C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe" ] //als 64 Bit angeben und
command = [ "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" ] // als 32Bit.

Hoffe die drei kleinen Tipps erleichtern das Windows Monitoring mit Powershell Skripts.
Wenn hierzu noch Fragen aufkommen kann ich unser Community Forum empfehlen und den ‘kleinen’ Guide von unserem Kollegen Michael. Icinga Community Forums

Ich sag Ciao bis zum nächsten Mal.

David Okon
David Okon
Support 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...