SolarWinds Additional Polling Engine vs. Platform Remote Collector: Welche Polling-Architektur passt?

Wer SolarWinds über mehrere Standorte, Netzwerkzonen oder eine DMZ verteilt, stößt früher oder später auf zwei unterschiedliche Polling-Ansätze: die Additional Polling Engine (APE) und den SolarWinds Platform Remote Collector.

Beide bringen Monitoring näher an die Zielsysteme. Sie sind aber keine austauschbaren Varianten derselben Architektur. Eine APE ist eine vollwertige SolarWinds-Skalierungsengine mit breiter Funktionsabdeckung und hoher Polling-Kapazität. Ein Remote Collector ist bewusst schlanker: Er ist für entfernte, bandbreitenarme oder stark segmentierte Netze gedacht und reduziert die zentrale Kommunikation auf Kosten von Kapazität und Funktionsumfang.

Gerade in einer DMZ ist dieser Unterschied relevant. Dort entscheidet nicht nur, was überwacht werden kann, sondern auch, welche Systeme über die Zonengrenze kommunizieren dürfen, ob direkter Datenbankzugriff zulässig ist und wie viele Firewall-Freigaben dauerhaft betrieben werden müssen.

Die Angaben in diesem Artikel beziehen sich auf die von SolarWinds im September 2026 veröffentlichte Dokumentation. Die tatsächlichen Limits hängen von Produkt, Lizenz, Version, Polling-Protokoll, Polling-Intervallen und Hardware ab. Vor einer Umsetzung sollte deshalb immer die aktuelle Support- und Portmatrix der eingesetzten Version geprüft werden.

Die Kurzfassung

Die praktische Entscheidung lautet daher selten „welcher Poller ist besser?“, sondern eher: Brauche ich die Funktionsbreite und Skalierung einer APE – oder ist das schlankere Kommunikationsmodell des Remote Collectors wichtiger?

Additional Polling Engine: volle Plattformintegration

Eine Additional Polling Engine erweitert die Polling-Kapazität einer SolarWinds-Installation. Sie ist eng in die zentrale SolarWinds-Plattform integriert und kann einen deutlich größeren Funktionsumfang abdecken als ein Remote Collector.

Typische Vorteile sind:

• hohe Polling-Kapazität;
• breite Unterstützung der SolarWinds-Produkte und Monitoring-Funktionen;
• geeignet für umfangreiche NPM-, SAM- und andere Plattform-Workloads;
• Lastverteilung über mehrere Polling Engines;
• Nodes lassen sich zwischen Polling Engines verschieben;
• APEs können in High-Availability-Designs eingebunden werden;
• für bestimmte Lizenzmodelle können Polling Engines beziehungsweise Lizenzen gestackt werden.

Die Kehrseite ist die engere Plattformkopplung. Nach den aktuellen SolarWinds Port Requirements benötigt eine APE für ihre Plattformkommunikation je nach Version und eingesetzten Features unter anderem:

• TCP 1433 zur SolarWinds Platform Database;
• TCP 5671 für verschlüsselte RabbitMQ-/AMQP-Kommunikation;
• TCP 17777 für SolarWinds-Service- und Plattformkommunikation;
• ab neueren Plattformständen zusätzliche Service-Ports, zum Beispiel TCP 17734;
• die jeweiligen Monitoring-Protokolle zu den Zielsystemen, etwa SNMP, WMI/WinRM, HTTPS oder SSH.

UDP 1434 ist nur erforderlich, wenn SQL Server Browser beziehungsweise dynamische SQL-Ports verwendet werden.

Für eine interne Serverzone ist diese Plattformkommunikation häufig unkritisch. In einer DMZ ist insbesondere der direkte SQL-Zugriff ein relevanter Architekturpunkt: Ein kompromittierter Polling-Server besitzt damit einen direkten Netzwerkpfad zu einem internen Datenbankdienst.

APE-Skalierung: 12.000 Elements sind nur eine Baseline, kein allgemeines Maximum

