Icinga 2 Best Practice Teil 7: "Friss oder stirb" der Variablen-Scope

This entry is part 7 of 7 in the series Icinga 2 Best Practice

Aus der Dokumentation kann man entnehmen das Objekte und Funktionen ihren eigene Variablen-Scope besitzen und nicht ohne weiteres auf Variablen eines “übergelagerten Scopes” zu greifen dürfen. Sollen z.B. Objekte über eine Schleife erzeugt werden, die sich nur maginal voneinander unterscheiden, können Variablen an diese bzw. dessen Scope via use gegeben werden.

template CheckCommand "by_ssh_base" {
  import "by_ssh"
  vars.by_ssh_plugindir = PluginDir
}
var cmdlist = [ "load", ""ntp_time", "yum" ]
for (cmd in cmdlist) {
  object CheckCommand "by_ssh_" + cmd use(cmd) {
    import cmd
    vars.by_ssh_arguments = arguments
    arguments = null
    vars.by_ssh_command = "$by_ssh_plugindir$/check_" + cmd
    import "by_ssh_base"
  }
}

Gleiches Verfahren lässt sich auch für das Erzeugen von Services über eine Schleife anwenden. Hier soll sich nun jedoch die Service-Bezeichnung vom verwendenten Check-Command unterscheiden und es kommt kein Array zum Einsatz, sondern ein Dictionary. Das folgende Beispiel ist allerdings für Commands, die via command_endpoint auf einer anderen Icinga-2-Instanz aufgerufen werden.

var srvlist = {
        "load" = "load"
        "time" = "ntp_time"
        "updates" = "yum"
}
for (srv => cmd in srvlist) {
  apply Service srv use(cmd) {
    import "generic-service"
    check_command = cmd
    command_endpoint = host.name
    assign where host.vars.os == "Linux"
    ignore where host.vars.noagent
  }
}

Werden im apply-Block mehrere Variablen, z.B. im obigen Beispiel auch srv, kann use durch Komma getrennt mehrere Variablen “weiter reichen”.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

NETWAYS Web Services: Request Tracker

Unsere NWS-Produktfamilie ist um ein weiteres Mitglied gewachsen: Den BestPractical Request Tracker. Dies wird vor allem Kunden freuen, die zwar ein stabiles und zuverlässiges Ticketsystem nutzen möchten, sich aber nicht um die Bereitstellung von Ressourcen, die Installation sowie die Wartung kümmern möchten – denn all dies wird von unserer NETWAYS Web Services Plattform übernommen. Der Kunde selbst muss sich nur um eine Hand voll Voreinstellungen kümmern, die jedoch direkt über Webformulare an die App übergeben werden.

Diese Voreinstellungen umfassen folgende Aspekte, die der Kunde bereitstellen muss:

  • ein IMAP oder POP3 Postfach, von dem der Request Tracker Kundenmails abholt und daraus ein Ticket generiert. Dies stellt vor allem sicher, dass bestehende Mail-Adressen weiter genutzt werden können.
  • einen SMTP-Server, der den Versand der Mails aus dem Request Tracker steuert.

Des Weiteren bietet unsere App viele Möglichkeiten, den Request Tracker nach Belieben anzupassen. Kunden können nicht nur den Namen Ihres Request Trackers und Ihrer Organisation festlegen, sondern auch eine Zeitzone und eine eigene Absender-Mail-Adresse eintragen:

Auch innerhalb der App kann der Request Tracker hervorragend an Ihr Unternehmen angepasst werden. Es können nicht nur im administrativen Bereich User-Gruppen und Ticket-Queues erstellt werden, sondern auch das Erscheinungsbild des Tools individualisiert werden.
Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

Nicole Lang
Nicole Lang
Account Manager

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...

STARFACE Services – heute: STARFACE Wartungsvertrag

Probleme bei der Einrichtung Ihrer STARFACE Appliance? Wir helfen gerne weiter! Im NETWAYS Online Store bieten wir nun zusätzlich zu den STARFACE Telefonanlagen, STARFACE Lizenzen, STARFACE Modulen und STARFACE Updateverträgen auch die STARFACE Services an!Die Firma sysob aus Schorndorf unterstützt uns dabei. Gemeinsam haben wir einen ganzen Strauß aus Dienstleistungen gebunden: Die STARFACE Einrichtung (remote), der STARFACE Service vor Ort, die STARFACE Wartungsverträge und der STARFACE Emergency Support. Heute stelle ich den Service STARFACE Wartungsverträge vor.
STARFACE Wartungsverträge  – Hilfe, auf die Sie zählen können! 
Sie wünschen sich Unterstützung beim Betrieb Ihrer STARFACE Appliance? Es gibt Ihnen ein sicheres Gefühl zu wissen, da ist jemand, den ich im Fehlerfall erreichen kann? Prima! Unser Servicepartner wird dies gemeinsam mit Ihnen und uns angehen. Wie das geht? Ganz einfach! Erfragen Sie bitte zu Ihrer STARFACE Compact Appliance mit bis zu 20 Usern ein Angebot für den Wartungsvertrag von uns. Wir beraten Sie gerne.
 
Was ist ein Wartungsvertrag?
Der jeweilige Wartungsvertrag wird mit unserem Dienstleister auf 12 Monate abgeschlossen und ist mit einer Frist von 3 Monaten zum Vertragsende kündbar. Die Abrechnung erfolgt quartalsweise. Die angegeben AEs beziehen sich jeweils auf einen Monat. Nutzen Sie diese ganz individuell z.B. für Updates durch den Dienstleister, mögliche Fehlerbehandlungen oder Hilfe bei neuen Implementierungen. Soll heißen: Sie kaufen monatliches Kontingent ein, das Sie individuell für Ihre Bedürfnisse nutzen können. Bitte sprechen Sie uns an, falls Sie ganz konkrete To dos haben, die abgedeckt werden sollen, denn möglicherweise sind für Sie dann auch unsere weiteren STARFACE Services, wie die STARFACE Einrichtung (remote) oder der STARFACE Service vor Ort interessant.
Sie möchten sich nicht binden, aber dennoch ein ruhiges Gefühl haben? Dann sollten Sie auf folgenden STARFACE Service ein Auge werfen.
Unsere Wartungsverträge und Supportleistungen im Überblick

STARFACE Wartungsvertrag Modalitäten
STARFACE Wartungsvertrag Compact bis 20 User Laufzeit: 12 Monate; 4 AE* zu den Servicezeiten** inklusive
STARFACE Wartungsvertrag Pro bis 40 User Laufzeit: 12 Monate; 7 AE zu den Servicezeiten inklusive
STARFACE Wartungsvertrag Advanced bis 80 User Laufzeit: 12 Monate; 10 AE zu den Servicezeiten inklusive
STARFACE Emergency Support individuell; Anfrage senden

Die Eckdaten des STARFACE Emergency Support auf einen Blick:

  • STARFACE Support auf Zuruf
  • Abrechnung erfolgt im AE*-Takt
  • initiale Reaktionszeit mindestens 4 Stunden innerhalb unserer Servicezeiten**
  • individuelle Hilfe durch unseren Servicepartner
  • Jetzt Anfrage versenden!

*AE= Arbeitseinheit à 15 Minuten
**Servicezeiten:  9/5 : Mo-Fr 8-17 Uhr;  4 Std. Reaktionszeit

Isabel Salampasidis
Isabel Salampasidis
Account Manager

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich...

Icinga 2 Best Practice Teil 4: Host Templates und Services

This entry is part 4 of 7 in the series Icinga 2 Best Practice

Heute soll es um die Strukturierung von Services und deren Zuordnungen zu Gruppen von Hosts gehen. Ein Host Template kann zur Zusammenfassung von Informationen einer Gruppe von Hosts dienen und damit mehrere unterschiedliche Services für den jeweiligen Host anziehen. Wir wollen in den folgenden Beispielen Linux Hosts überwachen. Dort neben, wie schon in Teil 3 beschrieben, der Belegung der Dateisysteme auch in Abhängigkeit in welchem Netzsegment der Host angeschlossen ist, ob die Zeit synchron zum Zeitserver läuft.

template Host "linux-host" {
  import "generic-host"
  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }
}
apply Service "time" {
  import "generic-service"
  check_command = "ntp_time"
  command_endpoint = host_name
  assign where host.vars.os == "Linux"
}

