Festplattenauslastung messen
Der freie Speicherplatz einer Festplatte ist ein kritisches Kriterium auf jedem System, aber nicht das Einzige. Es ist auch möglich das eine Festplatte altersbedingt (oder von den Grundvoraussetzungen) den Anforderungen nicht mehr gewachsen ist. Eine volle Warteschlange oder hohe Latenzen über einen längeren Zeitraum können daher ein Hinweis sein. Eine Kunde kam genau mit dieser Frage auf mich zu und wie man so etwas in servereye abbilden kann.
Die Antwort ist, es gibt mehrere Möglichkeiten wie Sie dies tun können. Da solche Performancewerte schwierig zu analysieren sind (bezogen auf einen möglichen Alarm), ist es häufig sinnvoller den Verlauf zu protokollieren und dann an Hand dieser Daten selbst zu prüfen ob es Änderungen im Bezug auf die Vergangenheit gab. Denn niemand will dauernd Fehlalarme.
Unser Sensor Festplatten Gesundheit prüft in erster Linie den Status der Festplatte seitens des Betriebssystems. Das ist die Hauptfunktion und durch einen negativen Status wird ein Fehler ausgelöst. Allerdings liefert der Sensor im Chart genau diese wichtigen Festplatten-Performancewerte und protokolliert diese je Prüfintervall.
In diesem Fall passiert über eine Woche lang nichts. Der Server langweilt sich, doch gegen Ende der Woche gibt es erhöhte Auslastungen. Das muss in diesem Fall nichts schlimmes sein, es kann aber helfen ein Problem zu verstehen. Vielleicht hat der Kunde sich an diesem Tag beschwert über langsame Performance und als Ursache hat ein Techniker einfach große Datenmengen kopiert oder ein Backup lief.
Der Sensor bietet dabei folgende Messwerte für das ausgewählte Laufwerk:
- Avg. Disk Read Queue Length
- Avg. Disk Write Queue Length
- Avg. Disk Sec/Read
- Avg. Disk sec/Transfer
- Avg. Disk Queue Length
- % Disk Time
- % Idle Time
Infos zu den einzelnen Werten findet man auch im MSDN
https://msdn.microsoft.com/en-us/library/ms804035.aspx
Die zweite Möglichkeit in servereye wäre es den generischen WMI Sensor zu benutzen, WMI Abfrage.
Da ist aber etwas mehr Eigeninitiative gefordert. Sie müssen sich eine Abfrage basteln und den Wert gegen einen Schwellwert vergleichen. Im Prinzip führen wir hier eine Abfrage der Windows Performance Counter durch.(die Sie vielleicht von perfmon.exe kennen)
Mit einem WMI Explorer können Sie sich auf einem System die verfügbaren Werte ansehen. Die relevanten für Ihre Festplatte finden Sie unter "Win32_PerfRawData_PerfDisk_LogicalDisk" oder "Win32_PerfRawData_PerfDisk_PhysicalDisk".
Das war schon der schwerste Part :). Jetzt kommt der einfache. Um den Sensor zu konfigurieren sind quasi alle Werte schon auf dem Bild erkennbar. Wir starten mit dem Vergleich. Wenn mehr wie 5 Elemente in der Warteschlangen enthalten sind, soll es einen Alarm geben. Der Wert CurrentDiskQueueLength enthält diesen.
Die eigentliche Abfrage lässt sich aus dem Feld Query 1:1 kopieren und da wir den Standard-Namensraum nutzen ist dieser schon vorausgefüllt. Fertig!
Wenn ich das ganze nun nicht für alle Datenträger zusammen prüfen will, kann ich noch die Abfrage bearbeiten und das ganze eingrenzen.
Zum Beispiel wie folgt:
SELECT * FROM Win32_PerfRawData_PerfDisk_LogicalDisk WHERE Name LIKE "C:"
Nun wird nur das Laufwerk C analysiert.
Einen wichtigen Hinweis bei der Alarmierung will ich aber noch geben. Ich hatte oben das Problem der Fehlalarme angesprochen. Es macht sicher keinen Spaß jeden Tag hunderte Emails zu bekommen, nur weil kurzfristig die Warteschlange den Grenzwert erreicht hat. Deswegen nutzen wir den Mechanismus der Verzögerung. Wenn der Sensor zum Bsp alle 5 Minuten prüft, könnte ich mir vorstellen das ein Alarm erst interessant ist wenn die Warteschlange länger wie 40 Minuten voll ist. Ich lege also einfach eine gewünschte Verzögerung an und erhalte so erst einen Alarm, wenn es wirklich kritisch ist. Trotzdem werden die Performancewerte natürlich pro Intervall protokolliert.
Wenn Sie noch Fragen oder Anregungen hier zu haben können Sie uns einfach jederzeit kontaktieren :)
Windows Updates überwachen
In servereye ist es schon länger möglich Ihr System auf fehlende Windows Updates zu überwachen.
Ab Mai wird es dabei zwei neue Filtermöglichkeiten geben, die ich Ihnen in diesem Artikel näher vorstellen möchte.
In servereye können Sie eine Überwachung von Windows Updates basierend auf ausgewählten Kategorien vornehmen. Dadurch ist es möglich, dass eine Alarmierung erfolgt wenn zum Beispiel mehr als 10 kritische oder sicherheitsrelevante Updates nicht installiert wurden. Die auswählbaren Kategorien ( wie“Critical Update“ und „SecuriyPatch“) sind interne Werte der Windows Update API und entsprechen nicht der Kennzeichung „wichtig“ und „optional“ in der Windows Update Ansicht. Da dies ganz schön verwirrend sein kann, haben wir uns dazu entschieden zwei neue Filtermöglichkeiten hinzuzufügen. Zum einen um zukünftig Missverständnisse zu minimieren und zum anderen weil wir das Kundenfeedback nutzen wollen um unsere Überwachung zu erweitern.
- Automatic Updates
- Automatic Updates (Important)
Diese Filter entsprechen 1:1 der Anzeige in der Windows Update Ansicht. Der erste Filter listet alle wichtigen und optionalen Updates auf. Der zweite nur die wichtigen und ist gleichzeitig auch die neue Standardeinstellung in unserer PC Gesundheit Überwachung.
Anbei sehen Sie einen Vergleich der Werte in servereye und Windows Update.
Wichtige Updates
Wichtige und Optionale
Es bleibt Ihnen natürlich weiterhin überlassen die internen Kategorien zu nutzen. Beachten Sie bitte nur, das es dann zu Unterschieden bezüglich der Anzeige in servereye und Windows Update kommen kann.
VMware - Neue Sensoren und Tipps bei der Umstellung
Mit dem Mai Update verlassen unsere neuen VMware PowerCLI Sensoren den Beta-Status. Das bedeutet aber auch das die Abschaltung der alten VMware Sensoren näher rückt. Ich möchte Ihnen in diesem Artikel Infos zum Grund der Umstellung liefern und Tipps wie Sie den Prozess beschleunigen können.
Schon im November 2014 haben wir Sensoren für die PowerCLI von VMware herausgebracht. Das hat zum einen den Hintergrund, dass die bis dahin genutzte API so nicht mehr unterstützt wird, zum anderen aber vor allem die deutliche Verbesserung der Monitoring-Qualität die wir dadurch erzielen.
Die PowerCLI bietet viel mehr Möglichkeiten Fehler zu erkennen und die Hardware besser zu überwachen. Manche Features wie die Snapshot-Existenz (in Minuten) oder die Auswahl der zu ignorierenden Ordner wurden gar erst durch diese Umstellung ermöglicht.
Wir werden ab dem 01.06.2015 den Support für die alten Sensoren einschränken, zum 01.09 endet er dann komplett.
Weiterhin werden die Sensoren ab 01.01.2016 komplett abgeschaltet. Kunden die diese Sensoren dann noch nutzen werden wir natürlich noch mal gezielt informieren.
Ich zeige Ihnen nun wie Sie die neuen Sensoren nutzen können, was für Voraussetzungen es gibt und wie man mit ein paar Tricks viel schneller diese Sensoren anlegen kann.
Schritt 1 – Voraussetzungen
Die erste Voraussetzung, die aber auch gleichzeitig eine Voraussetzung der PowerCLI selbst ist, ist die Skript-Policy. Es muss erlaubt sein PowerShell Skripte auszuführen.
Das können Sie ganz schnell setzen auf dem System mit dem Befehl Set-ExecutionPolicy RemoteSigned. Achten Sie nur das die PowerShell als Admin gestartet ist.
Die zweite Voraussetzung ist natürlich eine installierte PowerCLI. Diese können Sie auf der VMware Seite beziehen. Das PowerCLI hat dabei bestimmte Voraussetzungen (es muss z. Bsp ein vsphere Client installiert sein).
Achten Sie auf eine aktuelle Version der PowerCLI.
Falls noch keine Skripte ausgeführt werden dürfen erhalten Sie beim installieren nochmal eine Warnung. Ist alles durchgelaufen, sollten Sie die PowerCLI einmal starten.
Im positiven Falle sieht das so aus
Im negativen Fall, wenn immer noch keine Skripte ausgeführt werden dürfen, gibt es eine Fehlermeldung
Schritt 2 – Das schnelle Anlegen
Je nach dem welche Sensoren Sie nutzen wollen gibt es nun 2-3 Befehle um die entsprechenden Daten anzuzeigen. Normalerweise wählen Sie im Sensor über das OCC direkt den ESX aus oder den Datastore den Sie überwachen möchten. Das ist super wenn man nur 1-2 Sensoren anlegt. Will man aber mehr als 10 Sensoren nutzen bedeutet das auch, dass man jedesmal die Zeit des Verbinden der PowerCLI bis zum Ausführen des Befehls warten muss, da wir im Sensor ja eine neue Verbindung aufbauen müssen.
Wenn Sie sich nun aber die einzutragenden Werte ausgeben lassen und einfach in den Sensor kopieren, sparen Sie richtig viel Zeit!
Lassen Sie die PowerCLI also noch offen und verbinden Sie sich einmal mit Ihren Zugangsdaten. Das erfolgt über den Befehl Connect-VIServer (IPdesESXoderVCenters)
Die ESX-IPs bekommen Sie angezeigt mit dem Befehl Get-VMHost
Die Daten unter Name sind die Werte die im Sensor Hostgesundheit für VmWarePowerCLI unter „Host System“ kommen. Sie können also alles direkt ausfüllen.
Für Datastores gibt es den Befehl Get-Datastore
Die letzte Möglichkeit stellt die einzelnen VMs dar. Diese sind abrufbar mit Get-VM.
Falls die Namen nicht vollständig in die Anzeige passen geht auch Get-VM |Select-Object Name
Durch dieses Verfahren sparen Sie locker 5-10 Minuten pro Kunde.
Schritt 3 – Glücklich sein
Das Ergebnis entlohnt dann auch alle Mühen, denn Sie erhalten nicht nur eine schönere Ausgabe sondern auch deutlich mehr Infos.
Hier zu erkennen an einem „kleinen“ Ausschnitt des „Hostgesundheit für VmWare PowerCLI“ Sensors.
Bei Fragen können Sie sich natürlich jederzeit an unseren Support wenden. Auch für Verbesserungsvorschläge haben wir ein offenes Ohr.
Auswertung einer Warenwirtschaft – Tipps und Tricks
Vor kurzem erreichte uns ein Kundenwunsch, der mich dazu inspirierte diesen Blog Artikel zu schreiben und deutlich zu machen wie man generische Sensoren in servereye nutzen kann um eine simple Funktion abzubilden. Dabei ging es um Auswertungen einer Warenwirtschaft, welche diese Features aber nicht bot.
Dabei war der Wunsch eigentlich sehr simpel. Es ging ihm um 3 wichtige Aspekte über die er informiert werden wollte:
- Lagerstand erreicht Wert x
- offene Posten bei Kunden/Lieferanten erreicht Wert x
- Kontostand unterschreitet Wert x
Anhaltspunkt für die Überwachung war in diesem Fall die vorhandene SQL Datenbank. Aber auch Oracle und MySQL könnte man in servereye abbilden.
Die SQL Sensoren erlauben aus Sicherheitsgründen natürlich nur ein einfaches Select und es werden auch nie sicherheitskritische Daten an das OCC übertragen. Es wird lediglich die Anzahl der Zeilen zurückgegeben.
Wenn man obige 3 Szenarien nun in einem Sensor abbilden will funktioniert das in unserem Beispiel wie folgt.
SELECT SUM(OPKunden) as OPKundenGesamt, SUM(WareImLager) as WareImLagerSUM,SUM(Geldkonten) GeldSUM
FROM CONTROL_BWAHISTORIE
where stand > (GETDATE() -1)
having SUM(OPKunden) > 35000 or SUM(WareImLager) >20000 or SUM(Geldkonten) < 15000
Das ist unsere SQL Abfrage. Es werden einfache Werte summiert und auf Schwellwerte verglichen. Die Funktion GetDate wird hier benutzt, damit nur der Stand aus den letzten 24 Stunden abgeglichen wird. Die Abfrage ist aber natürlich auf das benutzte Warenwirtschaft System zugeschnitten.
Jetzt muss ich im Sensor "MS-SQL Abfrage" nur noch die Query und die Datenbankdaten eintragen und schon kann ich meinen Kunden mit einer individuellen Überwachung glücklich machen. Für drei unabhängige Alarme kann man die obige Abfrage einfach aufsplitten und in dire Sensoren nutzen.
Dank der Messwerte bei den zurückgegebenen Zeilen, kann ich aber auch ganz andere Auswertungen durchführen die der Warenwirtschaft (oder irgendeiner anderen Software mit Datenbank) vielleicht fehlen.
Bei Fragen können Sie natürlich wie immer unseren Support kontaktieren, wir helfen Ihnen gerne aus :)
Korrekte Systemzeitsynchronisierung
Wenn Sie sicherstellen wollen, dass in Ihrem Netzwerk immer die korrekte Systemzeit angezeigt wird gibt es mehrere Wege. Im Folgenden Beispiel zeige ich Ihnen, wie einfach Sie das ganze in servereye lösen können. So kommen Sie dann auch pünktlich zu Ihren Terminen.
Einleitung
Wenn Sie eine Systemzeitsynchronisierung vornehmen wollen, dann ist der erste Schritt die Auswahl eines NTP-Servers. NTP steht dabei für Network Time Protocol und stellt den Standard für die Synchronisation in Computernetzen dar. Aktuell verwenden wir in servereye noch den Dienst der Physikalisch-Technischen Bundesanstalt (PTB), diesen werden wir allerdings demnächst ablösen durch Server des NTP Projektes. Nähere Informationen zu dem Projekt und dem aktuellen Serverumfang finden Sie http://www.pool.ntp.org/zone/de
Das liegt vor allem daran, das zum Zeitpunkt der Erstellung dieses Artikels ganze 504 Server sich daran beteiligen und so eine zuverlässige Synchronisierung gewährleistet wird.
Zusätzlich empfiehlt es sich in Ihrem Netzwerk einen Server zu beauftragen, der die Zeit gegen diese externe Quelle synchronisiert. Klassisch übernimmt das der Domänencontroller. Alle anderen Systeme synchronisieren sich dann wiederum gegen diesen. So muss nicht jedes System eine Internetverbindung vorweisen und Sie minimieren auch die Anfragen an den entsprechenden NTP Server selbst.
Sollten Sie bereits eine Überwachung in servereye nutzen, stellen Sie diese bitte auf den NTP-Server de.pool.ntp.org um.
Monitoring in servereye
Nun müssen Sie nichts aufwendig konfigurieren, sondern Sie können servereye die ganze Arbeit überlassen.
Dazu nutzen Sie einfach unseren Sensor Zeitdienstüberwachung. Die vorgeblendete Konfiguration ist dabei schon ausreichend.
Unsere Vorschläge geben dabei direkt schon die richtige Konfiguration je nach System vor. Auf einem DC erscheint ein Vorschlag mit dem Vermerk "Extern" und auf anderen Systemen wird der Vermerk (Intern) angezeigt. Die Interne Prüfung hat dann automatisch als Zeitserver schon den entsprechenden Domaincontroller eingetragen.
Im OCC sieht das jeweils so aus:
Sobald eine Abweichung vorliegt, erhalten Sie eine Fehlermeldung und die Information das die Zeit automatisch für Sie korrigiert wurde. So können Sie sich protokollieren lassen wie häufig eine Korrektur vorkommt. Sollte es dann wirklich öfters zu Zeitkorrekturen kommen, macht es Sinn die automatische Korrektur per Einstellung zu deaktivieren und auf dem System auf Problemsuche zu gehen.
Nutzen Sie dazu die Windows-Ereignisanzeige, die nützliche Informationen dazu liefern kann.
Fujitsu ServerRaid in VMware Umgebungen - Tipps und Tricks
Normalerweise ist der Status in einer virtuellen Umgebung direkt vom Hypervisor zu beziehen (Beispiel VMware). Fujitsu bietet jedoch zusätzlich zu diesem Weg an, den Festplattenstatus klassisch über das ServerRaid Tool zu prüfen.
Dieser Artikel befasst sich mit den Schritten die notwendig sind, damit diese Kommunikation korrekt funktioniert.
Schritt 1 – Voraussetzungen
Setup prüfen
Zu aller erst ersparen Sie sich viel Ärger wenn Sie bereits eine von Fujitsu vorkonfigurierte VMware Version nutzen.
Auf VMware Seite ist es wichtig das die CIM Konfiguration wie folgt aussieht:
- Installation CIM Provider (wenn nicht vorkonfiguriertes VMware)
- Einträge im VCenter unter „Konfiguration – Erweitertete Einstellungen – UserVars“
- UserVars.CIMvwm_emulex-cim-providerPrvoviderEnabled = 1
- UserVars.CIMvwm_LSIProviderPrvoviderEnabled = 1
Desweiteren müssen für die Kommunikation die folgenden Dienste gestartet sein:
- Secure CIM-Server auf Port 5989
- CIM-Server auf Port 5988
Detaillierte Informationen zu diesen Schritten finden Sie natürlich auch direkt bei Fujitsu in der folgenden Anleitung: https://support.ts.fujitsu.com/prim_supportcd/SVSSoftware/Software/ServerView/Linux/CIM_Providers/VMware_ESXi/ESXi6x/readme_en.txt
Schritt 2 – Anpassungen auf einer ausgewählten VM
CLI-Befehle
Der Fujitsu ServerRaid Manager kann auf einer beliebigen virtuellen Maschiene installiert werden. Es muss nur der betreffende Host über IP erreichbar sein und natürlich die Anforderungen der Software erfüllt werden.
Jetzt erfolgt die weitere Konfiguration mittels des CLI des Raid Managers, amCLI.
Dies finden Sie normalerweise unter „C:\program files\fujitsu\serverview suite\raid manager\bin“
Die folgende Befehlszeile müssen Sie nur um Ihre Werte ergänzen:
amCLI -e 21/0 add_server name=<FQDN oder Hostname oder IP> port=5989 username=root password=<ESXi Root Passwort>
Ob alles geklappt hat können Sie mit dem Befehl „verify_server“ überprüfen:
amCLI –e 21/0 verify_server name=<FQDN oder Hostname oder IP>
Ein „No Error“ signalisiert, dass alles funktional ist.
Bezüglich spezieller Zeichen in dem ESXi Passwort und weiteren Einstellungsmöglichkeiten sehen Sie bitte in die von Fujitsu bereitgestellte Anleitung: http://manuals.ts.fujitsu.com/file/4338/sv-serverview-raid-de.pdf (Kapitel 2.1.2 VMware ESXi)
Nun nur noch den Server View Raid Manager Dienst neustarten und im Raid Manager anmelden. Voilá!
Schritt 3 – Überwachung
Monitoring des Raid
Anstatt unsere PowerCLI basierenden Sensoren zu nutzen, können Sie nun auch wie bisher unseren SNMP Sensor „Festplattenüberwachung für Fujitsu Siemens® Server“ anlegen um den RAID Status zu überwachen.
Beachten Sie hier nur das eine weitere Konfiguration von SNMP notwendig ist.
Dies wurde aber bereits hier beschrieben:
Danach können Ihnen solche Fehler nie wieder entgehen:
Vielen Dank an der Stelle auch an unseren Kunden ParIT GmbH für den tollen Denkanstoß und das Bereitstellen von Informationen für diesen Eintrag!
Korrekte Übertragung des Schattenspeichers (MPS)
Viele Städte und Gemeinden haben damit zu kämpfen, das sie regelmäßig prüfen müssen, ob die Schattenspeicher-Datei korrekt übertragen wurde. Dabei gibt es zwei Abhängigkeiten in Form des Programmes MPS (welches die Schattenspeicherdatei erstellt) und EWO Transfer welches den Upload dieser XML-Datei über FTP übernimmt.
Ich zeige Ihnen nun an Hand von wenigen Schritten, wie Sie dieses Problem zuverlässig überwachen können und eine Sorge weniger haben :).Der erste Schritt zur erfolgreichen Überwachung sollte sein, folgende Dienste zu überwachen:
- DW-DBCControl_mpsEM
- DW-DBCControl_mpsNF
- DW-DBControl_EM_OSCI
Sind diese Dienste nämlich nicht gestartet, funktioniert das Erstellen der Schattenspeicher-Datei schon gar nicht.
Dazu bietet servereye den Sensor "Windows Dienst Gesundheit", der alle automatisch gestarteten Dienste im System überwacht.
Danach kommt das Herzstück der Überwachung, das Überprüfen der Logdateien wofür wir den Sensor "Log-Datei Ordnerüberwachung" anbieten.
Diesen füllen Sie einfach wie folgt aus:
Sobald nun eine neue Logdatei hinzukommt, die nicht das Schlüsselwort "Datei erfolgreich" enthält, erhalten Sie eine Alarmierung.
Wenn Sie die beiden Sensoren nun noch als Template abspeichern, können Sie diese Form der überwachen schnell und einfach auf Ihre Server anwenden.
Aktionen dank PowerShell
Manchmal ist es notwendig einen Prozess oder Dienst neuzustarten um ein bestimmtes Problem zu lösen. Vielleicht haben Sie ein solches Problem in Ihrer Umgebung, für die Software gibt es keinen Patch mehr der Abhilfe schaffen kann, oder es handelt sich einfach um ein Task der regelmäßig neu angestoßen werden muss. Genau das sind typische Beispiele wo Aktionen hilfreich sein können. In diesem Artikel zeige ich Ihnen wie Sie Aktionen in servereye mittels Remote PowerShell nutzen können.
Die Macht der PowerShell
Die PowerShell ist eine mächtige Shell mit der sich fast jede Aktion umsetzen lässt. So gibt es vorgefertigte Befehle um einen Prozess zu beenden und wieder zu starten, einen Dienst und sogar den eigenen Rechner (oder einen fremden) neuzustarten.
In unserem Partnerbereich bieten wir bereits eine kurze Einführung in die PowerShell-API, also wie Sie eigene Überwachungen auf Basis eines PowerShell-Skripts erstellen können.
Die Infos finden Sie hier:
Erweiterte PowerShell Sensor Doku
Ich habe auch ein Beispielskript angehängt an diesen Eintrag, in welchem ein gewählter Prozess auf CPU und Arbeitsspeicher Verbrauch überwacht werden kann. Werden die Schwellwerte erreicht, wird der Prozess beendet und wieder gestartet.
Die Befehle dafür sind
- Stop-Process
- Start-Process
Für Dienste neuzustarten oder gar den PC gibt es folgende Befehle:
- Restart-Service
- Restart-Computer
Das Skript ist funktionsfähig, kann aber auch einfach als Anreiz für andere Szenarien genutzt werden.
Skript in servereye einbinden[/vc_custom_heading]
Um ein Skript in servereye zu nutzen müssen Sie es im Installationsverzeichnis in das Unterverzeichnis „Scripts“ kopieren. Dies liegt standardmäßig unter C:\Program Files (x86)\servereye\service\current\Scripts\.
Wenn Sie solche System-Aktionen durchführen wollen starten Sie zur Sicherheit den Sensorhub Dienst auf dem System als Administrator starten, da sonst die PowerShell-Kommandos in einem UAC Dialog hängen bleiben könnten. Außerdem kann es durchaus sein, das Prozesse mit einer grafischen Oberfläche nicht korrekt neugestartet werden können.
Danach ist es über den Sensor „Erweiterte PowerShell Überprüfung“ auswählbar und lässt sich überwachen.
Falls Sie Argumente in Ihrem Skript nutzen wollen können Sie dies über die entsprechende Einstellung tun. In unserem Falle gibt es die Argumente
- process
- maxRamMB
- maxCPU
Ich rufe das Skript also mit folgenden Parametern auf:
Die Ausgabe des Sensors sind dann wie folgt aus:
Bzw. im Fehlerfall, wenn der Prozess zuviel schluckt so:
Viel Spaß beim Skripten 🙂
Blacklist dnsbl.ahbl.org stellt Dienst ein!
Aus aktuellem Anlass! Der Betreiber ahbl.org stellte zum 05.01.2015 unter anderem die Dienste dnsbl.ahbl.org ein. Das bedeutet das Sie in aller Voraussicht eine Fehlermeldung in servereye erhalten.
Im Folgenden zeige ich Ihnen wie Sie diese Fehlermeldung beheben können.
UPSMan SNMP Konfiguration
Besitzt Ihre USV keine eigene SNMP-Karte bietet die UPSMan Software Abhilfe für viele Hersteller wie AEG, Online USV , Eaton, Generex, Riello, Effekta uvm.
Eine schöne Übersicht finden Sie hier GENEREX – UPSMAN Suite for Windows
UPSMan stellt dabei die SNMP-Funktionalität softwareseitig bereit, in dem es den Windows-SNMP Agenten nutzt. In diesem kleinen Beitrag zeige ich euch wie man das ganze konfiguriert und anschließend überwachen kann.
Konfiguration in Windows
Zu allererst benötigen Sie den Window SNMP Dienst auf Ihrem System. Ist dieser noch nicht vorhanden können Sie dies entweder über den Server-Manager oder aber die Windows-Features schnell hinzufügen.
Ist der Dienst installiert muss er noch konfiguriert werden, sodass SNMP Anfragen durchgeführt werden können. Dazu setzen Sie die „Read“ Community am besten auf public. Sie können den Zugriff auf bestimmte IPs einschränken.
Konfiguration UPSMan SNMP
Ist dieser Schritt abgeschlossen, können Sie in der UPSMan Software nun die SNMP Funktionalität konfigurieren.
Dies finden Sie unter dem Punkt System. Setzen Sie hier das Häkchen bei Enable SNMP Support und Restart SNMP Service.
Danach sollten Sie zur Sicherheit nochmal manuell den Windows SNMP Dienst neustarten.
Jetzt können Sie die Funktionalität mit einem MIB-Browser bestätigen und mit der Überwachung der Gesundheit Ihrer USV beginnen.
Monitoring in servereye
Kommen wir nun zum einfachsten Schritt.
Wir bieten zur Überwachung schon unseren USV Status über UPSMan® Sensor an. Dieser benötigt auch keine weitere Konfiguration und ist direkt einsatzbereit. Viele wichtige Informationen werden auch als Messwerte zur Langzeitanalyse bereitgestellt.
Das ganze sieht dann wie folgt aus:
Frohes Monitoring!
LSI Raid Controller Integration in VMware ESX Server
Die Virtualisierung ist mittlerweile nicht mehr wegzudenken. Mit Ihr kommen neue technischen Herausforderungen und es ist wichtiger den je alles im Überblick zu haben. Wenn Sie einen LSI Raid Controller auf Ihrer ESX Hardware nutzen, möchte ich Ihnen in diesem Artikel kurz aufzeigen, wie Sie diesen korrekt integrieren, sodass der Status auch im ESX berücksichtigt wird. Viele Hersteller bieten extra Tools an, die zugeschnitten sind auf die genutzte Virtualisierungslösung, so auch LSI.
Den ersten Schritt den Sie durchführen müssen, ist es von der LSI Webseite www.lsi.com die notwendigen MegaRAID Treiber herunterzuladen.
Bevor wir mit der Installation beginnen, sehen Sie hier noch einmal der Urzustand des ESX nach Installation:
Um nun fortzufahren müssen Sie in den Firewall Eigenschaften den SSH Dienst aktivieren und auch starten. Das ist notwendig um den heruntergeladenen MegaRaid Treiber auf das System kopieren zu können.
Jetzt können Sie Ihr Tool der Wahl (zum Bsp WinSCP) benutzen um die heruntergeladene .zip Datei zu übertragen. Am besten in das Verzeichnis /tmp.
Bauen Sie nun mit PuttY ebenfalls eine Verbindung auf, und beginnen Sie mit der Treiberinstallation wie folgt:
esxcli software vib install -v /tmp/vmware-esx-provider-lsiprovider.vib
Eine erfolgreiche Installation können Sie am Ausgabetext erkennen, der in etwa wie folgt lautet:
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Folgen Sie der Anweisung und tätigen Sie einen Neustart.
Herzlichen Glückwunsch! Jetzt sollte die Ansicht in Ihrem vSphere Client genau so aussehen:
Jetzt bekommen Sie alle Fehler mit, die an dem LSI Controller anliegen. Das könnte dann wie folgt aussehen:
Damit Sie nun nicht ständig Ihren vSphere Client aufhaben müssen und Hoffen und Bangen das alles gut gehen wird, können Sie das ganze natürlich auch zuverlässig überwachen mit servereye. Sobald nämlich der Status sauber im vSphere Client ersichtlich ist, können unsere Sensoren über die VMware PowerCLI diese Werte abgreifen.
In diesem Fall wäre dies über den Sensor Host Gesundheit für VMware® PowerCLI abzubilden.
In einem meiner nächsten Blog-Artikel werde ich nochmal gezielt auf die Thematik "VMware in servereye" eingehen, damit Sie sehen wie einfach es ist Ihre virtuelle Umgebung zu überwachen.
Logdateien zuverlässig bereinigen – Tipps und Tricks
Es gibt Programme oder auch Serverumgebungen, die viel protokollieren und unter Umständen massig an Logdateien generieren. Dies kann unter Umständen regelmäßig dazu führen, dass die Festplatte voll läuft.
Jetzt kann man natürlich jedes Mal händig diese Log-Verzeichnisse aufräumen, aber dies ist sehr zeit intensiv und nervenaufreibend.
Typische Anwendungsgebiete sind Exchange Server, Server wo ein IIS genutzt wird, SBS und Sharepoint Logs oder aber auch das Programm X das einfach zu viel Logdateien generiert.
Ich stelle Ihnen in diesem Beitrag ein kleines Skript vor, das Ihnen Ihr Leben erheblich erleichtern kann, und wenn Sie doch mal Hand anlegen müssen, auch darüber informiert werden.
Wir bedienen uns dabei der PowerShell, da dort diese Aufgabe am einfachsten und sinnigsten umgesetzt werden kann.
Ich will jetzt nicht speziell auf Details eingehen bezüglich PowerShell Befehlen und Syntax, aber hier ist das Herzstück des Skriptes, ein Befehl welcher sich um das Ermitteln der zu alten Dateien kümmert und zur weiteren Verarbeitung in die Variable $itemsFound speichert.
#PsIsContainer means if it is a folder..and compare to the lastWriteTime tresh we have given above..
$itemsFound = Get-ChildItem $LogFolder -Recurse | where{!$_.PsIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DateToDelete)}
Es werden also auch nur Logdateien gelöscht, die älter als x Tage als sind. Dies ist auch immer zu empfehlen da aktuelle Logs (egal in welchem Anwendungsgebiet) sehr wichtige Analysemöglichkeiten darstellen.
Im Skript können Sie dabei einen ganzen Ordner angeben oder aber auch mit Wildcards arbeiten, um wirklich nur einen speziellen Typ von Dateien zu löschen (Zum Beispiel C:\temp\*.log). Ich habe zwei Skripte angehängt für die potentiellen Szenarien:
1. Einfaches PowerShell-Skript über geplanten Task (Aufgabenplanung)
- Öffnen Sie die Datei „ClearAnnoyingLogs.ps1“ und ändern Sie die Variablen „daysToDelete“ und „LogFolder“ nach Ihren Wünschen ab.
- Öffnen Sie die geplante Task Ansicht von Windows und lassen Sie das Skript mindestens 1x pro Tag laufen.
- Unter „Programm starten“ geben Sie die powershell.exe an und als Argumente -noninteractive -file „pfad zum ps1 script“
- Es kann notwendig sein, dass Sie den genauen Pfad zur powershell.exe angeben müssen.
- Erstellen Sie in servereye einen geplanten Task Sensor. An Hand des positiven Rückgabewertes (0) bekommen Sie direkt mit, ob der Task erfolgreich durchgelaufen ist.
2. Eigener Sensor in servereye über PowerShell API
- Kopieren Sie Die Datei „ClearAnnoyingLogsSensor.ps1“ in das servereye Verzeichnis unter „scripts“.
- Gehen Sie nun in Ihr OCC und legen auf dem Server den Sensor „Erweiterte PowerShell Skript Überprüfung“ an.
- Tragen Sie als Parameter „-days xyz -path „C:\meinpfad“ ein und wählen Sie anschließend das Skript aus der Liste aus.
- Wenn Sie möchten können Sie nun das Intervall auf Ihre Bedürfnisse anpassen oder sogar Pausenzeiten definieren
Der Vorteil ist, dass Sie die direkte Ausgabe des Skripts immer in Ihrem OCC haben und von den Vorteilen eines eigenen Sensors profitieren.
So liefert das Skript zum Beispiel auch Messwerte, damit Sie immer wissen wie viele Dateien bereinigt wurden.
Weitere Infos, wie Sie PowerShell Skripte zu eigenen Sensoren in servereye umwandeln, finden Sie unter https://servereye.freshdesk.com/support/solutions/articles/14000035882-erweiterter-powershell-sensor
Ich hoffe, ich konnte Ihnen mit diesen zwei Lösungen etwas helfen, die tägliche Logbelastung zu bekämpfen und den Techniker-Alltag etwas einfacher zu gestalten.
Zum Skript-Paket
