Skip to Main Content
Cloud Management and AIOps


This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Workspace Instana
Categories Agent Sensor
Created by Guest
Created on Aug 2, 2023

Process-Level Configuration for Prometheus Scraper in Instana Agent (Kubernetes/OpenShift)

Summary: 

This idea outlines the essential need for a generic per-process configuration for scraping Prometheus data in Instana. 
The current missing of this feature limits Prometheus monitoring on Kubernetes and OpenShift; workarounds are causing unnecessary overhead.

 

Current Situation: 

Instana allows environment variables for specific sensor configurations, as the documentation describes, see:
https://www.ibm.com/docs/en/instana-observability/222?topic=agent-host-configuration#configurations-from-process-environment

Unfortunately, the Prometheus sensor "com.instana.plugin.prometheus" does not recognize process environment variables, always defaulting to the specified value. 
Example config:
-------- 
com.instana.plugin.prometheus: 

# Generic Definition of Prometheus Scraper customMetricSources: 
# metrics endpoint, the IP and port are auto-discovered 
- url: 
      configuration_from: 
      type: env env_name: MON_PROMETHEUS_URL 
      default_value: '/metrics' ---

----------

Problem:
We do not use Prometheus on every service and we have a security / performance risk, when we query all of our services on Openshift / Kubernetes for prometheus metrics.
Therefore there is the need for granular settings, to enable / disable or change the configurations, since every service is different.
These changes should be applied by the service teams themselves for their own services.
The approach the let teams define, how their services is scraped is also standard with prometheus and part of the kubernetes scrapper via labels.
 

Proposed Idea: 

Introduce the option to define the following attributes in the prometheus sensor at the process level for Prometheus scraping:

enabled

url

user

pwd

metricexcludeRegex

poll-intervall

This implementation will allow the setting of Prometheus scraping per process with individual settings by teams and a company default behaivour.

Long-Term Vision:

Eventually, these settings should align with pod labels, similar to how the Prometheus scraper functions. The Instana Kubernetes sensor should obtain k8s Labels on pods and remotely configure agents to scrape the pods. Additionally, Prometheus metrics should be visible in the INSTANA UI at the process level and queryable with associated infrastructure hierarchy information.

Necessity: 

This idea is crucial for organizations utilizing prometheus metrics as part of the Opentelemetry support with Instana on Kubernetes and OpenShift. The present configuration is not suitable and results in inefficiency. Implementing this idea is necessary to enable effective Prometheus monitoring on these platforms.

Conclusion:
We strongly encourage the prioritization of this idea in upcoming Instana updates. It will enhance Instana's compatibility with standard monitoring practices on Kubernetes and OpenShift, reduce superfluous overhead, and increase user satisfaction.

Thank you for considering this vital innovation.


 

Idea priority High