I noticed a new probe called called threshold_migrator. Then I noticed updates in dirscan, logmon and ntperf.
dirscan: "The probe can be migrated to standard static thresholds using the threshold_migrator probe. The Admin Console GUI will be configurable using the standard static threshold block and the Infrastructure Manager GUI will no longer be available.". Logmon and ntperf say the same about the migrator probe, but nothing about the GUIs. dirscan still ships with the IM GUI in the package.
Looking at this, should I understand that CA is now shipping alarming away from probes and into baseline_engine? The appearance of baseline_engine etc seems to have suggested so for a while, but looking at these release notes it seems like they're sneaking in a major change in alarm flow on a practical level.
This has a bad feeling to it..
I'd like to know more about this as well.
CA UIM folks\staff in general, how do you expect us, your end users, your clients who use your product to learn about these new changes that majorly impact the products overall use?
I don't like installing a new version and then finding out I cannot monitor our infrastructure due to change xyz. There really should be a formal WebCast prior to each .x released announcing these changes and a little bit if 'training' explaining how the new method works, so we are in the know and don't go "Oh that doesn't work now. Let me open an issue."
Then I've hit times in the past were your support staff wasn't even aware of these changes and they were like, "Oh yeah that was changed, or Oh that was taken out..."
Historically its been really bad regarding this area.
Thanks for the feedback.
In general for major new UIM features, usually training/videos are done.
For threshold migration we will consider it for the next release of the probe.
By default the probes (dirscan, logmon, ntperf) still support alarming in the probe.
The threshold_migrator probe is a tool to enable central baseline_engine based alarming and migrate customer's probe specific threshold configurations to the baseline_engine. By moving to baseline_engine based alarms, you can take advantage of new alarming features (e.g Time Over Threshold, support for five threshold levels) and over the long term it will also make alarming consistent across the probe estate.
So the migration to baseline_engine based alarming is optional and there is no change in default probe alarming behavior.
Architect (UIM Probes)
This is old discussion but still valid. Now there are new probe versions that seems to use baseline_engine only for alarming. Then what happens when this is configured and alarms are sent from the baseline_engine in client hub1 and the robot changes its connection to another hub, client hub2? Alarms coming from where? Are those configs still valid?
I'm afraid to tell you that you will not see that alarm even if threshold breaches after your robot switches to another hub, because baseline_engine in the other hub do not know the alarming threshold.
Does this mean that the controller parameter: "secondary_hub" is not (really) valid/useful anymore , because if the robot swaps to his backup hub there is no alarming available?
My response only applies to alarming which is being managed by baseline_engine probe.
You will see alarming after your robot switches to another hub, as long as the alarm is being managed by monitoring probe itself.
could you get some kind of list of those alarmings that baseline_engine actualy handles. So what probes rely on baseline_engine..
I'm afraid to tell you that unfortunately we don't have that list.