Computer Viren in der Cloud

Verschiedene Anbieter von Anti-Virus Produkten bieten mittlerweile SaaS Platformen an um eine zentrale Übersicht über den Status aller Systeme zu bekommen. Dort wird dann neben allen Details eine Übersicht von Alarmen bzw. Bedrohungen verfügbar.

Ein Kunde stellte mich vor die Herausforderung aus diesen Platformen per API die aktuellen Alarme und Probleme abzufragen, daraus sind zwei neue Plugins entstanden.

Hinweis: Wir machen hier keine Werbung für die Produkte, nur unsere Plugins. Wir stehen aktuell in keiner Geschäftsbeziehung zu beiden Anbietern.

(mehr …)

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

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 2 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 | Nürnberg | 27.-28. Oktober 2020 | 9 – 17 Uhr
Elastic Stack | München | 24.-26. November 2020 | 9 – 17 Uhr

 

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

 

AUTOMATION TRAININGS

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

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

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

 

DEVELOPMENT TRAININGS
GitLab 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!

Jessica Kupfer
Jessica Kupfer
Online Marketing Manager

Jessica ist seit September 2020 bei NETWAYS dabei und freut sich unglaublich darüber! Unser Marketing Team bereichert sie mit ihrem Wissen über Social Media und Performance Marketing. Nach 3 Jahren als Au Pair in Boston, L.A. und London und weiteren 6 Jahren in Wien, hat es die gebürtige Saarländerin mit ungarischen Wurzeln nun nach Nürnberg verschlagen. In ihrer Freizeit besucht sie Freunde & Familie, reist gerne und ergreift jede sich bietende Chance, Hunde und Katzen...
Monthly Snap August 2020

Monthly Snap August 2020

August was the hottest month of the year. A fact that was met with mixed emotions at the NETWAYS HQ. Some colleagues were complaining and swearing and planning trips to the north pole, while others were walking around with a smile, enjoining the summer sun. And who stayed calm throughout it all? Our data centers! Yes, monitoring sometimes really is everything.

The Shop has it all!

What do you need for monitoring your data centers? Humidity- and temperature-sensors? Or water-leak detectors? How do you want to be alerted? The NETWAYS Shop can definitely help you on this subject. Here are some of the topics the Shop treated in August, in addition to your orders of course!
Natalie gave us the details of the new SMSEagle update in SMSEagle: Das Update ist da. What to do after unboxing your SMSEagle? Read Nicoles` tipps and get started! Kickstarter: SMSEagle NXS-9700 4G und NXS-9750 4G. And the second part of the Kickstarter series was Nicoles` Kickstarter: HW group STE2 R2 PoE. Nicole also proudly announced that you can now book the STARFACE Cloud directly from us! STARFACE Cloud – jetzt bei uns buchbar!

News from our Webinars

Our Webinar-Master Christian has simplified the access to our webinars and explained why it makes sense to follow our YouTube channel in NETWAYS Webinare 3.0 und Kubernetes mit Thomas-Krenn.

Nextcloud

A good cooperation with Nextcloud led to more, and NETWAYS is now an official partner! Pamela wrote about the process in NETWAYS ist offizieller Nextcloud-Partner

Always consulting 

Christoph tested a new tool and shared his findings with us in tooltip httrack. Dirk does a lot of planning and teaching in our apprenticeship-program and let us in on the news regarding IT apprenticeships in Die Neuordnung der IT-Ausbildungsberufe und wir. And Daniel wrote down his path to sorting Ansible groups in Ansible Host-Gruppen: Wer gehört zu wem? Meanwhile David was working from home when suddenly his computer didn`t work anymore. He shared a few ideas on using tools available to still be able to work in GTD ohne Equipment. Lorenz took a closer look at alerting witch Icinga, and let us in on the advantages of XMPP in Zurück in die Zukunft: Icinga2-Benachrichtigungen mit XMPP

OSMC 2019

In our blog series OSMC 2019 | Recap, we present last years talks. Afeef has summarized Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments by Francesco Cina & Patrick Zambelli | OSMC 2019.

 

Kubernetes

Part 8 of our series Kubernetes – so startest Du durch! is Logging mit Loki und Grafana in Kubernetes in which Achim explained why some might prefer to log with Loki. Moumen taught us some tricks in GitLab – Merge Requests, and he also showed us how to display all users in a MySQL project in Alle User in MySQL anzeigen.

 

#lifeatnetways

In our blog series NETWAYS stellt sich vor you can get to know our great team a little better. This month read about Lorenz, Michael, Dominik and Saeid!

Catharina Celikel
Catharina Celikel
Office Manager

Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.

Windows: One Framework to Monitor them all by Christian Stein | OSMC 2019

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

 

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Christian Stein captivated the entire conference room with his presentation “Windows: One Framework to Monitor them all”. His demo was the highlight of his presentation, which ended up with enthusiastic applause. You have missed him speaking? We have got something for you: Watch the video of Christian’s presentation and read a short summary (below).

At OSMC international monitoring experts meet annually to set and discuss future trends and objectives. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and are ready to answer your hardest questions. Discuss with top developers, exchange knowledge and learn wen techniques.

You want more? 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 and tickets at osmc.de.


Windows: One Framework to Monitor them all

Christian Stein signed up with a talk titled “Windows: One Framework to Monitor them all” and the intention to turn the Windows side of Icinga upside down. After giving a short run down of the the current issue with “Icinga for Windows” and his attempts at fixing them, we get to the good stuff.

An Icinga PowerShell Framework supported by Powershell 4.0 or higher, but let‘s get into the juicy details: The framework comes with a lot of features, to easily extend it within your environment and to simplify monitoring on Windows as well. Additionally, there is a dev-toolkit, which offers plenty of possibilities for developers to give the framework their own tweak. As of now, there are four repositories beyond the framework itself. Up first and most important to mention is icinga-powershell-kickstart, which provides a basic PowerShell script to interactively install the framework. Also rather essential for the framework is the icinga-powershell-plugins repository, which provides a collection of Windows check plugins.

Want to run the framework as a service? Glad you asked. There is a repository for that as well. It’s also covered by the kickstart wizard. Check icinga-powershell-service to find out more or to give some feedback. If you’ve always asked yourself why you should run appliances as a service, there are several benefits. Like the service running before a user logs on and continuing to run, without a logged on user.

Last but not least, even most essential, the framework itself. If we look at the current ways to make Icinga work on windows, they are good, but not great. The icinga-monitoring-framework provides tools and configuration to make icinga monitoring on windows possible, almost natively, except for said repositories.

Having said all that and more, Christian went on with a live demo of the Framework, gave some installation advice and by that I mean, delved deeper into the kickstart script. He also showed off some features and gave some best practice advice. So, all that was left to say is… whats next?

Christian announced, that it will be available on PowerShell Gallery, which will not only help the project grow, but make it even more available as is. And of course, there will be more plugins. For those eagerly waiting for one of these, the next release hopefully provides MSSQL, Active-Directory, Exchange and Hyper-V plugins.

The community’s and the customer’s interest in better windows monitoring is undeniable, but we depend on your feedback and support on this, the respective repository is the place to be, and if you can’t figure, which one it fits, just post your issue at: https://github.com/Icinga/icinga-powershell-framework/issues

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

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
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.