nats, nats-server und nats-top sind die Werkzeuge rund um NATS, ein schlankes Nachrichtensystem für Cloud- und Edge-Umgebungen. Kernthemen sind Subjects, Publish/Subscribe, JetStream und Monitoring.

Server starten und prüfen

# Einfacher Start
nats-server

# Mit JetStream und Monitoring
nats-server -js -m 8222 -c /etc/nats/server.conf

# Verbindung und Zustand prüfen
curl -s http://localhost:8222/varz | jq .
curl -s http://localhost:8222/connz | jq '.num_connections'
curl -s http://localhost:8222/jsz | jq '.streams, .consumers'

Subjects und Publish/Subscribe

# Zuhören (Subscribe)
nats sub "bestellungen.>"

# Publish
nats pub bestellungen.neu '{"id":1,"summe":42.90}'

# Mit Antwort erwarten (Request/Reply)
nats request service.rechnen '{"a":1,"b":2}'

# Subject-Hierarchie
#   bestellungen.*      genau eine Ebene
#   bestellungen.>      beliebig viele Ebenen

Das Subject-Modell ist der Kern: Punkte trennen Ebenen, * passt auf genau ein Token, > auf beliebig viele. Ein Abonnement auf bestellungen.*.bezahlt erhält Nachrichten für jede Region, aber nicht für Unterebenen.

JetStream: Persistenz und Zustellung

# Stream anlegen: Subjects, Aufbewahrung, Speicher
nats stream add BESTELLUNGEN \
  --subjects "bestellungen.>" \
  --storage file --retention limits \
  --max-age 7d --max-msgs 1000000 --replicas 3

nats stream ls
nats stream info BESTELLUNGEN
nats stream report

# Nachricht in einen Stream schreiben
nats pub bestellungen.neu '{"id":2}'

# Nachrichten ansehen
nats stream view BESTELLUNGEN --last 5

# Consumer anlegen
nats consumer add BESTELLUNGEN ARBEITER \
  --deliver all --pull --ack explicit --max-deliver 5 --filter "bestellungen.*"

nats consumer ls BESTELLUNGEN
nats consumer info BESTELLUNGEN ARBEITER

Für den Betrieb sind drei Parameter entscheidend: --ack explicit verlangt eine ausdrückliche Bestätigung, --max-deliver begrenzt Zustellversuche und --filter schränkt den Consumer auf einen Teil der Subjects ein. Wird die Anzahl der Zustellversuche überschritten, kann eine Nachricht in einen eigenen Fehler-Stream (dead letter) wandern – das ist die Stelle, an der verlorene Nachrichten sichtbar werden.

Konsumieren und Nachrichten verwalten

# Mit dem CLI-Client konsumieren
nats consumer next BESTELLUNGEN ARBEITER --count 10

# Nachricht wiederherstellen/erneut zustellen
nats stream get BESTELLUNGEN 5
nats consumer rm BESTELLUNGEN ARBEITER

# Stream sichern und wiederherstellen
nats stream backup BESTELLUNGEN /backup/nats --check
nats stream restore /backup/nats

# Nachrichten löschen
nats stream purge BESTELLUNGEN --keep 1000   # nur die letzten 1000 behalten
nats stream purge BESTELLUNGEN --subject bestellungen.test

Accounts, Benutzer und Rechte

nats account add APP
nats account info APP

nats user add arbeiter --account APP
nats user info APP arbeiter

# Rechte über Konfigurationsdatei (Auszug)
# authorization {
#   users = [
#     { user: "arbeiter", password: "geheim"
#       permissions: { publish: "bestellungen.>", subscribe: "aufgaben.>" } }
#   ]
# }

Monitoring

nats-top                      # interaktive Übersicht
nats server ls
nats server info
nats server report connections
nats server ping

# Endpunkte der Monitoring-Schnittstelle
# /varz   Variablen und Statistik
# /connz  aktive Verbindungen
# /subsz  Abonnements
# /jsz    JetStream-Status

Praxis-Tipps

• Reihenfolge und Verlust klären: Ohne JetStream ist NATS reines Pub/Sub – ist kein Abonnent angemeldet, ist die Nachricht weg. Für dauerhafte Aufgaben, Verarbeitung mit Wiederholung und Zustellgarantien braucht es JetStream.
• nats server report connections ist die erste Diagnose: Es zeigt, welcher Client wie viele Verbindungen hält und wie viel Datenverkehr erzeugt. Ein Client mit tausenden Verbindungen ist meist ein Fehler in der Ressourcenverwaltung.
• Streams mit Replikation anlegen: --replicas 3 in einem Cluster, sonst ist ein Knotenausfall ein Datenverlust.
• Aufbewahrung bewusst wählen: limits (Zeit, Anzahl, Größe), interest (nur solange Interesse besteht) und workqueue (jede Nachricht genau einmal) haben sehr unterschiedliches Verhalten. Die Wahl entscheidet über Datenhaltung und Zustellmuster.

