Serien - Kategorie - NETWAYS Blog

Archive for the 'Serien' Category

NETWAYS stellt sich vor – Birger Schmidt

Published by Manuela Pirner on 09.03.2010 in Diverses, German, Mitarbeiter, NETWAYS and Serien. 0 Comments

Teil 7 von 13 in der Blogserie Mitarbeitervorstellung

Name: Birger Schmidt

Alter: 36

Ausbildung/Titel: Dipl. Informatiker

Position bei NETWAYS: Senior Consultant

Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?

Ich berate unsere Kunden vorrangig im Themenkomplex Monitoring aber auch Systems Management. Das beinhaltet von der Konzeption über Implementation bzw. Development bis hin zur Schulung die gesamte Bandbreite unseres Dienstleistungsangebotes. Darüber hinaus unterstütze ich auch im Bereich Support via Remotezugriff im Rahmen unserer Supportverträge.

Welche großen Projekte und besonderen Herausforderungen hast Du hier bereits bewältigt?

Jedes Projekt birgt seine eigenen Herausforderungen. Meistens sind es Besonderheiten in Details. Manchmal ist die Systemlandschaft besonders exotisch und manchmal ist es der Kunde selbst. Immer wieder ist es spannend sich auf die individuellen Anforderungen einzustellen und mit dem Kunden die beste Lösung für ihn zu finden.

Besonders interessant sind natürlich die größeren Projekte. Ich habe bei Bosch in der IT Abteilung im Bereich der Überwachung der Infrastruktur unterstützt. Dabei sind die enormen Anforderungen an die Verfügbarkeit der Komponenten an der Linie, die früher wohl am ehesten als Fließband bezeichnet worden wäre, natürlich besonders spannend.

Bei der Deutschen Welle hatte ich im Rahmen meiner Tätigkeit Kontakt zu modernster Fernsehtechnik.

An welchen Projekten arbeitest Du momentan – wie ist da der Stand?

Ich bin gerade in der Endphase des Migrationsprojektes für das StayFriends Ticket System. Die besondere Herausforderung ist dabei nicht das Update an sich, sondern die vielen individuellen Anpassungen im Open Source Ticket System Request Tracker.

Welche größeren oder besonders interessanten Projekte stehen zukünftig an?

Vielleicht ja Monitoring bei einem großen deutschen Automobilhersteller?

Was macht Dir an Deiner Arbeit am meisten Spaß?

Die Gestaltungsfreiheit. Als Berater habe ich die Chance dem Kunden ein Konzept vorzulegen welches meine Idealvorstellung widerspiegelt. Der Kunde könnte zwar auch das absolute Gegenteil verlangen, aber das tut er natürlich nicht. Er kauft ja nicht ohne Grund Beratungsleistung ein. Gemeinsam haben wir bisher jedes mal eine für den Kunden passende Lösung gefunden. Darüber hinaus schätze ich es die verschiedenen Kunden und ihre Arbeitsweise kennenzulernen.

Welche Technologie oder Entwicklung der letzten Jahre ist Deiner Meinung nach die wichtigste, bzw. herausragendste im Bereich Open Source?

Ich finde es besonders bemerkenswert, dass die Arbeitsweise und Weltanschauung der Open Source Gemeinde inzwischen ihren Weg in die Gesellschaft findet. Das meine ich ganz allgemein, aber auch ganz speziell – angefangen bei Online Petitionen bis hin zur Piratenpartei.

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Ich kümmere mich um meine Familie und freue mich die Kinder nicht nur aufwachsen zu sehen, sondern groß zu ziehen.

Wie geht es in Zukunft bei Dir weiter?

Who knows – auf jeden Fall fröhlich. Vielleicht bringt einer der nächsten Kunden ja eine Tätigkeit im Ausland mit sich.

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Published by Michael Streb on 10.02.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 1 Comment

Teil 4 von 4 in der Blogserie NSClient++

Im vierten Teil der NSClient++ Serie geht es um die Überwachung des Windows Eventlogs und weitere kleine Features des NSClients wie z.B. check_multiple.

