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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
+1 - Lack of this option is currently a major inhibitor to my customer (major German bank) while evaluating Instana for montoring of their large Integration Platform (ACE, MQ on both k8s and "classic" Linux VM).
Re. implementation:
It seems a bit odd that the keystore is to be mounted to the Instana Agent Pod, but the corresponding keystore password must be mounted (or exposed as env variable) at the MQ Pod (when following procedure described here: https://www.ibm.com/docs/en/instana-observability/current?topic=cha-configuring-host-agents-by-using-agent-configuration-file#kubernetes-secrets)
Thus it might be even better if the Agent could retrieve the MQ client keystore also from the MQ Pod. (I think the ACE sensor is doing something similar with TLS certificates.)
That way, keystore and password would be kept together (also in terms of responsibilities) and the overall approach would be more consistent. Obviously, this would required a change to the Agent itself or the MQ sensor, rather than the helm chart.
Furthermore, an option to add an init, or sidecar approach would be very beneficial in allowing for any required pre-processing implementation