Global and Policy‑Based Endpoint Mapping for Application Perspectives

Problem Statement

Instana’s default HTTP endpoint mapping behavior (“use the first URL path segment”) is insufficient for modern, large‑scale microservice and API‑driven environments, particularly where:

• APIs are versioned using path prefixes (for example /v1, /v2, /v5)

• Multiple teams deploy services independently and frequently

• Platform teams require governance‑level consistency without modifying application code

While Instana provides mechanisms to override default endpoint mapping, none of the existing approaches scale operationally across hundreds of applications.

Current Workarounds and Why They Fail at Scale

1. Per‑Service Endpoint Rules in Instana

Endpoint mapping rules today:

• Are defined per application or service

• Cannot be defined or enforced globally

• Can only be created after a service is discovered and assigned an ID

This results in:

• High manual effort

• Configuration drift between services

• Delayed observability correctness for newly deployed services

• Continuous rework as APIs evolve

At enterprise scale, this approach is operationally infeasible.

2. Path Annotations / Code‑Level Overrides

Embedding endpoint mapping hints directly in application code:

• Pushes observability concerns into application ownership

• Requires developer buy‑in and redeployments

• Is inconsistent across languages, frameworks, and teams

• Breaks the separation between platform observability and application logic

This contradicts Instana’s strength as an automatic, low‑touch observability platform.

These are real‑world patterns, not edge cases:

Versioned APIs

All meaningful endpoints collapse under /v5, eliminating endpoint‑level visibility.

/v5/orders/{id}
/v5/customers/{id}

Shared API Gateways

The first segment is a routing concern, not a business endpoint.

/api/v1/*

Microservice Churn

• New services appear frequently

• Endpoint rules cannot be pre‑applied

• Observability quality is degraded until manual intervention

SLO and Alerting Instability Endpoint remapping after discovery disrupts:

• SLO baselines

• Alert thresholds

• Historical comparability

Proposed Enhancement

Introduce Global / Policy‑Based Endpoint Mapping

Add the ability to define organization‑wide endpoint mapping policies that are:

• Evaluated before per‑application rules

• Applied automatically to all current and future services

• Independent of service discovery timing

Example Capabilities

• Disable or override default “First path segment” behavior globally (I have seen customers with 100+ services!)

• Define reusable policies such as:

  • “Ignore versioned path prefixes (/v*)”

  • “Skip gateway path segments”

Apply policies via: (even if its just one of these paths, the ability is important)

• UI

• API (for automation / configuration‑as‑code) (expose the endpoint(s) for First Path Segment and add custom HTTP rules)

• Optional scoping by tags (environment, team, namespace)

Global endpoint mapping is not a “nice‑to‑have” customization; it is a foundational requirement for operating Instana effectively at scale in versioned, API‑first environments. Providing policy‑based endpoint mapping would remove significant friction, reduce customer configuration overhead, and improve overall observability outcomes.

Reference IDEA that was closed from lack of followup on the requester: https://ideas.ibm.com/ideas/INSTANA-I-773