Es gibt zwei Netze mit je eigenem Zeitserver. Um dieses abzubilden, definieren wir für jedes Netz ein eigenes Host-Template:

template Host "dmz-net" {
  vars.ntp_address = "172.16.2.99"
}
template Host "lan-net" {
  vars.ntp_address = "172.16.1.99"
}

Diese beiden Templates enthalten nur netzspezifische Informationen, in unserem Beispiel auch nur den jeweilig zuständigen Zeitserver. Der Service-Check time mit dem Plugin check_ntp_time ermittelt die Differenz zwischen der lokalen Zeit des Hosts und der Zeit des NTP-Servers, der in ntp_address angegeben ist. Nun müssen wir für einen Host im internen Netzwerk lan-net nur noch beide Templates zusammen bringen:

object Host "host.example.org" {
  import "linux-host"
  import "lan-net"
  import "postgres-dbms"
  address = "172.16.1.11"
}

Habe wir weitere Services, die abhängig vom Netzsegment unterschiedlich zu konfigurieren sind, können diese Informationen den Netz-Templates hinzugefügt werden. Ein weiteres Beispiel wäre hier die Überwachung unterschiedlicher Domain Name Services. Diese Konzept der Stapelung von Host templates kann natürlich noch weitergeführt werden, z.B. auf Applikationen wie einen Postgresql basierendes Datenbank-Management-Systems bezogen. Ggf. muss jedoch auf die Reihenfolge der Importe geachtet werden, wenn Werte überschrieben werden sollen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

