Seite wählen

Ergebnisse für " icinga 2 "

Benachrichtigungen mit Icinga 2 mal anders

Vor Kurzem stand ich im Rahmen eines Kundentermins vor der Anforderung noch die Benachrichtigungen für das Icinga 2 Setup umzusetzen. „Soweit kein Problem“ dachte ich mir, allerdings war die genaue Anforderung dann doch etwas speziell: Sowohl bei Hosts als auch bei Services können SLA’s gesetzt werden („gold“, „silver“ oder „bronze“). Wenn bei einem Service kein SLA gesetzt ist, greift das Servicelevel des Hosts. Hier der erste Entwurf dazu:

apply Notification "host-mail-gold" to Host {
  import "mail-host-notification"

  period = "gold"
  users = host.vars.contacts

  assign where host.vars.sla == "gold"
}

apply Notification "service-mail-gold" to Service {
  import "mail-service-notification"

  period = "gold"
  users = service.vars.contacts

  assign where (host.vars.sla == "gold" && ! service.vars.sla) || (service.vars.sla == "gold")
}

mehr lesen…

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Komm‘ nach Nürnberg für Deinen Icinga 2 Deep Dive!

Du hast bereits den Einsteigerkurs „Icinga 2 Fundamentals“ bei uns belegt bzw. besitzt Monitoring-Grundkenntnisse? Sehr gut. Nun möchtest Du Dein Fachwissen auf diesem Gebiet weiter vertiefen, Dir weitere praktische Kenntnisse aneignen? Perfekt! Dann ist der Icinga Director Workshop genau das Richtige für Dich!
Am 20. und 21. Oktober 2020 erwartet Dich von jeweils 9 – 17 Uhr in Nürnberg eine geballte Ladung an:

  • Grundlagenwissen zu Hostobjekten, Vorlagen für Hosts und Services, Verwendung von Apply-Regeln, Service Sets uvm.
  • Installation und Konfiguration des Directors und einer Beispiel-Umgebung, bestehend aus Icinga Master, Satellite und Agenten auf Linux und Windows zur Überwachung
  • Automatischer Import aus verschiedenen Quellen: Dateiebene und SQL-Datenbank

Nach dem zweitägigen Workshop bist Du also fit darin, Deine Icinga Konfiguration mit Hilfe des webbasierten graphischen Userinterface zu erstellen. Außerdem meisterst Du die Automatisierung von Aufgaben mit dem Icinga Director. Klingt nicht nur super, das ist es auch! Und das beste ist: Wir teilen nicht nur unser versiertes Fachwissen mit Dir, sondern auch Kekse – also sei dabei! Hier geht’s zur Anmeldung. Solltest Du nicht aus Nürnberg kommen und Hilfe bei der Suche nach einer passenden Unterkunft für diesen Zeitraum benötigen, dann unterstützen wir Dich gerne – melde dich einfach bei uns!

Neben dem Icinga Director Workshop stehen in den kommenden Monaten auch noch weitere Trainings aus anderen Fachbereichen an:

 

MONITORING TRAININGS
Icinga Schulung (Fundamentals) | Online | 1.-4. Dezember 2020 | 9-17 Uhr
Icinga 2 Advanced | Nürnberg | 8.-10. Dezember 2020 | 9 – 17 Uhr

 

LOGGING & METRICS TRAININGS
Graylog Schulung | Nürnberg | 27.-28. Oktober 2020 | 9 – 17 Uhr
Elastic Stack Schulung | München | 24.-26. November 2020 | 9 – 17 Uhr

 

ADMINISTRATION TRAININGS
Linux Schulung (Basics) | Nürnberg | 27.-29. Oktober 2020 | 9 – 17 Uhr
PostgreSQL Schulung (Fundamentals) | Nürnberg | 1.-3. Dezember 2020 | 9 – 17 Uhr
PostgreSQL Advanced | Nürnberg | 15.-18. Dezember 2020 | 9 – 17 Uhr

 

AUTOMATION TRAININGS

Ansible Schulung | Online | 13.-15. Oktober 2020 | 9 – 17 Uhr

Ansible Tower | Online | 16. Oktober | 9 – 17 Uhr
Puppet Schulung (Fundamentals) | Online | 20.-22. Oktober | 9 – 17 Uhr

Foreman Schulung | Nürnberg | 1.-2. Dezember | 9 – 17 Uhr
Terraform Schulung | Online | 8.-9. Dezember 2020 | 9 – 17 Uhr

 

DEVELOPMENT TRAININGS
GitLab Schulung (Fundamentals) | Online | 27.-28. Oktober 2020 & Nürnberg | 15.-16. Dezember 2020 | 9 – 17 Uhr

 

Wir bieten Trainings an, die sowohl online, als auch vor Ort stattfinden. Also, egal, ob virtuell oder IRL – wir freuen uns auf Dich und den gemeinsamen Austausch!

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments by Francesco Cina & Patrick Zambelli | OSMC 2019

This entry is part 3 of 4 in the series OSMC 2019 | Recap

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Francesco Cina and Patrick Zambelli whirled up a „Tornado – Extend Icinga 2 for active and passive Monitoring of complex heterogeneous IT Environments”. If you missed their presentation: See the video of their introduction to Tornado and its use cases, and read a summary (below).

