Interactions between monitored services and surrounding components are displayed as map in the Map tab.
The map is composed of three horizontal parts :
The links thickness and color depends on the importance of the link compared to all links. The thickness depends on the transaction count and the color on the mean latency.
The links between entry points and the application services are incoming transactions. The links bewteen the application services and external componants are outgoing transactions.
It is possible to view the evolution of the number of incoming and/or outgoing transaction count and latency of any element of the map just by selecting it.
Stop guessing, monitor all your business transactions.
Thanks to the data collected by our agents in all software layers (database, remote calls, …), Nudge-APM brings a precise (inner and outer) view of all business transactions and their behaviors over time.
Having such information, you get able to:
Deep dive into the code
Nudge APM is a monitoring and a troubleshooting tool that allows you to have an in-depth view of your applications. It points out all the hotspots and bottlenecks in your code.
Slowdowns or errors are visible straightaway, you discover at a glance the related code and you can even have a detailed view of the involved methods/functions of your codebase using our profiling.
You get a rendering of stacktraces and each method/function in which most of the time is spent represented either in a graph and a detailed dashboard:
Around 1% overhead. It has the lowest overhead of the market. It uses sampling for the retrieval of stacktraces in order to lower the impact on the host. It makes it then important to use this feature in production environments (unlike classic profilers).
Furthermore, it does not require any change in the source code.
Profiling additional information:
The profiling is currently only supported with the Java agent.
The Nudge APM agent not only analyzes the response times of transactions, it also qualifies the transactions in respect of their success or failure.
In order to help the diagnosis of the failures, the probe retrieve the available contextual information at the time of the incident. With Java, it refers to the stacktrace of the potential exception and to its causes.
The errors and their causes can be seen from the transaction’s tab after choosing the corresponding transaction. The screen represents a distribution of errors in time. It groups the errors by their nature (http code, class of exception, …). You are able to visualize the complete stacktrace of the exception and its causes.
Nudge APM is going to allow to visualize (display) the following metrics collected on the browser:
The gathering of such metrics is handled by the Java agent when using particular technologies related with web pages development.
You are able to follow user’s navigation in your application (from the beginning to the end of a session), so that you can:
Have access to our new Key Indicators by clicking on the “User Sessions” tab:
Get the users list with nice data (you can sort them) such as:
You can choose the columns you want to see or hide:
In order to analyze the behavior of a specific user, click on Details:
The user navigation will appear in a time-line, on which you can scroll horizontally and zoom. By clicking on a specific transaction, you get further details.
For each session action, you get:
You get more information on transactions with either a frustrating response time or an error.
When the transaction comes from an HTTP call, all HTTP parameters will be displayed.
You can also have a in-depth view of all calls triggered by the transaction. For each related software layer, you get a list of calls initiated by the transaction with corresponding information:
Those data are available for 1 month.
Nudge APM provides detailed following information about database interaction or connexion pools:
The recovery of the data and the route of ResulSet can also be a cause of latencies for transactions. Also there, Nudge APM is able to supply tracks for optimization of your application (please see Java agent configuration about that subject).
Synthetic system monitoring is provided by the application agents. No need to install specific agent or service to get information about host health.
In order to activate system monitoring, please follow the documentation of corresponding agent:
The Apdex measurement standard Application Performance Index allows clear definition of user satisfaction with regard to the response time.
We deal only with the ability of an application to respond quickly and the other aspects of user satisfaction will not be discussed in this section.
This measurement is computed according to response times for a set of requests over a given period of time.
The Apdex needs 2 parameters that define the response time requirements:
The maximum response time beyond which the user experience is described as “tolerable”.
A response time below this threshold means that the user experience is described as “satisfying”. We will call this value
The maximum response time beyond which the user experience is described as “frustrating”.
This response time is greater than the previous parameter ‘T’. We will call this value
The Apdex is a measurement between 0 and 1, calculated based on the two above parameters.
The formula for the calculation of this measurement is as follows:
Apdex = (#Sat + (#Tol / 2)) / #Total
#Satis the number of requests whose response time is less than
#Tolis the number of requests whose response time is greater than
'T'and less than
#Totalis the total number of requests. If
#Fruis the number of requests whose response time is greater than
'F', then we get
#Total = #Fru + #Tol + #Sat.
The Apdex is therefore a weighting on the number of requests according to their response time.
The response time is divided into 3 categories: satisfying, tolerable and frustrating.
'F' are satisfaction thresholds related to the response time.
With these thresholds and the measurements of response time, we can thus measure user satisfaction regarding the ability of the application to respond quickly.
The Apdex is a ratio with a value between 0 and 1. This way, it can be easily converted to a percentage (simply multiply by 100) to make the information easier to understand. This percentage is correlated to the number of requests through the weighting defined by the Apdex. This is not exactly a percentage of satisfactory responses but is nevertheless a percentage related to the number of certain types of responses (satisfying / tolerable / frustrating). This can be used as a reference from which the improvement or degradation of the system can be observed.
This figure from Nudge APM shows a way to represent that user satisfaction (tied with the response time of the application) over time.
An alert is tied with a (Service Level Agreement). It allows monitor a (QoS) for an application or server.
An alert is defined by:
When a threshold is exceeded, a notification is raised and sent.
Nudge APM allows definition of an alert with a fixed threshold or with a trend.
Here are some examples:
Here are all consequences of the raise of an alert:
Please take a look at the page dedicated to the configuration of an alert.
The Nudge APM REST API gives you access to all the data on the dashboard.
With the API you can:
You can access the REST API through the API button on the Nudge APM interface
You can get more information about the REST API here.
Nudge-APM supports follow-up of transactions between two or several monitored applications. The transactions can be followed through these ; it’s what we call Cross-apps monitoring.
The follow-up of transactions is automatically enabled by the Java agent with many communication protocols.
With Nudge APM you can send or receive reports about the performance of your applications in production.
You can build reports using various widgets available on the platform. Reports can suit many needs of
You would find more information about how to configure reports here.
With an onpremises installation, you can even customize your reports (with your company’s logo for exemple).
This feature is only available for an on-site (or on-premises) installation of the Nudge APM monitor.
It allows users to use their usual login and password in order to connect to the Nudge APM monitor. They will have no need to register or subscribe.
The Nudge APM monitor will be aware of users by connecting to your LDAP compatible authentication service.
You can find information about LDAP integration configuration on this page.