MDH GROUP · BLOG

Monitoring‑Playbook für self‑hosted Affilentra: Synthetic Events, Prometheus‑Metriken und Alerting

Einleitung Wenn Affilentra self‑hosted läuft, liegt Verantwortung für Tracking‑Integrität, Webhook‑Zustellung und Auszahlungsjobs beim Betreiber. Fehlende Konversionen, verzögerte Payout‑Jobs oder fehlerhafte Webhook‑Verarbeitung gefährden Umsatz und Partnervertrauen. Dieses Playbook beschreibt prag

← Alle Beiträge

Monitoring‑Playbook für self‑hosted Affilentra: Synthetic Events, Prometheus‑Metriken und Alerting

Einleitung

Wenn Affilentra self‑hosted läuft, liegt Verantwortung für Tracking‑Integrität, Webhook‑Zustellung und Auszahlungsjobs beim Betreiber. Fehlende Konversionen, verzögerte Payout‑Jobs oder fehlerhafte Webhook‑Verarbeitung gefährden Umsatz und Partnervertrauen. Dieses Playbook beschreibt pragmatische, umsetzbare Schritte: synthetische Conversions als End‑to‑End‑Checks, Prometheus‑Metriken für Zustand und Performance sowie Alerting über Alertmanager mit PagerDuty/Slack‑Integrationen für schnelle Eskalation.

Überblick: Was überwacht werden muss

  • Tracker‑Endpoint: Aufnahme von Klicks/Leads/Bestellungen und die unmittelbare Validierung.
  • Webhook‑Delivery: Zustellung von Conversion‑Benachrichtigungen an Händler oder externe Systeme.
  • Payout‑Jobs: Batch‑Durchläufe, Provisionsberechnung und Auszahlungsprozesse.
  • Infrastrukturmetrik: Latenz, Fehlerquoten, Datenbankverbindungen, Queue‑Länge.

Synthetic Transactions: End‑to‑End Prüfungen einrichten

Ziel ist ein regelmäßiger, automatisierter Testlauf, der den kompletten Weg einer Conversion simuliert — von Klick über Tracker bis zur Webhook‑Auslieferung und zur Payout‑Bearbeitung.

1. Testidentitäten und Test‑Merchants anlegen

Legen Sie eine oder mehrere dedizierte Testpartner und Test‑Händler in Ihrer Affilentra‑Instanz an. Diese Konten sollten klar gekennzeichnet, gering privilegiert und von Produktionsdaten getrennt sein.

2. Simulationsablauf definieren

Ein typischer Ablauf:

  • HTTP‑GET/POST an Tracker‑Endpoint mit Test‑Trackinglink.
  • Warten auf interne Verarbeitung; optional Prüfung, ob Conversion in DB eingetragen ist.
  • Prüfung der Webhook‑Zustellung an den konfigurierten Test‑Webhook‑Receiver.
  • Auslösung eines Payout‑Jobs (manuell oder per API) und Verifikation der Job‑Abschlüsse.

3. Technische Umsetzung

Implementieren Sie den Runner als Cronjob, Kubernetes‑CronJob oder in einem External Synthetic Monitoring Service. Beispielkomponenten:

  • Ein leichtes Script (curl, Python, Go) führt Tracker‑Requests aus und prüft HTTP‑Antwortcode und Response‑Payload.
  • Ein Endpoint‑Receiver akzeptiert Webhook‑Benachrichtigungen und bestätigt Empfang; Runner vergleicht erwartete mit tatsächlichen Webhook‑Events.
  • Optional: Validierung in Datenbanktabellen per read‑only DB‑User oder über die Affilentra‑API.

Wichtig: Testdaten dürfen keine realen Provisionen auslösen. Verwenden Sie Testflags oder separate Test‑Merchants.

Prometheus: Metriken definieren und exponieren

Prometheus eignet sich zur Aggregation von Verfügbarkeits‑ und Performancekennzahlen. Zwei Ansätze:

  • Application Metrics: Affilentra exponiert einen /metrics‑Endpoint (oder ein kleines PHP‑Exporter‑Script) mit Kernkennzahlen.
  • Exporter/Proxies: Externe Sidecar‑Exporter sammeln Latenz und Fehler aus Webserver‑Logs, Queue‑Systemen oder Cron‑Runnables.

Empfohlene Metriken

  • affilentra_tracker_requests_total{status="200|400|500"}
  • affilentra_tracker_latency_seconds_bucket
  • affilentra_webhook_deliveries_total{status="success|failure"}
  • affilentra_webhook_retry_count
  • affilentra_payout_jobs_total{state="running|failed|success"}
  • affilentra_payout_job_duration_seconds
  • affilentra_db_connections_current
  • affilentra_queue_length

Exponieren Sie in jedem Fall Latenz (Histogram) und Fehlerzähler (Counters). Scrape‑Interval 15–30s ist praxisgerecht; längere Intervalle für nicht‑kritische Jobs.

Alertmanager: Regeln und Eskalationen

Leiten Sie Alerts aus Prometheus an Alertmanager weiter und konfigurieren Sie Receiver für PagerDuty und Slack.

Beispielhafte Alerting‑Regeln (Konzept)

  • Tracker‑Fehler: Wenn tracker_errors_total in 5min > 1% der Requests → Warning; > 5% in 5min → Critical.
  • Webhook‑Failure: Wenn webhook_failures_total in 10min > 3 → Critical.
  • Webhook‑Latency: Wenn webhook_latency_p95 > 2s für 10min → Warning.
  • Payout‑Job‑Failure: Wenn payout_jobs_failed_total > 0 in 15min → Critical.
  • Queue‑Backlog: Wenn affilentra_queue_length > konfigurierter Threshold → Warning.

Formulieren Sie Alerts so, dass sie auf konkrete Maßnahmen verweisen (z. B. "Prüfe Webhook‑Endpoint, letzte Response‑Codes und Retry‑Queue").

Integration in PagerDuty und Slack

Alertmanager unterstützt mehrere Receiver. Konfigurieren Sie:

  • PagerDuty: Verwenden Sie den PagerDuty‑API‑Key als Alertmanager‑Receiver für Critical‑Alerts. Legen Sie Routing so fest, dass Critical‑Alerts sofort in den On‑Call‑Rotations erscheinen.
  • Slack: Schicken Sie Warnings und Incidents an dedizierte Channels; fügen Sie Links zur Grafana‑Dashboard und zum Runbook hinzu.

Testen Sie das Routing durch gezielte Trigger: synthetische Conversion mit manipulierten Antworten, um die gesamte Kette zu prüfen.

Dashboards und Runbooks

Ein Dashboard (Grafana) sollte folgende Panels enthalten:

  • Tracker: Requests/sec, Fehler‑Rate, p95/p99 Latenz.
  • Webhook: Delivery‑Rate, Fehler‑Gründe, Retry‑Queue.
  • Payout‑Jobs: Laufende Jobs, Dauer, fehlgeschlagene Jobs.
  • Infrastruktur: DB‑Verbindungen, CPU, Memory, Queue‑Längen.

Erstellen Sie zu jedem kritischen Alert ein kurzes Runbook mit: erste Prüfungen, typische Ursachen, schnelle Remediationschritte, und wie man ein Incident eskaliert. Verlinken Sie Runbooks direkt in Slack‑Messages und PagerDuty‑Incidents.

Praxisbeispiele: Schnelle Checks

  • Synthetic Tracker Check: HTTP POST an Tracker, prüfe 200 + valid payload; bei Fehler → erhöhe Logging‑Level, prüfe Webserver‑Logs und DB‑Writes.
  • Webhook Check: Test‑Webhook empfängt Event; prüfe Signatur/Authentifizierung und Statuscode 200; bei 4xx → Konfig prüfen, bei 5xx → Empfängerseite kontaktieren.
  • Payout Job Check: Starte Job im Testmodus; prüfe, ob Job queued → processed → completed innerhalb erwarteter Zeit.

Rollout und Betrieb

Starten Sie mit einem Minimum Viable Monitoring: Synthetic Runner + 5–8 Prometheus Metriken + zwei Alertmanager‑Receivers (PagerDuty, Slack). Intensivieren Sie schrittweise: mehr Metriken, granulare Alerts, Dashboards und automatisierte Remediation (z. B. Restart von Background‑Worker via Kubernetes Job).

Abschließende Empfehlung

Self‑hosting bedeutet Kontrolle — diese Kontrolle sollten Sie in zuverlässige Überwachung übersetzen. Mit synthetischen Conversions prüfen Sie End‑to‑End‑Funktionalität; Prometheus liefert beobachtbare Kennzahlen; Alertmanager mit PagerDuty/Slack sorgt für schnelle Reaktion. Affilentra lässt sich so als Betreiber proaktiv betreiben: Tracking transparent, Webhooks verlässlich, Payouts nachprüfbar.

Bereit für den nächsten Schritt? Wählen Sie den Einstieg und testen Sie Monitoring‑Best Practices direkt in Ihrer Affilentra‑Instanz: Einstieg wählen.

Nächster Schritt

Affilentra selbst ausprobieren

Einheitliche Plattform, die Produktbereitstellung, Tracking, Conversion-Validierung, Provisionsberechnung und Auszahlung entlang klar getrennter Rollen transparent zusammenführt; Option zur self-hosted Installation mit Dauerlizenz ohne Umsatzbeteiligung; Händler behalten Kontrolle über Produkte, Konditionen und Werbemittel; Partner erhalten persönliche Trackinglinks und nachvollziehbare Auszahlungshistorie.

Einstieg wählen