Verwandte Grundlagen: Message Queue, Ereignisgesteuerte Architektur, Message Broker, RabbitMQ-Befehle.

mosquitto, mosquitto_pub und mosquitto_sub sind die Werkzeuge des MQTT-Brokers Eclipse Mosquitto. MQTT ist ein leichtes Publish/Subscribe-Protokoll für Geräte mit wenig Bandbreite und Energie – der Standard in IoT und Gebäudeautomation.

Broker starten und prüfen

mosquitto -c /etc/mosquitto/mosquitto.conf -v
systemctl status mosquitto
systemctl enable --now mosquitto

# Läuft der Port?
ss -lntp | grep 1883
ss -lntp | grep 8883        # TLS

Publizieren und abonnieren

# Zuhören
mosquitto_sub -h localhost -t 'haus/+/temperatur' -v
mosquitto_sub -h localhost -t 'haus/#' -v -q 1

# Nachricht senden
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -m '21.5'
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -m '21.5' -q 1 -r

# Mit Benutzer und Passwort
mosquitto_pub -h broker.example.org -u sensor -P geheim \
  -t 'fabrik/presse/druck' -m '4.2' -q 2

# TLS
mosquitto_sub -h broker.example.org -p 8883 \
  --cafile /etc/ssl/certs/ca.pem -t 'haus/#'

Das Topic-Modell ist hierarchisch: + passt auf genau eine Ebene, # auf alle folgenden. haus/+/temperatur erhält also haus/wohnzimmer/temperatur, aber nicht haus/og/schlafzimmer/temperatur.

Quality of Service und letzte Nachricht

• QoS 0: höchstens einmal – schnell, Verlust möglich.
• QoS 1: mindestens einmal – Bestätigung, dafür Duplikate möglich.
• QoS 2: genau einmal – aufwendiger Handshake, langsamer.
• Retained Message (-r): Der Broker speichert die letzte Nachricht eines Topics und liefert sie jedem neuen Abonnenten sofort aus. Damit erhält ein neu gestartetes Gerät den aktuellen Zustand, ohne zu warten.
• Last Will: Beim Verbinden kann ein Gerät festlegen, welche Nachricht der Broker verschickt, wenn die Verbindung unerwartet abbricht – die übliche Art, „Gerät offline“ zu melden.

# Letzte Nachricht löschen
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -r -n

# Will-Nachricht setzen
mosquitto_sub -h localhost -t 'haus/keller/temperatur' \
  --will-topic 'status/keller' --will-payload 'offline' --will-qos 1 -v

Benutzer und Zugriffskontrolle

# Passwortdatei anlegen
mosquitto_passwd -c /etc/mosquitto/passwd sensor
mosquitto_passwd /etc/mosquitto/passwd arbeiter

# Konfiguration (Auszug)
# listener 1883
# allow_anonymous false
# password_file /etc/mosquitto/passwd
# acl_file /etc/mosquitto/acl
#
# acl-Datei:
# user sensor
# topic write fabrik/presse/#
# user arbeiter
# topic read fabrik/#

Der wichtigste Sicherheitshinweis: Ohne allow_anonymous false und eine ACL darf jedes Gerät im Netz jedes Topic lesen und schreiben – auch die Steuerbefehle der Heizung. Ein offener MQTT-Broker im Internet ist eine der häufigsten IoT-Schwachstellen überhaupt. Für Produktionsbetrieb gehören TLS mit Zertifikaten, Benutzer je Gerät und eng gefasste ACLs dazu.

Diagnose

# Alle Topics beobachten (Vorsicht: viel Ausgabe)
mosquitto_sub -h localhost -t '#' -v

# Verbindungszustand im Broker-Log
journalctl -u mosquitto -f

# Topics auflisten – MQTT kennt keine Topic-Liste!
# Hilfsmittel: Nachrichten mitschneiden und Topics sammeln
mosquitto_sub -h localhost -t '#' -v | awk '{print $2}' | sort -u

Praxis-Tipps

• Kein Topic-Verzeichnis: MQTT kennt nur Topics, die gerade benutzt werden. Ein Schema gehört in die Dokumentation, sonst entsteht Wildwuchs, den niemand mehr überblickt.
• Retained Messages bewusst nutzen: Für Zustandswerte sinnvoll, für Ereignisse („Tür geöffnet“) falsch – ein später Abonnent bekäme sonst eine alte Meldung als aktuell.
• QoS 2 sparsam: Es kostet vier Pakete pro Nachricht. In den meisten Fällen genügt QoS 1 mit idempotenter Verarbeitung.
• Testablauf mit -v: Die Option zeigt Topic und Nutzlast – unverzichtbar, um zu prüfen, ob ein Gerät überhaupt sendet.

