Analyze

The Analyze tab in Service Catalog provides an automated, trace-based dependency map for any instrumented service. It aggregates distributed traces to visualize how your service communicates with other services, databases, caches, and external endpoints — revealing request volumes, error rates, latency, and health status at a glance.

Overview

When investigating a service's behavior, understanding its upstream and downstream dependencies is critical. The Analyze tab automatically discovers these relationships from your trace data, so you can:

• Visualize your service's dependency graph: See every service, database, cache, and external endpoint your service interacts with, rendered as an interactive directed graph.
• Monitor service health at a glance: Colored health indicators on service nodes show whether each service is healthy, in warning, critical, or unmonitored — without navigating away from the graph.
• Identify high-load dependencies: Nodes with disproportionately high request volume relative to the root service are flagged with a load multiplier (for example, 3.8X), helping you spot amplification patterns.
• Switch latency aggregation: Toggle between average, minimum, maximum, and sum latency on edge labels to analyze connection performance from different angles.
• Inspect per-connection metrics on hover: Hover over any node to reveal detailed metrics for each incoming and outgoing connection, including request rate, error percentage, latency, and protocol (HTTP, gRPC, etc.). The metrics are derived from span data.
• Filter by direction: Toggle between All, Upstream, and Downstream views to focus on callers or callees independently.
• Detect uninstrumented dependencies: Virtual nodes are automatically created for databases (PostgreSQL, MySQL, Redis, etc.), message brokers (Kafka, RabbitMQ), and external HTTP/gRPC endpoints that lack their own instrumentation.

Prerequisites

• Your services must be instrumented with distributed tracing.
• Trace data must be flowing into Coralogix for the selected time range.
• The service must appear in the Service Catalog.
• To display health status indicators, configure alert-based service health or policy-based service health for your services.

How it works

The Analyze tab works by querying and aggregating your service's trace data in real time:

1. Trace collection: Up to 1,000 trace IDs associated with the selected service are fetched from the current time range.
2. Batch processing: Traces are processed in batches of 100. A progress indicator in the top-left of the graph area shows how many traces have been analyzed (for example, "500/1000 traces").
3. Span classification: Each span is classified by kind (client, server, producer, consumer), direction (incoming, outgoing, internal), and error state. Uninstrumented dependencies (databases, caches, message queues, external calls) are detected automatically from span attributes like db.system, messaging.system, rpc.system, and http.method.
4. Graph construction: Nodes represent services and virtual dependencies. Edges represent communication between them. Both nodes and edges accumulate request counts, error counts, and latency statistics.
5. Incremental rendering: The dependency map updates progressively as each batch completes, so you can begin exploring before all traces are processed.
6. Health evaluation: After all traces complete, a single batch request evaluates the health status of all discovered services. Health data is re-fetched automatically when you change the time range or selected service.

Access the Analyze tab

1. In your Coralogix toolbar, navigate to APM, then Service Catalog.
2. Select a service to open the service drilldown view.
3. Select the Analyze tab.

The dependency map loads automatically, displaying a progress indicator until all traces have been processed.

The Analyze tab is split into Service list and Dependency graph.

Service list

The left panel displays a sortable list of all discovered dependencies:

• Name: The service or dependency name.
• Request Volume: Total request count with a relative load multiplier. A warning indicator appears when the multiplier exceeds 1X, signaling that the dependency receives more traffic than the root service.

Select any row in the service list to select and highlight that node in the graph.

Dependency graph

The right panel renders an interactive directed graph using a hierarchical left-to-right layout:

• Nodes represent services and dependencies. Each node displays its name, type, request count, and error count (if any).
• Edges connect caller to callee. Edge thickness scales with request volume, and edges turn amber when connecting to high-load nodes. Each edge displays a latency label based on the selected aggregation (average, minimum, maximum, or sum).

Node types

The Analyze tab automatically detects and categorizes different types of dependencies:

Type	Detection	Examples
Service	Instrumented service with spans	frontend, cartservice
Database	db.system span attribute	PostgreSQL, MySQL, MongoDB
Cache	db.system with cache type	Redis, Memcached
Message Queue	messaging.system span attribute	Kafka, RabbitMQ, SQS
External	Client span with rpc.system or http.method	External gRPC/HTTP endpoints

Progress indicator

A badge in the top-left of the graph area shows trace processing progress:

• During loading: "500/1000 traces" with a progress bar
• After completion: "Based on 1000 traces"

Health status indicators

Service nodes in the dependency graph display a colored health square next to the service name, giving you immediate visibility into each service's health without leaving the graph.

Health squares appear only on service-type nodes. Virtual nodes representing databases, caches, external endpoints, and messaging systems do not display health indicators.

Health tooltip

Hover over the health square to view a tooltip with detailed policy information:

• Total count of breached policies.
• Colored badges for each breached policy type.

Health data is fetched in a single batch request after all traces have been processed and is automatically re-fetched when you change the time range or selected service.

Latency aggregation

The graph toolbar includes a latency aggregation selector that controls which latency metric is displayed on edge labels. Select one of the following aggregations:

• Avg: Average latency across all requests on the connection
• Min: Minimum observed latency
• Max: Maximum observed latency
• Sum: Total cumulative latency

The selected aggregation is persisted in the URL via the analyzeGraphLatencyAgg query parameter, so it is preserved when you share or bookmark the page.

Hover metrics

Hover over any node in the dependency graph to expand it and reveal detailed per-connection metrics.

Use the menu to explore additional insights for the selected service:

• View service overview
• View errors
• View related logs

The expanded node displays:

Metric	Description
Req/s (or Query/s for databases)	Request rate calculated over the selected time range
Errors	Error percentage for requests to/from this service
Max	Maximum observed latency

Below the summary metrics, each incoming and outgoing connection is listed with:

• Direction arrow: -> for outgoing calls, <- for incoming calls
• Target service name
• Protocol: The communication protocol (HTTP, gRPC, PostgreSQL, Kafka, etc.)
• Per-edge Req/s, Errors, and Max latency

Filter by direction

Use the filter tabs above the service list to focus on specific parts of the dependency graph:

• All: Displays the complete dependency graph with all discovered nodes and edges.
• Upstream: Shows only services and callers that send traffic to the root service. Use this to understand who calls your service.
• Downstream: Shows only services and dependencies that receive traffic from the root service. Use this to understand what your service depends on.

Upstream view

The upstream view shows only the services that send requests to the selected service. This is useful for identifying which callers contribute to the service's load.

Downstream view

The downstream view shows all services, databases, caches, and external endpoints that the root service calls. This is useful for understanding your service's dependency footprint and identifying potential bottlenecks.

Load indicators

Services and dependencies with high relative traffic display a load multiplier badge:

• The multiplier is calculated relative to the root service's request count. For example, if the root service receives 491 requests and a dependency receives 1,800 requests, the multiplier is 3.8X.
• Nodes with a multiplier greater than 1X display an amber warning indicator in both the service list and the graph.
• Edge thickness and color also reflect load — thicker, amber edges indicate high-traffic connections.

This helps you quickly identify request amplification patterns, such as a single frontend request triggering multiple downstream calls.

Limitations

• The Analyze tab processes up to 1,000 traces per analysis. For services with very high trace volumes, the displayed metrics represent a sample of recent activity.
• Virtual node detection relies on OpenTelemetry semantic conventions in span attributes. Dependencies without standard attributes may not be automatically categorized.
• The graph layout is recalculated when filters change. For very large graphs (30+ nodes), there may be a brief layout delay.
• Health indicators require service health configured. Services without configured policies display a gray "Unmonitored" square.