Select Page

NETWAYS Blog

Icinga Webinare im Dezember

NETWAYS Webinare Nachdem im Rahmen einer wieder einmal erfolgreichen OSMC sowohl eine neue Version von Icinga 2 als auch Icinga Web 2 veröffentlicht wurde, wollen wir natürlich die Gelegenheit nutzen, diese in unseren Webinaren vorzustellen.
Die Termine im Dezember stehen bereits fest und wir freuen uns wie immer auf eine rege Teilnahme zum Abschluss dieses erfolgreichen Jahres!

Titel Zeitraum Registrierung
Icinga 2 – Neues in 2.4 08. Dezember 2015 – 10:30 Uhr Anmelden
Icinga Web 2: Das neue Interface 09. Dezember 2015 – 10:30 Uhr Anmelden
Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Improved NodeJS Events durch Cluster …


… jeder von euch kennt das Problem, der Kollege kommt um die Ecke und möchte wenn möglich sofort, dass ein neues geiles Tools mit in den Infra Stack aufgenommen wird, gesagt getan.
In diesem Bespiel eine besonders cooles in NodeJS geschriebenes Dashboard für… lass es hier ein DockerManagement Tool sein. Dabei stößt man bei der großen Akzeptanz durch die Kollegen, auch auf einmal auf noch ganz andere Probleme (Stichwort: Performance Bottlenecks wie DDoS durch eigene Leute).
Hierbei könnte euch das NodeJS Modul Cluster behilflich sein, hier ist die Doku zu finden.
Cluster macht dabei nicht viel, es erweitert den NodeJS Stack insbesondere das Event Driven Modell von NodeJS ( so Arbeitet Google(s) v8 Engine ) um eine Art Interprocess Schnittstelle zu forked Child NodeJS Prozessen, die sich dabei Filesystem Elemente/Typen wie Sockets, Filedeskriptoren etc. teilen können und somit gemeinsam auf diesen operieren können.
Hier wollen wir eine schon bestehende Express Framework Anwendung mit einigen wenigen Zeilen Code um die Fähigkeit erweitern, dem System zur Verfügung stehenden CPU Cores effizienter ausnutzen zu können, damit sich die Events schneller abarbeiten lassen.
Ich werde hier allerdings nicht Express selber beschreiben, sondern setzte hier voraus das der Leser dieses Framework kennt. Wenn nicht könnt ihr die Infos unter diesem Link abrufen, so let’s beginn …

$ sudo -i                                  # <- da meine Workstation ein Ubuntu ist sollten wir zumindest was die Essentials sind kurz zu 'root' werden um diese Problemlos installiert zu bekommen
$ npm install express -g                   # <- installiert uns das Express Framework samt CLI Tools
express@4.13.3 /usr/lib/node_modules/express
├── escape-html@1.0.2
├── merge-descriptors@1.0.0
├── cookie@0.1.3
├── array-flatten@1.1.1
├── cookie-signature@1.0.6
├── utils-merge@1.0.0
├── content-type@1.0.1
├── fresh@0.3.0
├── path-to-regexp@0.1.7
├── content-disposition@0.5.0
├── vary@1.0.1
├── etag@1.7.0
├── serve-static@1.10.0
├── range-parser@1.0.2
├── methods@1.1.1
├── parseurl@1.3.0
├── depd@1.0.1
├── qs@4.0.0
├── on-finished@2.3.0 (ee-first@1.1.1)
├── finalhandler@0.4.0 (unpipe@1.0.0)
├── debug@2.2.0 (ms@0.7.1)
├── proxy-addr@1.0.8 (forwarded@0.1.0, ipaddr.js@1.0.1)
├── send@0.13.0 (destroy@1.0.3, statuses@1.2.1, ms@0.7.1, mime@1.3.4, http-errors@1.3.1)
├── type-is@1.6.9 (media-typer@0.3.0, mime-types@2.1.7)
└── accepts@1.2.13 (negotiator@0.5.3, mime-types@2.1.7)
$ npm install express-generator -g
/usr/bin/express -> /usr/lib/node_modules/express-generator/bin/express
express-generator@4.13.1 /usr/lib/node_modules/express-generator
├── sorted-object@1.0.0
├── commander@2.7.1 (graceful-readlink@1.0.1)
└── mkdirp@0.5.1 (minimist@0.0.8)
$ exit                                     # <- ab hier geht es ohne 'root' Rechte weiter
$ mkdir cool-app && cd cool-app            # <- Projekt Verzeichnis anlegen und in dieses wechseln
$ pwd                                      # <- vergewissern das wir uns auch in diesem wirklich befinden
/home/enzo/nodejsProjects/cool-app
$ express --git .                          # <- wir provisionieren uns unser Projekt from Scratch, dieses ist somit direkt Lauffähig ohne das wir einen Zeile Code schreiben müssen, haben hier leider keine Zeit zu ;)
   create : .
   create : ./package.json
   create : ./app.js
   create : ./.gitignore
   create : ./public
   create : ./routes
   create : ./routes/index.js
   create : ./routes/users.js
   create : ./views
   create : ./views/index.jade
   create : ./views/layout.jade
   create : ./views/error.jade
   create : ./bin
   create : ./bin/www
   create : ./public/javascripts
   create : ./public/images
   create : ./public/stylesheets
   create : ./public/stylesheets/style.css
   install dependencies:
     $ cd . && npm install
   run the app:
     $ DEBUG=cool-app:* npm start