Häufig wird für SolarWinds die Zahl 12.000 Elements pro Polling Engine genannt. Diese Zahl ist weiterhin eine sinnvolle generische Planungsgröße für klassische NPM-Deployments bei Standardintervallen. SolarWinds empfiehlt außerdem, bereits ab ungefähr 10.000 Elements beziehungsweise einer Polling Rate über 85 Prozent über Lastverteilung oder zusätzliche Engines nachzudenken.

Sie ist aber kein universelles technisches Maximum.

In aktuellen SolarWinds-Observability-Self-Hosted-Enterprise-Scale-Szenarien nennt SolarWinds deutlich höhere protokollabhängige Werte. Für den dokumentierten 2025.4-Stand sind beispielsweise Größenordnungen von bis zu:

• 100.000 SNMPv2-Elements pro Polling Engine;
• 72.000 SNMPv3-Elements pro Polling Engine;
• 20.000 WMI/WinRM-Elements bei maximal 2.000 Nodes;

beschrieben, jeweils abhängig von CPU-Ausstattung, Lizenzmodell und Standard-Pollingfrequenzen. Mit zusätzlichen CPU-Cores können einzelne Limits weiter steigen.

Die entscheidende Erkenntnis lautet daher: APE-Kapazität muss immer gegen das konkrete Produkt- und Lizenzmodell dimensioniert werden. Eine pauschale Gegenüberstellung „12.000 gegen 1.000“ ist für moderne Enterprise-Scale-Deployments zu grob.

Platform Remote Collector: ein kleinerer Trust-Pfad

Der SolarWinds Platform Remote Collector verfolgt einen anderen Ansatz. Er basiert auf der SolarWinds-Agent-Technologie, führt die Polling-Jobs aber lokal für andere Geräte aus. Damit können Systeme im entfernten Netz weiterhin agentless über WMI oder SNMP überwacht werden, während die zentrale Rückkommunikation über die Agent-Verbindung läuft.

Der wichtigste Unterschied: Ein Remote Collector benötigt keine direkte Verbindung zur SolarWinds Platform Database.

SolarWinds dokumentiert für seine zentrale Kommunikation TCP 17778 outbound vom Collector zur SolarWinds Platform. Die Verbindung ist agent-initiiert. Der Collector ist NAT-fähig und unterstützt authentifizierte Proxy-Traversierung. SolarWinds nennt DMZs, Branch Offices, Cloud-Netze sowie Low-Bandwidth- und High-Latency-Verbindungen ausdrücklich als typische Einsatzszenarien.

Weitere Eigenschaften:

• kein direkter SQL-Zugriff;
• nur ein zentraler Kommunikationsport für den Collector selbst;
• lokale Ausführung der Polling-Jobs;
• Pufferung von Polling-Ergebnissen für bis zu 24 Stunden bei unterbrochener Verbindung;
• automatische Plugin-Bereitstellung, wenn neue unterstützte SolarWinds-Produkte installiert werden;
• automatische Collector-Upgrades zusammen mit dem Main Polling Engine;
• Upgrades laufen über denselben Kommunikationspfad TCP 17778;
• Nodes können zwischen Remote Collectors und APEs verschoben werden.

Aus Security-Sicht reduziert das die Anzahl der Trust Paths erheblich. Aus Betriebssicht ist zusätzlich interessant, dass ein kurzzeitiger WAN-Ausfall nicht sofort eine Monitoring-Lücke erzeugen muss.

Der Remote Collector ist trotzdem kein Reverse Proxy. Er ist ein eigenständiger Poller mit lokalem Job Engine und einem agent-initiierten Rückkanal zur Plattform.

Warum Remote Collector häufig eine gute DMZ-Option ist

In einer DMZ ist die Frage oft nicht, ob eine APE technisch funktioniert. Sie funktioniert. Die wichtigere Frage ist, ob ihre Verbindungen zur internen Plattform gewünscht sind.

Vereinfacht sieht der Unterschied so aus:

Additional Polling Engine in der DMZ
    -> SQL / TCP 1433
    -> Main Polling Engine / TCP 5671
    <-> SolarWinds Platform / TCP 17777
    -> Monitoring-Zielsysteme

Remote Collector in der DMZ
    -> SolarWinds Platform / TCP 17778
    -> Monitoring-Zielsysteme

