Grafana Cloud

Explore service dependencies and impact

Use the entity graph to visualize relationships between services and infrastructure. Understanding dependencies helps you predict incident blast radius, trace issues to their source, and assess the impact of changes.

When to use this workflow

Use this workflow when you want to:

  • Understand which services depend on a specific service or database
  • Predict the blast radius if a service or infrastructure component fails
  • Trace errors upstream to find the root cause service
  • Assess the impact of deploying or changing a service
  • Document your architecture and service relationships

This workflow is essential for architecture reviews, incident planning, and root cause analysis.

Before you begin

Ensure your environment is:

  • Sending service-to-service call data (from OpenTelemetry, Istio, or APM)
  • Reporting infrastructure relationships (Pod-to-node, service-to-Pod)
  • Visible in the entity graph

Open the entity graph

From Grafana Cloud, navigate to Observability > Entity graph.

Start with a service

Find and display a service as your starting point for exploring dependencies.

Use predefined searches

  1. Under Frequently used, select a starting point:
    • Show all Services - See all services and relationships
    • Show all Nodes - Infrastructure view
    • Show Service [name] - Start with a specific service

Search for a specific service

  1. In the search bar, type: Show Service payment-api.
  2. Replace payment-api with your service name.
  3. The graph displays the service and its immediate connections.

Find a service by property

Use Advanced search to find services matching criteria:

  1. Click Advanced search.
  2. Set conditions like:
    • Entity type = Service
    • Namespace = production
    • Cluster = us-east-1
  3. Click Search.

Explore service dependencies

Navigate the graph to understand how services connect and depend on each other.

View immediate connections

When viewing a service, you’ll see:

  • Upstream callers - Services that call this service
  • Downstream dependencies - Services this service calls
  • Infrastructure - Pods and nodes running the service

The graph uses arrows to show call direction.

  1. Click a service in the graph.
  2. A menu appears showing connected entity types and counts.
  3. Select a connection type (for example, “5 Services”).
  4. The graph updates to show all connected services.
  5. Use the Back arrow to return to the previous view.

Filter the graph

If the graph becomes crowded:

  1. Click entity types in the legend to hide them
  2. For example, hide Pods to focus only on service-to-service calls
  3. Click again to show the entity type

Use the “Only” filter

To isolate a specific entity and its connections:

  1. Click the entity.
  2. Click Only.
  3. The graph shows only that entity and what it connects to.
  4. This focuses the view on a single component.

Understand relationship types

The Entity Graph shows different relationship types:

Calls relationships

Services calling other services:

  • Arrow points from caller to callee
  • Represents HTTP, gRPC, or other protocol calls
  • Shows service dependencies and data flow

Hosts relationships

Infrastructure hosting applications:

  • Node Hosts Pod
  • Pod Hosts Service (containers running the service)
  • Shows physical deployment topology

Contains relationships

Logical groupings:

  • Namespace contains Services and Pods
  • Cluster contains Nodes and Namespaces
  • NodeGroup contains Nodes

Analyze dependency patterns

Use the graph structure to identify critical services, single points of failure, and potential issues.

Identify critical services

Critical services have:

  • Many upstream callers (many services depend on it)
  • Failure would impact multiple other services
  • Often databases, authentication services, or shared APIs

To find critical services:

  1. Look for services with many incoming arrows
  2. Count connected entities in the service menu
  3. Note services appearing in multiple dependency chains

Find single points of failure

Single points of failure are:

  • Services with many dependents but no redundancy
  • Databases without replicas
  • External dependencies without fallbacks

If a critical service fails, all upstream services are affected.

Trace error propagation

When a service has errors, trace impact:

  1. Start with the failing service in the graph.
  2. Navigate to upstream callers.
  3. These services may show timeout or error rate increases.
  4. Continue upstream to see full blast radius.

Example: If a database is slow, you’ll see:

  • Database → Services calling it → Services calling those services

Identify circular dependencies

Circular dependencies can cause cascading failures:

  • Service A calls Service B
  • Service B calls Service C
  • Service C calls Service A

Look for loops in the graph. Circular dependencies may cause:

  • Retry storms
  • Difficult-to-diagnose failures
  • Deadlocks during deployment

Assess change impact

Before deploying or modifying a service, use the graph to predict impact:

Identify affected services

  1. Find the service you plan to change in the graph.
  2. Navigate to upstream callers.
  3. These services become affected if your change breaks compatibility.
  4. Plan to test these services after deployment.

Plan deployment order

For multi-service deployments:

  1. View all services involved in the graph.
  2. Deploy downstream dependencies first (services with no dependencies).
  3. Then deploy services that call them.
  4. Finally deploy top-level services (those with many dependencies).

This minimizes breaking changes during rollout.

Combine with entity catalog

Use both tools together to understand relationships and monitor health.

From entity catalog to entity graph

  1. In the entity catalog, find a service with issues.
  2. Note the service name.
  3. Open entity graph and search for that service.
  4. View its dependencies to understand if related services are also affected.

From entity graph to entity catalog

  1. In the entity graph, identify critical services.
  2. Note their names.
  3. Open the entity catalog and filter to those services.
  4. Monitor their health proactively.

Use graph view vs list view

The entity graph offers two views:

Graph view

Best for:

  • Visualizing relationships
  • Understanding architecture
  • Tracing dependency chains
  • Finding circular dependencies

Use when you need to see the structure.

List view

Best for:

  • Seeing entity properties (CPU, memory, version)
  • Checking health status across many entities
  • Sorting by specific attributes
  • Exporting entity lists

Switch with the Graph / List toggle.

Advanced search for architecture queries

Find specific sets of services using property-based queries.

Find all services in a namespace

  1. Click Advanced search.
  2. Entity type = Service.
  3. Namespace = your-namespace.
  4. View all services in that namespace and their connections.

Show services with specific properties

  1. Click Advanced search.
  2. Add property filters (version, environment, team label).
  3. See only services matching your criteria.
  4. Useful for auditing or targeted monitoring.

Document your architecture

Capture and maintain up-to-date architecture diagrams from the entity graph.

  1. Search for services in a specific domain (payment services, checkout services).
  2. Capture screenshots of the graph.
  3. Add to documentation or runbooks.
  4. Update periodically as services change.

The graph is always up to date based on actual traffic, unlike static architecture diagrams.

Common use cases

Apply dependency knowledge to these common scenarios.

Pre-deployment review

Before deploying a critical change:

  1. Find the service in the graph.
  2. Identify all upstream and downstream dependencies.
  3. Plan testing for affected services.
  4. Schedule deployment during low-traffic periods for critical services.

Incident blast radius

During an incident:

  1. Find the failing service or infrastructure.
  2. Navigate to upstream callers.
  3. Add all affected entities to RCA workbench.
  4. Communicate scope to stakeholders.

Architecture refactoring

When breaking apart a monolith or consolidating services:

  1. Visualize current service relationships.
  2. Identify tightly coupled services.
  3. Plan refactoring to reduce dependencies.
  4. Monitor the graph after changes to verify new architecture.

Onboard new team members

Help new engineers understand the system:

  1. Show them the entity graph.
  2. Navigate through key services and dependencies.
  3. Explain critical services and their role.
  4. Use as a visual reference during code reviews.

Next steps

After exploring dependencies:

Additional resources