I am trying to read software version from storage array with logmon probe. The output of the the command, I am using, s something like
I am able to generate the alarm from logmon probe and message body is able to show the exact version. Now I am trying to inject this version information into the CA UIM database as qos in order to generate report. The challenge I am facing is in creating QOS of string type. All QOS type options are available only in B,KB,MB,GB etc.
Here are a few questions
First of all, is it possible to insert qos as string into the CA UIM database and can be used for reporting?
Secondly, what other alternatives, in UIM, we have to satisfy this type of requirement?
I believe only numeric values are allowed in QOS or state(true/false)
That is correct only numerics can be stored in QOS metrics
Thanks Hitesh and Rowan for the confirmation. Do you see any other alternative for this ask. I don't want to create a custom table to store this type of information.
Hi Balkar - Does this storage device have a REST API? (I am betting that it does) If so, ping youju01 for a possible option using RESTmon probe. Of note, the complex nature of the version string may be tough to handle, but it may still be possible to get you some kind of solution.
We've used two approaches to this:
for well formatted numeric only versions, just use a QoS for each of the numeric sections - in your case a pattern like /^(\d+)\.(\d+)\.(\d+)\.(\d+).*/
For versions that are text strings, we use a script that returns a numeric index to a lookup table. That requires that you know ahead of time what versions you are going to discover but it does enable you to query for specific versions by translating from the version string you want to the index of the lookup table. It's easy enough to reverse into a readable string again for display using SQL and a case statement.
Otherwise it would be really nice if there was a string QoS type....
This sort of data is static and not a good match for QOS even if you extract the numerics.
It really should be a device attribute but I don't think there is an easy way to collect this data automatically and store in the database, unfortunately.
That would be an interesting idea though - wouldn't it?
Publish as a different subject, i.e. "discovered_prop" and we store it in the db for the device?
Yeah would be great if we had that in the product - an attribute processor which uses the message bus
Sort of got it with Application Discovery but that uses niscache I think.
Balkar, you could modify your script to run as part of the Attribute Publisher - maybe that's your best option.