Skip to content

Observe · ServiceIQ APM

Every service, every call, every slow span.

ServiceIQ is OpenTelemetry-native application performance monitoring: golden signals and Apdex for every service, a live map of who calls whom, and distributed traces that point straight at the slow span. Synthetic checks test what your users actually do.

ServiceIQ / Topology Map
Example
Example: the ServiceIQ topology map in Flow layout shows the gateway calling checkout-api and orders-api, which call payments-api, inventory, redis and postgresql. Request pulses travel along each call; payments-api has an amber warning ring and its edge reads 142/min, 2.4% errors, 1.21s.

Services

Golden signals, judged against your own normal.

Every service shows latency, throughput and error rate, with Apdex against the threshold you set. Baselines are learned per service, so an alert compares against what is normal for this hour of the week — not a fixed line.

  • Latency percentiles computed at read time from histograms
  • Apdex against your own threshold
  • Baselines per service, per hour of the week
  • Health and Hosts views, APM Dashboards and Logs
ServiceIQ / Services
Example
Example: the ServiceIQ services list shows throughput, latency and failures for gateway, checkout-api and payments-api. The payments-api drill-down shows Apdex 0.94 against a 750 ms threshold, and its p95 latency climbing to 1.21s, well above the baseline band learned as normal for Tuesday 14:00.

Distributed tracing

Spot the slow span instantly.

Open a trace and see it as a Waterfall timeline, a Flame graph, a list of Spans or a Services view. Drill down from a service to its transactions through a latency heatmap, then into the individual traces behind each one.

  • Waterfall, Flame graph, Spans and Services views
  • Transactions: latency heatmap → per-transaction KPIs and traces
  • Dependencies as a list and a map, DB Operations, Errors and Alerts
ServiceIQ / Traces
Example
Example: a trace for POST /api/checkout (1.84s, 14 spans, 1 error) opens in the Waterfall view and expands level by level from the gateway through checkout-api to inventory, payments-api, shipping-service and notifier. The slowest span, payments-api POST /charge at 1.21s, is highlighted; shipping-service POST /quote is the red error span.

Synthetic Monitoring

Test what users actually do — before they do.

Schedule HTTP and API checks, or script multi-step browser journeys that navigate, click, type and select the way a customer would. Every run lands in a success and failure history.

  • Scheduled HTTP and API checks
  • Scripted browser journeys: navigate, click, type, select
  • Success and failure history
Synthetic Monitoring / Checks
Example
Example: two synthetic checks, an API check of app.example.com/health every minute and a Checkout flow browser journey every five minutes, each with a strip of recent passes and failures. The journey runs its steps (navigate, click, type, select, click Pay) with a timing for each and passes in 3.2s; on some runs the shipping step fails and a red tick is added to the history.

Capabilities

Everything in Application performance

The complete list, as it exists in the product today.

ServiceIQ — Application Performance Monitoring

Services

  • Services list with health, golden signals (latency, throughput, error rate) and Apdex against your own threshold
  • Latency percentiles computed at read time from histograms
  • Topology map of service-to-service calls
  • Health and Hosts views; APM Dashboards and Logs

Service drill-down

  • Overview: latency, throughput, errors, response codes, running hosts, top transactions, dependencies, top DB queries, callers and callees
  • Metrics: baseline charts and resource metrics
  • Transactions: a latency heatmap leading to per-transaction detail with its own KPIs and traces
  • Dependencies as a list and a map
  • DB Operations, Traces, Errors and Alerts

Distributed tracing

  • Trace detail with Waterfall timeline, Flame graph, Spans and Services views
  • Spot the slow span instantly

Baselines

  • Baselines learned per service, so alerts compare against “normal for this hour of the week”

Synthetic Monitoring

Checks

  • Scheduled HTTP and API checks
  • Scripted multi-step browser journeys — navigate, click, type, select
  • Success and failure history for every check

Works with AI Core

Application signals feed AI Core.

Saturated services are one of the signals AI Core correlates with what the network and infrastructure are doing, so a slow checkout and the congested link behind it surface as one situation.

How AI Core works

From Application performance

  • Saturated services
  • Golden-signal deviations from the learned baseline

Get started

See every signal in one place.

Start with one site and one probe. Add modules as you go — the AI Core gets more useful with every source you connect.

Already have an account? Sign in to the portal