Daten sammeln
Einer der Hauptunterschiede zwischen den beiden Monitoring-Systemen ist die Art und Weise, wie die Daten der überwachten Systeme gesammelt werden. Icinga verfolgt hier einen eher zentralistischen Ansatz und sammelt die Daten direkt vom Icinga-Server aus ein, während SCOM dies von Agenten erledigen lässt. Beide Systeme erlauben aber auch eine Umkehrung. So ist es beispielsweise möglich, auf Icinga-überwachten Systemen einen Dienst zu installieren, der das Sammeln und Versenden der Daten übernimmt (so genannte passive Checks). Ebenso ist es möglich, den SCOM-Server aktiv zum Sammeln von Daten zu bewegen, zum Beispiel bei Netzwerk-Komponenten oder anderen agentenlosen Systemen.
Beide Vorgehensweisen haben Vor- und Nachteile. Bei einem Sammeln der Daten müssen alle Konfigurationen und Anpassungen nur am zentralen Server vorgenommen werden, da es keine dezentralen Agenten gibt. Beim Einsatz von Agenten wiederum kann ein Teil der Sammellogik auf den Client verlagert werden und damit den Server entlasten. So reicht es, wenn der Agent den Füllstand einer Festplatte überprüft und beim Überschreiten eines Schwellwertes einen Alarm auslöst (Modell SCOM), wohingegen ohne Agent (Modell Icinga) in regelmäßigen Intervallen eine entsprechende Kenngröße an den Server übermittelt wird und dieser dann entscheidet, ob ein Alarm ausgelöst wird. Dies belastet nicht nur den Server, sondern auch die Netzverbindung. Ein einzelner SCOM-Server ist laut Microsoft für die Überwachung von bis zu 3.000 Agenten ausgelegt.
Natürlich gibt es Dienste, die besser "von außen" überwacht werden, zum Beispiel ein Mail-Server. Ein Verbindungsversuch auf den entsprechenden Port muss erfolgreich sein, sonst erfolgt ein Alarm. Genauer betrachtet ist das aber nicht ganz ausreichend. Handelt es sich nur um ein Mail-Relay, so wäre interessant, ob die angenommenen Mails auch zeitnah weitergeleitet werden konnten. Handelt es sich um einen Web-Server, der auf eine nachgelagerte Datenbank zugreift, sollte dieser mit einer korrekt generierten Seite antworten und nicht nur mit einer beliebigen Seite. Oft ist demnach die Kombination beider Monitoring-Verfahren sinnvoll, also ein Agent, der den Service und abhängige Komponenten überwacht, sowie ein externer Verbindungsversuch, wie ihn auch ein Client vornimmt.
Microsoft löst das Problem der dezentralen Umkonfiguration seiner Agenten dadurch, dass der Administrator die einzelnen Konfigurationsänderungen zentral am Server vornimmt und diese dann automatisch an die Agenten übertragen werden. Icinga löst das Problem des dezentralen Sammelns über passive Checks, die es Clients erlauben, einen Status an einen zusätzlichen Service auf dem Icinga-Server zu melden und diesen dann in die normale Ereigniskette einsortiert und abarbeitet. Bei diesem Entscheidungskriterium ist also interessant, wie und wo die Mehrzahl der benötigten Informationen gewonnen werden können. Ein weiteres Kriterium wäre es, wenn der zu überwachende Server durch eine Firewall geschützt ist. In diesem Fall ist unter Umständen eine Abfrage "von außen" per Icinga nicht möglich, aber ein Senden des SCOM-Agenten "von innen" erlaubt.