## Problem statement
Key instance metadata — **name**, **version**, **status** and **uptime** — is
available in Instana only as a snapshot on each individual sensor page. None of
these fields are exposed as Dynamic Focus keywords, which means they cannot be
queried, filtered, sorted, or used in dashboard widgets natively.
This gap affects every sensor independently:
| Sensor | Instance name | Version | Status | Uptime |
| Host | ✅ available | ✅ available | ✅ available | ❌ not a keyword |
| IBM MQ | ✅ available | ✅ available | ✅ available | ❌ not a keyword |
| IBM DB2 | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword |
| MS SQL Server | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword |
| NGINX | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword |
| IBM WAS / Liberty | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword | ❌ not a keyword |
IBM MQ is the reference model — it already exposes `entity.ibmmq.qm.name`,
`entity.ibmmq.qm.version`, `entity.ibmmq.qm.status` and `entity.ibmmq.qm.platform`.
The request is to extend this same pattern to all other sensors.
Customers who need uptime or version visibility across a large estate are forced
to implement custom workarounds (cron scripts + StatsD pipelines), adding
operational overhead for every technology independently.
There is also no cross-layer correlation possible — for example, comparing host
uptime against a DB2 instance uptime to detect silent restarts or unmonitored
service recoveries.
This has been confirmed as a current platform limitation:
"Today, uptime are snapshot and we can see only at sensor page by each host"
## Proposed solution
Expose **instance name**, **version**, **status** and **uptime** as first-class,
indexed Dynamic Focus keywords on every sensor that manages a named instance
lifecycle, following the pattern already established by the IBM MQ sensor:
**Host sensor:**
| Keyword (proposed) | Description |
| entity.host.uptime | Host uptime |
**IBM DB2 sensor:**
| Keyword (proposed) | Description |
| entity.db2.instance.name | DB2 instance name |
| entity.db2.instance.version | DB2 instance version |
| entity.db2.instance.status | DB2 instance status |
| entity.db2.instance.uptime | DB2 instance uptime |
**IBM MQ sensor** *(uptime only — name, version and status already exist)*:
| Keyword (proposed) | Description |
| entity.ibmmq.qm.uptime | MQ Queue Manager uptime |
**Microsoft SQL Server sensor:**
| Keyword (proposed) | Description |
| entity.mssql.instance.name | SQL Server instance name |
| entity.mssql.version | SQL Server version |
| entity.mssql.status | SQL Server instance status |
| entity.mssql.uptime | SQL Server instance uptime |
**NGINX sensor:**
| Keyword (proposed) | Description |
| entity.nginx.version | NGINX version |
| entity.nginx.status | NGINX status |
| entity.nginx.uptime | NGINX uptime |
**IBM WAS / Liberty sensor:**
| Keyword (proposed) | Description |
| entity.was.server.name | WAS server name |
| entity.was.version | WAS version |
| entity.was.status | WAS server status |
| entity.was.uptime | WAS server uptime |
**Other sensors (same pattern):**
SAP, and any sensor with a named instance and measurable start time.
Note: The exact keyword names, data types, status values and uptime format (seconds, minutes, days, or a composite representation such as "Xd Xh Xm") can be a good practice by Instana keyword conventions for all sensors.
## Business value / use cases
1. **Consolidated multi-technology dashboard — zero configuration**
A single dashboard showing instance name, version and uptime across all
technologies without any StatsD pipeline or custom script.
| Hostname | OS Type | Version | Architecture | Uptime |
| server01 | AIX | 7.2 TL5 | ppc64 | 47d 12h |
| Hostname | DB2 Instance | DB2 Version | Database | Uptime |
| server01 | DB2INST1 | 11.5.9 | PRODDB | 46d 22h |
| Hostname | Queue Manager | MQ Version | Uptime |
| server01 | QMPROD01 | 9.3.0.40 | 44d 6h |
2. **Version visibility at scale**
Identify instances running outdated versions across a large estate without
navigating host by host. With `entity.db2.instance.version` or
`entity.mssql.version` as keywords, a single Dynamic Focus query returns
all instances below a target version — critical for patch management.
3. **Silent restart detection via cross-layer correlation**
If `entity.host.uptime` >> `entity.db2.instance.uptime`, the DB2 instance
restarted without the OS rebooting — a strong signal for an undetected crash
or silent failure. This correlation is not possible today without custom metrics.
Example Smart Alert rule:
`entity.db2.instance.uptime < 86400` AND `entity.host.uptime > 604800`
— "DB2 instance restarted in the last 24h on a host running for 7+ days"
4. **Elimination of StatsD custom workarounds**
Our SRE team currently maintains cron-based StatsD exporters on 241 PROD
servers (Linux and AIX) specifically to push uptime metrics to Instana.
A native keyword would eliminate this entire pipeline.
5. **Smart Alert: detect any middleware restart automatically**
A common SRE requirement is to be notified whenever a middleware instance
restarts unexpectedly in production — for example, a DB2 instance, a MQ
Queue Manager or a SQL Server that comes back with uptime near zero.
With a native uptime keyword this becomes a single Smart Alert rule:
`entity.db2.instance.uptime < 3600` AND `environment = PROD`
— "DB2 instance restarted in the last hour in production"
Today this is only achievable through a custom StatsD pipeline (cron script
+ custom metric + Custom Event) — one pipeline per technology, per customer.
A native keyword makes it a built-in, zero-configuration alert.
6. **Consistency across sensor types**
IBM MQ already provides name, version and status keywords. Extending this
pattern to DB2, SQL Server, NGINX, WAS and others brings keyword parity
across the full IBM middleware stack and simplifies cross-technology
dashboard and alert management.
## References
- IBM MQ keywords (reference pattern — name, version, status already available):
https://www.ibm.com/docs/en/instana-observability?topic=instana-filtering-dynamic-focus#concept_1__title__1
- Related IBM Idea: Add Dynamic Focus keywords for DB2 instance name and version
(submitted separately — overlaps with entity.db2.instance.name/version/uptime)
