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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
This requirement is planned for consideration in the 1H of 2026.
Which time source should Instana compare against? (e.g., your internal NTP/Chrony servers, a public NTP service, or the Instana agent host itself?)
Local Chrony Deamon ( /usr/sbin/chronyd )
What level of time drift would you consider unacceptable for your workloads?
This should be a value gathered and showed in instana for a possible Alert to be put in place in the UI . Currently we set 1sec as our baseline in our workaround
Should this check be performed on all servers, or only on specific/critical ones?
All Servers that are using Chronyd [Linux]
Are you expecting just alerting, or would you also like to see historical drift metrics?
Both
Lastly, could you share a real-world example where time drift affected your business? This will help us better understand the impact and shape a suitable solution.
An exemple is ofset in database records time since those are intertwined with the local time
An other exemple would be Application Time in a UI for the same reason
============================What are we doing as a mitigation
Currently we have addapted the script we use to have to work with instana with statsd ( com.instana.plugin.statsd )
This script is called by a crontab on the servers
We have a counter to monitor the status of that crontab
We have a gauge to monitor the millisec
We put monitoring on the status of the cron and the milliseconds
Hi @Guest
We understand your request for Instana to monitor server time drift. To scope this properly, could you clarify which time source you want Instana to compare against (e.g., your internal NTP/Chrony servers, a public NTP service, or the Instana agent host itself), and what level of drift you consider unacceptable for your workloads? It would also help to know whether you need this check on all servers or only critical ones, and if you expect just alerting or also historical metrics. Finally, could you share a reliable use case where time drift has impacted your business, so we can better understand the importance and design the right solution?
Thank you!
This is not on the roadmap for the first half of 2025. It will be reevaluated afterward based on shifting priorities.