MELT is PulseServe's observability module — the place your metrics, events, logs, and traces from your existing monitoring stack land, get explored, and feed the AI agents. It doesn't replace tools like Prometheus, Grafana, or your log shipper; it ingests from them and turns that signal into something the rest of the platform (correlation, RCA, predictive warnings) can act on.
The MELT page
- Signals — one searchable table of everything that's come in, filterable by system, signal type, and time range, with a running count of metrics/logs/traces/events you can click to filter.
- Traces — explore a single request's full journey across every system it touched.
- Predictive Warnings — AI-flagged risks surfaced before they become incidents (see Alert Thresholds & Predictive Anomalies).
- Alert Thresholds — where alerting rules are configured (see Alert Thresholds & Predictive Anomalies).
- Ingest Guide — copy-paste setup instructions for connecting your monitoring stack.
Connecting your monitoring stack
The Ingest Guide tab has ready-to-use setup snippets for each source: metrics from Prometheus, traces from OpenTelemetry, logs from whatever shipper you already run, plus a generic option for anything else that can send a webhook. Once connected, data flows in automatically — how long it's kept is controlled by a retention setting an admin can adjust.
Exploring a trace
Open the Traces tab, paste in a trace ID (or click "View trace" from any trace row in Signals), and PulseServe renders the request's full path as a waterfall — every system it touched, in order, with how long each step took. It calls out the slowest step and the first point where something actually failed, so you're not left guessing which of several errors was the real starting point.
It also flags patterns worth a second look: a step that fanned out to many systems at once, a shared dependency called from multiple places in the same request, calls that crossed regions, repeated retry attempts, and — this is the newest addition — expected calls that didn't happen. That last one compares this request against what the same step normally does, and flags anything missing.
Smarter log handling
Incoming logs are automatically processed before anyone — or any AI agent — sees them: sensitive data (tokens, keys, emails, and similar) is masked, error and exception details are pulled out automatically, and near-identical error lines are grouped into one pattern instead of showing up as thousands of separate rows. Brand-new error patterns, and patterns that suddenly start recurring, are flagged as worth investigating. An admin can turn masking on or off and adjust sensitivity under Settings → Log Intelligence.
How your dependency map builds itself
As traffic flows between your systems, PulseServe learns which systems actually call which — and folds that automatically into the CMDB's dependency relationships, visible on a CI's detail page and in the Blast Radius graph, the same as a manually entered relationship. This is what missing-call detection on a trace is compared against, and it means your dependency map gets more accurate over time without anyone maintaining it by hand.
Example
A checkout request is reported as slow. Opening its trace shows a waterfall where one step — a pricing service call — takes up most of the total time, and fans out to three downstream systems concurrently. One of those systems is flagged as a "missing call": the pricing service normally also checks a promotions cache, but didn't this time. That turns out to be the actual clue — the promotions cache was down, and the pricing service silently fell back to a slower path instead of failing loudly.