Dynamic Evidence table - StringData field now empty

Hi All.

In my shop we run a lot of script monitors. We collect both the 'Message' fields for string data, and 'Statistic' fields for numeric data.

We have a number of consoles that display the Statistic and Message data. The Message data comes from the APM.DynamicEvidence table - StringData field

Last week we upgraded to Solarwinds 2023.3 . Now our message data does not display.

It appears that the APM.DynamicEvidence table no longer contains any StringData. Also the APM.DynamicEvicence table now has a line through it in SWQL Studio, meaning I assume it has been depreciated (screenshot).

Can someone advise where the Message data from script monitors now stores in the database? Thanks.

Find more posts tagged with

sam

tables

2023.3

swql_query

Accepted answers

All comments

robert777

Hi All.

After a bit of back-and-forth with Solarwinds support (and with Solarwinds development), I think we have an answer regarding Message and Statistic data captured by script monitors:

Beginning with the Orion 2023.2 release, a design change was made regarding the retention policies of data returned from script monitors:

For String data (defined by the Message construct in scripts) only the last collected data point will be available for use in consoles.
For Numeric data (defined by the Statistic construct in scripts) historical data will continue to be available up to the configured retention period.

So, if you need historical string data from script monitors in your consoles, Orion 2022.x.x is the end of the road.

In case anyone not clear what is meant by 'script monitor', they are SAM application component monitors that run a 'script' to collect data, whether Powershell, Bash, Python, Perl, T-SQL (Microsoft), or Oracle SQL (any others I've missed?).

Example of the script component that returns data to Solarwinds below (this is from a Linux Bash script):

printf "Message.data1:$stringfromscript1\n" # only the latest data point available in consoles
printf "Statistic.data1:$numberfromscript1\n" # historical data available in consoles
printf "Message.data2:$stringfromscript2\n"
printf "Statistic.data2:$numberfromscript2\n"

Anyone in the community feel free to question or comment. Cheers.

mesverrum

I like that you were able to pin this down and bring it to the community, i do not like the change.

I can see why someone at SWI might think that it would have been a beneficial change, the message payload in many of the OOTB example script monitors is just a slightly more verbose version of the statistic. So it might have appeared to them in their lab that it was not really providing much value to keep more than double the data historically, and there is no way to min/max/avg text strings for aggregation so it adds some bloat to the SAM tables.

Of course savvy scripters have been using the message field to bring in all kinds of valuable data that can't otherwise be collected specifically because SAM doesnt have any place to store non numeric data points.

I opened this feature request today on the topic

thwack.solarwinds.com/.../need-a-sam-component-that-allows-for-storing-historical-string-values-even-better-if-it-can-also-handle-json