Service Intelligence

A service is a logical thing you operate, a checkout API, an authentication provider, a payments worker, assembled from the hosts, containers, and log sources that produce its telemetry. Service Intelligence gives each service a single health status rolled up from its KPIs, and collects them into one hub so you can see, at a glance, what is healthy and what needs attention.

It lives in the Observability hub, alongside Health Checks, Entities, and Maintenance windows. The hub lists every service with its current status and summary counts; opening a service drills into its KPIs, members, dependencies, anomalies, and settings.

Create a service, give it a name and description, then tell LogPulse which telemetry belongs to it. Membership is resolved automatically and stays current as entities come and go, so you define the service once rather than maintaining a static list.

A KPI (Key Performance Indicator) turns an LPQL search into a health signal for the service. The query produces a value, a chosen field is read as the metric, and thresholds map that value to a severity. KPIs are the building blocks of a service's health.

Each KPI defines the search, the value field to read, a unit, and its thresholds. The service's scope is put in front of the search when it runs, so the search itself only describes the measurement. For example, a 5xx error-rate KPI:

# KPI: 5xx error rate (%)
status=*
| eval is_error=if(status>=500, 1, 0)
| stats count as total, sum(is_error) as errors
| eval error_rate=if(total>0, round(errors/total*100, 2), 0)

Read error_rate as the value field, set the unit to %, the threshold direction to above, and a warning at 1 with a critical at 5. The KPI is evaluated on a schedule; its latest value and severity are shown on the service, and you can chart it over 1h / 6h / 24h / 7d windows.

A service's overall status is rolled up from its KPIs: the most severe KPI wins, so a single Critical KPI makes the whole service Critical. The Observability hub summarizes the estate with counts of Critical, Warning, and Healthy services, and you can filter the list by status to triage the ones that matter.

Health says how a service is doing right now. A service level objective (SLO) says how reliable it has to be over time: "99.9% over 30 days". The 0.1% that may go wrong is the error budget. The SLOs tab of a service shows, per SLO, the SLI now (the measured percentage), how much of the budget is left, how fast it is being spent, and a burn-down of the budget over the window. SLOs are evaluated every 5 minutes.

Good events:  status=* | where status < 500
All events:   status=*

Services rarely fail in isolation. You can record upstream and downstream relationships between services and view them as a dependency graph, so when a service degrades you can see what it relies on and what relies on it. This turns a single red KPI into context: is checkout unhealthy because checkout broke, or because the payments service it depends on did?

Thresholds catch values you can name in advance; anomaly detection catches the ones you cannot. Each KPI is given a baseline, a per-KPI statistical profile of its normal range that accounts for daily and weekly seasonality, and LogPulse flags when the current value departs from it, even while it is still inside the static thresholds.

Anomalies surface on the service's Anomalies tab with the affected entity, the time the deviation started, and a severity. A per-KPI sensitivity setting (in the KPI editor's advanced settings) controls how far from baseline a value must drift before it is flagged. Raise it to catch subtle drift, lower it to only flag dramatic swings.

The baseline is learned per weekday and per hour, on the clock of your organization: set the baseline time zone in the security settings, under Anomaly scoring. With the default, UTC, a rhythm that follows local office hours shifts an hour when the clocks change.

"What changed just before this?" is the first question about any deviation. Change events answer it: deploys, config changes and feature-flag flips show as vertical markers on the KPI charts of a service, in a list on its Changes tab, and on an anomaly as "Changes in the 2 hours before". KPI cards also draw the previous period as a faint dashed line and say how the average compares ("+12% vs previous period").

Add a change by hand on the Changes tab, or let your CI pipeline post one after every deploy. Create a personal access token with the services:propose scope and call:

curl -X POST https://api.logpulse.io/api/v1/changes \
  -H "Authorization: Bearer $LOGPULSE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "deploy",
    "service": "checkout-api",
    "title": "Deploy checkout-api",
    "version": "'"$GIT_SHA"'",
    "url": "'"$CI_PIPELINE_URL"'"
  }'

A service name that does not exist answers 404 instead of silently marking every chart. Read changes back with GET /api/v1/changes?serviceId=…&from=…&to=… (a session, or a token with services:read).

Every member of a service is an entity with its own unified view. Entity 360 combines an observability lens, the services, KPIs, and telemetry tracked for the entity, with a security lens of accumulated risk and reputation. The same view is reachable from the Observability hub and from the security side, so an SRE and an analyst arrive at the same full-context page from different directions. See the Security Monitoring (SIEM) page for the security lens.