atexit, oder wie man Python-Dienste nicht beenden sollte

Wer schon einmal einen Dienst mit Python realisiert hat, wird bereits vor der Aufgabe gestanden haben die Aufgaben die er verrichtet sauber und geordnet zu beenden. Python bietet einem hier vielerlei Lösungen an, darunter auch das atexit Modul. Für schnelle und simple Aufräum-Arbeiten ist dieses Modul wunderbar geeignet, nicht jedoch wenn Thread-Synchronisation und externe Kommunikation im Spiel ist. Warum das so ist und was die saubere Alternative ist, darum geht es heute in diesem Blogpost.
Wie der Name des Moduls und dessen Dokumentation bereits sagt, werden registrierte Routinen ausgeführt kurz bevor der Interpreter angehalten wird. Klingt erst einmal nicht besonders problematisch, ist es doch gerade was man haben möchte. Und es funktioniert sogar, solange keine Threads laufen. Dann werden die registrierten Routinen nicht aufgerufen. Das liegt daran, dass “normale” Threads explizit beendet werden müssen, sonst verhindern diese den Stopp des Interpreters. Damit das nicht passiert, kommt man möglicherweise auf folgende Idee:

t = threading.Thread(target=func)
t.daemon = True  # Avoids that python hangs during shutdown
t.start()

Ganz schlecht. Das mag möglicherweise den gewünschten Effekt haben und die Aufräum-Routinen können ihre Arbeit verrichten. Aber tatsächlich ist dies nur eine Lösung für ein Symptom, das eigentliche Problem ist noch immer nicht gelöst. Das wird einem spätestens klar, wenn es nicht mehr nur darum geht Threads zu beenden, sondern auch noch mit anderen über das Netzwerk verbundenen Diensten/Klienten eine saubere Unterbrechung der Kommunikation einzuleiten.
Denn was genau passiert wenn der Interpreter angehalten wird?

  1. Der MainThread wird sofort angehalten
  2. Offene File-Handles werden geschlossen
  3. Es wird gewartet dass alle nicht-Daemon Threads beendet wurden
  4. Die atexit-Routinen werden ausgeführt
  5. Garbage Collection
  6. Der Prozess wird beendet

Der zweite Punkt lässt einige vielleicht bereits aufhorchen, denn sockets sind nichts anderes als File-Handles. Wer nun immer noch denkt er könne in einem daemon-Thread die Netzwerk-Kommunikation mit seinem Gegenüber sauber beenden, ist auf dem Holzweg. Zum Zeitpunkt zu dem die atexit-Routinen laufen, sind bereits alle sockets unwiderruflich geschlossen.
Angenommen der Stopp des Dienstes wird ganz normal über SIGTERM initiiert, so könnte man nun alle atexit-Routinen in einen Signal-Handler verlagern. Dadurch würden sie laufen noch bevor der Interpreter angehalten wird, allerdings kommt man so sehr schnell wieder in die Bredouille, je nachdem welche Art von Arbeit der MainThread verrichtet. Denn da Signal-Handler asynchron im MainThread ausgeführt werden, ist das Risiko für ein Deadlock sehr groß. Kommen wir also zur erwähnten, sauberen Alternative: Feuer mit Feuer bekämpfen.
Was vormals in etwa so aussah:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...
    def _sigterm(self, signum, frame):
        sys.exit(0)
    def _atexit(self):
        # Alle Aufräum-Arbeiten

Kann ganz einfach, mit durchschlagendem Erfolg, so umgebaut werden:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...
    def _sigterm(self, signum, frame):
        threading.Thread(target=self._cleanup, name='CleanupThread').start()
    def _cleanup(self):
        # Komplexe Aufräum-Arbeiten
    def _atexit(self):
        # Einfache Aufräum-Arbeiten

Der “CleanupThread” sollte selbstverständlich keine Arbeit verrichten die unkontrolliert blockt. Denn dann sieht das ganze am Ende wieder so aus:

    def _sigterm(self, signum, frame):
        t = threading.Thread(target=self._cleanup, name='CleanupThread')
        t.daemon = True
        t.start()

Und der ganze Spaß geht von vorne los..

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.

Webinare im Mai

NETWAYS Webinare Nachdem der Webinar-Marathon im April fast zuende geht und das Vagrant Webinar kurz bevor steht, möchte ich natürlich gleich auf die nächsten Webinare im Mai hinweisen. Einerseits geht es dann um unsere Cloud-Lösungen welche wir über unsere Rechenzentren anbieten und einmal um das Thema Windows Vorbereitung für Puppet. Bei dem Windows Webinar liegt der schwerpunkt darauf, wie ein Windows-System soweit vorbereitet werden kann, dass sowohl eine automatische Installation über Images aber auch die anschließende Konfiguration mit Puppet möglich ist. Christoph hatte hierzu bereits einen interessanten Blog-Artikel veröffentlicht.
Zusammengefasst noch einmal die Themen, die Termine und Anmeldelinks im Überblick:

Titel Zeitraum Registrierung
Vagrant: Virtualisierungs Wrapper 30. April 2015 – 10:30 Uhr Anmelden
NETWAYS Cloud Lösungen 08. Mai 2015 – 10:30 Uhr Anmelden
Windows: Vorbereitung für Puppet 22. Mai 2015 – 10:30 Uhr Anmelden

Vorab natürlich eine schöne Restwoche!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Reminder für das morgige RT-Webinar!

Morgen um 10:30 Uhr werden Marius und ich die Open Source Ticket Lösung Request Tracker in unserem Webinar vorstellen und sowohl die Vorteile als auch die Flexibilität demonstrieren.
Wer also noch teilnehmen möchte, sollte sich jetzt schnell registrieren, bevor alle Plätze vergeben sind!
Eine vorab Vorbereitung ist zwar nicht notwendig, aber in einem früheren Blog-Artikel zum RT, hatte ich bereits versucht einige Vorteile heraus stechen zu lassen. Um die 24 Stunden bis zum Webinar noch zu verkürzen, lohnt es sich natürlich direkt in unserem Webinar Archiv vorbeizuschauen.
Bis morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Neu im NETWAYS Portfolio – Puppet Starterpaket

Puppet_LogoBei Puppet handelt es sich um ein OpenSource Konfigurationsmanagement System, welches vom amerikanischen Unternehmen PuppetLabs entwickelt wird.
Puppet bietet den Vorteil, Administratoren bei z.B. regelmäßigen Aufgaben wie Paketinstallation, Serverinstallationen oder Konfigurationsänderungen zu entlasten.
Das gesuchte Stichwort heißt: Automatisierung.
Um Unternehmen beim Einstieg in die Puppet-Welt zu unterstützen, bieten wir seit einiger Zeit das Puppet Starterpaket in zwei Varianten an:
Puppet Starterpaket Standard
Dieses Paket besteht aus einem 4-Tages-Workshop mit einem unserer Puppet-Consultants, welcher eine Evaluierung einer vorhanden IT-Umgebung vornimmt und anschließend eine mögliche Konzeptionierung aufzeigt, um Puppet erfolgreich zu implementieren. Anschließend wird der Puppet-Master sowie ein Versionskontrollsystem (z.B. SVN, Git, etc.) installiert, um Änderungen an den Puppet-Modulen nachzuvollziehen. Für einen noch besseren Einstieg, werden zusätzlich einige Beispielmodule erstellt, welche im späteren Verlauf natürlich weiter angepasst werden können.
Puppet Starterpaket Premium
Für komplette Einsteiger im Puppet-Bereich, die bisher noch keine persönlichen Berührungspunkte hatten, bieten wir im Premium-Starterpaket zusätzlich zu den 4 Workshop-Tagen noch 3 Tage Vor-Ort Schulung für 3 Teilnehmer an (weitere Teilnehmer gegen Aufpreis möglich).
Die Schulungsinhalte werden 1:1 von unserer Puppet Fundamentals-Schulung übernommen, inkl. Schulungsnotebooks, Schulungsunterlagen sowie ein Teilnehmerzeugnis.
Je nachdem wie komplex die Umgebung und die jeweiligen Anforderungen an das Puppet-System sind, können folgende Themen im Rahmen des Workshops noch mit aufgenommen werden:

  • Einrichtung von Foreman
  • Einrichtung der PuppetDB
  • Anbindung von externen Datenquellen

