Agents
Last updated
Last updated
Each agent instance is assigned to an application. You can view all the connected agents in the Applications page. You just need to select the application and you will get a list of all agent instances of this application.
All the agents instances are presented in a table. All the table columns are self-explanatory. The first Name column contains an instance name and some additional information. The green icon in front of the instance name denotes that this agent has an assigned license. If the name of the instance is in green, it means that this instance has a profile. If you click the instance name you will get a detailed view of the selected agent instance.
Each agent provides some information about its operations and the JVM it runs within. The data about the agent and the JVM are updated every 5 seconds. The data are not persisted anywhere so they are delivered as long as the agent is able to maintain its connection to the Flopsar server.
Nearly all the presented data are self-explanatory. The Errors graph shows the total number of the agent errors, which can be investigated in the Diagnostics tab.
If an agent detects a JVM error of java.lang.Error it is displayed at the top of the agent details view. Agents do not detect all errors of java.lang.Error. Only a subset of the most important errors are reported, such as:
VerifyError - thrown when the class verifier detects that a class file, though well formed, contains some sort of internal inconsistency or security problem. If this error is caused by the agent instrumentation, you must exclude the offending class from your profile.
NoClassDefFoundError - thrown if the JVM or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or as part of creating a new instance using the new expression) and no definition of the class could be found.
ClassFormatError - thrown when the JVM attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file. If this error is caused by the agent instrumentation, you must exclude the offending class from your profile.
StackOverflowError - thrown when a stack overflow occurs because an application recurses too deeply.
OutOfMemoryError - thrown when the JVM cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
UnsupportedClassVersionError - thrown when the JVM attempts to read a class file and determines that the major and minor version numbers in the file are not supported.
VirtualMachineError - thrown to indicate that the JVM is broken or has run out of resources necessary for it to continue operating.
ClassCircularityError - thrown when the Java Virtual Machine detects a circularity in the superclass hierarchy of a class being loaded.
UnsatisfiedLinkError - thrown if the JVM cannot find an appropriate native-language definition of a method declared native.
NoSuchMethodError - thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.
NoSuchFieldError - thrown if an application tries to access or modify a specified field of an object, and that object no longer has that field.
If you want to find out more about the detected error, just click the error link and you will get a popup window with more details.
You can always clear the errors from the agent registry by pressing the Clear button on the errors warning banner.
Each agent collects JVM heap memory usage. By default, agents collect only the overall memory usage. If you want to know which objects occupy the memory, just press the Enable heap sampling button and wait for the data.
Please note, the heap sampling may have a negative impact on your application performance, so do not use it over a long period of time.
Each agent collects JVM threads count. If you need to know what threads are currently
Please note, the threads sampling may have a negative impact on your application performance, so do not use it over a long period of time.
The agent does not have log files, instead it maintains a list of errors that can occurred in the agent. These errors are divided into logical groups. To see which errors have occurred, just click one of the bars in the graph.
Each error code is presented in a form NNLNN. It is divided in two parts with L as a separator. When checking a code, you should only check the first part NNL* of the code. Since the same errors can occur multiple times, only the last error date and message are presented. The Count value shows how many times the error occurred. The error message is optional and can be empty in some cases.
103L*
Data retrieved from the server is corrupt.
104L*
Agent and server uses different versions of the data protocol.
402L*
Class bytes parse failed.
403L*
Classes retransformation failed.
406L*
Some method will not be instrumented.
Agents call multiple JVMTI functions, which can return errors. These errors are reported by agents. In order to map the agent errors 2XXL* on JVMTI ones, you need to take into account only XX part of the error, which is a hexadecimal value of the original JVMTI error.
20AL* - 274L*
501L*
Some data cannot be passed to the outbound queue.
301L*
Some resource is currently unavailable.
302L*
JVM does not support a capability.
303L*
Some class constructor cannot be found.
304L*
Some class has not been found by the agent.
305L*
Some method has not been found by the agent.
306L*
Some class object cannot be created.
308L*
Some thread is detached from JVM.
309L*
Failed to attach to JVM thread.
30AL*
Some exception has been thrown.
