Generic Entity Types creation by native OpenTelemetry (OTEL) infrastructure data instead of Otel-Collector Entity

Instana currently supports a variety of entity types—including infrastructure entities (hosts, containers, Java processes) and trace-specific entities (services, endpoints, applications). While the Instana sensors offer powerful application monitoring, they sometimes fall short in providing full observability over certain infrastructure components. In these cases, users often rely on OpenTelemetry (OTEL) to define custom metrics and monitoring logic, sending the data into Instana via an OTEL backend.

The Challenge:
At the moment, OTEL data is received and stored generically under the Entity Type “otel-collector,” usually associated with the agent receiving the data. This generic handling makes it difficult to relate the metrics back to specific entities. For example, while Instana can map some infrastructure metrics (like those for pods), many OTEL data points show up with cryptic IP addresses and ports. Although tag filtering can sometimes reveal the source, this approach is neither reliable nor user-friendly.

Proposal:
Implement native OTEL support in Instana so that incoming OTEL data is automatically processed and mapped to Instana entities. 

This would involve:

Entity Creation Based on OTEL Data:
Instana should detect and extract OTEL-specific fields that indicate entity type, identifier, and name.
This would enable Instana to automatically create a new infrastructure entity (e.g., a “switch” entity) with the appropriate UID and name, directly correlating the incoming metrics to a tangible monitored object.

Benefits for Instana Users:

• Improved Infrastructure Analysis: With native OTEL entity support, users would benefit from a more granular and accurate view of their infrastructure.
• Enhanced Search and Correlation: Clear mapping of OTEL metrics to their respective entities (e.g., hosts, switches, etc.) would simplify searching, filtering, and troubleshooting.
• Expanded Monitoring Capabilities: This feature would enable Instana to support a broader range of entity types out-of-the-box, much like the current service name mapping for trace-based data, thereby increasing its overall value in diverse monitoring environments.

Reference to OTEL Specifications:
To our knowledge the OpenTelemetry specification, does not have a built‑in, dedicated attribute for “entity type” in metrics. 
Instead, you can use the Resource attributes (or additional labels) for contextual information.

To follow the OTEL naming style for a custom field that indicates the entity type (pod, process, JVM, or switch) the arributes entity.type , entity.id and entity.name can be used.
This follows the same naming conventions used for standard attributes like service.name or host.name.

As an example for 4 switches indicating if there are up or down could look like this, where entity type would define a the entity type, which is based of a common known supported entity type list:
# HELP switch_status The operational state of the network switch (1=up, 0=down). 
# TYPE switch_status gauge 
switch_status{entity.name="sw1", entity.id="SN0001", location="dc1", entity.type="switch"} 1 
switch_status{entity.name="sw2", entity.id="SN0002", location="dc1", entity.type="switch"} 0 
switch_status{entity.name="sw3", entity.id="SN0003", location="dc2", entity.type="switch"} 1 
switch_status{entity.name="sw4", entity.id="SN0004", location="dc2", entity.type="switch"} 1
 

Conclusion:
Implementing native support for OTEL entities in Instana would provide significant benefits: more precise mapping of infrastructure metrics, enhanced dashboards, and an overall richer observability experience. 
It would bridge the gap between the current OTEL data ingestion and Instanas internal Entity Type model, reusing the current service-name mapping for trace based data and significantly enhancing infrastructure monitoring capabilities.