Damit ist der Remote Collector bei DMZ-Designs häufig die erste Architekturvariante, die geprüft werden sollte. Nicht weil er mehr Funktionen bietet, sondern weil sich die zentrale Angriffs- und Kommunikationsfläche leichter begrenzen lässt.

Eine Einschränkung bleibt: Auch der Remote Collector initiiert TCP 17778 aus seinem Netz zur internen SolarWinds-Plattform. Wenn eine Security-Policy jeglichen DMZ-initiierten Traffic nach intern verbietet, erfüllt auch der Remote Collector diese Vorgabe nicht. Er reduziert den Pfad jedoch auf einen klar definierten, agent-basierten Kanal und vermeidet insbesondere die direkte SQL-Verbindung.

Remote-Collector-Limits: 1.000 Elements sind eine harte Planungsgrenze

Die aktuellen SolarWinds Scalability Engine Guidelines nennen:

• maximal 1.000 Elements pro Remote Collector;
• maximal 100 Remote Collectors pro Polling Engine;
• maximal 48.000 Elements pro Polling Engine über alle zugeordneten Remote Collectors zusammen.

Die 1.000-Element-Grenze bedeutet nicht 1.000 Geräte. Ein Switch kann einen Node und Dutzende oder Hunderte Interfaces erzeugen. Ein Server kann zusätzlich Volumes und weitere überwachte Objekte beisteuern.

Ein einfaches Beispiel:

Das sind nur Planungsbeispiele, keine SolarWinds-Lizenzberechnung. Sie zeigen aber, warum Device Count allein für Remote-Collector-Sizing nicht ausreicht.

SolarWinds empfiehlt außerdem, einen Collector nahe am 1.000-Element-Limit hardwareseitig eher wie eine kleine SolarWinds-Platform-Installation auszulegen. Ein „leichtgewichtiger Collector“ ist also nicht automatisch eine minimale VM, wenn er voll ausgelastet werden soll.

Ein oft übersehener Punkt: Betriebssystem und Agent-Basis

Der Remote Collector läuft aktuell auf Windows. SolarWinds listet unter anderem Windows Server 2012 R2 bis 2025 sowie Windows 10 und 11 als unterstützte Plattformen; Linux und AIX sind für den Remote Collector nicht unterstützt. Der Host benötigt außerdem:

• einen eindeutigen Hostnamen;
• .NET Framework 4.8 oder neuer;
• einen SolarWinds Platform Agent im agent-initiierten Modus.

Server-initiated Agent Communication wird für Remote Collectors ausdrücklich nicht unterstützt.

Für eine DMZ bedeutet das: Das schlankere Netzwerkmodell spart zwar Firewall-Beziehungen, benötigt aber weiterhin einen gepflegten Windows-Server beziehungsweise Windows-Host in der Zone.

Feature Coverage: der wichtigste Teil der Entscheidung

SolarWinds weist ausdrücklich darauf hin, dass ein Remote Collector nicht alle Metriken und Funktionen einer Additional Polling Engine unterstützt.

Die aktuelle Supportmatrix nennt den Remote Collector für:

• Network Automation Manager (NAM);
• SAM mit node-basierter Lizenzierung;
• SolarWinds Observability Self-Hosted.

Unterstützt werden unter anderem gemeinsame Plattformmetriken wie:

• Node CPU;
• Node Memory;
• Node Status und Response;
• Volumes.

Für NPM dokumentiert SolarWinds zusätzlich unter anderem:

• Interfaces;
• Device Studio und Device View;
• Routing/VRF;
• VLANs;
• Wireless und Wireless Heatmaps;
• Topology;
• Universal Device Pollers (UnDP);
• Multicast, Nexus, Switch Stack und weitere NPM-Funktionen.

Für SAM werden unter anderem genannt:

• AppInsight for Active Directory;
• AppInsight for IIS;
• AppInsight for SQL;
• AppInsight for Exchange;
• die meisten Application Monitor Templates;
• Asset Inventory;
• Hardware Health mit Einschränkungen.

Explizit nicht unterstützt

Die aktuelle SAM-Dokumentation zum Remote Collector nennt beispielsweise:

