U.S. patent application number 14/609298 was filed with the patent office on 2016-08-04 for dynamic agent delivery.
The applicant listed for this patent is AppDynamics Inc.. Invention is credited to Vinay Srinivasaiah, Bradley Winslow.
Application Number | 20160224322 14/609298 |
Document ID | / |
Family ID | 56554294 |
Filed Date | 2016-08-04 |
United States Patent
Application |
20160224322 |
Kind Code |
A1 |
Srinivasaiah; Vinay ; et
al. |
August 4, 2016 |
DYNAMIC AGENT DELIVERY
Abstract
The present technology utilizes agents to monitor and report
data from Java virtual machines (JVM) to a controller as part of
application performance monitoring. When a JVM is loaded, code
defining an interface for agents is loaded as well. A determination
may be made as to whether the loaded agent implements the interface
defined at the JVM. If the loaded agent does not implement the
interface, for example if it is missing one or more methods defined
by the interface, the agent class may be modified to define the
missing methods. The modification to the agent class may be made
after compilation but before the class is loaded into the JVM.
Inventors: |
Srinivasaiah; Vinay; (San
Francisco, CA) ; Winslow; Bradley; (Torrance,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
AppDynamics Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
56554294 |
Appl. No.: |
14/609298 |
Filed: |
January 29, 2015 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 8/33 20130101; G06F
9/45504 20130101; G06F 9/45533 20130101; G06F 9/44521 20130101;
G06F 8/315 20130101; G06F 9/44589 20130101; G06F 9/4406 20130101;
G06F 8/30 20130101 |
International
Class: |
G06F 9/44 20060101
G06F009/44; G06F 9/455 20060101 G06F009/455 |
Claims
1. A method for delivering an agent on a machine, comprising:
compiling at a machine an agent class for an agent, the agent
monitoring a distributed business transaction on the machine once
the agent is loaded; loading an interface definition to be
implemented by the agent on all the machine; analyzing an agent
class intended to implement an interface complying with the
interface definition; and modifying the agent class to comply with
the interface definition to be implemented by the agent when the
loaded agent monitors the distributed business transaction.
2. The method of claim 1, wherein the interface definition is
bootstrap loaded onto a java virtual machine at startup time.
3. The method of claim 1, wherein the agent class is analyzed in
byte code form after compilation.
4. The method of claim 1, wherein the agent class is modified by
byte code injection.
5. The method of claim 1, wherein agent class modification includes
adding methods to the agent class that are in the interface
definition but not included in the agent class at the time the
agent is analyzed.
6. The method of claim 5, wherein the added methods throw an
exception.
7. The method of claim 1, further comprising: retrieving
environment information by a .jar agent file; and selecting a
version of an agent to load into the machine.
8. The method of claim 1, wherein the machine is a java virtual
machine.
9. A non-transitory computer-readable storage medium having
embodied thereon a program, the program being executable by a
processor to perform a method for delivering an agent on a machine,
the method comprising compiling at a machine an agent class for an
agent, the agent monitoring a distributed business transaction on
the machine once the agent is loaded; loading an interface
definition to be implemented by the agent on the machine; analyzing
an agent class intended to implement an interface complying with
the interface definition; and modifying the agent class to comply
with the interface definition to be implemented by the agent when
the loaded agent monitors the distributed business transaction.
10. The non-transitory computer-readable storage medium of claim 9,
wherein the interface definition is bootstrap loaded onto a java
virtual machine at startup time.
11. The non-transitory computer-readable storage medium of claim 9,
wherein the agent class is analyzed in byte code form after
compilation.
12. The non-transitory computer-readable storage medium of claim 9,
wherein the agent class is modified by byte code injection.
13. The non-transitory computer-readable storage medium of claim 9,
wherein agent class modification includes adding methods to the
agent class that are in the interface definition but not included
in the agent class at the time the agent is analyzed.
14. The non-transitory computer-readable storage medium of claim
13, wherein the added methods throw an exception.
15. The non-transitory computer-readable storage medium of claim 9,
the method further comprising: retrieving environment information
by a .jar agent file; and selecting a version of an agent to load
into the machine.
16. The non-transitory computer-readable storage medium of claim 9,
wherein the machine is a java virtual machine.
17. A system for delivering an agent on a machine, comprising: a
processor; memory; and one or more modules stored in memory and
executable by the processor to compile at a machine an agent class
for an agent, the agent monitoring a distributed business
transaction on the machine once the agent is loaded, load an
interface definition to be implemented by the agent on the machine,
analyze an agent class intended to implement an interface complying
with the interface definition, and modify the agent class to comply
with the interface definition to be implemented by the agent when
the loaded agent monitors the distributed business transaction.
18. The system of claim 17, wherein the interface definition is
bootstrap loaded onto a java virtual machine at startup time.
19. The system of claim 17, wherein the agent class is analyzed in
byte code form after compilation.
20. The system of claim 17, wherein the agent class is modified by
byte code injection.
21. The system of claim 17, wherein agent class modification
includes adding methods to the agent class that are in the
interface definition but not included in the agent class at the
time the agent is analyzed.
22. The system of claim 21, wherein the added methods throw an
exception.
23. The system of claim 17, further comprising: retrieving
environment information by a .jar agent file; and selecting a
version of an agent to load into the machine.
24. The system of claim 17, wherein the machine is a java virtual
machine.
Description
BACKGROUND OF THE INVENTION
[0001] The World Wide Web has expanded to provide web services
faster to consumers. Web services may be provided by a web
application which uses one or more services to handle a
transaction. The applications may be distributed over several
machines, making the topology of the machines that provides the
service more difficult to track and monitor.
[0002] In some application performance monitoring systems, agents
are installed onto Java virtual machines (JVM) at start-up. The
agents may be used over and over for a running system, but may
become outdated over time. In particular, an interface definition
loaded by a JVM for interfacing with an agent may change over time.
As a result, older agents become obsolete and no longer
function.
[0003] There is a need in the art for managing agents for
monitoring systems that involve changing interfaces.
SUMMARY OF THE CLAIMED INVENTION
[0004] The present technology utilizes agents to monitor and report
data from Java virtual machines (JVM) to a controller as part of
application performance monitoring. When a JVM is loaded, code
defining an interface for agents is loaded as well. A determination
may be made as to whether the loaded agent implements the interface
defined at the JVM. If the loaded agent does not implement the
interface, for example if it is missing one or more methods defined
by the interface, the agent class may be modified to define the
missing methods.
[0005] The modification to the agent class may be made after
compilation but before the class is loaded into the JVM. In some
instances, the modification may be made by a class loader by byte
code injection into the byte code class. As a result, the class may
be modified to implement the interface without changing the source
code of the agent. The modification by the class loader may be done
to implement a dummy method, for example a method that throws an
exception.
[0006] An embodiment may include a method for delivering an agent
on a machine. The method may load an interface definition on a
machine. An agent class may be analyzed, wherein the agent class is
intended to implement an interface complying with the interface
definition. The agent class may be modified to comply with the
interface definition.
[0007] An embodiment may include a system for monitoring a business
transaction. The system may include a processor, memory and one or
more modules stored in memory and executable by the processor. When
executed, the one or more modules may load an interface definition
on a machine, analyze an agent class intended to implement an
interface complying with the interface definition, and modify the
agent class to comply with the interface definition.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is a block diagram of an exemplary system for
monitoring a distributed application.
[0009] FIG. 2 is a block diagram of an agent.
[0010] FIG. 3 is a method for loading an agent.
[0011] FIG. 4 is a method for configuring agent classes to
implement an interface.
[0012] FIG. 5 is a block diagram of an exemplary system for
implementing a computing device.
[0013] FIG. 6 is a block diagram of an exemplary system for
implementing a mobile device.
DETAILED DESCRIPTION
[0014] The present technology utilizes agents to monitor and report
data from Java virtual machines (JVM) to a controller as part of
application performance monitoring. When a JVM is loaded, boot
strap code is loaded to interface with an agent. The boot strap
code defines an interface to be implemented by an agent class. Over
time, the interface definition may change, and an agent that was
able to implement an old version of the interface may not be able
to implement an updated version of the interface.
[0015] The classes of the agent may be modified to properly
implement the agent interface. The agent classes are compiled and
then a class loader accesses the byte code for each class
implementing the interface. A determination may be made as to
whether the agent class implements the interface defined at the
JVM. If the agent class does not implement the interface, for
example if it is missing one or more methods defined by the
interface, the agent class may be modified to define the missing
methods.
[0016] The modification to the agent class may be made after
compilation but before the class is loaded into the JVM. In some
instances, the modification may be made by a class loader by byte
code injection into the byte code class. As a result, the class may
be modified to implement the interface without changing the source
code of the agent. The modification by the class loader may be done
to implement a dummy method, for example a method that throws an
exception.
[0017] FIG. 1 is a block diagram of a system for monitoring a
distributed application. System 100 of FIG. 1 includes client
device 105 and 192, mobile device 115, network 120, network server
125, application servers 130, 140, 150 and 160, asynchronous
network machine 170, data stores 180 and 185, and controller
190.
[0018] Client device 105 may include network browser 110 and be
implemented as a computing device, such as for example a laptop,
desktop, workstation, or some other computing device. Network
browser 110 may be a client application for viewing content
provided by an application server, such as application server 130
via network server 125 over network 120. Mobile device 115 is
connected to network 120 and may be implemented as a portable
device suitable for receiving content over a network, such as for
example a mobile phone, smart phone, tablet computer or other
portable device. Both client device 105 and mobile device 115 may
include hardware and/or software configured to access a web service
provided by network server 125.
[0019] Network 120 may facilitate communication of data between
different servers, devices and machines. The network may be
implemented as a private network, public network, intranet, the
Internet, a Wi-Fi network, cellular network, or a combination of
these networks.
[0020] Network server 125 is connected to network 120 and may
receive and process requests received over network 120. Network
server 125 may be implemented as one or more servers implementing a
network service. When network 120 is the Internet, network server
125 may be implemented as a web server. Network server 125 and
application server 130 may be implemented on separate or the same
server or machine.
[0021] Application server 130 communicates with network server 125,
application servers 140 and 150, controller 190. Application server
130 may also communicate with other machines and devices (not
illustrated in FIG. 1). Application server 130 may host an
application or portions of a distributed application and include a
virtual machine 132, agent 134, and other software modules.
Application server 130 may be implemented as one server or multiple
servers as illustrated in FIG. 1, and may implement both an
application server and network server on a single machine.
[0022] Application server 130 may include applications in one or
more of several platforms. For example, application server 130 may
include a Java application, .NET application, PHP application, C++
application, AJAX, or other application. Different platforms are
discussed below for purposes of example only.
[0023] Virtual machine 132 may be implemented by code running on
one or more application servers. The code may implement computer
programs, modules and data structures to implement, for example, a
virtual machine mode for executing programs and applications. In
some embodiments, more than one virtual machine 132 may execute on
an application server 130. A virtual machine may be implemented as
a Java Virtual Machine (JVM). Virtual machine 132 may perform all
or a portion of a business transaction performed by application
servers comprising system 100. A virtual machine may be considered
one of several services that implement a web service.
[0024] Virtual machine 132 may be instrumented using byte code
insertion, or byte code instrumentation, to modify the object code
of the virtual machine. The instrumented object code may include
code used to detect calls received by virtual machine 132, calls
sent by virtual machine 132, and communicate with agent 134 during
execution of an application on virtual machine 132. Alternatively,
other code may be byte code instrumented, such as code comprising
an application which executes within virtual machine 132 or an
application which may be executed on application server 130 and
outside virtual machine 132.
[0025] Agent 134 on application server 130 may be installed on
application server 130 by instrumentation of object code,
downloading the application to the server, or in some other manner.
Agent 134 may be executed to monitor application server 130,
monitor virtual machine 132, and communicate with byte instrumented
code on application server 130, virtual machine 132 or another
application or program on application server 130. Agent 134 may
detect operations such as receiving calls and sending requests by
application server 130 and virtual machine 132. Agent 134 may
receive data from instrumented code of the virtual machine 132,
process the data and transmit the data to controller 190. Agent 134
may perform other operations related to monitoring virtual machine
132 and application server 130 as discussed herein. For example,
agent 134 may identify other applications, share business
transaction data, aggregate detected runtime data, and other
operations.
[0026] Agent 134 may be a Java agent, .NET agent, PHP agent, or
some other type of agent, for example based on the platform which
the agent is installed on.
[0027] Each of application servers 140, 150 and 160 may include an
application and an agent. Each application may run on the
corresponding application server or a virtual machine. Each of
virtual machines 142, 152 and 162 on application servers 140-160
may operate similarly to virtual machine 132 and host one or more
applications which perform at least a portion of a distributed
business transaction. Agents 144, 154 and 164 may monitor the
virtual machines 142-162 or other software processing requests,
collect and process data at runtime of the virtual machines, and
communicate with controller 190. The virtual machines 132, 142, 152
and 162 may communicate with each other as part of performing a
distributed transaction. In particular each virtual machine may
call any application or method of another virtual machine.
[0028] Asynchronous network machine 170 may engage in asynchronous
communications with one or more application servers, such as
application server 150 and 160. For example, application server 150
may transmit several calls or messages to an asynchronous network
machine. Rather than communicate back to application server 150,
the asynchronous network machine may process the messages and
eventually provide a response, such as a processed message, to
application server 160. Because there is no return message from the
asynchronous network machine to application server 150, the
communications between them are asynchronous.
[0029] Data stores 180 and 185 may each be accessed by application
servers such as application server 150. Data store 185 may also be
accessed by application server 150. Each of data stores 180 and 185
may store data, process data, and return queries received from an
application server. Each of data stores 180 and 185 may or may not
include an agent.
[0030] Controller 190 may control and manage monitoring of business
transactions distributed over application servers 130-160.
Controller 190 may receive runtime data from each of agents
134-164, associate portions of business transaction data,
communicate with agents to configure collection of runtime data,
and provide performance data and reporting through an interface.
The interface may be viewed as a web-based interface viewable by
mobile device 115, client device 105, or some other device. In some
embodiments, a client device 192 may directly communicate with
controller 190 to view an interface for monitoring data.
[0031] Controller 190 may install an agent into one or more virtual
machines and/or application servers 130. Controller 190 may receive
correlation configuration data, such as an object, a method, or
class identifier, from a user through client device 192.
[0032] Controller 190 may collect and monitor customer usage data
collected by agents on customer application servers and analyze the
data. The controller may report the analyzed data via one or more
interfaces, including but not limited to a dashboard interface and
one or more reports.
[0033] Data collection server 195 may communicate with client 105,
115 (not shown in FIG. 1), and controller 190, as well as other
machines in the system of FIG. 1. Data collection server 195 may
receive data associated with monitoring a client request at client
105 (or mobile device 115) and may store and aggregate the data.
The stored and/or aggregated data may be provided to controller 190
for reporting to a user.
[0034] FIG. 2 is a block diagram of an agent. Agent 200 may include
an agent .jar file 210 and class loader 220. The agent may be
installed on JVM 240 which includes an interface definition 230.
Class loader 220 may load class files from the agent into the JVM.
The agent .jar file 210 may include one or more files for analyzing
the interface definition 230 and the agent class to implement the
interface, and determine what methods are defined in the interface
definition 230 but missing in the class. One or more classes in
agent .jar file 210 may dynamically perform byte code injection to
define the methods in the class, thereby configuring the class to
properly implement the interface. In some instances, initialization
code 250 within the agent .jar file may analyze the classes and
modify the classes via byte code injection. The modified class is
then provided to the class loader. When request is subsequently
received to load the class, the modified class is provided rather
than the original class.
[0035] FIG. 3 is a method for loading an agent. First, a JVM is
started up at step 310. During the JVM start-up, bootstrap Java
agent files are loaded at step 320. The java agent file may include
a .jar file that includes one or more files that implement the
agent.
[0036] Environment information is retrieved by the agent file at
step 330. The environment information may include controller
information, node, tier or application information. At step 340, an
agent version is selected to install onto the JVM based on the
environment detected at step 330. Selected agent files for the
agent version are loaded at step 350.
[0037] The agent class to implement an interface loaded into the
JVM is then modified at step 360. The process for modifying the
class may include analyzing the interface and the class and then
modifying the class to be able to implement the interface. More
details for modifying the agent class is discussed with respect to
the method of FIG. 4.
[0038] The modified class byte code is loaded into a JVM at step
370. The modified agent class may then implement the interface at
step 380 to allow for application monitoring and data
collection.
[0039] FIG. 4 is a method for configuring agent classes to
implement an interface. The method of FIG. 4 provides more detail
for step 360 of the method of FIG. 3. First, an interface
definition is analyzed at step 410. The interface may be loaded
into a JVM by agent bootstrap code and analyzed by a file in an
agent .jar file. The interface definition may be analyzed for
methods required to implement the definition.
[0040] Compiled agent classes are accessed at step 420. The
compiled agent classes are then analyzed at step 430 by one or more
agent .jar files, such as initialization code within the agent .jar
file, to identify methods that are defined in the agent interface
but not included in the class to implement the interface. The
classes may be analyzed before they are loaded into the JVM so they
can be changed before loading if needed.
[0041] Though analysis of the class is discussed with respect to
identifying missing methods that appear in an agent interface
definition, other discrepancies may be detected as well. For
example, the present technology may be implemented in languages and
platforms other than Java. In other languages, an analyzing module
may analyze the agent files to determine if anything needs to be
changed in order to interface with a corresponding interface on an
application, machine or service to be monitored by the agent.
[0042] Returning to the method of FIG. 4, any methods determined to
be missing from in the class to implement the interface are
dynamically added via byte code injection at step 440. The
injection may be performed by initialization code within the agent.
jar file or other code that can access the classes after they are
compiled into byte code and before they are loaded into a JVM. The
modified classes may then be loaded into the JVM and may implement
the interface as discussed with respect to FIG. 3.
[0043] FIG. 5 illustrates an exemplary computing system 500 that
may be used to implement a computing device for use with the
present technology. System 500 of FIG. 5 may be implemented in the
contexts of the likes of clients 55-115, network server 125,
application servers 130-160, machine 170, data stores 180-185, and
controller 190. The computing system 500 of FIG. 5 includes one or
more processors 54 and memory 54. Main memory 54 stores, in part,
instructions and data for execution by processor 54. Main memory 54
can store the executable code when in operation. The system 500 of
FIG. 5 further includes a mass storage device 530, portable storage
medium drive(s) 540, output devices 550, user input devices 560, a
graphics display 570, and peripheral devices 580.
[0044] The components shown in FIG. 5 are depicted as being
connected via a single bus 590. However, the components may be
connected through one or more data transport means. For example,
processor unit 54 and main memory 54 may be connected via a local
microprocessor bus, and the mass storage device 530, peripheral
device(s) 580, portable storage device 540, and display system 570
may be connected via one or more input/output (I/O) buses.
[0045] Mass storage device 530, which may be implemented with a
magnetic disk drive or an optical disk drive, is a non-volatile
storage device for storing data and instructions for use by
processor unit 54. Mass storage device 530 can store the system
software for implementing embodiments of the present invention for
purposes of loading that software into main memory 54.
[0046] Portable storage device 540 operates in conjunction with a
portable non-volatile storage medium, such as a floppy disk,
compact disk or Digital video disc, to input and output data and
code to and from the computer system 500 of FIG. 5. The system
software for implementing embodiments of the present invention may
be stored on such a portable medium and input to the computer
system 500 via the portable storage device 540.
[0047] Input devices 560 provide a portion of a user interface.
Input devices 560 may include an alpha-numeric keypad, such as a
keyboard, for inputting alpha-numeric and other information, or a
pointing device, such as a mouse, a trackball, stylus, or cursor
direction keys. Additionally, the system 500 as shown in FIG. 5
includes output devices 550. Examples of suitable output devices
include speakers, printers, network interfaces, and monitors.
[0048] Display system 570 may include a liquid crystal display
(LCD) or other suitable display device. Display system 570 receives
textual and graphical information, and processes the information
for output to the display device.
[0049] Peripherals 580 may include any type of computer support
device to add additional functionality to the computer system. For
example, peripheral device(s) 580 may include a modem or a
router.
[0050] The components contained in the computer system 500 of FIG.
5 are those typically found in computer systems that may be
suitable for use with embodiments of the present invention and are
intended to represent a broad category of such computer components
that are well known in the art. Thus, the computer system 500 of
FIG. 5 can be a personal computer, hand held computing device,
telephone, mobile computing device, workstation, server,
minicomputer, mainframe computer, or any other computing device.
The computer can also include different bus configurations,
networked platforms, multi-processor platforms, etc. Various
operating systems can be used including Unix, Linux, Windows,
Macintosh OS, Palm OS, and other suitable operating systems.
[0051] FIG. 6 illustrates an exemplary mobile device system 600
that may be used to implement a mobile device for use with the
present technology, such as for mobile device 62. The mobile device
600 of FIG. 6 includes one or more processors 65 and memory 612.
Memory 612 stores, in part, programs, instructions and data for
execution and processing by processor 65. The system 600 of FIG. 6
further includes storage 614, one or more antennas 616, a display
system 618, inputs 620, one or more microphones 622, and one or
more speakers 624.
[0052] The components shown in FIG. 6 are depicted as being
connected via a single bus 626. However, the components 65-524 may
be connected through one or more data transport means. For example,
processor unit 65 and main memory 612 may be connected via a local
microprocessor bus, and storage 614, display system 618, input 620,
and microphone 622 and speaker 624 may be connected via one or more
input/output (I/O) buses.
[0053] Memory 612 may include local memory such as RAM and ROM,
portable memory in the form of an insertable memory card or other
attachment (e.g., via universal serial bus), a magnetic disk drive
or an optical disk drive, a form of FLASH or PROM memory, or other
electronic storage medium. Memory 612 can store the system software
for implementing embodiments of the present invention for purposes
of loading that software into main memory 65.
[0054] Antenna 616 may include one or more antennas for
communicating wirelessly with another device. Antenna 616 may be
used, for example, to communicate wirelessly via Wi-Fi, Bluetooth,
with a cellular network, or with other wireless protocols and
systems. The one or more antennas may be controlled by a processor
65, which may include a controller, to transmit and receive
wireless signals. For example, processor 65 execute programs stored
in memory 612 to control antenna 616 transmit a wireless signal to
a cellular network and receive a wireless signal from a cellular
network.
[0055] Display system 618 may include a liquid crystal display
(LCD), a touch screen display, or other suitable display device.
Display system 670 may be controlled to display textual and
graphical information and output to text and graphics through a
display device. When implemented with a touch screen display, the
display system may receive input and transmit the input to
processor 65 and memory 612.
[0056] Input devices 620 provide a portion of a user interface.
Input devices 660 may include an alpha-numeric keypad, such as a
keyboard, for inputting alpha-numeric and other information,
buttons or switches, a trackball, stylus, or cursor direction
keys.
[0057] Microphone 622 may include one or more microphone devices
which transmit captured acoustic signals to processor 65 and memory
612. The acoustic signals may be processed to transmit over a
network via antenna 616.
[0058] Speaker 624 may provide an audio output for mobile device
600. For example, a signal received at antenna 616 may be processed
by a program stored in memory 612 and executed by processor 65. The
output of the executed program may be provided to speaker 624 which
provides audio. Additionally, processor 65 may generate an audio
signal, for example an audible alert, and output the audible alert
through speaker 624.
[0059] The mobile device system 600 as shown in FIG. 6 may include
devices and components in addition to those illustrated in FIG. 6.
For example, mobile device system 600 may include an additional
network interface such as a universal serial bus (USB) port.
[0060] The components contained in the computer system 600 of FIG.
6 are those typically found in mobile device systems that may be
suitable for use with embodiments of the present invention and are
intended to represent a broad category of such mobile device
components that are well known in the art. Thus, the computer
system 600 of FIG. 6 can be a cellular phone, smart phone, hand
held computing device, minicomputer, or any other computing device.
The mobile device can also include different bus configurations,
networked platforms, multi-processor platforms, etc. Various
operating systems can be used including Unix, Linux, Windows,
Macintosh OS, Google OS, Palm OS, and other suitable operating
systems.
[0061] The foregoing detailed description of the technology herein
has been presented for purposes of illustration and description. It
is not intended to be exhaustive or to limit the technology to the
precise form disclosed. Many modifications and variations are
possible in light of the above teaching. The described embodiments
were chosen in order to best explain the principles of the
technology and its practical application to thereby enable others
skilled in the art to best utilize the technology in various
embodiments and with various modifications as are suited to the
particular use contemplated. It is intended that the scope of the
technology be defined by the claims appended hereto.
* * * * *