Die Prüfung des Windows Eventlogs kann über mehrere Wege stattfinden.
In unserer Serie erfolgt die Prüfung über CheckEventlog und die dazugehörige Filtersprache, durch Angabe verschiedener Filter sind auch hier komplexe Abfragen möglich. Beispielsweise kann mit folgender Abfrage auf vorkommen von Fehlermeldungen (nicht success) innerhalb des Systemlogs geprüft werden die einen Tag alt sind und von einem Service erzeugt wurden. Eine CRITICAL Meldung wird in diesem Fall ab dem ersten Treffer erzeugt.

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckEventLog -a file=system filter=new filter=out filter-eventType==success filter+eventSource=substr:Service 'filter-generated=>1d' MaxCrit=1

Dabei wird ausgegeben welche Services den Fehler verursacht haben, zur genaueren Diagnose sollte dann das Eventlog herangezogen werden.
Die Ausgabe kann je nach Gusto noch mit verschiedenen Parametern angereichert werden. Zu finden ist die Dokumentation der Filtersprache unter http://www.nsclient.org/nscp/wiki/CheckEventLog/CheckEventLog

Ein weiterer interessanter Check des NSClients ist im Modul CheckHelpers enthalten. Das Kommando CheckMultiple ermöglicht es ähnlich zu check_multi unter Linux/Unix in einem Connect mehrere Abfragen auszuführen. CheckMultiple erwartet als Argumente die auszuführenden Checks, um Beispielsweise die Festplattenauslastung sowohl auf prozentualer als auch auf absoluter Basis zu messen kann beispielsweise dieses Kommando verwendet werden:

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckMultiple -a command=CheckDriveSize Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long command=CheckDriveSize Drive=c MinWarnFree=2G MinCritFree=1G ShowAll=long
WARNING: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%) > warning, OK: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%)|'c:'=90%;80;95; 'c:'=36.00G;37.99;38.99;

Die Verknüpfung der von CheckMultiple ausgeführten Prüfungen ist immer oder, d.h. der schlechteste Status der ausgeführten Subprüfungen wird immer in das Ergebniss übernommen. In unserem Testfall ist die Prüfung also ein WARNING Status. Die Textuelle Ausgabe der beiden Prüfungen wird ausschließlich bei den Performancedaten kombiniert, so bleibt jede Information der eigentlichen Prüfungen erhalten.

Serie NSClient++ – Teil 3: Basisüberwachung

Published by Michael Streb on 03.02.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 0 Comments

Teil 3 von 4 in der Blogserie NSClient++

Nachdem in Teil eins und zwei der Blogserie über den NSClient++ die Grundlagen und Installation durchgeführt wurden kann es nun ans Überwachen der ersten Komponenten gehen. Ziel dieses Teils ist es eine Basisüberwachung des Betriebssystems abzudecken, daraus ableiten lässt sich dann auch eine erweiterte Überwachung diverser Dienste, Festplattten oder Prozesse.

Die Kommunikation hin zum Client erfolgt über das Plugin check_nrpe, wichtig hierbei ist NRPE mit aktivierten Kommandoargumenten übersetzt zu haben. Die benötigte Option hierfür heißt “–enable-command-args” und muss zur Kompilezeit angegeben werden.

Generell funktionieren die verschiedenen Abfragen ähnlich, einzig das auszuführende Kommando (Parameter “-c”) und die dazugehörigen Argumente (Parameter “-a” für check_nrpe) unterscheiden sich je nach Prüfung.

Ein Beispielhafter Aufruf für die Prüfung der CPU Auslastung über einen Zeitraum von 5 Minuten sieht wie folgt aus:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long

Sieht das Ergebnis wie gewünscht aus können wir uns den weiteren Checks widmen. Als Basisüberwachung werden folgende Prüfungen auf jedem Windowssystem eingerichtet:

CPU Auslastung (80% Warning, 95% Critical, 5 Minuten Messintervall)
Festplattenauslastung (80% Warning, 95% Critical)
Speicherauslastung (70% Warning 85% Critical)
Uptime
Server Dienst

Die Kommandozeilen für die genannten Prüfungen:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
OK: 5m: average load 1%|'5m'=1%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckDriveSize -a Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long
OK: c:: Total: 40G - Used: 24.6G (61%) - Free: 15.4G (39%)|'c:'=61%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckMEM -a MaxWarn=70% MaxCrit=85% type=physical ShowAll=long
OK: physical memory: Total: 2G - Used: 840M (41%) - Free: 1.18G (59%)|'physical memory'=41%;70;85; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckUpTime -a ShowAll=long
OK: uptime: 0:13

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckServiceState -a Server
OK: All services are in their apropriate state.

Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:

define command {
        command_name    check_win_load
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_drive
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckDriveSize -a Drive=$ARG1$ MaxWarnUsed=$ARG2$ MaxCritUsed=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_mem
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckMEM -a MaxWarn=$ARG1$ MaxCrit=$ARG2$ type=physical ShowAll=long
}

define command {
        command_name    check_win_uptime
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckUpTime -a ShowAll=long
}

define command {
        command_name    check_win_service
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckServiceState -a $ARG1$
}

Serie NSClient++ – Teil 2: Installation

Published by Michael Streb on 27.01.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 2 Comments

Teil 2 von 4 in der Blogserie NSClient++

Für die Installation des NSClient++ zur Windowsüberwachung gibt es generell zwei Möglichkeiten.

Variante eins ist die Installation auf Basis von zum Download bereitstehenden MSI Paketen. Bei dieser Installationsweise werden während des Installationsvorgangs die benötigten Parameter abgefragt.

Bei der zweiten Installationsvariante wird das ZIP Archiv heruntergeladen und auf die Systeme ausgerollt. Vorab sollte allerdings eine Anpassung der globalen Konfigurationsdatei “nsc.ini” erfolgen um die gewünschten Parameter zu setzen. Danach kann dieses Archiv einfach auf beliebig viele Rechner verteilt werden, wobei nach Entpacken des Archives manuell der Windows-Dienst registriert und gestartet werden muss.

Die Registrierung und der Start des Dienstes erfolgt in einer Kommandozeile mit den Befehlen:

# nsclientpp.exe -install
# net start nsclientpp

Beiden Installationswegen gemein ist jedoch der automatische Start des “nsclientpp” genannten Dienstes beim nächsten Neustart des Systems. Wer sich für den manuellen Installationsweg entscheidet muss in der NSC.ini folgende Parameter an die vorhandene Umgebung

Aktivieren der gewünschten Checks in derr [modules] Sektion:

FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll

Durch die Aktivierung der oben genannten DLL’s wird die Funktionalität des NSClient++ bestimmt, eine Erklärung der Funktionen innerhalb der Bibliotheken findet sich in der Dokumentation unter http://www.nsclient.org/nscp/wiki/CheckCommands

Anpassungen im [settings] Abschnitt:

allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1

Die Direktive use_file weist den NSClient an die Konfigurationsdatei anstatt von Registryeinträgen zu verwenden. Bei der Installation wird also lediglich der Dienst registriert, weitere Einstellungen werden nicht in die Windows Registrierung geschrieben.

Zusätzlich müssen noch Kommandoargumente und Sonderzeichen für diese freigeschalten werden, dazu gibt es in der Sektion [NRPE] folgende Parameter die jeweils auf 1 zu setzen sind:

allow_arguments=1
allow_nasty_meta_chars=1

Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:

# net stop nsclientpp
# net start nsclientpp

Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:

# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion

Als Antwort des Clients wird hierbei die Versionsnummer der aktuell Installierten NSClient Version zurückgegeben. Sollten hier Fehler auftreten bietet der NSClient die Möglichkeit den Dienst über eine Kommandozeilenoption in den Debugmodus zu schalten und so eventuell auftretenden Fehler zu lokalisieren. Dazu wird als erstes der Dienst gestoppt und der NSClient manuell mit der Option “-test” gestartet.

# net stop nsclientpp
# nsclientpp.exe -test

Jasper Reporting – Zusammenfassung

Published by Bernd Erk on 20.10.2009 in Development, German, ICINGA, Jasper Reporting, Nagios and Serien. 1 Comment

Teil 5 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting In den letzten Wochen habe ich mich an dieser Stelle ausführlich mit Jasper-Report beschäftigt. Da wir Jasper stark zunehmend in unseren Kundenprojekten einsetzen auch im Bereich Managed Service darauf zurückgreifen, lag die Serie sehr nah und ich hoffe soweit die wichtigsten Kernaspekte getroffen zu haben.

Hier nochmals die verschiedenen Posts zum Thema im Überblick:

An dieser Stelle Danke für das positive Feedback und dem starken Interesse an der Serie und dem Thema Reporting. Hier sei auch nochmals auf die NETWAYS Reports auf netways.org hingewiesen. Sollten Fragen offen geblieben sein, so freue ich mich über Kommentare oder Gespräche auf der Open Source Monitoring Conference nächste Woche.

Alle Beispielreports befinden sich auch auf dem Demo-System und können dort gegen unser Nagios-Demo-System gestartet werden.

Jasper Reporting – Distribution

Published by Bernd Erk on 16.10.2009 in Development, German, Jasper Reporting and Serien. 0 Comments

Teil 4 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting Der vorerst letzte Teil unserer Jasper Serie widmet sich der automatischen Erzeugung und Versendung von Berichten mit Hilfe des JasperServers. Die Konfiguration des Schedulers erfolgt über das Webinterface und erlaubt neben der Speicherung von bestimmten Reportparametern auch die Speicherung der versendeten Berichte auf dem Server.

Reports auf Basis von beweglichen Daten, wie in unserem Beispiel die NDO, sollten ergänzend zur Versendung besser gespeichert werden, da der entsprechende Bericht ja nicht wiederherstellbar ist!

Bevor die erzeugten Berichte versendet werden können, muss noch die SMTP-Konfiguration des integrierten Quartz-Schedulers erfolgen. Hierfür werden SMTP-Server und ggf. User und Passwort in der Datei js.quartz.properties angepasst. Die Datei befindet sich im Verzeichnis /apache-tomcat/webapps/jasperserver.

Ein Beispiel:

report.scheduler.mail.sender.host=localhost
report.scheduler.mail.sender.username=
report.scheduler.mail.sender.password=
report.scheduler.mail.sender.from=jasper@netways.org
report.scheduler.mail.sender.protocol=smtp
report.scheduler.mail.sender.port=25

Nach Neustart des Servers sind die Einstellungen aktiv und mögliche Probleme sind im Logfile des Tomcat-Servers (/apache-tomcat/logs) zu sehen.

Das Webinterface ermöglicht über die entsprechende Schaltfläche die Anlage von Jobs, nachdem ein entsprechender Report ausgewählt wurde.

Im ersten Übersichtsfenster erfolgt die Einstellung der Ausführungszeit und bei Aktivierung der “Calendar Recurrence”-Box wird eine Vielzahl von weiteren Optionen zur zeitgesteuerten Ausführung angezeigt.

Verfügt der gewählte Report über Parameter, so können die entsprechenden Einstellungen im nächsten Übersichtsfenster gesetzt werden. So kann ein Bericht unter Anlage verschiedener Jobs und Definition der Parameter für verschiedene Kunden erstellt und personalisiert zugestellt werden.

Der Bereich Output dient der Vorauswahl der erzeugten Formate und ggf. Lokation für verschiedene Sprachen sowie Angebe des Server-Ordners der zur Speicherung der Berichte verwendet werden soll. Ergänzend kann hier noch der Emailtext für den Empfänger eingegeben werden.

