Momentan bin ich daran einen einfachen SAP2SCOM Connector zu entwickeln. Leider stellt sich die Informationsrecherche im SAP Umfeld für mich als relativ schwierig dar. Daher: Falls jemand ebenfalls mal in diesem Umfeld etwas machen darf, hier zwei relevante Links:
Für Visual Studio 2003 gibt es einen SAP .NET Connector um auf BAPI und Webservices von SAP zuzugreifen. Für neuere Versionen gibt es diesen nicht mehr. Trotzdem mach dieses Add-On die Entwicklung einfacher, da es die komplette Komplexität kapselt. Möchte man dies also heute noch nutzen, dann gibt es unter http://www.codeproject.com/KB/dotnet/Connect_SAP_from_VS2008.aspx eine Anleitung dazu.
Für die Extraktion der Alert Informationen aus dem CCMS von SAP habe ich nur wenige Informationen gefunden. Das beste Dokument natürlich erst als dieser Teil schon fast abgeschlossen war: External Interface for Alert Management.
meistens bin ich ja auf eurer Seite. Aber mache Dinge muss man nicht verstehen, oder?
Das ist kein gemeinsamer Dienst der System Center Familie (soweit ist die Integration wirklich noch nicht), sondern der Operations Manager Dienst (System Center Operations Manager 2007 R2). Gemeinsame Identitäten schaffen ist gut. Alle Familienmitglieder nur mit dem Nachnamen anzusprechen ist aber zu viel des Guten. Bitte nennt den Dienst doch mindestens System Center Operations Agent oder so ähnlich!
Wie bereits in einem früheren Post erklärt musste man vor OpsMgr 2007 R2 bei einem Proxy Error (“Agent proxying needs to be enabled for a health service to submit discovery data about other computers.”) umständlich aus der angegebenen internen Rechner GUID den eigentlich gemeinten Agent herausfinden um ihm dann als Proxy Agent zu aktivieren.
R2 hat hier eine kleine aber wesentliche Verbesserung erfahren: In den Details des Alarms wird jetzt die GUID direkt durch den DNS Namen ersetzt:
Details:Health service ( rechner.domain.local ) should not generate data about this managed type
Gerade solche Kleinigkeiten machen das Produkt immer besser!
Im DNS 2003 Version 6.0.6480.0 existiert ein Fehler. In der Standardeinstellung wird ein Fehler bei der externen DNS Auflösung gemeldet (“DNS 2003 Server External Addresses Resolution Alert”).
Ursache ist ein fehlerhafte Zieladresse. Es wird versucht einen Namenservereintrag (NS) für www.microsoft.com zu ermitteln. Der korrekte Nameserver wäre microsoft.com. www.microsoft.com ist nur ein Ressourcen Eintrag (A Record). Als Lösung sollte man somit den Alarm überschreiben und entweder den Typ auf A ändern oder die Adresse auf microsoft.com (oder irgend eine andere) und den Typ auf NS lassen.
HP bietet viele Erweiterungen an, um seine Clients und Server optimal in die System Center Umgebung zu integrieren. Für meinen neuen Arbeitgeber habe ich dazu einen Übersichtsartikel erstellt, um die einzelnen Produkte der Familie kurz darzustellen und dabei speziell auf die Zusatzangeboet von HP zu verweisen (jeweils auf den Detailseiten).
Es wurde bewusst möglichst wenig Technik beschrieben. Zu finden ist der Artikel unter Im Focus.
Does anyone need an english version of the instruction? Then just post a comment.
In Absprache mit meinem früheren Chef habe ich den bereits vor längerer Zeit versprochenen SCOM2Nagios Connector aufgeräumt und in eine releasefähige Version verpackt.
Ich stelle ihn hiermit unter die GPL. Lizenzinformationen sind mit im Zip File enthalten.
Ein Wort der Warnung: Obwohl diese Version des Programms bei meinem früheren Arbeitgeber bereits im produktiven Umfeld lief, sollte er natürlich vorher ausgiebig in einer Testumgebung ausprobiert werden.
Die aktuell vorliegende Dokumentation ist sehr rudimentär und beschreibt hauptsächlich die (relative komplexe) Installation. Voraussetzung ist ein aktuelles .Net Framework, dass auch für den OpsMgr notwendig ist. Detailiertere Informationen müssen momentan noch aus dem mitgelieferten Quellcode entnommen werden.
Bei Rückfragen stehe ich natürlich über diese Webseite zur Verfügung (ohne Anspruch auf eine schnelle Reaktion).
Die Zip-Datei mit allen Informationen ist unter scc-scom2nagios_v10 zu finden.
Zeitweise stieg die Datenbankgröße des OpsMgr extrem schnell an. Um herauszufinden, woher dieses ungewöhnliche Verhalten kam, wollte ich ein Liste aller Alerts mit deren Summe des Auftretens erstellen. Früher wäre ich dafür direkt in die Datenbank gegangen. Heute gibt es dafür Powershell. Das ist einfacher und supported.
Die Liste lässt sich mit folgendem Einzeiler erstellen:
get-alert | group-object -property Name | sort-object count
Der Aufbau ist recht einfach: Zuerst alle Alerts ausgeben (inklusiv der bereits geschlossenen). Diese Liste gruppieren nach der Eigenschaft Name. Als letztes die Ausgabe nach der Anzahl des Auftretens sortieren.
Die Ausgabe sieht dann gekürzt so aus: [...]
158 SMTP Message Pending R... {SMTP Message Pending Routing is outside calcu...
790 Pool Non Pages Bytes i... {Pool Non Pages Bytes is outside the calculate...
4861 DB Chaining Flag {DB Chaining Flag, DB Chaining Flag, DB Chaini...
10754 Disk % Free Space low ... {Disk % Free Space low - Yellow(<15%)., Disk %...
Bei zirka 200 Agenten sind 11000 Disk Free Alerts innerhalb von sieben Tagen sehr ungewöhnlich.
Also schauen wir uns das mal genauer an:
get-alert -criteria 'Name Like ''Disk%''' | group-object -property NetbiosComputerName | ft *
Also alle Alerts ausgeben, die mit Disk beginnen. Das Ergebnis nach dem Computernamen, auf dem der Alarm aufgetreten ist sortieren. Zum Schluss das Ergebnis als Tabelle ausgeben:
Values Count Group Name
------ ----- ----- ----
{Rechner1} 10784 {Disk % Free Spa... Rechner1
{Rechner2} 89 {Disk transfer (... Rechner2
{Rechner3} 2 {Disk not respon... Rechner3
Laut dieser Ausgabe sind alle Alerts auf nur einem Rechner entstanden. Der Übertäter ist somit erkannt. Jetzt sollte man ihn genauer untersuchen, um die Ursache zu ermitteln.