As a user I would like to log all parameter changes for a given text parameter as an information (purpose is debugging/troubleshooting). However in the current implementation text parameters will only log an information message when there is an exact match, no wildcharts are taken into account.
This is counter intuitive (as '*' works perfectly well for any other severity). And it is not feasable to predict as a humble user what ever a text parameter could take as a state (by definition that would make it a 'discrete' parameter). And even if it would be predictable it may be very impractical to enter say a few hundreds of possible text values.
A simple '*' support would be the most obvious solution here I believe
Hans,
As alternative. You can activate trending on text parameters if the driver tag is set.
You can use the DataMiner Cube trend-graph to evaluate the evolution of that text parameter. Note that Cube only shows 20 distinct values on the Y-axis.
But as the data is in the database, it would be quite easy to create a script that fetches this data.
After some further investigation, there is a magic trick you can apply which is currently not supported in the UI. The magic trick is about making sure an empty value gets added to the list of text values you want to generate an alarm for. When an empty value is specified any value change will be registered as an information event.
As it is not supported in the UI, there are some manual steps to take:
Steps:
– take the alarm-template.xml you want to modify from the server (the bare xml file)
– open it with notepad and find the parameter you want to configure
– in the info tag of that parameter, set 2 semicolons (;;)
– save the file and upload it via the protocols and templates app
– hit apply
– you can still modify your alarm-template, but don’t touch that specific information field. If you do, the ’empty’ value will be gone again.
Thanks for your suggestion on alternative solution but I do not fully subscribe to this view.
First of all extracting data from Cassandra is a lot less easy than it used to be from mysql (at least it is in my opinion) and secondly data can be spread over multiple Dataminer agents so at least data will not be recoverable as easy as it would be through the standard available information message tools.
And finally do not forget about the ‘intuitiveness’ of the behavior in the alarm template.