How Does eG Enterprise Measure Performance of Business Transactions to Windows Service Applications?

eG's approach to business transaction monitoring varies according to the type of Windows service application being monitored - whether web-based or standalone.

The sections below discuss how eG Enterprise monitors both these service application types.

How eG Enterprise Monitors Business Transactions to Web-based Windows Service Applications?

As mentioned already, web-based Windows service applications are .NET/.NET Core-based applications that listen on a TCP port and respond to HTTP/S requests received via that port.

Typically, when a user / client application makes a transaction request to the Windows service application via its port, a Windows process is launched in the background corresponding to that service application. This process automatically invokes an instance of the .NET CLR / .NET Core CLR (as the case may be) to service the transaction request. Once the eG profiler is installed on the application host, this background Windows process also loads an instance of the profiler.

As soon as the profiler loads, it injects a .NET / .NET Core code (as the case may be) into the application code. The injected code adds a GUID to each unique transaction to the application, and performs the following tasks:

Traces the path of a transaction;
Measures the responsiveness of a transaction by computing the time difference between when the transaction started and when it ended;
Identifies the slow, stalled, and error transactions, and computes the count of such transactions;
Discovers the exit calls made by a transaction from the IIS web server, determines the destination of the calls, and measures the average time taken by each call to process the requests for a transaction;

The profiler then sends all these statistics to the eG agent. To know how and when the profiler transmits metrics to the eG agent, refer to the How Does the eG Profiler for Windows Service Applications Communicate with the eG Agent?topic.

The eG agent reports these metrics to the eG manager. The eG manager stores these metrics in the eG database and also publishes them in the eG monitoring console using the Microsoft .NET Application monitoring model.

How eG Enterprise Monitors Business Transactions to Standalone Windows Service Applications?

Note that currently, eG Enterprise does not monitor .NET Core-based Standalone Windows service applications. Only .NET-based service applications are supported.

Standalone Windows service applications do not listen on any port, and hence cannot receive/respond to requests from clients over the web.

Typically, these service applications will be programmed to run at scheduled intervals and execute business-critical jobs. For executing these jobs, these service applications call one/more .NET methods/functions. In case of standalone Windows service applications, the eG profiler monitors these 'functions' only, and not 'web URLs'.

However, the profiler, upon installation, will have no knowledge of what functions are to be monitored and which background Windows service calls them. This is why, the administrator is first required to configure the eG manager with the following:

The Windows services, which correspond to the .NET applications that need to be monitored;
The methods/functions to be monitored per service

The eG agent downloads this information from the manager.

Every time the service application runs, the corresponding Windows service runs in the background. This service automatically invokes an instance of the .NET CLR. Once the eG profiler is installed on the application host, this background Windows service also loads an instance of the profiler.

The profiler, upon loading, communicates with the eG agent and downloads the list of Windows services to be monitored and the functions to be traced per service. Then, the profiler injects a .NET code into the application code. The injected code adds a GUID to each unique method/function called by the service, and performs the following tasks:

Traces the path of a method/function;
Measures the responsiveness of a function by computing the time difference between when the function was called and when its execution ended;
Identifies the slow, stalled, and erroneous function calls, and computes the count of such calls;