The OSMC is the annual meeting of international monitoring experts, where future trends and objectives are set. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and be ready to answer your hardest questions. Learn new techniques, exchange knowledge and discuss with top developers.

In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.
More information at osmc.de.


 

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments

Monitoring Challenges: Pool vs. Event.

First of all we have to explain the difference between Pool and Event approach. Icinga and nagios use the polling approach, which is scheduling monitoring or checks in a static time interval to get a specific state. You can derive from this state if the status from monitored device or service is critical or ok. That means, we know not only the results of monitoring but also the monitored systems. By Polling we have centralized configuration and control. This will be performed either agentless e.g. SHH, SNMP or through an agent for example Icinga, NSClient++.

Contrarily to this historical approach is the event based approach. On the one side we accept the matrix all the time from the remote system and we don’t know exactly what will come, but on another side we have to understand the incoming protocol and derive if there is a problem or not.

 

Advantages and disadvantages of polling and event:

Polling Pros

  • Control when a check should be executed
  • Get only the data which you are interested in
  • Knowing the context from the system you are interacting with (context = host, service, performance data)

Polling Cons

  • Static configuration for monitored architecture (not good for a changeable one e.g. micro services)
  • Continuously usage of resources day and night
  • Not all data is retrievable via polling

 

Event Pros

  • No delay to react when event happens
  • No need to know what to receive but understand it
  • Dynamic on fast changing architecture
  • Listen to channel => new added hosts are integrated

Event Cons 

  • Need to face large amount of data (peaks)
  • Lack for filtering at source. We can lose information specially when the protocol is not reliable e.g. UDP or SNMP
  • Risk to lose information
  • Not the right approach for host alive and service availability  

Combination of both Polling (Icinga 2) and event (Tornado) will definitive a winning:

With Icinga 2 we have the advantage to start a project very quickly and easily. We have a wide range of checks in the community. Through Templates we can create a reusable monitoring. We can adapt to changes in the architecture by interacting with CMDB or domain controller for example.

With Tornado we listen on the monitored host to the output of a service on a specific channel then we convert this output via collector to Json, which is the only recognized language by Tornado. After that we compare the flow with by regular expression created rules. In the end we forward an action to Icinga 2 – “Critical” for example. 

That means, when our infrastructure grows with new hosts we can monitor the availability from these hosts and their services with Icinga 2. We can control the output from services with Tornado.

 

How to handle the increased load?

01. Scale the monitoring system horizontally

When our servers and services grow, we can increase the number of monitoring instances. This is not good because it doesn’t work out of the box and too many problems will appear. Moreover the throughput does not go linearly. At a number of scaled nodes the overhead of communication and sycronization between them will take more time than analyzing the traffic itself.

02.  Use a big data system

We put a big data system between events and the monitoring system, for example kafka, spark, cassandra. The idea is, we reprocess the messages or the events and send only the important ones to the monitoring system. In this way we will reduce the flow against our monitoring system. This will definitely lead to reduce the load as well. It is a real solution but terribly expensive and needs a lot of knowledge with the used data system.

03. Tornado

Why is Tornado the solution?

  • Can handle millions of events per second per CPU
  • Stateless: the nodes don’t need to communicate to each other
  • Cloud-ready
  • Has collectors which translate events from format X to Tornado format (Json)
  • Take decision based on the event content
  • Cheap because it doesn’t need too much resources 

Tornado decides to pass the events to Icinga when they match the pipelines and the rules we defined in Tornado. Not suitable events will be dropped.

 

You liked this blog post and want to read more about different monitoring solutions? Then browse through our blog series, visit our YouTube channel or just contact us.

 

Afeef Ghannam
Afeef Ghannam
Systems Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kolleg:innen im Operations Team der NETWAYS Professional Services bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Zugangsdaten und globale Variablen in Icinga 2

Viele Kunden fragen mich, wie man zentral Zugangsdaten oder allgemeine Variablen in Icinga 2 verwalten kann. Icinga 1.x und Nagios hatte für solche Zwecke die resources.cfg, dort wurden zentrale Macros wie $USER1$ usw. konfiguriert.

Nun hat Icinga 2 einen relativen ähnlichen Mechanismus, mit dem man an einer zentralen Stelle globale Konstanten bzw. Variablen speichern kann. Dann können diese überall in der Konfiguration benutzt werden. Aber leider nicht als Macro, was die Verwendung mit dem Director etwas schwieriger macht.

Aber dafür gibt es Abhilfe, auch dafür pflegen wir die Werte in der /etc/icinga2/constants.conf

const GlobalVars = {
  OracleDbUser = "svcicinga"
  OracleDbPassword = "hunter2"
}

Nun fehlt noch eine kleine Konfiguration, damit diese Variablen auch überall verfügbar sind, dazu bearbeiten wir die Datei /etc/icinga2/conf.d/app.conf und die IcingaApplication.

object IcingaApplication "app" {
  vars = GlobalVars
}

Jetzt sind die Variablen überall auch als Macro verfügbar.

vars.oracle_health_username = "$OracleDbUser$"
vars.oracle_health_password = "$OracleDbPassword$"

Ich wünsche viel Spaß beim Ausprobieren, und hoffentlich ruhige Feiertage und einen guten Rutsch ins Jahr 2020!

Bildrechte: Wikimedia Commons – von Psyomjesus

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
Senior 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 Arbeit an Icinga Web 2 bei uns friedliche Wege.