Instana for z/OS currently performs unconditional sensor discovery for all supported technologies, even when customers only use a small, well‑defined subset (e.g., WebSphere and Java only).
Under IBM Z Tailored Fit Pricing (TFP), any avoidable CPU activity has direct, measurable cost impact. Customers need a supported, documented mechanism to disable discovery for unused sensors so that Instana does not consume MSUs for platforms that will never exist in their environment.
This is a cost‑containment and design requirement unique to IBM Z, not a general performance or tuning request.
Problem Statement:
On distributed platforms, background discovery overhead is typically negligible.
On IBM Z under TFP, even short‑lived or periodic CPU activity has real financial consequences.
Today:
- Instana’s z/OS host agent:
- Always runs discovery for all sensors
- Logs frequent "discovery took too long" warnings
- Performs probing even when customers know with certainty that entire technology stacks (e.g., Db2, MQ, CICS, etc.) will never be used
- Features like Selective Monitoring or process ignore rules:
- Do not prevent sensor discovery
- Only limit instrumentation after discovery has already occurred
- Customers therefore pay recurring CPU costs for:
- Discovery logic
- Timeouts
- Capability probing
- Logging and retries
- — all for technologies that are explicitly irrelevant
Under TFP, there is no “free lunch” CPU usage.
What looks like guarded or lightweight discovery still translates into billable MSUs.
This concern is not about general efficiency — it is about platform economics:
- IBM Z TFP pricing assigns direct business cost to:
- Background tasks
- Periodic probes
- Short CPU bursts
- Customers carefully size and optimize every workload
- Observability tooling must:
- Be explicitly controllable
- Avoid all unnecessary execution paths by design
A discovery‑first architecture that works elsewhere becomes cost‑inefficient on Z unless customers can explicitly disable unused components.
Desired Capability:
Provide a supported, documented configuration for Instana for z/OS that allows customers to:
- Explicitly declare which sensors are enabled
- Prevent any discovery or probing for all other sensors
- Ensure disabled sensors:
- Do not execute discovery logic
- Do not attempt attach
- Do not log timeouts
- Do not consume CPU cycles
This should occur at agent startup, not post‑discovery.
Example of Desired agent configuration:
instana:
zos:
enabledSensors:
- websphere
- java
- jvm
- host
- zos
Any sensor not explicitly listed would be completely omitted from:
- Discovery
- Probing
- Timeout handling
- Logging
(Exact syntax is flexible — the capability is what matters.)
Why Selective Monitoring Is Not Sufficient
Selective Monitoring helps reduce:
- Attachment
- Metrics collection
- Data volume
However, it does not stop discovery itself.
Customers still incur CPU cost before selective monitoring rules are applied.
For IBM Z under TFP, this distinction is critical.
https://www.ibm.com/docs/en/zos/latest?topic=z-what-is-tailored-fit-pricing
Acceptance Criteria
- Customers can explicitly disable sensor discovery
- Disabled sensors perform zero runtime work
- Behavior is:
- Supported
- Documented
- Stable across releases
- Measurable reduction in:
- Discovery warnings
- CPU usage attributable to unused sensors
