Organisationseinstellungen
Die Organisationseinstellungen ermöglichen Admins die Konfiguration von Infrastruktur-Optionen. Navigieren Sie zu Organisation > Einstellungen in der Seitenleiste.
Eigene SMTP-Server (E-Mail)
Konfigurieren Sie eigene SMTP-Server für ausgehende E-Mail-Benachrichtigungen.
Pulse versendet Benachrichtigungs-E-Mails automatisch über den integrierten E-Mail-Dienst. Fügen Sie einen eigenen SMTP-Server hinzu, um E-Mails von Ihrer eigenen Domain zu senden. Sind mehrere eigene SMTP-Server konfiguriert, probiert Pulse sie in der angezeigten Reihenfolge und verwendet den ersten, der erfolgreich antwortet.
Klicken Sie auf Server hinzufügen, um einen neuen SMTP-Server zu konfigurieren:
| Feld | Beschreibung |
|---|---|
| Host | SMTP-Server-Hostname |
| Port | SMTP-Server-Port (z.B. 587 für TLS) |
| Benutzername | Authentifizierungs-Benutzername |
| Passwort | Authentifizierungs-Passwort |
| Absenderadresse | E-Mail-Adresse, die als Absender verwendet wird |
| Absendername | Anzeigename, der als Absender verwendet wird |
| TLS verwenden | TLS-Verschlüsselung für die Verbindung aktivieren |
TIP
Um die Einstellungen zu validieren, können Sie test E-Mails absetzen.
INFO
SMTP-Server werden nur für Benachrichtigungs-E-Mails verwendet. Benutzer-E-Mails wie Registrierungen sind nicht betroffen.
Lizenzen
Lizenzen haben eine eigene Seite. Unter Lizenzen können Sie einen Lizenzschlüssel hinzufügen, Ihre Plan-Limits und Nutzung einsehen und mehr über das Lizenzstatus-Banner erfahren.
Lizenznutzung
Das Nutzungspanel zeigt, wie der aktuelle Verbrauch Ihrer Organisation mit den Limits Ihrer aktiven Lizenz verglichen wird – gemessen über die gesamte Lizenzlaufzeit.
Das Panel ist in zwei Gruppen unterteilt:
Plan-Limits — Dimensionen mit einem Kontingent, dargestellt als Fortschrittsbalken:
| Dimension | Beschreibung |
|---|---|
| Endpunkt-Monitore | Konfigurierte Datenquellen im Verhältnis zum Plan-Limit |
| Knoten-Monitore | Aufbewahrte Datenpunkte im Verhältnis zum Plan-Limit |
| Bereitschaftspläne | Aktive Bereitschaftspläne im Verhältnis zum Plan-Limit |
| E-Mails | Während der Lizenzlaufzeit versendete E-Mails |
| SMS | Während der Lizenzlaufzeit versendete SMS-Nachrichten |
| Sprachanrufe | Während der Lizenzlaufzeit getätigte Sprachanrufe |
Die Balkenfarbe gibt Auskunft über den Kapazitätsstatus:
- Grau — innerhalb der Limits (unter 80 %)
- Gelb / Limit fast erreicht — Kontingent wird bald ausgeschöpft (80 – 99 %)
- Gelb / Limit erreicht — Nutzung liegt genau am Kontingent (100 %)
- Rot / +N darüber — Kontingent überschritten
Dimensionen, die nicht im Plan enthalten sind, werden mit dem Badge „nicht in Ihrem Plan" gekennzeichnet. Wenn trotzdem Nutzung anfällt, wechselt der Badge auf Rot.
Erfasste Nutzung — Dimensionen ohne Kontingent-Limit, als reine Zähler für die Lizenzlaufzeit:
| Dimension | Beschreibung |
|---|---|
| Benachrichtigungen | Versendete In-App-Benachrichtigungen |
| Push-Benachrichtigungen | Versendete mobile Push-Benachrichtigungen |
| Webhooks | Durchgeführte Webhook-Zustellungen |
Funktionen — lizenzierte Fähigkeiten, angezeigt als aktiviert (✓) oder nicht enthalten (—):
| Funktion | Beschreibung |
|---|---|
| MCP (Model Context Protocol) | Ob sich MCP-Clients mit Ihrer Organisation verbinden können |
| CVE-Überwachung | Ob CVE-Monitore erstellt werden können und Scans durchführen |
| KI-Canvas | Ob der KI-Canvas-Untersuchungsbereich aktiviert ist |
Ist keine aktive Lizenz mit der Organisation verknüpft, zeigt das Panel stattdessen einen Hinweis an. Wenden Sie sich an Ihren Administrator, um einen Lizenzschlüssel hinzuzufügen.
Webhooks
Webhooks ermöglichen es Pulse, bei bestimmten Ereignissen Echtzeit-Benachrichtigungen per HTTP(S) oder TCP an externe Systeme zu senden.
Navigieren Sie zu Organisation > Einstellungen > Webhooks, um Webhooks zu verwalten.
Klicken Sie auf Webhook hinzufügen, um einen neuen Webhook zu erstellen:
| Feld | Beschreibung |
|---|---|
| Anzeigename | Eine Bezeichnung zur Identifikation dieses Webhooks |
| Endpunkt-URL | Ziel-URL – unterstützt die Schemata https://, http:// oder tcp:// |
| Aktiv | Aktivieren oder deaktivieren Sie die Zustellung |
| Ereignistypen | Wählen Sie aus, welche Ereignisse diesen Webhook auslösen |
WARNING
Pulse zeigt eine Warnung „Unverschlüsselter Transport" an, wenn Sie eine tcp://- oder http://-URL eingeben. Reines TCP und reines HTTP verschlüsseln Payloads während der Übertragung nicht – verwenden Sie diese Schemata nur für Altsysteme, die kein HTTPS unterstützen.
INFO
TCP-Payloads werden mit Leerzeichen aufgefüllt, sodass die Gesamtlänge der Nachricht (JSON + Padding + Zeilenumbruch) immer ein Vielfaches von 64 Bytes beträgt. Dies unterstützt festgroße Stream-Puffer auf SPS-Steuerungen, die in 64-Byte-Blöcken lesen.
So funktioniert die Zustellung
Jedes Ereignis löst pro passendem Webhook eine Zustellung aus. Zustellungen an denselben Endpunkt werden der Reihe nach und einzeln verarbeitet, sodass ein langsamer Endpunkt niemals dafür sorgt, dass Ereignisse außerhalb der Reihenfolge ankommen.
Schlägt eine Zustellung fehl — Verbindungsfehler, HTTP-Antwort ohne 2xx-Status oder Timeout — wiederholt Pulse sie bis zu insgesamt 3 Versuchen mit exponentiellem Backoff zwischen den Versuchen. Nach dem dritten gescheiterten Versuch wird das Ereignis für diesen Endpunkt verworfen. Für darüber hinausgehende Ausfallsicherheit richten Sie den Webhook auf eine eigene Warteschlange oder einen Reverse-Proxy.
HTTP(S)-Transport
HTTP(S)-Endpunkte erhalten ein POST mit den folgenden Headern:
| Header | Wert |
|---|---|
Content-Type | application/json |
User-Agent | Pulse-Webhook/1.0 |
X-Pulse-Signature | sha256=<hex> — nur vorhanden, wenn Signierung aktiv |
Der Anfragetext ist die JSON-Ereignis-Payload — unverändert, ohne abschließenden Zeilenumbruch.
TCP-Transport
TCP-Endpunkte erhalten jeden Frame in der Reihenfolge JSON-Payload → ASCII-Leerzeichen-Auffüllung (0x20) → ein einzelner Zeilenumbruch (\n) — die Leerzeichen stehen also zwischen der Payload und dem abschließenden Zeilenumbruch, der stets das letzte Byte ist. Die Auffüllung ist so bemessen, dass die Gesamtlänge des Frames (Payload + Leerzeichen + Zeilenumbruch) ein Vielfaches von 64 Bytes beträgt. Pulse öffnet pro Zustellung eine frische TCP-Verbindung, sendet den aufgefüllten Frame, schließt anschließend die Schreibseite des Sockets und beendet die Verbindung.
NOTE
Es handelt sich um reines TCP, nicht um WebSockets. Es gibt keinen HTTP-Upgrade-Handshake, keine Opcode-Frames und keine persistente Sitzung — jedes Ereignis ist eine eigene kurzlebige Verbindung. Die 64-Byte-Auffüllung existiert, damit SPS und ähnliche Steuerungen in festen Blockgrößen lesen können. Der nachgestellte Zeilenumbruch und die Leerzeichen sind gemäß der JSON-Spezifikation (RFC 8259, wonach JSON-text = ws value ws gilt und ws das Leerzeichen 0x20 sowie den Zeilenumbruch 0x0A umfasst) unbedeutender Leerraum, sodass jeder spezifikationskonforme JSON-Parser den aufgefüllten Frame unverändert akzeptiert — ein Abschneiden ist nicht erforderlich. Ist Ihr Parser strenger als die Spezifikation, lesen Sie bis zum Ende des Streams und schneiden Sie den nachgestellten Leerraum vor dem Parsen ab.
Signaturen prüfen
Wenn Sie für einen Webhook ein oder mehrere Signaturgeheimnisse konfigurieren, enthält jede HTTP(S)-Zustellung einen X-Pulse-Signature-Header mit einem HMAC-SHA256 des Anfragetexts.
Der Header-Wert ist eine durch Kommas getrennte Liste aus sha256=<hex>-Einträgen — einer pro Geheimnis, in der Reihenfolge, in der die Geheimnisse beim Webhook hinterlegt sind. Mehrere Einträge ermöglichen es Ihnen, Geheimnisse zu rotieren, ohne Zustellungen zu verlieren: neues Geheimnis hinzufügen, neuen Verifizierer ausrollen (der beide Geheimnisse akzeptiert), dann das alte Geheimnis entfernen.
Eine Zustellung verifizieren:
- Lesen Sie den rohen Anfragetext als Bytes — parsen und re-serialisieren Sie das JSON nicht. Schon unbedeutende Whitespace-Unterschiede verändern den Hash.
- Berechnen Sie
HMAC-SHA256(geheimnis, body)und formatieren Sie das Ergebnis als kleingeschriebene Hexadezimalzeichenkette. - Vergleichen Sie Ihren berechneten Wert
sha256=<hex>mit mindestens einem der Einträge inX-Pulse-Signature. Verwenden Sie einen zeitkonstanten Vergleich, um Timing-Lecks zu vermeiden. - Stimmt mindestens ein Eintrag überein, ist die Zustellung authentisch. Stimmt keiner überein, lehnen Sie die Anfrage ab.
Node.js-Beispiel:
import crypto from "node:crypto";
// `body` muss der rohe Anfragetext als Bytes sein, kein geparstes Objekt.
function verifyPulseWebhook(body, header, secrets) {
const expected = secrets.map((secret) => {
const hex = crypto.createHmac("sha256", secret).update(body).digest("hex");
return `sha256=${hex}`;
});
const received = header.split(",").map((s) => s.trim());
return received.some((r) =>
expected.some(
(e) =>
e.length === r.length &&
crypto.timingSafeEqual(Buffer.from(e), Buffer.from(r)),
),
);
}Python-Beispiel:
import hmac
import hashlib
def verify_pulse_webhook(body: bytes, header: str, secrets: list[str]) -> bool:
expected = [
f"sha256={hmac.new(s.encode(), body, hashlib.sha256).hexdigest()}"
for s in secrets
]
received = [s.strip() for s in header.split(",")]
return any(hmac.compare_digest(e, r) for e in expected for r in received)WARNING
Verwenden Sie stets einen zeitkonstanten Vergleich (crypto.timingSafeEqual, hmac.compare_digest oder Äquivalent). Ein normaler String-Vergleich mit == kann die erwartete Signatur Byte für Byte über Timing-Unterschiede preisgeben.
Ereignistypen
Jeder Ereignistyp wird durch seinen event.type-Schlüssel in der Webhook-Payload identifiziert:
event.type | Beschreibung |
|---|---|
incident.created | Vorfall erstellt |
incident.acknowledged | Vorfall bestätigt |
incident.resolved | Vorfall behoben |
oncall.rotation | Bereitschaftswechsel oder Betriebszeiten geändert |
notification.email_scheduled | E-Mail-Benachrichtigung eingeplant |
notification.sms_scheduled | SMS-Benachrichtigung eingeplant |
notification.push_scheduled | Push-Benachrichtigung eingeplant |
notification.call_scheduled | Anruf eingeplant |
Webhook-Payload-Struktur
Jede Webhook-Zustellung ist ein JSON-Objekt. Pulse fügt das Feld event_type auf oberster Ebene zusammen mit den ereignisspezifischen Feldern ein:
{
"event_type": "incident.created",
...ereignisspezifische Felder
}Incident-Event-Payloads
Die Ereignisse incident.created, incident.acknowledged und incident.resolved verwenden die gleiche Payload-Struktur:
| Feld | Typ | Beschreibung |
|---|---|---|
event_type | string | Eines von incident.created, incident.acknowledged, incident.resolved |
incident_id | integer | ID des Vorfalls |
title | string | Titel des Vorfalls |
status | string | Vorfallstatus — "created", "acknowledged" oder "resolved" |
Benachrichtigungs-Event-Payloads
Die Ereignisse notification.email_scheduled, notification.sms_scheduled, notification.push_scheduled und notification.call_scheduled verwenden die gleiche Payload-Struktur:
| Feld | Typ | Beschreibung |
|---|---|---|
event_type | string | Eines von notification.email_scheduled, notification.sms_scheduled, notification.push_scheduled, notification.call_scheduled |
incident_id | integer | ID des Vorfalls, der die Benachrichtigung ausgelöst hat |
channel | string | Benachrichtigungskanal — "email", "sms", "push" oder "call" |
recipients | array | Liste der Benachrichtigungsempfänger |
Jeder Eintrag in recipients enthält:
| Feld | Typ | Beschreibung |
|---|---|---|
display_name | string | Anzeigename des Empfängers |
email | string|null | E-Mail-Adresse, falls vorhanden |
phone_number | string|null | Telefonnummer, falls vorhanden |
oncall.rotation-Payload
Das Ereignis oncall.rotation wird ausgelöst, wenn sich die aktiven Bereitschaftspersonen ändern oder sich der Betriebszeiten- oder Override-Status eines Zeitplans ändert:
| Feld | Typ | Beschreibung |
|---|---|---|
event_type | string | Immer "oncall.rotation" |
schedule_id | integer | ID des Bereitschaftsplans |
schedule_name | string | Name des Bereitschaftsplans |
previous_responders | array | Bereitschaftspersonen vor der Änderung |
current_responders | array | Bereitschaftspersonen nach der Änderung |
in_operating_hours | boolean | Ob der Zeitplan aktuell innerhalb der Betriebszeiten liegt |
is_override | boolean | Ob aktuell eine Ausnahme (Override) aktiv ist |
Jeder Eintrag in previous_responders und current_responders enthält:
| Feld | Typ | Beschreibung |
|---|---|---|
id | integer | Login-ID |
name | string | Anzeigename oder E-Mail-Adresse |
email | string | E-Mail-Adresse |
phone | string|null | Mobilnummer, falls hinterlegt |
Verbundene MCP-Clients
KI-Assistenten und Automatisierungswerkzeuge verbinden sich über das Model Context Protocol per OAuth mit Pulse: Jeder Benutzer autorisiert einen Client im Browser, pro Organisation. Es müssen keine Tokens mehr erstellt oder kopiert werden — der Client erkennt den Autorisierungsserver von Pulse, registriert sich selbst und leitet Sie zu einem Zustimmungsdialog.
INFO
Der MCP-Zugriff erfordert eine aktive Lizenz, die MCP einschließt. Der Zustimmungsdialog bietet nur Organisationen an, deren Lizenz MCP enthält; qualifiziert sich keine Ihrer Organisationen, wenden Sie sich an Ihren Administrator, um die Lizenz zu erweitern.
Einen Client verbinden
Der MCP-Endpunkt ist unter /mcp auf Ihrer Pulse-Instanz verfügbar. Die Registerkarte MCP-Clients in den Einstellungen zeigt die genaue URL mit einer Kopierschaltfläche.
Voraussetzung
CS_BASEURL muss auf die extern erreichbare Basis-URL Ihrer Pulse-Instanz gesetzt sein (z.B. https://pulse.example.com). Die OAuth-Discovery-Metadaten und die URL des Autorisierungsendpunkts werden daraus abgeleitet — mit dem Standardwert können Clients auf anderen Rechnern den Ablauf nicht abschließen.
Claude Code
claude mcp add --transport http pulse https://<ihre-domain>/mcpErsetzen Sie <ihre-domain> durch den Host, unter dem Ihre Pulse-Instanz erreichbar ist — derselbe Wert wie CS_BASEURL. Fügen Sie --scope user hinzu, um den Server in jedem Projekt auf Ihrem Rechner verfügbar zu machen und nicht nur im aktuellen.
Die erste Werkzeugnutzung (oder /mcp in Claude Code) öffnet Ihren Browser: Melden Sie sich bei Pulse an, wählen Sie die zu verbindende Organisation und genehmigen Sie den Zugriff. Tokens werden von da an automatisch verwaltet.
claude.ai, Cursor und andere MCP-Clients
Fügen Sie einen Remote-MCP-Server (HTTP) mit der URL https://<ihre-domain>/mcp hinzu. Der Client erkennt die OAuth-Konfiguration, registriert sich automatisch und öffnet den Pulse-Zustimmungsdialog in Ihrem Browser.
Der Zustimmungsdialog
Der Zustimmungsdialog benennt den Client, lässt Sie die zu verbindende Organisation wählen und listet auf, welchen Zugriff er erhält (Lesezugriff auf Monitore, Vorfälle, Tags, Sensordaten und CVEs). Er zeigt außerdem, wohin Sie nach der Genehmigung zurückgeleitet werden — prüfen Sie vor dem Klick auf Genehmigen, dass dieser Host zu dem Werkzeug passt, aus dem Sie die Verbindung gestartet haben.
Verbundene Clients verwalten
Navigieren Sie zu Organisation > Einstellungen > MCP-Clients, um alle Clients zu sehen, denen Zugriff auf die Organisation gewährt wurde.
Jede Zeile zeigt den Client, wer ihn autorisiert hat, wann er zuletzt verwendet und wann er verbunden wurde. Um den Zugriff zu widerrufen, klicken Sie auf das Löschen-Symbol und bestätigen Sie.
WARNING
Der Widerruf erfolgt sofort — die nächste Anfrage des Clients wird abgelehnt, auch wenn sein aktuelles Token noch nicht abgelaufen ist. Widerrufen Sie Clients, die Sie nicht mehr verwenden.
Verfügbare MCP-Werkzeuge
Der Pulse-MCP-Server stellt verbundenen Clients die folgenden Werkzeuge bereit. Die Parameter sind selbstbeschreibend — Ihr KI-Assistent erkennt sie automatisch über das MCP-Schema.
list_monitors— Monitore der Organisation auflisten und filtern.list_incidents— Vorfälle auflisten und filtern.query_data— Zeitreihendaten mit Aggregationen abfragen, dargestellt als ASCII-Graph oder Tabelle. Die Ergebnisse können nach Monitor, Datenpunkt oder Datenquelle gruppiert werden.query_cves— CVE-Funde über die überwachten Geräte hinweg abfragen.list_tags— Die Tags der Organisation auflisten.list_data_sources— Datenquellen auflisten und optional ihre einzelnen Datenpunkte: Adressen, letzte Messwerte und die Monitore, die sie lesen. So findet ein Assistent die Namen der Quellen und die Adressen der Datenpunkte, nach denenquery_datafiltert — und es ist das einzige Werkzeug, das einen Datenpunkt zeigen kann, für den kein Monitor alarmiert.get_condition— Den Bedingungsgraphen lesen, auf den ein Bedingungsmonitor alarmiert, samt dem aktuellen Wert jedes Knotens und dem Zeitpunkt, ab dem dieser Wert gilt. Ein Bedingungsmonitor hat keinen einzelnen Schwellenwert — dies beantwortet, welcher Eingang ihn ausgelöst hat.list_incident_events— Den Verlauf eines Vorfalls lesen: wann der Monitor ausgefallen ist und sich erholt hat, jede zugestellte Benachrichtigung und an wen, Bestätigungen, Auflösungen und Eskalationsschritte.
OPC-UA-Zertifikat
Navigieren Sie zu Organisation > Einstellungen > OPC-UA-Zertifikat, um das Anwendungsinstanzzertifikat zu verwalten — die gemeinsame X.509-Identität, mit der sich Pulse beim Aufbau sicherer OPC-UA-Kanäle (Modus Sign oder Sign & Encrypt) ausweist. Eine konzeptionelle Übersicht und den vollständigen Rotationsablauf finden Sie unter OPC-UA-Sicherheit — Anwendungsinstanz-Zertifikat.
Die Registerkarte zeigt den Antragsteller des aktiven Zertifikats, die Gültigkeitsdaten und den SHA-1-Fingerabdruck. Läuft eine Rotation, werden sowohl das aktive als auch das ausstehende Zertifikat angezeigt. Jeder Fingerabdruck ist gekennzeichnet — Aktuell für das aktive Zertifikat und Neu – vor Abschluss der Rotation vertrauen für das ausstehende — damit die beiden nicht verwechselt werden.
Aktionen
| Aktion | Verfügbar wenn | Beschreibung |
|---|---|---|
| PEM herunterladen | Aktives Zertifikat vorhanden | Zertifikatsdatei herunterladen, um sie auf Ihren OPC-UA-Servern zu installieren |
| Fingerabdruck kopieren | Aktives Zertifikat vorhanden | SHA-1-Fingerabdruck kopieren, um ihn in der Zertifikatsverwaltung Ihres Servers zu überprüfen |
| Zertifikat generieren | Kein aktives Zertifikat vorhanden | Zertifikat vorab bereitstellen (Pulse stellt es auch automatisch bei der ersten sicheren Verbindung bereit) |
| Zertifikat rotieren | Aktives Zertifikat vorhanden, keine Rotation in Gang | Ersatzzertifikat erstellen, um die Überlappungsrotation zu starten |
| Rotation abschließen | Ausstehende Zertifikat vorhanden | Ausstehendes Zertifikat als aktiv übernehmen — erst nach Vertrauen auf jedem Server |
| Ersatz verwerfen | Ausstehendes Zertifikat vorhanden | Laufende Rotation abbrechen und das ausstehende Zertifikat entfernen — ein Bestätigungsdialog erscheint |
| Zertifikat widerrufen | Aktives Zertifikat vorhanden | Nur im Notfall: aktives Zertifikat sofort durch eine neue Identität ersetzen |
WARNING
Zertifikat widerrufen verursacht einen sofortigen Ausfall der gesamten sicheren OPC-UA-Überwachung — jeder Server weist Pulse zurück, bis Sie das neue Zertifikat dort als vertrauenswürdig eingetragen haben. Verwenden Sie für einen geplanten, unterbrechungsfreien Austausch stattdessen die Rotation.
Verwandte Seiten
- Mitglieder & Rollen -- Organisationsmitglieder verwalten
- Einstellungen -- Persönliche Benachrichtigungseinstellungen
- OPC-UA-Konfiguration -- OPC-UA-Monitore und das Anwendungsinstanzzertifikat