Verwandte Grundlagen: Message Queue, IoT, Message Broker, TLS 1.3.

otelcol (OpenTelemetry Collector) und das Werkzeug otel-cli gehören zum OpenTelemetry-Ökosystem. Der Collector ist das zentrale Element: Er nimmt Telemetriedaten entgegen, verarbeitet sie und leitet sie an ein oder mehrere Backends weiter. Diese Referenz zeigt Konfiguration, Prüfung und Diagnose.

Start und Prüfung

# Mit Konfigurationsdatei starten
otelcol --config /etc/otelcol/config.yaml

# Konfiguration vor dem Start prüfen
otelcol validate --config /etc/otelcol/config.yaml

# Als Dienst
systemctl status otelcol
systemctl enable --now otelcol

# Endpunkte: OTLP gRPC 4317, OTLP HTTP 4318, interne Metriken 8888

Aufbau der Konfiguration

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: node
          static_configs:
            - targets: ["web01:9100"]

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 20
  resourcedetection:
    detectors: [env, system]

exporters:
  otlphttp/tempo:
    endpoint: http://tempo:4318
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/tempo]
    metrics:
      receivers: [otlp, prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]
  telemetry:
    metrics:
      readers:
        - pull:
            exporter:
              prometheus:
                host: 0.0.0.0
                port: 8888

Drei Bausteintypen sind zu unterscheiden: Receivers nehmen Daten an, Processors verändern sie, Exporters geben sie weiter. Die service-Sektion verbindet sie zu Pipelines pro Signalart (traces, metrics, logs).

Zwei wichtige Prozessoren

• memory_limiter: gehört an den Anfang jeder Pipeline. Bei Speicherdruck verwirft der Collector Daten, statt selbst abzustürzen – ein abgestürzter Collector verliert alles, ein überlasteter nur einen Anteil.
• batch: gehört ans Ende. Es bündelt Datensätze und reduziert die Anzahl der Netzwerkaufrufe an das Backend erheblich.

Konfiguration prüfen und testen

# Gültigkeit prüfen
otelcol validate --config config.yaml

# Mit Debug-Ausgabe starten: zeigt Datensätze auf der Konsole
# exporter "debug" in die Pipeline aufnehmen
otelcol --config config.yaml | grep -i "Resource"

# Testdaten erzeugen
otel-cli exec --service demo --name "test-span" --attribute key=value true
otel-cli span --service demo --name "mein-span" --endpoint localhost:4317

# Direkt per curl testen (OTLP/HTTP, Protobuf)
# Praktischer: ein SDK-Beispielprogramm senden lassen

Betrieb und Skalierung

# Collector als DaemonSet auf jedem Knoten (Konfiguration in Kubernetes)
# kubectl get pods -n observability -l app=otelcol

# Collector als Deployment für zentrale Aggregation
# - Agent-Modus: jede Node liefert an den zentralen Collector
# - Gateway-Modus: nur Export nach außen

# Mehrere Collectoren hintereinander: loadbalancing-Exporter
exporters:
  loadbalancing:
    routing_key: traceID          # oder service
    protocol:
      otlp:
        ttl: 30s
        timeout: 5s
    resolver:
      static:
        hostnames:
          - otelcol-0:4317
          - otelcol-1:4317

Der loadbalancing-Exporter ist die Antwort auf horizontale Skalierung: Er verteilt Spans desselben Traces immer an dieselbe Instanz, weil sonst Teile eines Traces in verschiedenen Collectoren landen und dort verworfen würden.

Wichtige Filter und Transformationen

processors:
  # Nicht benötigte Attribute entfernen (spart Volumen und Kosten)
  attributes/scrub:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: k8s.pod.uid
        action: delete

  # Nur bestimmte Dienste durchlassen
  filter/traces:
    error_mode: ignore
    traces:
      span:
        - 'attributes["service.name"] == "healthcheck"'

  # Attribute umbenennen
  transform:
    trace_statements:
      - context: span
        statements:
          - set(attributes["env"], "prod")

Praxis-Tipps

• memory_limiter immer zuerst: Ohne ihn kann der Collector bei Lastspitzen den gesamten Knoten in Speichernot bringen.
• Debug-Exporter nur kurzzeitig: Er schreibt jeden Datensatz auf die Konsole – bei realer Last ist das selbst eine Lastursache.
• Sampling nicht vergessen: Vollständiges Tracing in großen Umgebungen erzeugt enormes Volumen. Sampling-Entscheidungen gehören in die Anwendung oder in den Collector, nicht ins Backend.
• Auth für OTLP: Ein offener OTLP-Empfänger im Netz nimmt Daten von jedem an. Für den internen Betrieb genügt TLS plus ein Token-Header; nach außen gehört ein Reverse-Proxy mit Authentifizierung davor.

Verwandte Grundlagen: OpenTelemetry, Observability, promtool-Befehle, Jaeger.

grafana, grafana-cli und grafana-server sind die Verwaltungswerkzeuge für Grafana. Sie starten den Dienst, installieren Plugins, verwalten Dashboards und prüfen den Zustand. Diese Referenz zeigt die wichtigsten Aufrufe rund um Betrieb und Datasources.

Dienst und Prüfung

systemctl status grafana-server
systemctl restart grafana-server
journalctl -u grafana-server -f

# Standardport 3000
curl -s http://localhost:3000/api/health | jq .
ss -lntp | grep 3000

Plugins

grafana-cli plugins list-remote | head
grafana-cli plugins install grafana-clock-panel
grafana-cli plugins install grafana-piechart-panel
grafana-cli plugins ls

# Nach der Installation Dienst neu starten
systemctl restart grafana-server

# In aktuellen Versionen auch über die Umgebung
GF_INSTALL_PLUGINS="grafana-clock-panel,grafana-piechart-panel"

API-Zugriff und Authentifizierung

export GRAFANA_URL=http://localhost:3000
export GRAFANA_TOKEN=glsa_xxx

# Health und Version
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" $GRAFANA_URL/api/health | jq .

# Servicekonto anlegen (empfohlener Weg für Automatisierung)
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  $GRAFANA_URL/api/serviceaccounts \
  -d '{"name":"provisioning","role":"Admin"}' | jq .

Dashboards über die API

# Alle Dashboards auflisten
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" \
  "$GRAFANA_URL/api/search?type=dash-db" | jq '.[] | {uid,title,folderTitle}'

# Ein Dashboard exportieren (JSON)
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" \
  "$GRAFANA_URL/api/dashboards/uid/abc123" | jq . > dashboard.json

# Ein Dashboard importieren
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" --data-binary @dashboard.json \
  "$GRAFANA_URL/api/dashboards/db" | jq .

# Ordner anlegen
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  "$GRAFANA_URL/api/folders" -d '{"title":"Produktion"}' | jq .

Provisionierung statt Handarbeit

Dashboards und Datenquellen lassen sich als Dateien ablegen; Grafana liest sie beim Start. Das ist der Weg für reproduzierbare Umgebungen.

# /etc/grafana/provisioning/datasources/prometheus.yaml
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: Standard
    folder: Produktion
    type: file
    options:
      path: /var/lib/grafana/dashboards

Der Vorteil: Ein neu aufgesetzter Grafana-Server bekommt die komplette Konfiguration aus versionierten Dateien – kein Klicken, kein Export-Import, keine Abweichung zwischen Test und Produktion.

Monitoring von Grafana selbst

# Interne Metriken von Grafana
curl -s http://localhost:3000/metrics | grep -E '^grafana_(http|alerting)' | head

# Dashboard-Ladezeiten
# im Log oder über die eigene Metrik
journalctl -u grafana-server | grep -i "slow"

# Datenbankwartung (SQLite ist Standard, PostgreSQL für größere Setups)
grafana-cli admin reset-admin-password

Benutzer und Organisationen

# Benutzer anlegen
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" $GRAFANA_URL/api/admin/users \
  -d '{"name":"Max","email":"Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.","login":"max","password":"geheim"}' | jq .

# Passwort zurücksetzen (CLI, auch ohne API-Zugang)
grafana-cli admin reset-admin-password --password geheim

# Datenbank sichern (SQLite)
cp /var/lib/grafana/grafana.db /backup/grafana-$(date +%F).db

Praxis-Tipps

• Provisionierung vor Handarbeit: Über die Oberfläche erstellte Dashboards sind nicht reproduzierbar und gehen bei einem Neuaufbau verloren. Dateien im Repository sind die robuste Lösung.
• Servicekonten statt Admin-Token: Für Automatisierung ein Konto mit minimal nötigen Rechten anlegen und ein Token mit Ablaufzeit verwenden.
• Datenbank sichern: In der Standardinstallation liegt alles in grafana.db. Ein Backup dieses Datei plus der Provisionierungsdateien deckt die gesamte Konfiguration ab.
• Alerting nicht doppelt: Wer Alarme aus Prometheus über den Alertmanager fährt, sollte in Grafana nicht dieselben Bedingungen erneut alarmieren – doppelte Meldungen erzeugen Alarmmüdigkeit.
• Dashboard-Ordner nutzen: Ab einer Handvoll Dashboards ist eine Ordnerstruktur nach Team oder System die Voraussetzung dafür, dass jemand etwas findet.

Verwandte Grundlagen: Grafana, promtool-Befehle, Alertmanager, Monitoring mit Prometheus und Grafana.