At the moment the request attributes seem to be cut at a length of 250. In AppMon we captured 3000 characters for some agents.
Further is there a full representation of the captured value where i can copy it from. At the moment I have to find the tooltip containing the full text in the html source and copy it from there.
Solved! Go to Solution.
As for the copying the value from the UI - it is possible to select the whole string (also beyond the three dots) and do the copy. Works for me (in Chrome browser at least). I agree, this is something that should be improved.
Hi @Julius L.
Thank you for the quick answer.
Do you know if there is already a RFE for the capture length?
Ah ok you are right it actually copies the whole string, I didn't try it because I though it will expand or something 😉
Sorry, I don't know. But I don't think they will extend it beyond 250 characters for storage reasons.
Can you elaborate on the use case? Are really more than 250 characters required? You can set multiple attributes and capture just the parts you need.
it would work for the most important parts of the message like status codes etc. but still the developers would loose the ability to directly reproduce the service call
I understand, so unfortunately there is no option for this. Only Idea I have is to modify app to store such transactions via log files. Then you can add this log to dynatrace for monitoring and correlate some id between logs and transactions to get value. It's not as useful but it's always something.
What about using a RegEx to capture characters (1..250) into one parameter, then another to capture characters (251..500), etc, etc, until you've captured the whole 3k. Then at least the developers would have the ability to reconstruct the whole request.
note: This is not a performant solution and the value of the data should be considered against the cost of handling many long strings.
@jalpeshs it depends on the data source afaik. For example, with HTTP request header source it works flawlessly. For Java method arguments I was not lucky and seems data is trimmed anyway.