Elastic Observability Service Map vs. Custom Dashboards: What You Need to Know

1. What Is Elastic Observability?

Elastic Observability brings logs, metrics, traces, and uptime data into a single platform built on Elasticsearch and Kibana. This unified data model allows engineers to correlate infrastructure health, application performance, and user experience in near real time.

A common design question is how to balance:

• Automatic, opinionated visualizations such as the Service Map
  
• Custom dashboards tailored to specific SLOs, KPIs, or operational workflows
  

Both approaches rely on the same APM data indexed in Elasticsearch, but they differ significantly in how data is aggregated, queried, visualized, and scaled.

2. Service Map: A Top-Down View of Your Application Architecture

The Service Map provides an automatic, topology-level visualization of service-to-service dependencies derived from Elastic APM data.

How the Service Map Works

1. APM agents instrument applications and emit traces, transactions, and spans.
   
2. The APM Server / APM integration processes this data, performing sampling and aggregation.
   
3. Pre-aggregated APM metrics documents (for example, service destination metrics) are indexed into Elasticsearch.
   
4. Kibana queries these metrics and trace relationships to render a directed service graph.
   
   

Important: Elasticsearch does not perform relational joins. Service Maps rely on metrics-based aggregation and trace relationship modeling, not joins across transaction indices.

What the Service Map Is Best At

• Automatic discovery of service dependencies
  
• Visualizing request flow and latency relationships
  
• Quickly identifying upstream/downstream impact during incidents
  

Elastic Cloud Considerations

• Elastic Cloud manages infrastructure scaling, upgrades, and availability, reducing operational overhead.
  
• Service Map performance still depends on:
  
  • Cardinality of service.name and service.environment
    
  • Retention of APM metrics
    
  • Kibana memory and query limits
    

Self-Managed Considerations

• Kibana limits such as xpack.apm.serviceMapMaxServices may require tuning in large environments.
  
• Service Map scalability depends on:
  
  • APM metrics aggregation
    
  • ILM retention for APM metrics indices
    
  • Kibana resource sizing
    

3. Custom Dashboards: Full Control for Advanced Analysis

While the Service Map gives a high-level view, Custom Dashboards let you define exactly what matters, custom visualizations, time ranges, field filters, and drill-downs.

Typical use cases:

• SLA compliance dashboards using transaction.duration.us percentile aggregations.
  
• Infrastructure-to-application correlation via host.name or kubernetes.pod.name.
  
• Cost optimization dashboards by comparing service.environment:production vs. staging.
  
  

Key benefit: You define the query layer, not Elastic. That means you can tune performance and visualization without being bound by pre-built logic.

4. Cloud vs. On-Prem: Architectural Differences That Matter

Engineering note:
On-prem setups often skip Fleet-managed APM agents, which causes version mismatches or missing data in Service Map nodes. Using Elastic Agent Fleet unifies agent policy rollout and simplifies observability scaling.

5. Performance & Scalability Considerations

• Latency: Service Map queries run complex joins on transaction indices. Keep index lifecycle short and leverage rollups for historical data.
  
• Storage: Dashboards with TSVB or Lens visualizations benefit from data views over multiple index patterns to reduce shard lookups.
  
• Cost: In Elastic Cloud, Service Map processing cost is included; on-prem users bear CPU and memory overhead.
  
  

Tip: For high-volume environments, route APM data through Kafka → Logstash → Elasticsearch to batch indexing efficiently.

6. Diagram: Data Flow from APM to Visualization

[Application Services]

        │

        ▼

 [APM Agents]

        │

        ▼

 [Elastic Agent Fleet or APM Server]

        │

        ▼

 [Elasticsearch Ingest Pipeline]

        │

        ├──> Service Map (Auto Topology)

        │

        └──> Custom Dashboards (User-Defined Queries)

‍

7. Real-World Config Example

Example APM agent setup (Node.js):

require('elastic-apm-node').start({

  serviceName: 'checkout-service',

  environment: 'production',

  serverUrl: 'https://apm.elastic-cloud.com',

  secretToken: process.env.ELASTIC_APM_SECRET_TOKEN

});

‍

Example dashboard query (Kibana Lens JSON export):

{

  "index": "apm-*",

  "query": {

    "bool": {

      "filter": [

        { "term": { "service.name": "checkout-service" }},

        { "range": { "@timestamp": { "gte": "now-15m" }}}

      ]

    }

  },

  "metrics": [{ "type": "avg", "field": "transaction.duration.us" }]

}

‍

This gives engineers full visibility into transaction response times, correlated with specific services shown in the Service Map.

8. When to Use Each Approach

Recommendation from Hyperflex:
Start with the Service Map for baseline visibility, then extend with Custom Dashboards for specific SLOs or client deliverables.

9. Final Takeaway

Both Service Map and Custom Dashboards are pillars of Elastic Observability. The real power lies in combining them:

• Use Service Map for automatic discovery and topology visualization.
  
• Use Custom Dashboards for deep analysis, cost optimization, and SLA metrics.
  
  

Hyperflex helps enterprises integrate both approaches - ensuring scalable, high-performance observability pipelines across Elastic Cloud and on-prem deployments.

Hyperflex helps teams scale Elastic fast - with confidence.

Contact us at marketing@hyperflex.co to explore how our Elasticsearch Consulting Services can optimize your Observability stack.

‍