Yes.
Java: the agent is activated with a single JVM argument. So you just have to setup this argument to your Java process of your app inside the container.
PHP: the Nudge APM extension if just about PHP configuration like any other extension. But the agent is a plain process and cannot be running on another machine than the one running the PHP app to monitores. So the agent must be started inside the same container than the PHP app itself.
First thing to check is “can you ping nudge server” ?
ping collector.nudge-apm.com
should output : (actual address may vary)
PING collector.nudge-apm.com (46.105.58.214) 56(84) bytes of data.
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=1 ttl=54 time=6.11 ms
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=2 ttl=54 time=6.48 ms
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=3 ttl=54 time=6.79 ms
In the console logs, if you find a line that says JAVAAGENT START
it means that the agent is recognized by the application server.
Once the application server is started, the agent should create a log
directory (next to probe jar by default) with a nudge.log
file inside.
With the parameter log_level=INFO
(default value) one line is written to log/nudge.log
on each send.
To test the connection without timeout, run the command
telnet collector.nudge-apm.com 443
if Connected to
is displayed then the connection is established, but there may be a significant lag.
error while sending data : java.net.SocketTimeoutException connect timed out
It would appear that communication with collector.nudge-apm.com on port 443 is not working.
If your environment uses a network proxy, it is possible to use it by defining the parameters proxy_host
, proxy_port
, proxy_user
and
proxy_password
in the nudge.properties
file.
It’s also possible to use port 80 (without encryption) by putting server_url=http://collector.nudge-apm.com
in the nudge.properties
file.
error while sending data : java.net.ssl.SSLHandshakeException
It appears that you are using a keystore that is not the JDK default.
By default the JDK keystore contains the certificates that enable the validation of the certificate chain for secure access to the nudge platform.
If you need to add specific certificates, for example to connect to a server using a self-signed certificate, it is normal to start with a copy of the default keystore instead of an empty one, which avoids such inconveniences.
Hence, if you export the current keystore to the default keystore everything should return to normal.
For more details, consult the JDK keystore management tool documentation called keytool.
You can also disable the use of SSL by replacing the https url with http.
Although less secure, in practice it is very unlikely that the exchanges with the server will be compromised, in particular because the information sent is only technical and therefore of relatively little sensitivity.
This is not currently possible; the property file must always be at the same directory level as the probe.
In the next version it will be possible to pass the properties directly in the command line.
Port 443, which is also the default port for SSL transfer.
The version number of the probe is in the file name but also in the jar manifest.
A check is performed on the server where the jar version must be both known and valid.
The property file must be at the same directory level as the probe by default.
The problem: Probes take place on a JVM or on PHP server which are both both likely to run several applications. Besides, if we create in the Nudge interface multiple applications, each is endowed with a particular token. How we can then obtain the monitoring of these applications separately from on another .
PHP Case:
The online documentation requests to specify the parameter nudge.apps
in the file nudge.ini
under the form
[document root path]: [token]
.
In fact this parameter allows to specify a whole mapping of root path with varied tokens of applications simply by means of the separator ","
.
So it is rather easy in PHP to answer this need simply by using the parameter in this way:
[app1 document root path]: [app1 token]
, [app2 document root path]: [app2 token]
, …
Java case:
In this description, we start from the hypothesis that the transactions possess in their code a characteristic which allows to recognize the application which it belongs to.
It’s the case in particular in type JEE’s Web applications with the path of context that appears in transactions URL’s.
It’s necessary to have in mind that the raw data produced by the probe Java contains all the transactions that runned on the JVM.
The aim of this solution, is to have the monitoring information sent to the Nudge platform simultaneously towards several applications which will sort out transactions accordingly to such or such application.
Stage 1:
Concerning probe, simultaneous wsending of the data .
The probe is provided with an option which allows of writting the data on record:
handlers=file
in nudge.properties
.
After writing the data on record, we can easily publish it on the Nudge portal by a simple command curl of this type:
-curl X WAS ABLE TO - Dated - binary
{rawdata_file} https://collector.nudge-apm.com/collect/rawdata/{app_token}
When a rawdata is produced, a simple executed script every minutes can consume the available files and publish them on the Nudge portal aimed concerned applications tokens.
Stage 2:
Regarding the portal, the transactions filtering for every app following stage 1 by default, all transactions are going to be considered by every applications.
Further to the stage 1, by default all the transactions is going to be considered by every application. Filters need to be applied for each one of them only to hold only too keep the ones regarding such or such app.
Filters can be configured in the the application configuration screen, tab “filters”.
In case of a Web app JEE, the applications can be recognized by the beginning of the transaction code, filter needs to be define in order exclude all the others.
For example, if we have an application wich path of context is /application/
, regular expression of the perimeter of exclusion is the following one:
^ (?! / application / $).*
A probe can only monitor a single server / JVM instance.
In order to send data to a single application, you just have to use the same app_id
in probe configuration.
We can help you automate the installation of probes on your server instances if this is required.
Java probe does not send back system information yet.
But another probe dedicated to the monitoring system is available on Nudge APM.
No, the agent only captures what passes through the server; treatments that occur at client level are not captured.
However, it is possible to capture the client side response time (browser) by activating the corresponding option (disabled by default).
A probe sends back information about a JVM / server instance.
All applications deployed on the server then appear under the same application defined in the Nudge APM dashboard.
The JVM setting only needs to support -javaagent
parameter, which means most versions
from java 1.5.
Probes send data every minute, all the information is analyzed and then made available in near real time.
Data is stored for 3 years. If this period is not sufficient, please contact sales department.
Satisfying threshold up to 5 seconds and tolerable up to 10 seconds.
Method names, start time, end time. No functional or business data is transmitted to the server.
They are systematically anonymized by default.
(In the properties file it is possible to disable this option in cases requiring fine diagnosis).
There are three possible causes:
Your application was not compiled in debug mode (by default, compilation is in debug mode).
Without debug mode, information regarding the line of code is not available.
The library for this piece of code was not compiled in debug mode.
The relevant portion of code was developed dynamically (e.g. by Java instrumentation) and is therefore not linked to the source code of the application.
This corresponds to a call to native code, not Java.
Check the parameter activate_rum=true
in the file properties, which is false by default and signifies that information related to the Web client (browser) is not sent back.
Response times are calculated by the browser with or without this parameter.
Enabling this sets a cookie which is sent to the probe which relays it to the Nudge dashboard.
It uses standard mechanisms related to the browser and the only constraint on the browser is that it must support HTML5.
The option does not affect page display.
The homepage of the application monitored by Nudge APM.
When two applications interacts with HTTP, a focus on the callee WS from the caller follows the trace and Nudge UI switches from caller to callee app automaticaly.
To ensure this tracing ability, the agent uses http protocol: it overloads the requests adding a new header.
In certain cases, (with ESB or reverse proxy for instance), it happens that original http message is modified before reaching the callee app. In such a case, the component between caller and callee must be configured to propagate Nudge header: NUDGE_TOKEN.
What does the REST API return compared with the information that is on the dashboard?
All information presented on the dashboard can be accessed through the REST API with the exception of links between the methods in the transactions.
No, no changes are required to monitor the code
No, losing track of these calls is an inherent limitation in Java technology.
Generally, the Java code is executed by the JVM and therefore visible to the probe.
The JNI code is executed by the CPU directly and therefore not visible to the JVM.
The Nudge APM probe works on any type of Java application.
But it features automatic detection mechanisms for some related technologies including JEE.
In other cases, some settings may be needed to teach the probe to detect transactions to be observed.
We assist clients in the implementation of our solution as well as the industrialization of deployment and installation procedures.
However, we do not provide deployment tools because these tools relate to the client environment, and each customer is master of those tools.
It is the JVM that consumes the CPU, not the transactions, but it is possible to make correlations between CPU load consumed by the JVM and transactions that are passed when the CPU load peaks. But CPU and transactions are two independent things.
Yes, it is possible to configure the JMX in order to monitor connection pools.
Certain pools do not reveal the load rate information, in which case, it is possible to create your own MBean which evaluates the load factors from the other information made available by the pool.
Threads are sampled every second.
The values of the Managed Bean attributes are observed every 10 seconds.
All databases are detected by the Nudge APM probe.
Yes ! it only requires configuration and some disk space.
Auditing requires two steps :
configure probe to store data to disk.
In nudge.properties
set handlers=file
(or handler=file,http
to keep sending to Nudge),
then restart application.
open binary “rawdata” files using probe
Raw data files are written to probe log folder using Protocol Buffers, thus you need a tool in order to read them.
In order to read them we provide two tools included in probe :
a graphical user interface (supports opening multiple files at once)
java -jar nudge-x.y.z.jar -va <rawdata-files>
a command-line tool to generate text output (one file at once)
java -jar nudge-x.y.z.jar -pa <rawdata-file>
Important note
By default, there is no limit on how much disk space can be used for audit.
Thus, you will probably need to use disk_dump_max_size
parameter to limit how
much space will be used for audit if you need to keep it enabled over a long period.
There are several possible alternatives.
Firstly the probe is able to pass through a proxy (see the documentation for more information).
Then it is possible to send the data asynchronously by stocking the data collected by the probe at customer premise and then send this data to Nudge at a specific place, determined by both parties (ftp,…).
You can send asynchronously from the files produced by the probe using a command like this:
curl -X PUT --data-binary @{un_fichier_protobuf} https://collector.nudge-apm.com/collect/rawdata/{un_app_id}
It is also possible to use port 80 via placing server_url=http://collector.nudge-apm.com
in the nudge.properties
file.
Note : Afterwards, on the Nudge portal, select the same period than the data you sent.
Yes you can use the same id for 1 probe on several JVM of a single application software to get back all the data. You will find in the tab “instance” load balancing and informations on every JVM.
For several applications on 1 server, our customers set up filters to identify every application.
You will find in the documentation site more set up explanations.
The easiest is to filter the transactions by application.
For exemple, in the case of a Web app, one needs to distinguish the transactions of the applications with a url prefix.
All these questions are account related. And resources are only available to an account administrator.
There is an API resource that provides the complete user ACL of every app of an account. You can access the REST API through the API button on the Nudge APM interface.
GET /api/accounts/{account-id}/appsAcl
If you have a new user to your company you perhaps want to copy his co-workers access controls.
You can do that with an dedicated API resource.
You can access the REST API through the API button on the Nudge APM interface.
POST /api/accounts/{account-id}/accessCopy
Using this resource, you have to provide a JSON message containing both source and target user login like this:
{
"source_user_login":"user1@cie.tld",
"target_user_login":"user2@cie.tld"
}
When someone leaves your company or change of job, you need to revoke all his access rights.
You can achieve this using a single API resource.
You can access the REST API through the API button on the Nudge APM interface
POST /api/accounts/{account-id}/accessRevoke
Using this resource, you have to provide a JSON message containing the user login you want to be revoked:
{
"user_login":"user1@cie.tld"
}