$

Ab hier können wir das ganze mal kurz testen, um uns zu vergewissern das die Anwendung auch läuft ...

$ npm start
> cool-app@0.0.0 start /home/enzo/nodejsProjects/cool-app
> node ./bin/www

Nicht wundern die Applikation bleibt im Vordergrund hängen, was ist Ok ist, somit können wir diese schneller terminieren und relaunchen. Weiter geht es mit einem Test im Browser, die Anwendung lauscht standardmäßig am Port 3000, somit rufen wir hier einmal http://localhost:3000 auf und lassen uns überraschen was da so schönes kommt ...

Geil es läuft also, nun gut machen wir das ganze mit Cluster noch skalierbarer, let's go ...
Öffnet hierzu im Projekt Verzeichnis einmal die bin/www Datei, diese stellt laut package.json unseren Eintrittspunkt in die Anwendung dar, wir kopieren uns diese als Backup weg bevor wir anfangen hier Änderungen vorzunehmen.
Kommentiert bitte folgende Zeilen einmal aus ...

/**
 * Get port from environment and store in Express.
 */
var port = normalizePort(process.env.PORT || '3000');
app.set('port', port);
/**
 * Create HTTP server.
 */
var server = http.createServer(app);
/**
 * Listen on provided port, on all network interfaces.
 */
server.listen(port);
server.on('error', onError);
server.on('listening', onListening);

... nun fügt ihr ab Zeile 10 bitte folgendes hinzu ...

// cluster requirements
var cluster = require('cluster');
var numCPUs = require('os').cpus().length;
if( cluster.isMaster ) {
  for( var i = 0; i < numCPUs; i++ ) {
    cluster.fork();
  }
  cluster.on( 'listening', function( worker ){
    console.log( 'worker ' + worker.process.pid + ' is now listen for incoming connections ... ' );
  });
  cluster.on( 'exit', function( worker, code, signal ) {
    console.log( 'worker ' + worker.process.pid + ' died' );
  });
} else {
    // Workers can share any TCP connection
    // In this case it is an HTTP server
    /**
    * Get port from environment and store in Express.
    */
    var port = normalizePort(process.env.PORT || '3000');
    app.set('port', port);
    /**
    * Create HTTP server.
    */
    var server = http.createServer(app);
    /**
    * Listen on provided port, on all network interfaces.
    */
    server.listen(port);
    server.on('error', onError);
    server.on('listening', onListening);
}

.. jetzt sollte das ganze auch schon funktionieren, probieren wir es doch einmal aus.

$ npm start
> cool-app@0.0.0 start /home/enzo/nodejsProjects/cool-app
> node ./bin/www
worker 31979 is now listen for incoming connections ...
worker 31974 is now listen for incoming connections ...
worker 31985 is now listen for incoming connections ...
worker 31996 is now listen for incoming connections ...
GET / 304 840.784 ms - -
GET /stylesheets/style.css 304 31.416 ms - -

Jetzt könnte man denken das sich hier nichts geändert hat, dem ist aber nicht so, der Beweis ist in der Prozess Tabelle zu finden, gucken wir doch kurz einmal hinein ...

$ ps auxf | grep node
enzo     31969  0.1  0.4 901264 33004 pts/7    Sl+  14:47   0:00          |   |       \_ node ./bin/www
enzo     31974  0.1  0.4 901256 32324 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31979  0.4  0.6 946192 47560 pts/7    Sl+  14:47   0:01          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31985  0.1  0.4 902668 32736 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31996  0.1  0.4 901256 32168 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www

Whoop whoop, 4 neue NodeJS Prozesse die hier ihre Arbeit verrichten, somit lassen sich auch die beschäftigsten Web Anwendungen wieder beschleunigen.
Das ist aber nur der Anfang wie sich NodeJS Applications aller Art verbessern lassen, für weiter Themen habe ich heute allerdings keine Zeit daher heben wir uns den Rest einfach für ein anderes mal auf.
Ich wünsche euch hiermit noch viel Spaß, ich hoffe ihr habt nun mehr Lust auf NodeJS bekommen.

Azubis erzählen: September 2015 Alexander

This entry is part 12 of 17 in the series Azubis erzählen

Name: Alexander Klimov
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Development
Lehrjahr: 2

C hat keine DLLs, sondern nur Headers”, sagte einst einer meiner ehemaligen Berufsschulklassenkollegen.
Solch grob fahrlässige fachbezogene Aussagen gebe ich nicht von mir – zumindest seit ich bei NETWAYS ausgebildet werde. Das Gegenteil des obigen Zitats habe ich hier nicht gelernt, dafür aber einige andere sehr interessante Sachen, die ich diesmal vorstellen will.

Git

Wer von den Fachinformatiker-Auszubildenden kennt das nicht: In der Berufsschule wird im Fach Anwendungsentwicklung und Programmierung ein Programm schrittweise weiterentwickelt und es wird einem nahe gelegt, vor jeder größeren Erweiterung des Programms den Quellcode zu sichern, um ggf. auf einen älteren Stand zugreifen zu können. Für diesen Zweck ist die Versionskontrolle Git viel besser geeignet – nicht zuletzt auch weil das Pflegen von vielen Versionen viel “attraktiver” ist. Ich hatte zu meinem Glück immer meinen Laptop dabei und kaum ein Programm, dessen Entwicklung nicht auf eine Schulstunde beschränkt war, ohne Git entwickelt.

$ mkdir AWP/Parkautomat && cd $_
$ git init
$ editor parkautomat.cpp && git add $_
$ git commit -m "Implementiere einen übertrieben übertriebenen Parkautomaten"
$ editor parkautomat.cpp && git add $_
$ git commit -m "Statte den Parkautomaten mit Funktionalität, die kein Mensch braucht, aus"

Zuletzt hat mich ein Kollege das Bisect-Kommando gelehrt. Dieses Wissen habe ich natürlich guten Willens bei nächstbester Gelegenheit weitergegeben.

Vim

Als ich bei NETWAYS angefangen habe, habe ich ernsthaft noch den Texteditor Nano verwendet – mit Ausreden wie “er genügt meinen Ansprüchen”. Aber kaum dass mir ein schönes neues Werkzeug in die Hände fällt, lasse ich den alten, primitiven Kram hinter mir. Auch in der Berufsschule hat der Editor gute Dienste geleistet. Es fiel mir viel leichter, damit zu arbeiten, als mit dem an der Schule propagierten Visual Studio. (Da liest mein Banknachbar in der 1. AWP-Stunde die 5-10-seitige bilderreiche Einführung in das letztgenannte Programm, während ich das zu schreibende Hallo-Welt-Programm schon längst mit Vim abgetippt und mit GCC kompiliert habe. Und – wer hätte das gedacht 😉 – es funktionierte!) Auch ich gehöre mittlerweile zu den Programmierern, die an ihrer .vimrc hängen.

$ cat ~/.vimrc
set bg=dark nu mouse=a ai et sts=4
sy on
nmap <F4> :qa<CR>
language de_DE.utf8
highlight Normal guibg=Black guifg=White

Puppet

… ist aus einer komplexen und automatisierten IT-Welt wie unserer nicht wegzudenken. Ob viele gleichartige Systeme aufwandarm aufgesetzt werden müssen oder die Entwicklungsumgebungs-VM eines Projektes mit einer Komanndozeile einsatzbereit sein muss – Puppet ist des Systemadministrators Freund und Helfer. Alleine die verglichen mit der konventionellen Bash verkürzte, intuitive und anti-redundante schreibweise für häufig verwendete Komponenten machen die Sprache attraktiv. Die Möglichkeit, Abhängigkeiten der Komponenten untereinander explizit zu definieren, nötigt bei komplexeren Beschaffungen der Systeme regelrecht zur Nutzung von Puppet. Im Rahmen eines Umbaus von Icinga Web 2 habe ich den Aufbau und die Funktionsweise von Puppet kennen gelernt. Mit Hilfe dieses Wissens habe ich für das jüngste von mir betreute Projekt von Grund auf Puppet-Manifeste geschrieben, um mir und anderen die Entwicklung zu erleichtern. Folgendes Beispiel installiert den Apache-Webserver auf Debian/Ubuntu, Fedora/RHEL, openSUSE/SLES und darauf basierenden Systemen:

$apache = $osfamily ? {
  'Debian' => 'apache2',
  'Suse'   => 'apache2',
  'RedHat' => 'httpd',
}
package { $apache:
  ensure => latest,
}
-> service { $apache:
  ensure => running,
  enable => true,
}

SQL

Angesichts des hohen Datenaufkommens, das Anwendungen heutzutage zu bewältigen haben, sind relationale Datenbanken unverzichtbar. Die Vielzahl unterschiedlicher Datenbankmanagementsysteme fordert einen möglichst großen gemeinsamen Nenner der Abfragesprachen. Dieser wurde mit SQL 1986 geschaffen und ist – nicht nur meiner Meinung nach – absolute Pflichtlektüre eines jeden werdenden Fachinformatikers. Im Rahmen der Entwicklung einer Stammdatenverwaltungssoftware bin ich dieser interessanten Thematik gelehrt worden – und auch in der Berufsschule soll das noch auf mich zukommen. Einer der größten Nutzen relationaler Datenbanken ist die Möglichkeit, Datensätze nur ein mal speichern zu müssen und mehrfach darauf verweisen zu können. Folgendes Beispiel ist eine Abfrage der Klassen und -leitungen von Schülern:

SELECT sn.name, k.name, ln.name
FROM schueler AS s
INNER JOIN klasse AS k ON k.id=s.klasse_id
INNER JOIN lehrer AS l ON l.id=k.lehrer_id
INNER JOIN natuerliche_person AS sn ON sn.id=s.natuerliche_person_id
INNER JOIN natuerliche_person AS ln ON ln.id=l.natuerliche_person_id;

Die Personalien von Schülern und Lehrern und evtl. anderen natürlichen Personen werden hierbei – da gleichartige Datensätze – in einer Tabelle gespeichert. Da bspw. ein Lehrer mehrere Klassenleitungen haben kann, wird er nur ein mal gespeichert und über lehrer.id referenziert, um Redundanz zu vermeiden.

Fazit

Lehrjahre sind zwar keine Herrenjahre, können aber eine große Bereicherung sein – vor allem für die kommenden Herrenjahre. Und mein vergangenes Lehrjahr hat gezeigt: Sich reinzuhängen lohnt sich – auch bei den unbeliebten Berufsschulfächern.

Alexander Klimov
Alexander Klimov
Senior Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Monthly Snap August: Monitoring Plugins, Icinga 2 on Windows 10, Tips and Tricks for Git, Docker and CoreOS

August started with Enrico´s post about a check for S.M.A.R.T. values which he has been using already successfully for one year.
Markus F. announced his talk “Why favor Icinga over Nagios?” at DebConf15 where NETWAYS is also sponsor.camera
Bernd counted 84 days to the OSMC with Oliver Jan´s talk: “Time to say goodbye to your Nagios based setup?”
Christoph looked at how to write monitoring plugins on your own and Sebastian told us about the core component of CoreOS etcd and gave us a quick example of how to use it.
Michael followed with his post about how to develop Icinga 2 on Windows 10 by using Visual Studio 2015 and Thilo explained us why time is unique.
Blerim explained why logging, especially with Docker, should be part of every good monitoring.
Finally, Matthias showed tips and tricks for using Git Bisect to find a fix for a problem rather than finding the commit that introduced a problem.

Stephanie Kotilge
Stephanie Kotilge
Accountant

Steffi ist seit 2011 bei NETWAYS. Sie fing als Office Managerin an und unterstützt seit 2017 als Accountant das Finance & Administration Team in allen buchhalterischen Belangen. In ihrer Freizeit ist sie mit ihrem Sohn immer auf der Suche nach den schönsten Spielplätzen in Nürnberg oder plant den nächsten Familientrip.

check_smartvalues Release … YEAH!!!

Endlich bin ich dazu gekommen, den schon im Post vom letzten Sommer angekündigten Check für S.M.A.R.T. -Werte zu veröffentlichen.
Ich hatte es ja schon angedroht, nun mache ich es wahr. 😉
Wir haben diesen Check nun schon ein gutes Jahr im Betrieb und er liefert seine Daten von daher kann ich ihn nur wärmstens empfehlen.
Bilder gibt es dieses Mal auch zu sehen, lasst sie am besten einfach mal auf euch wirken.
Wenn der Eine oder Andere von euch noch weitere tolle Ideen/Vorschläge hat, dann lasst es uns wissen. Wir lieben Monitoring, von daher stehen die Chancen recht gut, dass wir noch mehr umsetzen wollen.
Ich schrieb ja auch schon, dass die freundlichen Kollegen der Thomas Krenn AG auch ein Plugin für das Ermitteln der S.M.A.R.T. -Werte gebaut haben, dieses erfüllt im Wesentlichen auch die gleichen Aufgaben. Ich wollte das Ganze aber doch noch ein wenig toppen.
Hier ein paar Beispiele wie es aufzurufen ist:

# cd /path/to/check/smartvalues
# ./check_smartvalues -db check_smartvalues.db.json -c check_smartvalues.db.json -s -d 'megaraid,22 /dev/sda'
OK: [ 22 OK ] - [ 0 WARNING ] - [ 0 CRITICAL ] - [ 0 UNKNOWN ] in 0.163578987121582ms ( for details pls take a look in longoutput )
OK: on LSI MegaRAID - [ DeviceID 22 ] - #5 - Reallocated_Sector_Ct is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #9 - Power_On_Hours is [ 100 ] - [ w: 200, c: 300 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #12 - Power_Cycle_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #170 - Available_Reserved_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #171 - Program_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #172 - Erase_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #174 - Unexpected_Power_Loss is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #183 - Runtime_Bad_Block is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #184 - End-to-End_Error is [ 100 / 090 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #187 - Reported_Uncorrect is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #190 - Airflow_Temperature_Cel is [ 31 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #192 - Power-Off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #199 - UDMA_CRC_Error_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #225 - Host_Writes is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #226 - Timed_Workload_Media_Wear is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #227 - Timed_Workload_Host_Read/Write _Ratio is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #228 - Power-off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #232 - Available_Reservd_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #233 - Media_Wearout_Indicator is [ 043 ] - [ w: 35, c: 25 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #241 - Total_LBAs_Written is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #242 - Total_LBAs_Read is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #249 - Total_NAND_Writes is [ 100 ]

oder mit mehr als nur einer Platte …

# ./check_smartvalues -db check_smartvalues.db.json -c check_smartvalues.db.json -s -d 'megaraid,22 /dev/sda' -d 'megaraid,21 /dev/sda'
OK: [ 44 OK ] - [ 0 WARNING ] - [ 0 CRITICAL ] - [ 0 UNKNOWN ] in 0.18438987121582ms ( for details pls take a look in longoutput )
OK: on LSI MegaRAID - [ DeviceID 22 ] - #5 - Reallocated_Sector_Ct is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #9 - Power_On_Hours is [ 100 ] - [ w: 200, c: 300 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #12 - Power_Cycle_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #170 - Available_Reserved_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #171 - Program_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #172 - Erase_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #174 - Unexpected_Power_Loss is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #183 - Runtime_Bad_Block is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #184 - End-to-End_Error is [ 100 / 090 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #187 - Reported_Uncorrect is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #190 - Airflow_Temperature_Cel is [ 31 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #192 - Power-Off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #199 - UDMA_CRC_Error_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #225 - Host_Writes is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #226 - Timed_Workload_Media_Wear is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #227 - Timed_Workload_Host_Read/Write _Ratio is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #228 - Power-off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #232 - Available_Reservd_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 22 ] - #233 - Media_Wearout_Indicator is [ 043 ] - [ w: 35, c: 25 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #241 - Total_LBAs_Written is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #242 - Total_LBAs_Read is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #249 - Total_NAND_Writes is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #5 - Reallocated_Sector_Ct is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #9 - Power_On_Hours is [ 100 ] - [ w: 200, c: 300 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #12 - Power_Cycle_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #170 - Available_Reserved_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #171 - Program_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #172 - Erase_Fail_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #174 - Unexpected_Power_Loss is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #183 - Runtime_Bad_Block is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #184 - End-to-End_Error is [ 100 / 090 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #187 - Reported_Uncorrect is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #190 - Airflow_Temperature_Cel is [ 32 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #192 - Power-Off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #199 - UDMA_CRC_Error_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #225 - Host_Writes is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #226 - Timed_Workload_Media_Wear is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #227 - Timed_Workload_Host_Read/Write _Ratio is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #228 - Power-off_Retract_Count is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #232 - Available_Reservd_Space is [ 100 / 010 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #233 - Media_Wearout_Indicator is [ 041 ] - [ w: 35, c: 25 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #241 - Total_LBAs_Written is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #242 - Total_LBAs_Read is [ 100 ]
OK: on LSI MegaRAID - [ DeviceID 21 ] - #249 - Total_NAND_Writes is [ 100 ]

und hier das Ergebnis im neuen Icinga Web 2 …
sdd22-smart-values
 
Nützliche Links: