SMTP-Relay für operative Alerts und System-Benachrichtigungen

Operative Alerts und System-Benachrichtigungen — Nagios, Zabbix, Prometheus AlertManager, Grafana, AWS CloudWatch — sind eine spezifische Kategorie von E-Mail-Versand. Anders als Marketing oder transactional gehen Alerts an interne Empfänger mit anderen Anforderungen.

Was Alert-Mails von anderen unterscheidet

• Geschwindigkeit kritisch: Critical-Alert muss in Sekunden im Postfach des On-Call-Engineers sein
• Bursty-Traffic: normalerweise niedrig, aber bei System-Ausfall plötzlich 100+ Mails in Minuten
• Niedrige Beschwerde-Quote strukturell: Empfänger sind interne Teams
• Korrelation wichtig: Empfänger müssen mehrere Alerts schnell als zusammenhängend erkennen
• Persistenz wichtig: Alerts werden für Post-Mortems archiviert

SMTP-Konfiguration für Alert-Versand

# Prometheus AlertManager
# alertmanager.yml

global:
  smtp_smarthost: 'smtp.authorizehosting.com:587'
  smtp_from: 'alerts@ihr-unternehmen.de'
  smtp_auth_username: '[Authorize-Username]'
  smtp_auth_password: '[Authorize-Passwort]'
  smtp_require_tls: true

route:
  group_by: ['alertname', 'service']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'oncall-team'

receivers:
  - name: 'oncall-team'
    email_configs:
      - to: 'oncall@ihr-unternehmen.de'
        send_resolved: true

Alert-Storm-Handling

Häufiges Problem: zentraler Service fällt aus, hunderte abhängige Services generieren Alerts gleichzeitig. Ohne Handling:

• SMTP-Relay throttelt (4xx-Fehler)
• On-Call-Engineer bekommt unleserlichen Mail-Strom
• Wichtige Alerts gehen in der Masse unter

1. Group-Aggregation

group_wait: 10s sorgt dafür, dass Alerts aggregiert werden. Statt 50 einzelner Alerts gibt es eine zusammengefasste Mail.

2. Inhibit-Rules

inhibit_rules:
  - source_match:
      severity: 'critical'
      alertname: 'DatabaseDown'
    target_match:
      service: 'api'
    equal: ['cluster']
# Wenn DatabaseDown aktiv: alle API-Service-Alerts unterdrücken

3. Severity-basiertes Routing

route:
  routes:
    - match:
        severity: 'critical'
      receiver: 'pagerduty'
    - match:
        severity: 'warning'
      receiver: 'email-warnings'
    - match:
        severity: 'info'
      receiver: 'slack-info'

Versandströme-Trennung für Alerts

In Multi-Brand-Setups Alerts nicht über transactional/Marketing-Versand-Infrastruktur laufen lassen:

# Eigene Alert-Domain
alerts.ihr-unternehmen.de. IN MX 10 mx.authorizehosting.com.
alerts.ihr-unternehmen.de. IN TXT "v=spf1 include:_spf.authorizehosting.com -all"
auth1._domainkey.alerts.ihr-unternehmen.de. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

# Monitoring-Tools verwenden:
SMTP-From: alerts@alerts.ihr-unternehmen.de
SMTP-Reply-To: oncall@ihr-unternehmen.de

Strukturierter Alert-Inhalt

Subject: [CRITICAL] DatabaseDown - production-cluster-eu

🚨 ALERT: DatabaseDown
Severity: critical
Service: production-cluster-eu
Started: 2026-04-25 14:32:15 UTC
Duration: 3 minutes

Description:
PostgreSQL primary database not responding to health checks.

Affected Components:
- api-server (down)
- worker-pool (degraded)

Runbook: https://wiki.ihr-unternehmen.de/runbooks/db-down
Dashboard: https://grafana.ihr-unternehmen.de/d/postgres-cluster
Acknowledge: https://alertmanager.ihr-unternehmen.de/...

Konkrete Beispiele für Monitoring-Tools

Nagios / Icinga

# /etc/postfix/main.cf - sendmail über externen Relay
relayhost = [smtp.authorizehosting.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_security_level = may

Zabbix

# Frontend → Administration → Media types → Email
SMTP server: smtp.authorizehosting.com
SMTP server port: 587
SMTP email: alerts@alerts.ihr-unternehmen.de
Connection security: STARTTLS

Grafana

# grafana.ini
[smtp]
enabled = true
host = smtp.authorizehosting.com:587
user = [Authorize-Username]
password = [Authorize-Passwort]
from_address = alerts@alerts.ihr-unternehmen.de
startTLS_policy = MandatoryStartTLS

Operative Best-Practices

Test-Alerts regelmäßig: Wöchentlicher Test-Alert um sicherzustellen, dass Pipeline funktioniert.

Alert-Fatigue beobachten: mehr als 20-30 Alerts/Tag pro Person reduzieren Aufmerksamkeit.

Resolved-Notifications senden: nicht nur "Problem aufgetreten", auch "Problem gelöst".

Mehrere Alerting-Kanäle: Critical → Pager + SMS, Warning → E-Mail, Info → Slack.

Konsistente Subject-Pattern: "[ALERT-CRIT]", "[ALERT-WARN]" für Filter-Regeln.