Lab 10: Fleet & Elastic Agent¶
Übungsziel¶
Am Ende dieser Übung hast du:
- Fleet Server und einen Elastic Agent als Compose-Profil gestartet
- Beide Agents in der Fleet-UI als "Healthy" gesehen
- Agent Policies und das Enrollment-Token-Konzept in der UI nachvollzogen
- System-Metriken des Agents in Discover gefunden
- Die Inputs und Datasets der System-Integration untersucht
- (Bonus) Eine weitere Integration hinzugefügt und den zentralen Policy-Rollout beobachtet
Dauer: ca. 25 Minuten
Voraussetzungen¶
- Die Tag-3-Umgebung (
environment/day3) läuft: 3-Node-Cluster + Kibana - Internetzugang: Kibana lädt Integrations-Pakete vom Elastic Package Registry
Teil 1: Fleet starten und erkunden¶
Schritt 1.1: Fleet-Profil starten¶
Starte die beiden Fleet-Container zusätzlich zur laufenden Umgebung:
cd environment/day3
docker compose --profile fleet up -d --wait
Das startet zwei neue Container: fleet-server ist ein Elastic Agent im
Fleet-Server-Modus (Port 8220), agent ein ganz normaler Elastic Agent
mit dem Hostnamen mustertech-agent-01.
Tipp: Geduld! Der erste Start dauert einige Minuten: Kibana lädt zunächst die Packages
fleet_serverundsystemvom Elastic Package Registry, dann bootstrappt sich der Fleet Server und erst danach kann sich der Agent enrollen.--waitkehrt zurück, sobald alles healthy ist.
Prüfe den Zustand:
docker compose ps
Erwartetes Ergebnis: Zusätzlich zu es01--es03 und kibana laufen
fleet-server (healthy) und agent.
Tipp: Wenn der Fleet Server nicht healthy wird, hilft
docker compose logs fleet-server. Weitere Hinweise stehen im Troubleshooting-Abschnitt vonenvironment/day3/README.md.
Schritt 1.2: Fleet-UI öffnen¶
- Öffne Kibana:
http://localhost:5601(Benutzerelastic, Passwortchangeme) - Navigiere über das Hauptmenü zu Management > Fleet
- Du landest auf dem Tab Agents
Erwartetes Ergebnis: Zwei Agents mit Status Healthy:
| Agent | Policy |
|---|---|
mustertech-agent-01 |
Agent Policy Training |
| Fleet Server (generierter Container-Hostname) | Fleet Server Policy |
Aufgabe: Notiere für mustertech-agent-01 die Agent-Version und den
Zeitpunkt des letzten Check-ins (Spalte Last activity).
Tipp: Der Fleet Server taucht selbst in der Agent-Liste auf: Er ist ein Elastic Agent im Sondermodus und wird genauso überwacht wie jeder andere Agent.
Schritt 1.3: Agent Policies ansehen¶
- Wechsle zum Tab Agent policies
- Du siehst zwei Policies: Fleet Server Policy und Agent Policy Training
- Öffne Agent Policy Training per Klick auf den Namen
Erwartetes Ergebnis: Die Policy enthält eine Integration: system-1
(Integration System). Sie wurde über kibana.yml vorkonfiguriert.
In der Praxis würdest du sie hier per Klick hinzufügen.
Aufgabe: Gehe zurück zur Policy-Liste. Wie viele Agents hängen an
welcher Policy? Kibana 9.3 zeigt die Zahl in der Spalte
Unprivileged / Privileged im Format unprivilegiert / privilegiert
(gesamt) - für beide Policies also 1 / 0 (1). Auf der Policy-Detailseite
steht sie zusätzlich oben als 1 agent.
Tipp: Das ⚠️ neben der Zahl der Agent Policy Training ist nur ein Hinweis: Der Agent ist unprivilegiert enrollt (der Container-Agent läuft ohne dedizierten
elastic-agent-Benutzer), während die System-Integration teils Root-Rechte nutzen könnte. Fürs Lab ist das egal, die System-Metriken fließen trotzdem. Die Fleet Server Policy zeigt das ⚠️ nicht.
Öffne anschließend kurz die Fleet Server Policy: Sie enthält nur die
Integration fleet_server-1, mehr braucht ein Fleet Server nicht.
Schritt 1.4: Enrollment-Tokens verstehen¶
- Wechsle zum Tab Enrollment tokens
- Du siehst mindestens zwei Tokens, je einen pro Policy
- Klicke bei einem Token auf das Augen-Symbol, um das Secret einzublenden
Erwartetes Ergebnis: Jedes Token ist genau einer Policy zugeordnet. Ein Agent, der sich mit einem Token enrollt, landet automatisch in der zugehörigen Policy.
So hat sich unser Agent angemeldet: Der Container bekam die Variable
FLEET_TOKEN_POLICY_NAME=Agent Policy Training. Daraufhin hat er sich
das passende Token automatisch geholt und beim Fleet Server enrollt.
Tipp: In der Praxis nutzt du den Button Add agent (Tab Agents): Fleet zeigt dir dort den fertigen Install-Befehl inklusive Enrollment-Token für jedes Betriebssystem.
Teil 2: Daten prüfen¶
Schritt 2.1: Metriken in Discover finden¶
Die System-Integration sammelt bereits Metriken des Agent-Containers.
- Navigiere zu Analytics > Discover
- Wähle oben links den Data View metrics-* (wurde von Fleet automatisch angelegt)
- Stelle den Zeitfilter auf Last 15 minutes
- Gib in die Suchleiste ein:
host.name: "mustertech-agent-01"
- Füge die Spalten
data_stream.datasetundhost.namehinzu
Erwartetes Ergebnis: Dokumente mit Datasets wie system.cpu,
system.memory, system.network und system.filesystem. Das ist das
Namensschema <typ>-<dataset>-<namespace>, z. B. im Data Stream
metrics-system.cpu-default.
Schritt 2.2: Eine CPU-Metrik im Detail¶
Verfeinere die Abfrage:
host.name: "mustertech-agent-01" AND data_stream.dataset: "system.cpu"
Klappe ein Dokument auf und suche das Feld system.cpu.total.norm.pct.
Aufgabe: Wie hoch ist die aktuelle CPU-Auslastung des Agent-Containers (Wert zwischen 0 und 1)?
Zusatzaufgabe: Wechsle zum Data View logs-* und prüfe, ob dort
Daten von mustertech-agent-01 ankommen. Gut möglich, dass hier
nichts auftaucht: Im schlanken Agent-Container fehlen die klassischen
Logdateien (/var/log/syslog & Co.), die die System-Integration
einsammeln würde. Auch das ist ein Ergebnis - welche Logs ein Agent
liefert, hängt davon ab, was auf dem Host wirklich existiert.
Schritt 2.3: Agent-Detailseite - welche Inputs laufen?¶
- Gehe zurück zu Management > Fleet > Agents
- Klicke auf
mustertech-agent-01
Die Detailseite zeigt dir den Zustand des Agents aus Sicht von Fleet:
- Zugewiesene Policy und Revision
- Agent-Version und Host-Metadaten
- Die Integration
system-1mit ihren Inputs und deren Status
Aufgabe: Welche Input-Typen laufen auf dem Agent? Du solltest
mindestens einen Metrik-Input (system/metrics) und Log-Inputs finden.
Schritt 2.4: Die System-Integration in der Policy¶
- Navigiere zu Fleet > Agent policies > Agent Policy Training
- Klicke auf die Package Policy
system-1 - Du siehst die Konfiguration der Integration:
- Collect logs from System instances - z. B. syslog, auth
- Collect metrics from System instances - cpu, memory, network, filesystem, ...
Aufgabe: Welche Metrik-Datasets sind aktiviert? Klappe die Sektion auf und sieh dir an, welche Schalter Fleet dir pro Dataset anbietet.
Verlasse die Ansicht ohne zu speichern (Cancel).
Tipp: Genau hier liegt der Unterschied zu Tag 2: Statt YAML-Dateien auf jedem Host zu editieren, konfigurierst du die Datensammlung zentral in der Policy. Alle zugehörigen Agents ziehen die Änderung automatisch.
Teil 3 (Bonus): Eine weitere Integration ausrollen¶
Der Betrieb möchte zusätzlich Docker-Metriken sehen. Wir erweitern die Policy und beobachten, wie der Agent die Änderung übernimmt - ohne SSH, ohne Neustart.
Schritt 3.1: Docker-Integration hinzufügen¶
- Öffne Fleet > Agent policies > Agent Policy Training
- Klicke auf Add integration
- Suche im Katalog nach Docker und öffne die Integration
- Klicke auf Add Docker
- Lass die Standardeinstellungen unverändert und speichere (Save and continue > Save and deploy changes)
Erwartetes Ergebnis: Die Policy enthält jetzt zwei Integrationen:
system-1 und docker-1.
Schritt 3.2: Rollout beobachten¶
- Wechsle zum Tab Agents
- Beobachte
mustertech-agent-01: Beim nächsten Check-in übernimmt er die neue Policy. Die Revision der Policy zählt hoch, der Agent zeigt kurz den Status Updating
Erwartetes Ergebnis: Der Agent läuft mit der neuen Policy-Revision. Die Konfigurationsänderung hat den Host erreicht, ohne dass du ihn angefasst hast.
Schritt 3.3: Kommen Daten an?¶
Prüfe in Discover (Data View metrics-*):
data_stream.dataset: docker.*
Tipp: In unserer Schulungsumgebung hat der Agent-Container keinen Zugriff auf den Docker-Socket (
/var/run/docker.sock). Der Docker-Input kann daher Fehler melden und der Agent als Unhealthy erscheinen. Das ist hier erwartbar: Der Lerneffekt dieses Teils ist der zentrale Rollout-Mechanismus, nicht die Docker-Daten selbst. Auf einem echten Docker-Host mit Socket-Zugriff würden die Metriken sofort fließen.
Schritt 3.4: Integration wieder entfernen¶
- Öffne Fleet > Agent policies > Agent Policy Training
- Öffne das Aktionsmenü (...) neben
docker-1und wähle Delete integration - Bestätige die Änderung
Erwartetes Ergebnis: Die Revision zählt erneut hoch, der Agent übernimmt die bereinigte Policy und kehrt zu Healthy zurück.
Abschluss: Aufräumen¶
Wenn du die Umgebung nicht mehr brauchst, stoppst du alles inklusive der Fleet-Container:
cd environment/day3
docker compose --profile fleet down
Tipp: Das
--profile fleetist wichtig: Ein einfachesdocker compose downwürdefleet-serverundagentnicht mit entfernen. Alternativ setzt./reset.shdie komplette Umgebung inklusive Daten, Zertifikaten und Fleet-Zustand zurück.
Zusammenfassung¶
Du hast erfolgreich:
- [x] Fleet Server und Elastic Agent per Compose-Profil gestartet
- [x] Beide Agents in der Fleet-UI als "Healthy" gesehen
- [x] Nachvollzogen, wie Enrollment-Tokens Agents ihrer Policy zuordnen
- [x] System-Metriken (
system.cpu& Co.) in Discover analysiert - [x] Die laufenden Inputs auf der Agent-Detailseite untersucht
- [x] (Bonus) Die Docker-Integration zentral ausgerollt und wieder entfernt
Geschafft! Damit endet der dreitägige Kurs: Du kannst Daten analysieren (Tag 1), Logs einsammeln (Tag 2) und die Plattform betreiben (Tag 3). Die Mustertech GmbH ist in guten Händen.