• API Poller Monitoring;
• Container Monitoring;
• JMX Monitoring;
• Hardware Health für UCS oder Nutanix;
• JMX Monitor;
• Nagios Script Monitor;
• NNTP Monitor;
• Oracle User Experience Monitor;
• RADIUS User Experience Monitor;
• TACACS+ User Experience Monitor.

Auch der SolarWinds API Poller Requirements weist ausdrücklich darauf hin, dass API Poller weder Agent Polling noch Remote Collectors unterstützen.

„NAM unterstützt Remote Collector“ bedeutet nicht automatisch volle Modul-Parität

Ein wichtiger Architekturfehler ist, aus der Aussage „NAM unterstützt Remote Collector“ abzuleiten, dass damit automatisch jede Funktion von NPM, NCM, NTA, IPAM, UDT und VNQM über den Collector ausgeführt wird.

Die SolarWinds-Supportmatrix differenziert hier: Sie nennt für NAM zunächst Common SolarWinds Platform Metrics und führt anschließend konkrete NPM-Funktionen auf. Für spezielle Modul-Workflows muss die Unterstützung separat geprüft werden.

Für ein Design-Review ist deshalb die bessere Frage nicht:

„Unterstützt unser Produkt Remote Collector?“

sondern:

„Unterstützt der Remote Collector genau die Polling-Methode, den Monitor-Typ und den Modul-Workflow, den wir an diesem Standort benötigen?“

Das gilt besonders für Configuration Management, Flow, spezielle Application Monitors und individuell entwickelte Checks.

Agent-polled Nodes sind ein Sonderfall

Remote Collectors verwenden Agent-Technologie für ihre eigene Plattformkommunikation, können aber nicht beliebig mit agent-basiertem Node Monitoring kombiniert werden.

SolarWinds dokumentiert ausdrücklich:

• Ein Remote Collector kann keine Nodes poll-en, die selbst über einen SolarWinds Platform Agent überwacht werden.
• Ein Agent, der auf dem Main Polling Engine oder einer APE installiert ist, kann nicht zum Remote Collector promoted werden.
• Der Collector benötigt agent-initiierte Kommunikation.

Für SAM ist zusätzlich die Lizenzierung entscheidend: Remote Collector wird dort mit node-basierter Lizenzierung unterstützt.

Wer heute viele Agent-Nodes betreibt, muss diesen Punkt deshalb früh in die Architekturplanung aufnehmen.

Noch ein Kapazitätsdetail: Laut SolarWinds reduziert jeder eingesetzte Remote Collector die maximale Agent-Skalierung seines zugeordneten Polling Engines rechnerisch um zehn Agents. In Umgebungen mit sehr vielen SolarWinds Platform Agents kann das relevant werden.

Migration: kein In-Place-Umbau einer APE

Ein praktischer Stolperstein bei bestehenden Umgebungen ist die Migration.

Ein auf einem Main Polling Engine oder einer Additional Polling Engine installierter Agent kann nicht zu einem Remote Collector promoted werden. Eine bestehende APE lässt sich deshalb nicht einfach per Klick in einen Remote Collector umwandeln.

Auch der Rückweg ist nicht symmetrisch: Ein Remote Collector kann nicht direkt zurück in einen normalen SolarWinds Platform Agent „demoted“ werden. SolarWinds beschreibt dafür einen Abbauprozess:

1. zugeordnete Nodes entfernen oder einem anderen Poller zuweisen;
2. den Remote Collector als Polling Engine entfernen;
3. den Collector-Agent löschen;
4. anschließend einen anderen Agent als Collector promoten beziehungsweise neu deployen.

Für DMZ-Migrationsprojekte ist deshalb oft ein neuer Collector-Host parallel zur bestehenden APE die risikoärmere Pilotvariante. Nodes können anschließend kontrolliert zwischen APE und Remote Collector verschoben werden.

WAN und Latenz: hier unterscheiden sich die Architekturen deutlich

SolarWinds beschreibt Remote Collectors ausdrücklich für Low-Bandwidth- und High-Latency-Szenarien. Der lokale Poller führt seine Jobs am Standort aus und sendet Ergebnisse anschließend zentral zurück.