Selbstverständlich unterstützen wir auch bei individuellen Anfragen zum Thema Puppet oder beim Betrieb einer bereits vorhanden Puppet-Umgebung, auf Basis unserer Supportverträge oder von Consulting-Dienstleistungen.
Für einen persönlichen Kontakt stehen wir ebenfalls sehr gerne zur Verfügung – weitere Details für eine Kontaktaufnahme sind in unserem Kontaktformular zu finden!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

"Der Checker"

Als NETWAYS schreiben wir uns selbst ein sehr hohes Icinga/Nagios KnowHow auf die eigene Fahne. Aber auch wir haben, wie 99,99% aller Icinga/Nagios Anwender, immer wieder den ein oder anderen Fallstrick zu bewältigen.
Ein Problem, welches sehr häufig Auftritt, das richtige maskieren von Sonderzeichen in Check-Definitionen.
Ein ganz simples Beispiel: Mit wie vielen Backslashes (\) muss man die Pfadangaben eines Shares maskieren, damit Icinga/Nagios diese richtig interpretiert?
Wie ist das vorgehen in einem solchen Szenario? Richtig, man ändert so lange und so oft die Definition, führt jedes mal einen Icinga/Nagios Reload aus und führt den Check neu aus bis man irgenwann das gewünschte Ergebnis hat… Das dies mitunter längere Zeitspannen in Anspruch nimmt ist vielen durchaus bewusst, uns auch!
Icinga/Nagios besitzt im Core ca. 10 Zeilen, welche für das maskieren von Sonderzeichen verantwortlich sind. Dieses kleine Snippet/Wrapperplugin hilft uns nun dabei unsere Checks im vorhinein schon richtig zu bauen und zu testen, um sie anschließend in die jeweilige Definition zu übernehmen.
Ein Aufruf des Wrapperplugins sieht wie folgt aus:

# ./check_executor /opt/icinga/libexec/check_http -H icinga -u "/icinga-web"
Executing command /opt/icinga/libexec/check_http -H icinga -u /icinga-web
Check output: HTTP OK: HTTP/1.1 301 Moved Permanently - 305 bytes in 0.001 second response time |time=0.001075s;;;0.000000 size=305B;;;0

Executing command gibt den eigentlichen Pluginaufruf aus, wie er duch Nagios/Icinga ausgeführt wird.
Check output beschreibt die eigentliche Ausgabe, wie sie u.a. auch in der Weboberfläche sichtbar wäre.
Zu finden ist das ganze in unserem GIT: https://git.netways.org/plugins/collection/trees/master/plugins/check_executor
Um Verwechslungen grundsätzlich aus dem Weg zu gehen: “Der Checker” kümmert sich natürlich um schöne Autos, unser “Checker” um Icinga/Nagios Plugins.

Das leidige Thema der IT – welches Ticket-System soll eingesetzt werden?

Wer kennt es nicht, den komplizierten Beschaffungsprozess in einem Unternehmen. Hat man seine IT-Anforderungen mühselig zusammengekratzt, beginnt die Recherche nach einem geeigneten Ticket-System, welches die vorgegebenen Anforderungen auch erfüllt. Gerade bei der Einführung eines solchen Systems macht es die große Fülle von kommerziellen und Open-Source Lösungen nicht gerade einfach.
Und hat man doch einmal das vermeintlich Richtige gefunden, darf man auch noch dem Management begründen, wieso ausgerechnet dies die korrekte Lösung ist.
Darum hab ich mir gedacht, zeig doch einfach mal die Vorteile des Request-Trackers auf und warum wir seit Jahren auf ihn setzen.
Das Tolle vorweg: Er ist Open-Source und kostet daher keine Lizenzgebühr!
Aber Warum den Request Tracker und nicht z.B. OTRS (Open Ticket Request System), Bugzilla oder gar kommerzielle Produkte wie BMC Remedy Action Request System oder OpenView Service Desk?
Ich hab mich mal hingesetzt und das Ganze auf unserer Übersichtsseite „Warum Request Tracker?“ zusammengefasst, um einerseits an einigen Alltagsbeispielen den Nutzen des Request Trackers aufzuzeigen, aber auch um den einen oder anderen zu unterstützen, das Management besser zu überzeugen.

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".