how would you like to monitor the time?
Compare it against a time server?
Not exactly what you're looking for but the ntp_response probe might help you on that.
When you invoke the get_info callback on the robot/controller, one of the fields that is returned is current_time. It is a Unix epoch timestamp (integer).
So you could create a probe that gets a list of all hubs, asks each hub for the list of robots, sends a get_info request to each robot, and checks the value of current_time. Of course, you would have to run the probe on a system that you are sure has the correct time.
The only concern I have in this approach is that there will be some delay involved which will result in controller for different hosts receiving get_info callback request in different timings and consequently reporting different current timings. I feel, through this approach, we can't conclude for sure that the system timings are not in sync with the time server even if the difference is of the order of around 10 seconds.
I suggest a small change in the approach mentioned by you.
1) Create a custom probe in Perl / LUA which will call get_info function for the controller for the host where it is deployed and return an alarm message like "Current system time is epochtime"
2) Make it a timed probe (instead of a daemon probe) which will run every 1 hour (for example) or even at a fix time in the day when the system load is least like 3:00 AM.
3) A trigger can be implemented in LUA so as to hold all the alarms and a LUA script can be made (to run after fixed number of seconds of the probe run like 3600 seconds i.e at 4:00 AM) which will iterate through each alarm from the trigger and extract the epoch time and calculate the difference between current epoch time and epoch time for the alarm. Whichever difference is deviating more than 1-2% of 3600 seconds, alarm for the same host can be generated.
Please let me know review coments on this approach.
Retrieving data ...