Das Spiel EVE Online verfolgt bei der verteilten Überwachung aufgrund seiner alten Architektur und des Umfangs seiner zeitbasierten Simulation einen unkonventionellen Ansatz. Statt alle Spans zu senden und erst am Ende der Aufzeichnung zu entscheiden, welche beibehalten werden, verwendet die Plattform Sampling ab Beginn der Aufzeichnung, kombiniert mit deterministischen und dynamisch variierenden Samples. Ziel ist es, ein analysierbares Bild des Systems zu bewahren, ohne die Simulation zu verlangsamen oder die Rechnung für Überwachungsdaten zu erhöhen.
Nicholas Herring von CCP Games stellte dieses Experiment in einem über InfoQ veröffentlichten Beitrag vor. Er erklärte, dass EVE Online in einem gemeinsamen Universum betrieben wird, das alle Spieler umfasst, und nicht auf getrennten regionalen Servern. Das alte System und die neuere Umgebung namens Quasar tauschen etwa 30.000 Nachrichten pro Sekunde aus. Die Plattform umfasst außerdem Millionen von Zeilen in C, C++, Python und SQL, wodurch die Einführung einer neuen zentralen Überwachungsschicht an sich zu einer betrieblichen Herausforderung wird.
Warum setzte die Plattform kein nachgelagertes Sampling ein?
Die Entscheidung hing mit der Leistung und den Einschränkungen des bestehenden Systems zusammen. Ein Teil von EVE Online läuft mit Stackless Python 2.7 auf einem einzigen logischen Prozessor. Daher war das Team der Ansicht, dass das vollständige Erfassen der Spans und ihre Übermittlung an einen zentralen Verarbeitungspunkt die Simulation selbst beeinträchtigen könnte. Nachgelagertes Sampling erfordert außerdem, die Spans an einem Ort zusammenzuführen. Wenn der Sammelpfad oder seine Verbindung ausfällt, könnten dadurch große Teile des Systems unsichtbar werden.
Sampling ab Beginn ermöglicht dagegen jeder Komponente, ihre Entscheidung lokal zu treffen. Wenn bestimmte Teile beeinträchtigt sind, kann das Team anhand der unterschiedlichen Fähigkeit dieser Teile, ihre Daten zu senden, auf den Ort des Problems schließen, statt die Sichtbarkeit im gesamten System zu verlieren.
Kombination aus Determinismus und EMA
Die älteren Systeme verwenden deterministisches Sampling, um Kosten und Leistungsauswirkungen zu reduzieren. Die neueren Quasar-Komponenten nutzen dagegen einen Algorithmus für den exponentiell gleitenden Durchschnitt, kurz EMA, der Schlüssel wie den Typ einer Protobuf-Nachricht und ihre Auftretensrate überwacht. Je häufiger eine Nachricht auftritt, desto stärker wird ihre Sampling-Rate reduziert; seltene Nachrichten erhalten dagegen eine größere Chance, sichtbar zu werden.
Dieser Ansatz hilft, das Rauschen wiederkehrender Ereignisse zu verringern, etwa beim Abfeuern einer sehr großen Anzahl von Geschossen oder bei Änderungen am Erscheinungsbild von Schiffen. Das Team verlässt sich jedoch nicht ausschließlich darauf, da einige wichtige Ereignisse aus den alten Systemen stammen oder mindestens einmal sichtbar werden müssen. Die Verteilung von EMA auf mehrere Instanzen führt zu dem, was der Vortrag als „hohe Wassermarke“ bezeichnet: eine praktische Untergrenze für das Datenvolumen, die sich nach einer Erhöhung der Instanzanzahl, des Schlüsselraums oder der Nachrichtenrate nicht einfach wieder senken lässt.
Was ändert sich in der Praxis?
Das Experiment zeigt, dass die Konfiguration der Überwachung nicht mit der Auswahl des Tracing-Tools beginnt, sondern mit dem Verständnis der Ereignisse, die das Team messen möchte. CCP Games verwendet Feature-Flags, um die Überwachung eines bestimmten Bereichs, Schiffs oder Charakters vorübergehend zu verstärken oder die Überwachung weniger wichtiger Bereiche zu reduzieren. Außerdem nutzt das Unternehmen Werkzeuge, die Sampling-Raten anzeigen und das tatsächliche Volumen der Ereignisse ableiten, anstatt Rohzahlen so zu lesen, als würden sie das gesamte Universum darstellen.
Die Plattform verarbeitete in einer der Quasar-Konfigurationen etwa 60 Millionen Ereignisse pro Tag und zielte dabei auf eine Auslastung von ungefähr 90 % des verfügbaren Kontingents. Dadurch lässt sich bei Bedarf eine intensive Überwachung betreiben, während das Risiko einer Kostenüberschreitung sinkt. Diese Flexibilität erfordert jedoch betriebliche Disziplin: Im Vortrag wurden Fälle erwähnt, in denen Überwachungs-Flags versehentlich aktiviert blieben, was Warnungen wegen steigender Ausgaben auslöste.
Einschränkungen, die beachtet werden müssen
Dieser Ansatz bietet nicht alle Vorteile des nachgelagerten Samplings. Das Team kann das Verhältnis von Erfolgen zu Fehlschlägen später nicht auf dieselbe Weise steuern. Daher können Service-Level-Metriken unverhältnismäßig empfindlich werden, wenn ein Ereignis äußerst selten ist. Das Experiment kam außerdem zu dem Schluss, dass Sampling-Entscheidungen innerhalb von Desktop-Clients wichtige Interaktionen verbergen können. Deshalb prüft das Team, die Entscheidung in ein vertrauenswürdiges Netzwerk innerhalb der Backend-Infrastruktur zu verlagern.
Die praktische Schlussfolgerung lautet nicht, dass Sampling ab Beginn grundsätzlich überlegen ist, sondern dass reale Einschränkungen eine Kombination aus deterministischem Sampling, EMA und vorübergehender Aktivierung geeigneter machen können als eine kostspielige zentrale Architektur. Der Wert dieses Ansatzes hängt weiterhin davon ab, ob das Team definieren kann, was überwacht werden sollte, die Kosten-Wassermarke versteht und mindestens ein Sample jedes wichtigen Ereignistyps bewahrt.