Introduction

When tracing an error's path through the code, the OverOps call stack includes all of the functions/methods used, i.e., the full call stack. The entry point (transaction) in any call stack is the first application code frame within the event call stack; however, sometimes this entry point is simply a common method that provides very limited information on the error origin itself (for example, a common servlet filter, a Proxy or SecurityProxy, or an InboundRequestProcessor).

What is an "OverOps transaction"?
An OverOps transaction is the flow from an ‘OverOps entry point’ to the error location of an event. This flow usually spans multiple method’s across multiple libraries/packages/classes.

Customizing the Entry Points

Because in some cases the most precise entry point is located deeper in the call stack than the entry point which is automatically detected by the system, OverOps provides you with the ability to customize the entry points.

📘

Note

Entrypoint customization is supported for the following languages -

• JVM languages listed here starting from version 4.41.
• .NET starting from version 4.51

This customization enables you to both prioritize certain entry points and deprioritize others:

• Define a list of packages and classes that get a higher priority over other entry points, so that when the OverOps Agent finds these packages/classes in the call stack, they will immediately be flagged as the priority entry points over any other entry point in the stack.
• Deprioritize common packages and classes so that they'll only be marked as entry points where there are no other options in the call stack. This option ensures that the information from these packages and classes is still retained and available, rather than sending these packages/classes to the third-party blacklist.

🚧

Important

• This functionality is accessible to account owners and administrators only.
• Note that after updating the entrypoints in the Settings dashboard, you'll need to restart the application attached to the Micro-Agent to apply these updates.

Example - Using Entry Point Prioritization for Better App Tier Grouping

If an event is labeled with one of the app tiers - but in some of the snapshots isn't visible in the packages associated with this app tier across the call stack - it's possible to miss an important event. This occurs because a set of events are grouped under a common entry point, and one of the snapshots may have this app tier package under it, so that the entire event is marked.

Using the entry point prioritization feature, you can prioritize or deprioritize packages and classes, and control how events will be grouped. For example, you can now mark app tiers as prioritized entry points so that the events associated with these app tiers will be grouped under the relevant entry points - so that when the Agent sees them in the call stack - they'll be marked as entry points with a high priority - even if there are valid entry points before them in the call stack (see Adding Prioritized and Deprioritized Entry Points for details).

In addition, the deprioritization option can be used, for example, for common entry points that group a lot of events under them; in this case, when a package or class is added - it will be marked as a valid entryphone only if no other point is found.