This entry is part 8 of 27 in the series stackconf online 2021
NETWAYS Blog
Hier erfährst Du alles was uns bewegt. Technology, Hardware, das Leben bei NETWAYS, Events, Schulungen und vieles mehr.
Revisited – Graphite-Web installation unter Debian 9
Graphite-Web install Guide Debian 9 (Stretch)
Secure Elasticsearch and Kibana with an Nginx HTTP Proxy
Elasticsearch provides a great HTTP API where applications can write to and read from in high performance environments. One of our customers sponsored a feature for Icinga 2 which writes events and performance data metrics to Elasticsearch. This will hit v2.8 later...
DevOpsDays 2017 | Berlin, Berlin, wir fahren nach Berlin!
Bald geht’s los zum 2. Hauptstadtevent in diesem Jahr! Am 18.+19. Oktober gehen die DevOpsDays in die nächste Runde! Und NETWAYS darf wieder bei der Organisation unterstützen! Als Unterstützung im kaufmännischen Bereich sind wir nun schon mehrere Jahre dabei und das...
Lösungen & Technology
Linux Kernel first meta block group too large
Das Thema von Spectre und Meltdown hat uns ebenfalls gut beschäftigt, aber heute wollen wir nicht darüber reden. Viel mehr gehen wir auf einen Bug im Linux Kernel ein, welcher uns bei den Upgrade-Aktionen über den Weg gelaufen ist und zuerst für Verwirrung sorgte. Im...
Linux Kernel first meta block group too large
Das Thema von Spectre und Meltdown hat uns ebenfalls gut beschäftigt, aber heute wollen wir nicht darüber reden. Viel mehr gehen wir auf einen Bug im Linux Kernel ein, welcher uns bei den Upgrade-Aktionen über den Weg gelaufen ist und zuerst für Verwirrung sorgte. Im...
Linux Kernel first meta block group too large
Das Thema von Spectre und Meltdown hat uns ebenfalls gut beschäftigt, aber heute wollen wir nicht darüber reden. Viel mehr gehen wir auf einen Bug im Linux Kernel ein, welcher uns bei den Upgrade-Aktionen über den Weg gelaufen ist und zuerst für Verwirrung sorgte. Im...
JavaScript Memory Leaks mit Chrome lokalisieren
JavaScript ist ja bekanntlich eine Sprache, die ihre Speicherverwaltung an einen Garbage Collector übergibt und dem Programmierer hier ein weitgehend unbeschwertes Leben verschafft. Meistens.
Wer bereits in anderen GC-basierten Laufzeitumgebungen wie Java programmiert hat, der weiß sicher dass auch ein Garbage Collector Memory Leaks in manchen Fällen nicht verhindern kann wenn der Programmierer unachtsam ist. Sobald ein Objekt nämlich noch in einem aktiven Bereich referenziert wird, bleibt er bis zum entfernen dieser Referenz im Heap (immerhin besteht die Möglichkeit, dass man das Objekt noch verwendet). Das Gute: Die meisten Memory Leaks sind so unbedeutend, dass man sie getrost ignorieren kann. Kritisch wird es erst, wenn man viele größere Objekte (z.B. DOM Knoten) über einen langen Zeitraum erstellt und entfernt, auf die aber noch in irgendwelchen Codeecken verwiesen wird (z.B. in einem Array). Dann gibt es auch in JavaScript irgendwann eine OutOfMemoryException – und ohne die richtigen Tools ist deren Ursache schwer aufzufinden (immerhin kann der Bereich z.b. in einem Closure liegen).
Abgeschaltete Blacklist führt zu vermehrten False-Positive Filterungen
Vor Zwei Wochen hatten wir den Fall, dass ungewöhnlich viele Mails auf unserem Mailsystem herausgfiltert wurden. Ein Blick in das Logfile verriet, dass die Mails wegen zu hoher Bewertung als Spam eingestuft und nicht zugestellt wurden. Ungefähr so sah das dann in den...
Umweltüberwachung und Alarmierungen via SMS – so geht's
Oft bekommen wir von unseren Kunden die Anforderung an entfernten Standorten Umweltparameter zu überwachen und diese zu alarmieren - am besten auch per SMS. Nichts leichter als das! Wir bieten verschiedene Möglichkeiten für verschiedenste Anforderungen, so geht es von...
Events & Trainings
Foreman's 8th birthday – We will give a party
After the success last year we decided to celebrate the 8th Birthday of the Foreman Project again at event room Kesselhaus on July, 27th. As feedback was very good about the provided content we decided to provide the same schedule. We will start right after lunch at...
Foreman's 8th birthday – We will give a party
After the success last year we decided to celebrate the 8th Birthday of the Foreman Project again at event room Kesselhaus on July, 27th. As feedback was very good about the provided content we decided to provide the same schedule. We will start right after lunch at...
Foreman's 8th birthday – We will give a party
After the success last year we decided to celebrate the 8th Birthday of the Foreman Project again at event room Kesselhaus on July, 27th. As feedback was very good about the provided content we decided to provide the same schedule. We will start right after lunch at...
Keine Ergebnisse gefunden
Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.
Web Services
Keine Ergebnisse gefunden
Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.
Keine Ergebnisse gefunden
Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.
Keine Ergebnisse gefunden
Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.
Keine Ergebnisse gefunden
Die angefragte Seite konnte nicht gefunden werden. Verfeinern Sie Ihre Suche oder verwenden Sie die Navigation oben, um den Beitrag zu finden.
Unternehmen
Willkommen zurück, wir freuen uns auf Euch!
Es ist nun doch anzunehmen, dass es die überwiegende Mehrheit wieder so langsam in die Arbeit geschafft hat. Ja, es ist nicht einfacher geworden und der ein oder andere musste am Morgen ganz schön beherzt zugreifen, um den Gürtel im Vorjahresloch einzuhaken. Natürlich...
Willkommen zurück, wir freuen uns auf Euch!
Es ist nun doch anzunehmen, dass es die überwiegende Mehrheit wieder so langsam in die Arbeit geschafft hat. Ja, es ist nicht einfacher geworden und der ein oder andere musste am Morgen ganz schön beherzt zugreifen, um den Gürtel im Vorjahresloch einzuhaken. Natürlich...
Willkommen zurück, wir freuen uns auf Euch!
Es ist nun doch anzunehmen, dass es die überwiegende Mehrheit wieder so langsam in die Arbeit geschafft hat. Ja, es ist nicht einfacher geworden und der ein oder andere musste am Morgen ganz schön beherzt zugreifen, um den Gürtel im Vorjahresloch einzuhaken. Natürlich...
Frohe Weihnachten
Links 004
OTRS Nagios Modul Automate ssh client setup for nagios puppet-nagios Nagios 2-way alerting via SMS Fast nagios exim mail queue plugin replacement How do Nagios clients on Windows communicate? Ruby On Rails Security Guide
Loadbalancing bei Geobasisinformation Brandenburg
Hochverfügbarkeit und Lastverteilung spielen bei Internet-basierenden Diensten eine immer größere Rolle. Der Einsatz von Open-Source Software schafft hierbei eine kostenkünstige Möglichkeit sowohl die Verfügbarkeit zu steigern, aber auch die Last eines einzelnen...
Blogroll
Da hast Du einiges zu lesen …
Deployment virtueller Maschinen – Cloud Provisoner vs. Compute Resource
In meinem Blogpost möchte ich zwei Lösungen vorstellen um virtuelle Maschinen unter VMware zu deployen, so dass diese danach mit Puppet weiter gemanaget werden können. Beide Lösungen folgen hierbei ganz unterschiedlichen Ansätzen, weshalb ich die Vor- und Nachteile wie ich sie sehe aufzeigen möchte und sehr an eurer Meinung interessiert wäre.
Die erste Lösung, die ich in den Ring werfen möchte, nennt sich Cloud Provisioner, wird von Puppetlabs entwickelt und ist Teil von Puppet Enterprise. Die Installation ist recht simpel, einfach beim Installation-Assistenten mit ausgewählt, schon erhält man das Kommandozeilen-Tool. Da es sich um ein Kommandozeilen-Tool handelt ist die Konfiguration auch relativ einfach in einer Datei erledigt, in der die Zugangsdaten hinterlegt werden.
War Installation und Konfiguration erfolgreich kann das Puppet-Subkommando node_vmware genutzt werden um die virtuellen Maschinen in der Umgebung aufzulisten, zu starten, stoppen und gleich ganz zu löschen. Die wichtigste Option ist natürlich create, mit dieser kann aus einem bestehenden Template eine neue virtuelle Maschine angelegt werden. In diesem Template sollte idealerweise bereits Puppet installiert sein. Ist dies nicht der Fall kann (ssh-Zugriff vorausgesetzt) mit puppet node install auch noch Puppet nachinstalliert werden. Nun lässt sich die virtuelle Maschine ganz wie gewohnt über die Weboberfläche oder Kommandozeile managen.
Die Alternative stellt Foreman und nennt sich Compute Resource. Auch hier ist die Installation recht einfach. Nachdem bereits Foreman installiert ist, wird über den Paketmanager der Distribution ein Paket foreman-vmware nachinstalliert. Danach hat man in der Oberfläche die Möglichkeit ein Virtual Center als Compute Resource anzulegen, wofür auch nur ein entsprechend berechtigter Account nötig ist. Hier schon mal ein Hinweis für Ausprobierwillige ein einzelner ESX-Host geht nicht, da Foreman nach Clustern sucht.
Installation und Konfiguration geschafft, kann über die Compute Resource direkt mit den virtuellen Maschinen kommuniziert werden. Zusätzlich zu den Optionen wie starten und stoppen ist auch der Konsolenzugiff möglich, wenn man noch etwas Konfigurationsaufwand in Firewallregeln steckt. Das Deployment erfolgt genauso wie bei physikalischen Systemen aus der Hostansicht heraus. Wählt man beim Anlegen eines neuen Hosts die Compute Resource, bekommt man einen zusätzlichen Reiter mit den Optionen für die virtuelle Maschine und kann alles hierbei festlegen. Anschließend wird die VM erzeugt und beispielsweise über PXE gebootet und mittels Kickstart installiert. Hierbei wird auch Puppet gleich mit installiert und die virtuelle Maschinen von Anfang damit konfiguriert.
Wie man sieht zwei völlig unterschiedliche Ansätze. Auf den Unterschied bei Installation und Verwendung auf Kommandozeile oder in der Weboberfläche möchte ich nicht eingehen, hier hat jeder persönliche Präferenzen und der Admin ist meist zufrieden solang es zuverlässig geht. Interessanter finde ich etwas unter die Haube zu schauen:
- Geschwindigkeit: Hier gewinnt klar das Deployment aus einem Template. In meinen Augen ist die Frage, ob 5 Minuten oder 30, aber nur in den wenigsten Umgebungen entscheidend.
- Sauberkeit: Hier gewinnt für mich das Deployment durch automatisierte Installation. Zum einen ist es aufwendig ein sauberes Template aus einem installierten System zu machen (zu beachten: Host-Keys, Puppet-Zertifkate, Netzwerkkonfiguration, Regeln für persistente Gerätenamen, Logs, …), dieses dann immer sauber und aktuell zu halten und zum anderen muss ich diesen Aufwand immer wieder neu betreiben und gewährleisten dass auch der nächste Betriebssystemrelease ähnlich aussieht.
- Übertragbarkeit: Hier gewinnt auch wieder die automatische Installation, denn ich kann den gleichen Automatismus für physikalische Systeme und virtuelle Maschinen nutzen, sogar egal welche Virtualisierungslösung.
- Nachvollziehbarkeit: Diese habe ich leider bei beiden Lösungen nur bedingt. Klone ich meine VM aus dem Template driften diese genauso auseinander wie bei der Autoinstallation. Aber einen leichter Vorteil sehe ich für letztere da man die Installationsanweisung (nach der installiert wurde) auf dem System ablegen kann, diese im Deploymenttool versionieren kann, etc.
- Arbeitsaufwand: Auch hier kann ich weder für die eine Seite noch für die andere stimmen. Die manuelle Installation für das Template kann für manch proprietäre Software einfacher sein, aber nachdem unser Ziel ist alles mit Puppet zu erschlagen, sollte der Aufwand unabhängig von der Lösung gleich sein. Der initiale Aufwand für die automatische Installation ist aber typischerweise etwas höher, je nach Betriebssystem sogar drastisch höher (Windows hat leider kein Kickstart 😉 ).
- Dokumentation: Klarer Sieg für Autoinstallation, da ich auf der Seite von „Quelltext ist die beste Dokumentation“ stehe.
- Security und Rollentrennung: Die internen Vorgaben brechen hier leicht der automatisierten Installation das Genick. Dürfen die Admins für das Betriebssystem nicht auf die Virtualisierung zugreifen ist dies für beide Lösungen nicht hilfreich, aber Templates vorbereiten und dann durch den VMware-Admin ausrollen zu lassen ist meist noch durchsetzbar.
Dies sind in meinen Augen die wichtigsten Punkte und für mich hat nicht nur aufgrund persönlicher schlechter Erfahrung die automatische Installation und somit Foreman mit seinen Compute Ressourcen die Nase vorn. Beide Lösungen lassen aber noch ein Feature vermissen, denn wenn ich nachträglich die virtuelle Hardware noch anpassen könnte, bräuchte ich keinen Zugriff mehr auf eine andere Management-Oberfläche.
Wie gesagt mich würde die Lesermeinung zu dem Thema interessieren, darum schaut euch die Lösungen Cloud Provisioner und Compute Ressource gegebenfalls nochmal an und dann kommentiert fleißig.
Dirk Götz
Principal Consultant
Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.
Brainstorming, aber bitte alleine!
Alex Osborn, ein Werbefachmann aus den USA veröffentlichte in den 50er Jahren folgende Idee: Brainstorming in der Gruppe führt zu geistigen Höchstleistungen. Osborn nahm an, dass Menschen in einer Gruppe mehr, und vor allem bessere Ideen hervorbringen. Dafür legte er bestimmte Regeln fest. Eine davon: Übe keine Kritik [1].
Diese Praktik der Ideenfindung wurde mittlerweile in einigen Studien überprüft, mit einem Interessanten Ergebnis: Keine der Studien konnte einen positiven Beleg dafür erbringen. Eher das Gegenteil war der Fall. In einer Gruppe von 2 Personen herrscht ungefähr Gleichstand zwischen Einzel- und Gruppenarbeit. Je größer die Gruppe ausfällt, umso verheerender fällt der Unterschied aus. Osborn ging damals von einer idealen Gruppengröße von 12 Personen aus. Das Ergebnis für ein Brainstorming dürfte katastrophal ausfallen.
Das eigentliche Problem: Die Gruppenmitglieder stehen sich selbst im Weg. Ideen entwickeln und gleichzeitig Zuhören ist eine Doppelaufgabe, die das Gehirn schwer bewerkstelligen kann. Dies konnte mit verschiedenen Experimenten nachgewiesen werden [2].
In einem Experiment wurden die Teilnehmer zur Ideenfindung aufgerufen:
- Teil 1: Jeder durfte nur sprechen, wenn kein anderer sprach
- Teil 2: Jeder durfte einfach drauf lossprechen
Die Gespräche wurden durch ein Mikrophon aufgezeichnet. Das Ergebnis: Im zweiten Teil war die Produktivität genau so hoch wie bei der Einzelarbeit, während der 1. Teil in der Produktivität deutlich schlechter abschnitt.
Im Alltag und in der Wirtschaft hält sich allerdings hartnäckig die Illusion, dass klassisches Brainstorming die beste Methode sei, um Ideen zu entwickeln. Schuld daran ist vermutlich der individuelle Vergleich: Natürlich produziert eine Gruppe mit 5 Teilnehmern mehr als ein einzelnes Individuum (subjektiv gesehen). Aber: Produziert eine Gruppe mit 5 Personen wirklich mehr Ideen als 5 Individuen in Einzelarbeit?
Abhilfe schaft hier z.B. die verstaubte Metaplan-Methode [3]. Jeder Teilnehmer schreibt seine Ideen auf eine Karte und hängt diese an die Wand. So findet ohne Blockade eine gegenseitige Befruchtung statt. Anschließend können die Ideen gemeinsam besprochen und geordnet werden.
[1] http://de.wikipedia.org/wiki/Brainstorming
[2] Prof. Dr. Michael Diehl, Universität Mannheim
[3] http://de.wikipedia.org/wiki/Pinwandmoderation
Marius Hein
Head of IT Service Management
Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.
Der Klassiker: syslog -> logstash
Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben.
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:
- Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
- Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
- Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)
Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.
input {
syslog {
type => "syslog"
port => 514
}
}
Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:
*.* @192.168.200.2
Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:
*.* @@192.168.200.2:514
Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
Conference Call in Real Life
This funny video is out there for a couple of weeks. It is really ridiculous, but it’s also a very good example that nothing will replace a face-to-face meet up.
[youtube]http://www.youtube.com/watch?v=DYu_bGbZiiQ[/youtube]
Bernd Erk
CEO
Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.
Realtime Graphing mit Graphite
Zu unserem bereits vollgepackten Schulungskalender haben wir dieses Jahr unter anderem auch die Graphite Schulung mit aufgenommen.
Mit Graphite steht eine sehr leistungsfähige Graphinglösung zu Verfügung. Es umfasst die Komponenten Carbon, Graphite Web und greift
zur Speicherung auf sog. Whisper-Dateien zurück. In dieser Kombination ist es möglich Liveaufzeichnungen von Daten der Performance- und
Verfügbarkeitsüberwachung darzustellen.
Während des Trainings werden Sie schrittweise an die praktische Installation und Konfiguration der einzelnen Komponenten von Graphite herangeführt.
Danach werden die verschiedenen Importmöglichkeiten vom manuellen Import über den Import aus Nagios bzw. Icinga bis hin zum Realtime Graphing behandelt.
Auch die Integration in Reportings und Webinterfaces kommt dabei nicht zu kurz und neben der Bedienung der einzelnen Komponenten steht
noch ein Auszug alternativer Interfaces auf dem Programm.
Die Schulung richtet sich an alle interessierten Administratoren, die über Linux-Grundkenntnisse verfügen und auf der Suche nach einer alternativen, leistungsfähigen Graphinglösung sind.
Sie werden dabei von Grundauf die beeindruckenden Möglichkeiten von Graphite kennenlernen und nach dem Besuch der Schulung die Komponenten von Graphite installieren, bedienen und in ihre Monitoringlösung integrieren können.
Für unseren ersten Termin im Februar gibt es noch vergünstigte Pakete mit einem Nachlass von 495,- netto. Also, schnell sein lohnt sich!
Weitere Informationen zur Graphite Schulung und zur Anmeldung finden Sie hier.
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.