Sobald die Einstellungen gespeichert worden sind, zeigt ein kleines Uhrensymbol neben dem Bericht den entsprechenden Job an. Bevor der Bericht automatisiert an den Kunden versendet wird, empfiehlt sich eine Testphase auf ein eigenes Mailkonto und manueller Weiterleitung der Reports. Gerade am Anfang können Kleinigkeiten für einen unschönen Seitumbruch oder eine Fehlselektion der Daten verantwortlich sein.

Im nächsten Blog-Post werde ich die vergangenen Artikel nochmals zusammenfassen und ggf. auf Frage eingehen, die uns bis dahin erreicht haben und in den Kommentaren unbeantwortet geblieben sind.

Jasper Reporting – Host Availability

Published by Bernd Erk on 09.10.2009 in Development, German, Jasper Reporting, NETWAYSPortal, Nagios and Serien. 2 Comments

Teil 2 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting Bisher haben wir uns lediglich den Konfigurationsdaten und dem aktuellen Status der Systeme gewidmet, aber wirklich spannend ist bei der Erstellung ja der Blick in die Vergangenheit und im Idealfall dann noch der Überblick über einen bestimmten Zeitraum.

Da die Verfügbarkeitsreports innerhalb von Nagios auf Filebasis erfolgen, müssen die Einträge in der Datenbank erst aufbereitet werden, vorausgesetzt man möchte sich nicht selbst darum kümmern.

Um eine Durchschnittsaussage über einen größeren Zeitraum durchzuführen, müssen die einzelnen Statuswechsel und die Zeiträume dazwischen analysiert und summiert werden. Das ganze kann mit Hilfe unseres Packages netMySLA erfolgen, dass genau diese Informationen in einem nächtlichen Batch ermittelt und in entsprechenden Aggregatstabellen speichert. Nach Installation dieses Packages kann unsere Abfrage wie folgt erweitert werden:

select c.alias,
  a.host_object_id,
  a.display_name,
  a.address,
  e.sla_availability_percent,
  e.sla_outage_percent,
  e.sla_period_identifier,
  d.current_state
from nagios_hosts a,
  nagios_hostgroup_members b,
  nagios_hostgroups c,
  nagios_hoststatus d,
  np_aggregate_sla e
where a.host_object_id = b.host_object_id
and b.hostgroup_id     = c.hostgroup_id
and a.host_object_id   = d.host_object_id
and a.host_object_id   = e.sla_host_objectid
and a.instance_id      = 1
and b.instance_id      = 1
and c.instance_id      = 1
and d.instance_id      = 1
and e.sla_service_name is null
and e.sla_period_name = 'month'
and e.sla_period_identifier > '2009-06-01'

Das Datum ist hier fälschlicherweise fest Codiert und muss in Realität entweder parametrisiert oder via Datums-Parameter gefüllt werden. Mit diesem Statement bekommen wir anschließend sowohl den aktuellen Status als auch den prozentualen Anteil der Verfügbarkeit in dem angegebenen Monatszeitraum.

Da die Darstellung unter Verwendung eines Kuchendiagramms erfolgen soll, ist dieses über die Palette in den Detailbereich des Reports einzufügen.

Die Datenübergabe an das Diagramm erfolgt wie in den vorhergehenden Beispielen mittels Kontextmenü. Wichtig ist, dass das Kuchendiagramm mit zwei Serien bestückt wird.

Serie Availability:
Key expression: “Availability”
Value expression:

$F{sla_availability_percent}

Serie Outage:
Key expression: “Outage”
Value expression:

$F{sla_outage_percent}

Wenn das Diagramm korrekt im Detailbereich platziert worden ist, wird die entsprechende Verfügbarkeit nun pro definiertem Service dargestellt. Um bei der Anzeige mit Ausfallkandidaten zu beginnen, genügt es dem Statement noch ein “order by e.sla_outage_percent” anzuhängen.

Hier kann der erstellte Beispielbericht wie gewohnt geladen werden. Die Vorlage gibt es bei netways.org und auf unserem Demo-System.

Der nächste Teil der Serie ergänzt das Thema Verfügbarkeit noch mit der Integration des Business Process Addons for Nagios.

Jasper Reporting – Dynamische Parameter

Published by Bernd Erk on 06.10.2009 in Development, German, Jasper Reporting, Nagios and Serien. 1 Comment

Teil 1 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting Seinen Report mit Parametern zu versehen hat mehrere Vorteile. Zum einen kann man die gleiche Vorlage für verschiedene Kunden und Objekte einsetzen, zum anderen hat der Endanwender die Möglichkeit der Interaktivität. Wer auf viele Parameter setzt sollte jedoch immer für eine hohe Quote an vordefinierten Reports sorgen, da die Hürde zur Ausführung nicht zu hoch liegen sollte.

Gerade beim Vergleich von Text in einem Statement muss der eingegebene Parameter exakt übereinstimmen, da sonst keine Daten ermittelt werden können. Bei etwas längeren Attributen wie Host- oder Servicegruppen ist dies einfach zu fehleranfällig. Hier können dynamische Parameter Abhilfe schaffen, da sie dem Benutzer quasi die Summe aller Möglichkeiten anbieten und man nur noch aus dieser Menge auswählen kann.

Die Definition erfolgt wieder direkt auf dem JasperServer durch Anlage eines neuen “Input Controls”. Bei Eingabe des Namens bitte dringend auf die richtige Schreibweise achten, da dies im Support Fehler Nummer 1 ist, wenn der Wert nicht angenommen wird und ein Default-Wert existiert.

Bei der Eingabe der “Input Control Details” ist der Type Single Select Query zu wählen. Anschließend kann entweder eine globale Query aus dem Repository oder eine lokale (unser Beispiel) verwendet werden. In unserem Fall ist der Wert zur Anzeige auch der Wert zur Übergabe. Wenn z.B. Namen ausgewählt, aber Personalnummern übergeben werden sollen, sind mind. zwei Columns zu selektieren.

Das Statement zur Ermittlung der verfügbaren Hostgruppen lautet:

select alias from nagios_hostgroups where instance_id = 1

Als Datasource übernehmen wir auch hier wieder die lokale Definition. Anschließend muss wie bereits angedeutet noch das Value und Visible Column hinterlegt werden und die Anlage des Parameters bestätigt werden. Nach Zuordnung des Parameters zum aktiven Report, kann dieser dann auch im Webinterface ausgewählt werden.

Der entsprechende Report findet sich natürlich auch wieder bei netways.org und unserem Demo-System.

Im nächsten Post steigen wir in das Thema Host-Availability ein.

Jasper Reporting – Inhalte verlinken

Published by Bernd Erk on 02.10.2009 in Development, German, ICINGA, Jasper Reporting, Nagios and Serien. 0 Comments

Teil 10 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting Vor einigen Tagen hatten wir schon das Thema Diagrammintegration angesprochen. Auf Basis dieses Beispiels beschreiben wir in diesem Post die Integration von Links in das Diagramm. Die Integration von URLs macht immer dann Sinn, wenn entweder eine aufrufbare Applikation die Basis der Reportingdaten erweitern kann oder wie im Beispiel von Nagios der Einstieg für die detaillierte Betrachtung durch den Report gesteuert wird.

Die Einstellung der Basis-URL erfolgt im Kontextmenü des Diagramms im Bereich “Section Hyperlink”. Hyperlink target bezeichnet das entsprechende Zielfenster des Links und Hyperlink type ergiebt sich aus der Auswahl der Parameterbefüllung.

Wie in iReport üblich erfolgt die Parametrisierung mittels Expression, welche in unserem Beispiel wie folgt lautet:

&http://guest:guest@nagios.demo.netways.de/nagios/cgi-bin/status.cgi?style=detail&amp;hostgroup=&quot; + $F{alias}

Die Übermittlung von Username und Passwort in einem Produktivsystem ist mit Sicherheit problematisch, vereinfacht jedoch den Aufruf des Nagios-Demosystems erheblich.

Als Tooltip kann ebenfalls eine Expression anlegen, welche die Ausgabe verschönert:

&Go to hostgroup in Nagios: & + $F{alias}

Auf die verschiedenen Textelemente des Reports, wie z.B. den Hostnamen sind Hyperlink auf die gleiche Art und Weise via Kontextmenü hinzufügbar. Auch die Verknüpfung mit anderen Reports ist möglich und Jasper kann so diverse Berichte miteinander verschachteln. Das Ergebnis kann sich auf jeden Fall sehen lassen.

Den entsprechenden Report findet ihr natürlich auf netways.org und unserem Demo-System.

Der nächste Post gibt eine Einführung in die Erstellung dynamischer Parameter.

Jasper Reporting – Diagramme hinzufügen

Published by Bernd Erk on 25.09.2009 in Development, German, Jasper Reporting and Serien. 0 Comments

Teil 8 von 15 in der Blogserie Jasper Reporting

Jasper-Reporting Die Hostobjekte werden nun bereits nach Hostgruppen gruppiert dargestellt und können auch mit Hilfe eines externen Parameters beeinflusst werden. Für einen besseren Überblick fügen wir dem Report jetzt ein Kuchendiagramm hinzu, welches uns auf der Ergebnisseite einen Überblick über die Hostverteilung gibt.

Über die Palette können wir das Diagramm-Symbol wählen und auf eine freie Stelle des Reports ziehen. Bei der Aufforderung des Diagrammtyps nehmen wir in diesem Beispiel das 3D-Kreisdiagramm. Darüber hinaus gibt es eine Vielzahl an Diagrammen, deren Eigenschaften jedoch auch zu den selektierten Daten passen muss. Aus meiner Sicht ist das Kreisdiagramm aber das Mittel der Wahl für die Darstellung von Verteilungen.

Nach erfolgter Auswahl lässt sich via Kontextmenü der Dateninhalt des Diagramms einstellen und im Tab Detail können die Daten bestehend aus Key expression, Value expression und Label expression eingetragen werden. Zusätzlich können die Werte können in den einzelnen Bereichen auch weiterverarbeitet, also z.B. summiert oder verändert werden.

In den Diagrammattributen kann für eine transparente Darstellung noch der Foreground Alpha (%) auf 0,5 gesetzt werden, was das Diagramm optisch abrundet. Das Ergebnis lässt sich im Preview sofort begutachten werden und man kann dort gleich noch Änderungen am Layout bzw. Größenverhältnis durchführen.

Die Einbindung eines Balkendiagramms erfolgt ähnlich, jedoch unter Angabe von Series-, Category- und Value-Expression. Wichtig ist die Angabe einer Increment group in den Dataset Einstellung, da dies als Iterator für die Balkenanzeige notwendig ist. Durch Anpassung der Label-Rotation auf 90 in den Eigenschaften des Diagramms können die entsprechenden Beschriftungen noch Vertikal dargestellt werden, was bei einer Vielzahl von Serien übersichtlicher ist.

Hier kann der entsprechende Report heruntergeladen werden und steht natürlich auch wieder auf netways.org und unserem Demo-System zur Verfügung.

Der nächste Post widmet sich der Anzeige von aktuellen Statusinformationen aus Nagios.

NETWAYS Blog

Archive for the 'Serien' Category

NETWAYS stellt sich vor – Birger Schmidt

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Serie NSClient++ – Teil 3: Basisüberwachung

Serie NSClient++ – Teil 2: Installation

Jasper Reporting – Zusammenfassung

Jasper Reporting – Distribution

Jasper Reporting – Host Availability

Jasper Reporting – Dynamische Parameter

Jasper Reporting – Inhalte verlinken

Jasper Reporting – Diagramme hinzufügen

Jobs bei NETWAYS

Tags

Countdown Timer

Show me posts in

Follow us on twitter

Last 5 Comments

Kategorien

Monatsarchiv

Blogroll

Links

Meta