In this series of blogs we’ll be talking about two MediationZone enhancements that are central to the upcoming release 8.0, as well as giving an overview of the full release itself in the last article. As we’ll see, these improvements help the system user in a number of areas including improving performance and easing maintenance.
First, we’ll look at a new feature called Conditional Tracing. This is a flow-based trace mechanism for real-time processing that enables incoming data records to be compared with a configurable trace filter, allowing the system user to define the parameters of the search.
With Conditional Tracing, every step in a workflow (the sequence of “events” which sees the MediationZone’s functions being executed) will generate a trace log in the workflow monitor and in the MZ’s System Log for any data record processed (UDR) that matches the filter.
This makes it easy to analyze processing logic and to identify incorrect workflow behavior or erroneous UDRs as well to provide insights into performance bottlenecks and RCA.
Why is this important? MediationZone already contains rich per-agent debug facilities, but until now has not provided a flow-based trace mechanism (nb. for those unfamiliar with the product, workflows are made up by combinations of sequential agents) that provides a broader vantage point for insights.
By comparing incoming UDRs with a trace filter (and if there is a match, then tracing will be enabled for that UDR) the system user will now be able to visualize the relevant trace segments chronologically, including timing information.
This flow-based view permits collection debugging and tracing information from multiple ECs and workflows to be consolidated into a single timeline, with elapsed time for each trace fragment. It is possible to activate or de-activate any conditional trace without a workflow restart and also easy to define a list of trace "keys", e.g. UDR fields which, if matching, should be traced. Typically these are IMSIs or MSISDNs, IPs, or cell ids, but they could be any data field and value.
Once a trace is enabled for a workflow all incoming UDRs will be checked against the defined trace profile and trace keys to see if there is a match.
The resulting workflow-based rather than “per-agent” view that Conditional Tracing provides is thus a significant step forward when investigating why UDRs are not processed as expected.
Lastly, how easy is configuration? An APL API for tracing makes it possible to check for, and add, explicit trace output from APL. This means that the user is able to do detailed tracing inside complex APL logic. An example might be an analysis agent making two blocking I/O calls to external systems. By surrounding each call with traces, then it becomes possible to see in trace output exactly how long each call took, helping to pinpoint problems.
If you have any questions about conditional tracing or you’d like to learn more, click here:
More Blogs in this blog series: