It is always the same, Winter is coming and it brings people to Nuremberg for OSMC. Our Open Source Monitoring conference still grows every year and after giving three parallel tracks a try last year, we changed format again to include also shorter talks and having always three tracks. It also gets more international and topics get more diverse, covering all different monitoring solutions with speakers (and attendees) from all over the worlds. Like every year also the 13th conference started with a day of workshops enabling the interested ones to get hands on Prometheus, Ansible, Graylog and practical example on using the Puppet modules for Icinga 2. Also this year two days of great talks will be followed by a day of hacking and the second issue of the Open Source Camp takes place, this time focusing on Puppet.
And another tradition is Bernd starting the conference with a warm welcome before the first talk. Afterwards Michael Medin talked about his journey in monitoring and being a speaker at OSMC for the eleventh time in „10 years of OSMC: Why does my monitoring still look the same?„. It was a very entertaining talk comparing general innovation with the one happening in monitoring. He was showing up that monitoring solutions changed to reflect the change in culture but still stayed the same mechanism and explained all the problems we probably know like finding the correct metrics and interpreting them resulting from this.
Second talk I attended was „Scaling Icinga2 with many heterogeneous projects – and still preserving configurability“ by Max Rosin. He started with the technical debt to solve and requirements to fulfill when migrating from Icinga 1 to Icinga 2 like check latency or 100% automation of the configuration. Their high-available production environment had no outage since going live in January, because the infrastructure design and testing updates and configuration changes in a staging setup, what is pretty awesome. The scripting framework they created for the migration will be released on Github. But this was not all they coded to customize their environment, they added some very helpful extensions for the operations team to Icinga Web 2, which will be available on Github somewhere in the future after separating company specific and upstream ready parts.
For the third session I had chosen Matthias Gallinger with „Netzwerkmonitoring mit Prometheus“ (Network monitoring with Prometheus). In his case study he showed the migration from Cacti to Prometheus and Grafana done at a international company based in Switzerland. The most important part is here the SNMP Exporter for Prometheus including a generator for its configuration. All required is part of their labs edition of Open Monitoring Distribution (OMD).
After the lunch Serhat Can started with „Building a healthy on-call culture„. He provided and explained his list of rules which should create such a culture: Be transparent – Share responsibilities – Be prepared – Build resilient and sustainable systems – Create actionable alerts – Learn from your experiences. To sum up he tells everyone to care about the on-call people resulting in a good on-call service and user experience which will prevent a loss of users and money.
The Director of UX at Grafana Labs David Kaltschmidt gave an update on whats new and upcoming in Grafana focusing on the logging feature in „Logging is coming to Grafana„. The new menu entry Explore allows to easily querying Prometheus metrics including functions – just one click away – for rate calculation or average and it works the same for logging entries as a new type of datasource. This feature should be very useful in a Kubernetes environment to do some distributed tracing. If you are interested in this feature it should be available as beta in December.
„Distributed Tracing FAQ“ was also the title of Gianluca Arbezzano’s talk. I can really recommend his talk for the good explanation on why and how to trace requests through more and more complex, distributed services of nowadays. If you are more interested in tool links, he recommends Opentracing as library, Zipkin as frontend and of course InfluxDB as backend.
This year Bernd’s talk about the „Current State of Icinga“ was crowded and interesting as always. I skip the organizational things like interest in the project is growing according to website views, customers talking about their usage, partners, camps and meetups all over the world. From the technical aspects Icinga 2 had a release bringing more stabilization, improved Syntax Highlighting and as new feature Namespacing. The coming Director release brings support for multiple instances helping with staging, health checks and a configuration basket allowing to easily export and import configuration. A new Icinga Web 2 module X509 helps managing your certificate infrastructure, available next week on github. The one for VMware vSphere (sponsored by dmTECH) is already released and was shown in a demo by Tom who developed it. Icinga DB will replace IDO as a backend moving volatile data to Redis and data to be keeped will be stored to MySQL or PostgreSQL and there will also be a new Monitoring Module for Icinga Web 2 to make use of it, all available hopefully in two weeks.
This year’s OSMC provided something special as the last talk of the first day with an authors‘ panel including Marianne Spiller (Smart Home mit openHAB 2), Jan Piet Mens (Alternative DNS Servers – Choice and deployment, and optional SQL/LDAP back-ends), Thomas Widhalm and Lennart Betz (Icinga 2 – Ein praktischer Einstieg ins Monitoring) moderated by Bernd and answering questions from the audience.
If you want to get more details or pictures have a look at Twitter. There will also be a post by Julia giving a more personal view on the conference from interviewing some attendees and one of me covering the talks of the second day, but now I am heading for the evening event.
NETWAYS Blog
NETWAYS Webinare – Jetzt mit OpenStack !
Wieder einmal mehr haben wir an unserem Webinar Kalender geschraubt – diesmal möchten wir euch etwas über OpenStack erzählen.
Anbei gibt es hier einmal die aktuelle Webinar Liste im Überblick:
- Icinga 2: Templates und Service-Sets mit dem Icinga Director (10. Oktober um 10:30 Uhr)
- OpenStack: Infrastructure Hosting by NETWAYS (17. Oktober um 10:30 Uhr)
- Icinga 2: Anbinden von externen Satelliten (24. Oktober um 10:30 Uhr)
- Icinga 2: Alarmierung mit NoMa 2 (14. November um 10:30 Uhr)
- Icinga 2: Monitoring für Windows (05. Dezember um 10:30 Uhr)
- Icinga 2: Integration von Rocket.Chat und Request Tracker (12. Dezember um 10:30 Uhr)
Selbstverständlich werden wieder alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht.
Ich freue mich wie immer auf eine rege Teilnahme und die Webinare!
Die Extrawurst
Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.
Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.
Zusätzliche Gruppen für jeden
Einmal installiert, lassen sich in der config.ini
des Moduls flexible Regeln definieren.
[Jeder ist ein Mimimi]
add_groups = "Mimimi"
Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini
eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:
[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"
Sobald wir uns neu anmelden sind wir Mitglied der Gruppe „Mimimi“ und sehen nur noch Hosts welche „mi“ enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens „Mimimi“ existiert oder nicht.
Mustervergleich mit Benutzernamen
Lasst uns das Ganze ein wenig einschränken:
[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"
Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.
Regeln basierend auf Umgebungsvariablen
Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:
[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"
Ähnlich wie REMOTE_ADDR
in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:
[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"
VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.
Mehrere Gruppen zuweisen
Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups
akzeptiert eine Komma-getrennte Liste:
[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"
Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME}
nutzen:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:
[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"
Auf Gruppenmitgliedschaften basierende Regeln
Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS
. Na gut, jeder außer der guest
und der admin
-Benutzer.
Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.
Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen „Linux Benutzer“ und/oder „Unix Benutzer“ in die Gruppe „Nagstamon Lokal“ kommen. Alle außer dem admin:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"
[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"
[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"
Dabei gilt es zu beachten, dass der Filter basierend auf die group
-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.
Das war’s auch schon, viel Spaß!
March Snap 2018 > OSBConf2018, Icinga 2 Book Reloaded, OS Monitoring, OSDC, NETWAYS Monitoring
Hello Sunshine!! Blerim shared the most important things to consider while writing „the impact of voice and tone in writing“. Then followed Systemd- Unitfiles and Multi-Instanz- Setups by Dirk, Isabel ’s news on NETWAYS Monitor for Temperature and humidity, Keya’s insights on the Ceph training and Nicole`s stories about NETWAYS Web Services: Meet and greet at Icinga Camp Berlin 2018.
Here is the checklist to be a speaker at the OSBConf2018 and early bird discount said Keya. Marius let us know that Gitlab now supports Let’s Encrypt. Gunnar showed us how to play in the cloud. Killian talked about server maintenance for colleagues. Keya announced the NETWAYS upcoming April Trainings. Johannes taught us RT Extensions Made Easy. Lennart announced Icinga 2 Book Reloaded. Let’s talk about OS Monitoring said Keya. Philips Brilliance 258B6 and macOS were brought to us by Tim. Markus talked about MSSQL databases from Icinga Web 2. Daniel reported on Elastic {ON} 2018 Travel Report and Review.
Icinga Director: Active Directory User als Kontakte importieren
Heute erklären wir euch im Schnelldurchlauf wie man Kontakte aus dem Active Directory in den Icinga Director importiert.
Als Grundlage konfigurieren wir das Active Directory als Ressource im Icinga-Web 2
# vi /etc/icingaweb2/resources.ini
[active_directory]
type = "ldap"
hostname = "ms-ad.supercorp.com"
port = "389"
encryption = "none"
root_dn = "DC=supercorp,DC=com"
bind_dn = "CN=bind_user,OU=Users,DC=supercorp,DC=com"
bind_pw = "*******"
Danach muss der Import im Icinga Director erstellt werden. Dazu geht ihr im Icinga Director auf Automation => Import Source => Add und legt den Import wie folgt an:
Wichtig ist hierbei der LDAP Filter mit mail=*. Dadurch werden nur Benutzer importiert die auch eine E-Mail-Adresse haben. Bei Benutzern ohne E-Mail-Adresse würde der spätere Sync fehlschlagen.
Im Anschluss erstellt ihr den dazu passenden Sync unter Automation => Sync Rule => Add
Die Customvariable var.import wird zwar nicht zwingend benötigt, ich verwende sie aber um später die Möglichkeit zur Filterung zu haben. So kann man (neben der History Funktion) erkennen ob ein Kontakt manuell oder vom Import angelegt worden ist.