Bei einer APE ist das anders: SolarWinds weist darauf hin, dass nur wenig Monitoring-Traffic zwischen Main Polling Engine und einer entfernten APE anfällt, der größte Teil des Monitoring-Traffics aber zwischen APE und SolarWinds-Datenbank läuft.

Das ist ein entscheidender Punkt für Standortdesigns. Eine APE am anderen Ende einer langsamen oder instabilen WAN-Strecke kann zwar die Zielsysteme lokal poll-en, bleibt aber stark von der Datenbankanbindung abhängig. Der Remote Collector entkoppelt genau diesen Teil und kann Ergebnisse bei Verbindungsunterbrechungen bis zu 24 Stunden zwischenspeichern.

Die 24-Stunden-Pufferung ist allerdings kein Ersatz für High Availability oder Disaster Recovery. Sie hilft bei temporären Netzwerkunterbrechungen, nicht beim dauerhaften Ausfall des Collector-Hosts.

Update- und Lifecycle-Verhalten

Der Remote Collector ist betrieblich enger an den Agent-Lifecycle gekoppelt:

• Collector-Plugins werden automatisch verteilt;
• Plattform-Upgrades aktualisieren Remote Collectors automatisch;
• die Upgrade-Kommunikation läuft über denselben TCP-17778-Kanal.

Das reduziert den separaten Upgrade-Aufwand an vielen kleinen Standorten.

Eine APE ist dagegen eine vollwertige Scalability Engine und Teil des zentralen SolarWinds-Upgradepfads. Sie benötigt entsprechend mehr Plattformkomponenten, Ressourcen und Netzwerkkommunikation, bietet dafür aber auch den breiteren Funktionsumfang.

Direkter Vergleich

Wann ist eine APE die bessere Wahl?

Eine Additional Polling Engine ist meist die robustere Wahl, wenn:

• deutlich mehr als 1.000 Elements an einem Standort benötigt werden;
• volle oder möglichst breite SolarWinds-Funktionsabdeckung erforderlich ist;
• API Poller, JMX, Container Monitoring oder nicht unterstützte Spezialmonitore genutzt werden;
• der Standort umfangreiche Modul-Workflows benötigt;
• hohe Polling-Dichte und kurze Intervalle gefordert sind;
• die zentrale Plattform- und SQL-Kommunikation aus dem Netz zulässig ist;
• High Availability für die Polling Engine Teil des Designs ist.

Für große Rechenzentren und komplexe Monitoring-Zonen ist die APE deshalb häufig die planbarere Plattformkomponente.

Wann ist ein Remote Collector die bessere Wahl?

Ein Remote Collector sollte besonders geprüft werden, wenn:

• Monitoring in einer DMZ, Außenstelle oder einem Cloud-Netz benötigt wird;
• möglichst wenige Firewall-Verbindungen zur zentralen Plattform gewünscht sind;
• direkter SQL-Zugriff aus dem entfernten Netz vermieden werden soll;
• NAT oder ein authentifizierter Proxy Teil der Netzarchitektur ist;
• maximal 1.000 Elements je Collector ausreichen;
• die benötigten Monitoring-Funktionen in der Supportmatrix enthalten sind;
• WAN-Verbindungen langsam, hoch-latent oder zeitweise instabil sind;
• viele kleine Standorte ohne vollwertige APE-Infrastruktur überwacht werden sollen.

Für SNMP-basiertes Infrastrukturmonitoring und viele klassische SAM-Szenarien kann dieses Modell sehr gut passen.

Hybrid ist oft sinnvoller als eine Alles-oder-nichts-Entscheidung

APE und Remote Collector müssen nicht exklusiv eingesetzt werden. SolarWinds unterstützt das Verschieben von Nodes zwischen Remote Collectors und APEs.

Ein typisches Hybridmodell kann so aussehen:

• Remote Collector für Standard-Monitoring in DMZs oder kleinen Remote-Sites;
• APE für große Standorte;
• APE für Spezialfunktionen, die der Remote Collector nicht unterstützt;
• zentrale APEs für API Poller oder spezielle Modul-Workflows;
• Collector-Pilot für neue Sicherheitszonen, bevor weitere Rollen ausgerollt werden.

Der Nachteil: Sobald für Sonderfälle weiterhin eine APE in derselben DMZ benötigt wird, verliert man einen Teil des vereinfachten Security-Modells. Deshalb sollten Ausnahmen nicht erst nach der Installation, sondern bereits bei der Template- und Monitor-Inventur erkannt werden.

Zehn Fragen für das Architektur-Review

Vor der Entscheidung helfen zehn konkrete Fragen:

1. Wie viele Elements entstehen tatsächlich – Nodes, Interfaces und Volumes zusammen?
2. Welche Polling-Protokolle werden genutzt: SNMPv3, WMI/WinRM, Agent, HTTPS, SSH?
3. Welche SAM Component Monitors und Templates sind im Einsatz?
4. Werden API Poller, JMX oder Container Monitoring benötigt?
5. Gibt es Nodes, die bereits agent-basiert überwacht werden?
6. Sind aus der Zielzone direkte Verbindungen zu SQL und zentralen Plattformdiensten erlaubt?
7. Ist TCP 17778 outbound aus der Zone zulässig?
8. Gibt es NAT, Proxy, hohe Latenz oder instabile WAN-Verbindungen?
9. Welches SAM-/NAM-/Observability-Lizenzmodell ist vorhanden?
10. Welche Funktionen müssen im Pilot nachgewiesen werden, bevor die Architektur freigegeben wird?

Diese Fragen erzeugen meist schneller eine belastbare Entscheidung als ein rein theoretischer Produktvergleich.

Eine pragmatische Pilotstrategie

Für eine DMZ oder Remote-Site empfiehlt sich ein kleiner, aber repräsentativer Pilot. Zum Beispiel:

• ein klassisches SNMPv3-Netzwerkgerät;
• ein Windows-System mit den vorgesehenen SAM-Monitoren;
• ein Linux-System;
• ein System mit mehreren Volumes oder vielen Interfaces für das Element-Sizing;
• mindestens ein anspruchsvollerer Application Monitor;
• ein bewusst nicht unterstützter Spezialfall, um die spätere Ausnahmebehandlung festzulegen.

Im Pilot sollten nicht nur Metriken geprüft werden. Ebenso wichtig sind:

• Firewall-Flows;
• Verhalten bei unterbrochener WAN-Verbindung;
• Nachlieferung gepufferter Daten;
• Alerting;
• Discovery und Node-Reassignment;
• Upgrade-Verhalten;
• CPU/RAM-Last des Collectors;
• tatsächlicher Elementverbrauch.

Fazit

Additional Polling Engine und Platform Remote Collector lösen unterschiedliche Probleme.

Eine APE bietet deutlich mehr Kapazität und den breiteren Funktionsumfang, benötigt dafür aber eine engere Integration mit der zentralen SolarWinds-Plattform und Datenbank. Ein Remote Collector reduziert diese Trust Paths erheblich und ist deshalb besonders für DMZs, Branch Offices, Cloud-Netze sowie High-Latency- und Low-Bandwidth-Szenarien interessant. Dafür gelten ein klares 1.000-Element-Limit je Collector und funktionale Einschränkungen.

Für DMZ-Projekte ist der Remote Collector daher häufig die erste Architektur, die fachlich und sicherheitstechnisch geprüft werden sollte. Die Entscheidung sollte aber erst fallen, nachdem Elementzahlen, konkrete Monitor-Typen, Agent-Nutzung, Lizenzierung und Security-Regeln gegen die tatsächliche Supportmatrix geprüft wurden.

Wenn Sie Ihre SolarWinds-Polling-Architektur, DMZ-Segmentierung oder bestehende Monitoring-Landschaft überprüfen möchten, finden Sie weitere Informationen unter Observability & Monitoring. Für ein konkretes Architektur-Review können Sie heureka kontaktieren.

Quellen und weiterführende Dokumentation

• SolarWinds Scalability Engine Guidelines
• SolarWinds Port Requirements
• SolarWinds Platform Optimization Checklist
• Use SolarWinds Platform Remote Collector with SAM
• SolarWinds API Poller Requirements
• SolarWinds Platform Requirements