US20200233677A2 - Dynamically-Updatable Deep Transactional Monitoring Systems and Methods - Google Patents
Dynamically-Updatable Deep Transactional Monitoring Systems and Methods Download PDFInfo
- Publication number
- US20200233677A2 US20200233677A2 US16/382,174 US201916382174A US2020233677A2 US 20200233677 A2 US20200233677 A2 US 20200233677A2 US 201916382174 A US201916382174 A US 201916382174A US 2020233677 A2 US2020233677 A2 US 2020233677A2
- Authority
- US
- United States
- Prior art keywords
- monitoring
- target
- application
- functions
- agent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 86
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000013515 script Methods 0.000 claims abstract description 35
- 230000000977 initiatory effect Effects 0.000 claims 1
- 230000006870 function Effects 0.000 abstract description 51
- 230000008569 process Effects 0.000 abstract description 47
- 238000004590 computer program Methods 0.000 abstract description 5
- 239000003795 chemical substances by application Substances 0.000 description 34
- 238000013459 approach Methods 0.000 description 24
- 230000006854 communication Effects 0.000 description 14
- 238000004891 communication Methods 0.000 description 12
- 238000012986 modification Methods 0.000 description 9
- 230000004048 modification Effects 0.000 description 9
- 230000036316 preload Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
- G06F9/45512—Command shells
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3495—Performance evaluation by tracing or monitoring for systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/87—Monitoring of transactions
Definitions
- Embodiments generally relate to software monitoring, and in particular to systems and methods for performing deep transactional monitoring of running applications in production usage.
- APM Software application performance management
- APM is the monitoring and management of the performance and availability of software applications.
- APM is a crucial part of ensuring software reliability, allowing fast diagnosis and recovery from runtime failures.
- APM software can be designed to detect and diagnose performance problems in a target application, with the goal of maintaining an expected level of service by the application.
- Any set of performance metrics can be monitored by an APM system.
- One common set of metrics describes the performance experienced by end users of an application, for example, average response times under peak load.
- Another common set of metrics measures the computational resources used by the application for a particular load, for example, CPU and memory usage. Computational resource measurements can help discover performance bottlenecks, detect changes in performance, and predict future changes in application performance.
- APM real user monitoring
- ROM real user monitoring
- Monitoring actual user interaction with a website or an application is important to operators to determine if users are being served quickly and without errors and, if not, which part of a business process is failing.
- Real user monitoring data is used to determine the actual service-level quality and transactional integrity delivered to end-users and to detect errors or slowdowns on application. The data may also be used to determine if changes that are promulgated to application have the intended effect or cause errors.
- BTM business transaction monitoring
- BTM provides tools for tracking the flow of transactions across IT infrastructure and code-level drill-down into defined portions of the transactions, in addition to detection, alerting, and correction of unexpected changes in business or technical conditions.
- BTM provides visibility into the flow of transactions across infrastructure tiers, including a dynamic mapping of the application topology and deep code-level drill-down in defined portions of the transactions.
- BTM may allow searching for transactions based on context and content—for instance, user performing the transaction, time and code context of execution of functions, web requests, or web services, input arguments and return values, and system component executing the transaction,—providing a way to isolate causes for issues such as application exceptions, stalled transactions, and lower-level issues such as incorrect data values.
- performing APM can be a complicated process that involves many technical challenges.
- APM has a performance cost, which can range from minor and negligible to extremely high impact and only suitable for development and non-production environments.
- Certain methods involve modifying the target application source code and recompiling, but this generally requires suspending and restarting the application.
- Some APM software may also need access to system resources that may be protected from reading or writing by security measures, for example, requiring administrator/root access.
- Other applications may block third-party library preloads, further complicating the options to access application data for methods that require modification of system libraries or system preload directives.
- FIG. 1 illustrates a target application monitoring environment, according to an example embodiment.
- FIG. 2 shows a diagram describing the flow of data in monitoring environment, according to an example embodiment.
- FIG. 3A shows a set of instructions illustrating how a thread may create a trampoline to a monitoring function, according to an example embodiment.
- FIG. 3B shows a set of instructions illustrating the stalker approach adds instrumentation to target functions, according to an example embodiment.
- FIG. 4 is an example computer system useful for implementing various embodiments.
- FIG. 1 illustrates a target application monitoring environment 100 , according to an example embodiment.
- a target application 112 runs on a software environment (e.g., an operating system) running on a target server 110 .
- the target application may be any application, such as, by way of example, back end application providing services over a network.
- target application 112 is an application developed in native compiled code (e.g., C/C++).
- Target application may also be a hosted application or a SaaS application running on a host provider.
- One or more agents 114 also runs on target server 110 , and in particular embodiments, an agent 114 follows an injection approach where it runs as a separate process within target server 110 .
- the agent 114 follows an embedded approach where it runs inside one or more target processes 113 .
- Agent 114 is configured to collect data from one or more target processes 113 in real-time and transmit the data to monitoring applications.
- Target application may have one or more agents performing application monitoring.
- Agent 114 communicates with a collector server 120 via a network 150 .
- Collector server 120 may run one or more monitoring processes 122 and store one or more monitoring scripts 124 .
- Processes 122 in collector server 120 may be configured to receive monitoring data from agent 114 and control the agent's behavior. For example, agent 114 may receive instructions on what data to collect from target process 113 and how often to collect it.
- agent 114 creates a new monitoring thread 115 within one or more target processes 113 .
- agent 114 may inject a Javascript engine (e.g, a Google® V8 engine or a Duktape engine, for example) into the new thread 115 .
- Monitoring thread 115 may run one or more of the monitoring scripts 124 provided by agent 114 , in accordance with the instructions received from, for example, monitoring processes 122 .
- monitoring scripts 124 may be Javascript scripts that are interpreted and executed by the injected Javascript engine.
- Thread 115 may receive monitoring scripts 124 stored in collector server 120 at runtime, as well as updates and modifications to the scripts, from agent 114 which communicates with collector processes 122 via a suitable communications channel (e.g., SSH tunnel). In this manner, monitoring processes 122 may load monitoring scripts 124 into thread 115 by communicating with agent 114 via the communications channel. New or updated monitoring scripts 124 may be loaded in real-time without the need to restart the target processes
- Collector server 120 may in turn communicate with a monitoring server 130 via network 150 .
- Monitoring server may include a controller 132 , database 134 , and monitoring portal 136 .
- Controller 132 communicates with collector server 120 and provides instructions for configuring the monitoring processes 122 and agents 114 and/or updating the monitoring scripts 124 that will be run inside the process(es) thread(s).
- Database 134 may receive and store data collected by agent 114 via the monitoring processes 122 running on collector server 120 .
- Monitoring portal 136 may retrieve the data from database 134 and prepare it for presentation at an end-user device 140 .
- database 134 may be hosted in monitoring server 130 , in a separate system external to monitoring server 130 , or any combination of both.
- Monitoring portal 136 may generate any suitable application performance monitoring system user interface for display in an end-user device 140 .
- the user interface may provide for controlling data collected, visualizing data, receiving events, and sending alerts, among other functions.
- Network 150 may be any communications network or combination of networks suitable for transmitting data between computing devices, such as, by way of example, a Local Area Network (LAN), a Wide Area Network (WAN), Metropolitan Area Network (MAN), Personal Area Network (PAN), the Internet, wireless networks, satellite networks, overlay networks, or any combination thereof. While some embodiments described herein are described within the context of a networked system, it should be understood this disclosure contemplates the any combination of networked or non-networked system. For example, all modules, servers, and processes described herein may run in a single computing system.
- LAN Local Area Network
- WAN Wide Area Network
- MAN Metropolitan Area Network
- PAN Personal Area Network
- End-user device 140 may be any computing device with software suitable for user interface interaction, such as, by way of example, a personal computer, mobile computer, laptop computer, mobile phone, smartphone, personal digital assistant, tablet computer, etc.
- the user interface may be displayed in any suitable software, such as, by way of example, a standalone application, a web interface, a console interface, etc.
- Servers 110 , 120 , and 130 may be any computing device or combination of devices suitable to provide server services, such as, by way of example, server computers, personal computers, database systems, storage area networks, web servers, application servers, etc., or any combination thereof.
- FIG. 2 shows a diagram describing the flow of data in monitoring environment 100 , according to an example embodiment.
- the agent 114 attaches to target process 113 and uses a software engine started in thread 115 to run monitoring script(s) 124 .
- the software engine is a runnable component capable of interpreting the monitoring APIs.
- the engine provides native access to low-level computer architecture.
- the monitoring scripts may be in low-level languages such as C/C++ or higher level languages (such as Javascript), and because the monitoring scripts are running in a thread inside the target process, the scripts have access to low-level computer constructs, such as memory locations, execution stack, registers, threads, and to hook functions and call native application and system functions.
- the agent may create a monitoring thread 115 to be run within target process 113 that injects a Javascript engine (a Google® V8 engine or a Duktape engine, for example) into the thread.
- a Javascript engine a Google® V8 engine or a Duktape engine, for example
- monitoring thread 115 may run Javascript monitoring scripts 124 that are interpreted and executed by the Javascript engine.
- the monitoring scripts 124 may in this manner have full access to inspect memory, threads, and registers, and to hook functions and call native application and system functions from inside process 113 .
- the thread has access to create trampolines, as described below.
- Agent 114 may use various techniques to obtain transactional monitoring information from target processes 113 .
- agent 114 uses an interception approach.
- Monitoring scripts 124 running in thread 115 may reference one or more functions used by target process 113 .
- Agent 114 may receive instructions specifying which monitoring scripts 124 to be loaded.
- the monitoring scripts 124 define which functions and what data from the functions to monitor.
- Agent 114 and/or thread 115 obtain the memory address of the functions to be monitored.
- Thread 115 then generates a trampoline for calling a monitoring interceptor code (specified for that function within the scripts 124 ) at certain points in the function's execution by substituting (for example) the first or last instruction in the targeted function for an instruction that calls the monitoring interceptor code within a monitoring script 124 .
- the interceptor code updates stacks and registers to pre-interception status prior to returning execution back to the target function.
- FIG. 3A shows a set of instructions illustrating how a thread 115 may create a trampoline to a monitoring function, according to an example embodiment.
- a target process 113 may at some point in execution call a function called “decrypt_frame.”
- Monitoring scripts 124 specifying this function may have been inserted into thread 115 by agent 114 per instructions sent from monitoring collector 120 .
- Thread 115 may thus substitute the first instruction in the function “decrypt_frame” for a trampoline instruction, as shown by instruction “jmp trampoline,” which transfers execution to the block labeled “trampoline.”
- instruction “jmp trampoline” which transfers execution to the block labeled “trampoline.”
- the trampoline function may then save the state of the stack and registers and call monitoring interceptor code within the monitoring script 124 (e.g., Javascript script) that may perform the desired monitoring for the monitoring system.
- the script 124 may record the time the “decrypt_frame” instruction was called, the value of input arguments received by the function, and any other data relevant to monitor the state or performance of the application.
- the information to be monitored may ultimately be configured by the rest of the monitoring system based on end-user instructions.
- the trampoline restores the registers to the original values before the trampoline call.
- Thread 115 may insert a trampoline in this manner at any point in execution, not just at the beginning of a function.
- thread 115 may replace the return instruction of a function with trampoline that may collect, for example, the time the function ended and the return values. In this manner, thread 115 may collect the execution time of a function based on the time the function started and ended, and thus allow monitors to assess the performance of the function and process.
- Agent 114 may communicate via a bi-directional communication channels with monitor communication processes 122 and monitoring scripts 124 running on threads 115 .
- the communication channels may be an SSH tunnels, thus maintaining security of sensitive target application data.
- Agent 114 may transmit the data collected by monitoring scripts 124 , and receive configuration and instructions for what functions to monitor, what data to collect, and at what points in the functions to collect the data.
- monitoring scripts 124 may directly find function pointers to a specific application functions of target process 113 and execute them.
- the scripts may retrieve data or results from the function's execution and store and/or transmit the data, e.g., for monitoring purposes.
- agent 114 may communicate the function execution data to collector 120 .
- the interception approach has numerous benefits. For example, it does not require access to the target application source code nor root/administrator level permissions.
- the approach allows monitoring to be enabled/disabled and modified in real-time without the need to restart the application. As implemented/optimized, it has minimal performance or system impact, and does not require source code instrumentation, modification, or compilation.
- this approach can be used on applications that block third-party library preloads and/or do not utilize shared resources, and thus allows transactional monitoring of these applications. It can monitor both application and system functions as well as both static or non-static functions.
- this approach works for compiled native processes (coded in C, C++, etc.) as well as interpreted processes (coded in Java, Node.js, etc.)
- agent 114 uses an embedded approach for monitoring, as mentioned earlier.
- the target process 112 is modified by embedding a library into the code through suitable means, such as, for example, source code modification, patching, or preloading.
- agent 114 is then loaded into and run in a separate new thread within target process 113 , as opposed to a new process.
- agent 114 may be embedded into the process. This loading is performed after the dynamic linker executes its constructor.
- the agent 114 then creates the thread 115 , which then directly communicates with monitoring communication processes in collector 120 , for example, via an SSH tunnel.
- the embedded approach also provides the option of storing the monitoring scripts 124 directly on the target system (as shown by dashed box 124 in FIG. 1 ) for autonomous application by the embedded agent. Modifications to these stored monitoring scripts 124 can be applied in real-time to running processes.
- the embedded approach may be useful in scenarios when access to source code, patch, or pre-loading is available.
- agent 114 uses a stalker approach for monitoring.
- the stalker approach may be useful in scenarios where the target application has strict in-app self-checking and the previously described approaches may not work.
- an agent intercepts function calls in target process 113 and splits them into basic blocks.
- a basic block is a straight-line code sequence with no branches-in except to the entry and no branches-out except at the exit. This restricted form makes a basic block highly amenable to analysis. Compilers usually decompose programs into their basic blocks as a first step in the analysis process.
- FIG. 3B shows a set of instructions illustrating the stalker approach adds instrumentation to target functions, according to an example embodiment.
- Each instruction is wrapped in instrumentation and a call back to stalker monitoring functions is made at every block transition.
- Stalker agent 114 incrementally rewrites basic blocks, adding instrumentation and the call back into monitoring functions at every basic block transition.
- This approach there is no stack modification, no register modification, and can be used in cases where the application code is self-modifying and self-checking (e.g., with checksums).
- the system can specify which functions are followed (as opposed to whole-program dynamic binary instrumentation alternatives) and can also add custom updates and synchronous callbacks through the use of the software engine (e.g., Javascript engine).
- the software engine e.g., Javascript engine
- the stalker approach has numerous benefits. As with the interception approach, it does not require access to the target application source code nor root/administrator level permissions. The approach allows monitoring to be enabled/disabled and modified in real-time without the need to restart the application. As implemented/optimized, it has minimal performance or system impact, and does not require source code instrumentation, modification, or compilation. Furthermore, this approach can be used on applications that block third-party library preloads and/or do not utilize shared resources, and thus allows transactional monitoring of these applications. It can monitor both application and system functions as well as both static or non-static functions. Finally, this approach works for compiled native processes (coded in C, C++, etc.) as well as interpreted processes (coded in Java, Node.js, etc.)
- FIG. 4 illustrates an example computer system 400 .
- one or more computer systems 400 perform one or more steps of one or more methods described or illustrated herein.
- one or more computer systems 400 provide functionality described or illustrated herein.
- software running on one or more computer systems 400 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein.
- Particular embodiments include one or more portions of one or more computer systems 400 .
- reference to a computer system may encompass a computing device, and vice versa, where appropriate.
- reference to a computer system may encompass one or more computer systems, where appropriate.
- computer system 400 may be an embedded computer system, a desktop computer system, a laptop or notebook computer system, a mainframe, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these.
- computer system 400 may include one or more computer systems 400 ; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks.
- one or more computer systems 400 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein.
- one or more computer systems 400 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein.
- One or more computer systems 400 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.
- computer system 400 includes a processor 402 , memory 404 , storage 406 , an input/output (I/O) interface 408 , a communication interface 410 , and a bus 412 .
- I/O input/output
- this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.
- processor 402 includes hardware for executing instructions, such as those making up a computer program.
- processor 402 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 404 , or storage 406 ; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 404 , or storage 406 .
- processor 402 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal caches, where appropriate.
- processor 402 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal registers, where appropriate.
- processor 402 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 402 .
- ALUs arithmetic logic units
- memory 404 includes main memory for storing instructions for processor 402 to execute or data for processor 402 to operate on.
- computer system 400 may load instructions from storage 406 or another source (such as, for example, another computer system 400 ) to memory 404 .
- Processor 402 may then load the instructions from memory 404 , execute the instructions, write one or more results to memory 404 .
- memory 404 includes volatile memory, such as random access memory (RAM).
- storage 406 includes mass storage for data or instructions.
- storage 406 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these.
- Storage 406 may include removable or non-removable (or fixed) media, where appropriate.
- Storage 406 may be internal or external to computer system 400 , where appropriate.
- storage 406 is non-volatile, solid-state memory.
- storage 406 includes read-only memory (ROM).
- this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these.
- I/O interface 408 includes hardware, software, or both, providing one or more interfaces for communication between computer system 400 and one or more I/O devices.
- Computer system 400 may include one or more of these I/O devices, where appropriate.
- One or more of these I/O devices may enable communication between a person and computer system 400 .
- an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these.
- communication interface 410 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 400 and one or more other computer systems 400 or one or more networks.
- communication interface 410 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network.
- NIC network interface controller
- WNIC wireless NIC
- WI-FI network wireless network
- computer system 400 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these.
- PAN personal area network
- LAN local area network
- WAN wide area network
- MAN metropolitan area network
- One or more portions of one or more of these networks may be wired or wireless.
- bus 412 includes hardware, software, or both coupling components of computer system 400 to each other.
- bus 412 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these.
- Bus 412 may include one or more buses 412 , where appropriate.
- a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate.
- ICs such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)
- HDDs hard disk drives
- HHDs hybrid hard drives
- ODDs optical disc drives
- magneto-optical discs magneto-optical drives
- computer system 400 may be configured to run an operating system software.
- An operating system manages computer system hardware and software resources and provides common services for computer programs. Modern operating systems are multi-tasking operating systems, which allow more than one program to run concurrently.
- the operating system may use time-sharing of available processor time by dividing the time between multiple processes.
- a process is an instance of a computer program that is being executed, containing the program code and its current activity. These processes are each interrupted repeatedly in time slices by a task-scheduling subsystem of the operating system.
- the operating system also allows the implementation of multiple threads of execution running within a process.
- a thread of execution (or simply a thread) is a smaller sequence of programmed instructions that is managed by a scheduling subsystem, and forms a component of a process.
- multiple threads can exist within one process and share resources such as memory, while different processes may not share these resources.
- the threads of a process may share its executable code and the values of its variables at any given time.
- references herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein.
Abstract
Description
- This application claims priority from U.S. Provisional Application 62/656,308 filed on 11 Apr. 2018, which is hereby incorporated by reference in its entirety for all purposes.
- Embodiments generally relate to software monitoring, and in particular to systems and methods for performing deep transactional monitoring of running applications in production usage.
- Software application performance management (APM) is the monitoring and management of the performance and availability of software applications. APM is a crucial part of ensuring software reliability, allowing fast diagnosis and recovery from runtime failures. APM software can be designed to detect and diagnose performance problems in a target application, with the goal of maintaining an expected level of service by the application.
- Any set of performance metrics can be monitored by an APM system. One common set of metrics describes the performance experienced by end users of an application, for example, average response times under peak load. Another common set of metrics measures the computational resources used by the application for a particular load, for example, CPU and memory usage. Computational resource measurements can help discover performance bottlenecks, detect changes in performance, and predict future changes in application performance.
- One variant of APM is known as real user monitoring (RUM), which involves passively recording user interaction with an application or client interacting with a server or cloud-based application. Monitoring actual user interaction with a website or an application is important to operators to determine if users are being served quickly and without errors and, if not, which part of a business process is failing. Real user monitoring data is used to determine the actual service-level quality and transactional integrity delivered to end-users and to detect errors or slowdowns on application. The data may also be used to determine if changes that are promulgated to application have the intended effect or cause errors.
- One variant of RUM is known as business transaction monitoring (BTM), which provides tools for tracking the flow of transactions across IT infrastructure and code-level drill-down into defined portions of the transactions, in addition to detection, alerting, and correction of unexpected changes in business or technical conditions. BTM provides visibility into the flow of transactions across infrastructure tiers, including a dynamic mapping of the application topology and deep code-level drill-down in defined portions of the transactions. BTM may allow searching for transactions based on context and content—for instance, user performing the transaction, time and code context of execution of functions, web requests, or web services, input arguments and return values, and system component executing the transaction,—providing a way to isolate causes for issues such as application exceptions, stalled transactions, and lower-level issues such as incorrect data values.
- In general, performing APM can be a complicated process that involves many technical challenges. Among them, APM has a performance cost, which can range from minor and negligible to extremely high impact and only suitable for development and non-production environments. Certain methods involve modifying the target application source code and recompiling, but this generally requires suspending and restarting the application. Some APM software may also need access to system resources that may be protected from reading or writing by security measures, for example, requiring administrator/root access. Other applications may block third-party library preloads, further complicating the options to access application data for methods that require modification of system libraries or system preload directives. Many known methods only work on interpreted processes (e.g., coded in Java, Node.js, etc.) but will not work on compiled native processes (e.g., coded in C, C++, etc.). Others depend on frameworks such as .NET or J2EE or profiling APIs such as provided for Java and .NET.
- The accompanying drawings are incorporated herein and form a part of the specification.
-
FIG. 1 illustrates a target application monitoring environment, according to an example embodiment. -
FIG. 2 shows a diagram describing the flow of data in monitoring environment, according to an example embodiment. -
FIG. 3A shows a set of instructions illustrating how a thread may create a trampoline to a monitoring function, according to an example embodiment. -
FIG. 3B shows a set of instructions illustrating the stalker approach adds instrumentation to target functions, according to an example embodiment. -
FIG. 4 is an example computer system useful for implementing various embodiments. - Provided herein are system, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for providing dynamically-updatable deep transactional monitoring of running applications in real-time.
-
FIG. 1 illustrates a targetapplication monitoring environment 100, according to an example embodiment. Atarget application 112 runs on a software environment (e.g., an operating system) running on atarget server 110. The target application may be any application, such as, by way of example, back end application providing services over a network. In particular embodiments,target application 112 is an application developed in native compiled code (e.g., C/C++). Target application may also be a hosted application or a SaaS application running on a host provider. One ormore agents 114 also runs ontarget server 110, and in particular embodiments, anagent 114 follows an injection approach where it runs as a separate process withintarget server 110. In another embodiment, theagent 114 follows an embedded approach where it runs inside one ormore target processes 113.Agent 114 is configured to collect data from one ormore target processes 113 in real-time and transmit the data to monitoring applications. Target application may have one or more agents performing application monitoring. -
Agent 114 communicates with acollector server 120 via anetwork 150.Collector server 120 may run one ormore monitoring processes 122 and store one ormore monitoring scripts 124.Processes 122 incollector server 120 may be configured to receive monitoring data fromagent 114 and control the agent's behavior. For example,agent 114 may receive instructions on what data to collect fromtarget process 113 and how often to collect it. - In particular embodiments following an injection approach,
agent 114 creates anew monitoring thread 115 within one ormore target processes 113. In an example,agent 114 may inject a Javascript engine (e.g, a Google® V8 engine or a Duktape engine, for example) into thenew thread 115.Monitoring thread 115 may run one or more of themonitoring scripts 124 provided byagent 114, in accordance with the instructions received from, for example,monitoring processes 122. In an example,monitoring scripts 124 may be Javascript scripts that are interpreted and executed by the injected Javascript engine.Thread 115 may receivemonitoring scripts 124 stored incollector server 120 at runtime, as well as updates and modifications to the scripts, fromagent 114 which communicates withcollector processes 122 via a suitable communications channel (e.g., SSH tunnel). In this manner,monitoring processes 122 may loadmonitoring scripts 124 intothread 115 by communicating withagent 114 via the communications channel. New or updatedmonitoring scripts 124 may be loaded in real-time without the need to restart the target processes -
Collector server 120 may in turn communicate with amonitoring server 130 vianetwork 150. Monitoring server may include acontroller 132,database 134, andmonitoring portal 136.Controller 132 communicates withcollector server 120 and provides instructions for configuring themonitoring processes 122 andagents 114 and/or updating themonitoring scripts 124 that will be run inside the process(es) thread(s).Database 134 may receive and store data collected byagent 114 via themonitoring processes 122 running oncollector server 120.Monitoring portal 136 may retrieve the data fromdatabase 134 and prepare it for presentation at an end-user device 140. In particular embodiments,database 134 may be hosted inmonitoring server 130, in a separate system external to monitoringserver 130, or any combination of both.Monitoring portal 136 may generate any suitable application performance monitoring system user interface for display in an end-user device 140. The user interface may provide for controlling data collected, visualizing data, receiving events, and sending alerts, among other functions. - Network 150 may be any communications network or combination of networks suitable for transmitting data between computing devices, such as, by way of example, a Local Area Network (LAN), a Wide Area Network (WAN), Metropolitan Area Network (MAN), Personal Area Network (PAN), the Internet, wireless networks, satellite networks, overlay networks, or any combination thereof. While some embodiments described herein are described within the context of a networked system, it should be understood this disclosure contemplates the any combination of networked or non-networked system. For example, all modules, servers, and processes described herein may run in a single computing system.
- End-
user device 140 may be any computing device with software suitable for user interface interaction, such as, by way of example, a personal computer, mobile computer, laptop computer, mobile phone, smartphone, personal digital assistant, tablet computer, etc. The user interface may be displayed in any suitable software, such as, by way of example, a standalone application, a web interface, a console interface, etc.Servers -
FIG. 2 shows a diagram describing the flow of data inmonitoring environment 100, according to an example embodiment. In particular embodiments, theagent 114 attaches to targetprocess 113 and uses a software engine started inthread 115 to run monitoring script(s) 124. The software engine is a runnable component capable of interpreting the monitoring APIs. The engine provides native access to low-level computer architecture. The monitoring scripts may be in low-level languages such as C/C++ or higher level languages (such as Javascript), and because the monitoring scripts are running in a thread inside the target process, the scripts have access to low-level computer constructs, such as memory locations, execution stack, registers, threads, and to hook functions and call native application and system functions. As an example, the agent may create amonitoring thread 115 to be run withintarget process 113 that injects a Javascript engine (a Google® V8 engine or a Duktape engine, for example) into the thread. In this example,monitoring thread 115 may runJavascript monitoring scripts 124 that are interpreted and executed by the Javascript engine. Themonitoring scripts 124 may in this manner have full access to inspect memory, threads, and registers, and to hook functions and call native application and system functions frominside process 113. By attaching to theprocess 113 and starting a thread (or, in another embodiment using an embedded approach, being preloaded into the application), the thread has access to create trampolines, as described below. -
Agent 114 may use various techniques to obtain transactional monitoring information from target processes 113. In particular embodiments,agent 114 uses an interception approach. Monitoringscripts 124 running inthread 115 may reference one or more functions used bytarget process 113.Agent 114 may receive instructions specifying whichmonitoring scripts 124 to be loaded. Themonitoring scripts 124 define which functions and what data from the functions to monitor.Agent 114 and/orthread 115 obtain the memory address of the functions to be monitored.Thread 115 then generates a trampoline for calling a monitoring interceptor code (specified for that function within the scripts 124) at certain points in the function's execution by substituting (for example) the first or last instruction in the targeted function for an instruction that calls the monitoring interceptor code within amonitoring script 124. In this embodiment, the interceptor code updates stacks and registers to pre-interception status prior to returning execution back to the target function. -
FIG. 3A shows a set of instructions illustrating how athread 115 may create a trampoline to a monitoring function, according to an example embodiment. Atarget process 113 may at some point in execution call a function called “decrypt_frame.” Monitoringscripts 124 specifying this function may have been inserted intothread 115 byagent 114 per instructions sent from monitoringcollector 120.Thread 115 may thus substitute the first instruction in the function “decrypt_frame” for a trampoline instruction, as shown by instruction “jmp trampoline,” which transfers execution to the block labeled “trampoline.” Thus, each time the function “decrypt_frame” is called, the execution runs into the trampoline. The trampoline function may then save the state of the stack and registers and call monitoring interceptor code within the monitoring script 124 (e.g., Javascript script) that may perform the desired monitoring for the monitoring system. For example, thescript 124 may record the time the “decrypt_frame” instruction was called, the value of input arguments received by the function, and any other data relevant to monitor the state or performance of the application. The information to be monitored may ultimately be configured by the rest of the monitoring system based on end-user instructions. Once the monitoring data has been stored or sent, the trampoline restores the registers to the original values before the trampoline call.Thread 115 may insert a trampoline in this manner at any point in execution, not just at the beginning of a function. As an example,thread 115 may replace the return instruction of a function with trampoline that may collect, for example, the time the function ended and the return values. In this manner,thread 115 may collect the execution time of a function based on the time the function started and ended, and thus allow monitors to assess the performance of the function and process. -
Agent 114 may communicate via a bi-directional communication channels withmonitor communication processes 122 andmonitoring scripts 124 running onthreads 115. As an example, the communication channels may be an SSH tunnels, thus maintaining security of sensitive target application data.Agent 114 may transmit the data collected by monitoringscripts 124, and receive configuration and instructions for what functions to monitor, what data to collect, and at what points in the functions to collect the data. - In particular embodiments, monitoring
scripts 124 may directly find function pointers to a specific application functions oftarget process 113 and execute them. The scripts may retrieve data or results from the function's execution and store and/or transmit the data, e.g., for monitoring purposes. As an example,agent 114 may communicate the function execution data tocollector 120. - The interception approach has numerous benefits. For example, it does not require access to the target application source code nor root/administrator level permissions. The approach allows monitoring to be enabled/disabled and modified in real-time without the need to restart the application. As implemented/optimized, it has minimal performance or system impact, and does not require source code instrumentation, modification, or compilation. Furthermore, this approach can be used on applications that block third-party library preloads and/or do not utilize shared resources, and thus allows transactional monitoring of these applications. It can monitor both application and system functions as well as both static or non-static functions. Finally, this approach works for compiled native processes (coded in C, C++, etc.) as well as interpreted processes (coded in Java, Node.js, etc.)
- In particular embodiments,
agent 114 uses an embedded approach for monitoring, as mentioned earlier. In this scenario, thetarget process 112 is modified by embedding a library into the code through suitable means, such as, for example, source code modification, patching, or preloading. In particular embodiments,agent 114 is then loaded into and run in a separate new thread withintarget process 113, as opposed to a new process. In other embodiments,agent 114 may be embedded into the process. This loading is performed after the dynamic linker executes its constructor. Theagent 114 then creates thethread 115, which then directly communicates with monitoring communication processes incollector 120, for example, via an SSH tunnel. The embedded approach also provides the option of storing themonitoring scripts 124 directly on the target system (as shown by dashedbox 124 inFIG. 1 ) for autonomous application by the embedded agent. Modifications to these storedmonitoring scripts 124 can be applied in real-time to running processes. The embedded approach may be useful in scenarios when access to source code, patch, or pre-loading is available. - In particular embodiments,
agent 114 uses a stalker approach for monitoring. The stalker approach may be useful in scenarios where the target application has strict in-app self-checking and the previously described approaches may not work. In the stalker approach, an agent intercepts function calls intarget process 113 and splits them into basic blocks. A basic block is a straight-line code sequence with no branches-in except to the entry and no branches-out except at the exit. This restricted form makes a basic block highly amenable to analysis. Compilers usually decompose programs into their basic blocks as a first step in the analysis process. -
FIG. 3B shows a set of instructions illustrating the stalker approach adds instrumentation to target functions, according to an example embodiment. Each instruction is wrapped in instrumentation and a call back to stalker monitoring functions is made at every block transition.Stalker agent 114 incrementally rewrites basic blocks, adding instrumentation and the call back into monitoring functions at every basic block transition. By using this approach there is no stack modification, no register modification, and can be used in cases where the application code is self-modifying and self-checking (e.g., with checksums). The system can specify which functions are followed (as opposed to whole-program dynamic binary instrumentation alternatives) and can also add custom updates and synchronous callbacks through the use of the software engine (e.g., Javascript engine). - The stalker approach has numerous benefits. As with the interception approach, it does not require access to the target application source code nor root/administrator level permissions. The approach allows monitoring to be enabled/disabled and modified in real-time without the need to restart the application. As implemented/optimized, it has minimal performance or system impact, and does not require source code instrumentation, modification, or compilation. Furthermore, this approach can be used on applications that block third-party library preloads and/or do not utilize shared resources, and thus allows transactional monitoring of these applications. It can monitor both application and system functions as well as both static or non-static functions. Finally, this approach works for compiled native processes (coded in C, C++, etc.) as well as interpreted processes (coded in Java, Node.js, etc.)
-
FIG. 4 illustrates anexample computer system 400. In particular embodiments, one ormore computer systems 400 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one ormore computer systems 400 provide functionality described or illustrated herein. In particular embodiments, software running on one ormore computer systems 400 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one ormore computer systems 400. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate. - This disclosure contemplates any suitable number of
computer systems 400. This disclosure contemplatescomputer system 400 taking any suitable physical form. As example,computer system 400 may be an embedded computer system, a desktop computer system, a laptop or notebook computer system, a mainframe, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate,computer system 400 may include one ormore computer systems 400; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one ormore computer systems 400 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example, one ormore computer systems 400 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One ormore computer systems 400 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate. - In particular embodiments,
computer system 400 includes aprocessor 402,memory 404,storage 406, an input/output (I/O)interface 408, acommunication interface 410, and abus 412. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement. - In particular embodiments,
processor 402 includes hardware for executing instructions, such as those making up a computer program. As an example, to execute instructions,processor 402 may retrieve (or fetch) the instructions from an internal register, an internal cache,memory 404, orstorage 406; decode and execute them; and then write one or more results to an internal register, an internal cache,memory 404, orstorage 406. In particular embodiments,processor 402 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplatesprocessor 402 including any suitable number of any suitable internal caches, where appropriate. In particular embodiments,processor 402 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplatesprocessor 402 including any suitable number of any suitable internal registers, where appropriate. Where appropriate,processor 402 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one ormore processors 402. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor. - In particular embodiments,
memory 404 includes main memory for storing instructions forprocessor 402 to execute or data forprocessor 402 to operate on. As an example,computer system 400 may load instructions fromstorage 406 or another source (such as, for example, another computer system 400) tomemory 404.Processor 402 may then load the instructions frommemory 404, execute the instructions, write one or more results tomemory 404. In particular embodiments,memory 404 includes volatile memory, such as random access memory (RAM). - In particular embodiments,
storage 406 includes mass storage for data or instructions. As an example,storage 406 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these.Storage 406 may include removable or non-removable (or fixed) media, where appropriate.Storage 406 may be internal or external tocomputer system 400, where appropriate. In particular embodiments,storage 406 is non-volatile, solid-state memory. In particular embodiments,storage 406 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. - In particular embodiments, I/
O interface 408 includes hardware, software, or both, providing one or more interfaces for communication betweencomputer system 400 and one or more I/O devices.Computer system 400 may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person andcomputer system 400. As an example, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An - In particular embodiments,
communication interface 410 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) betweencomputer system 400 and one or moreother computer systems 400 or one or more networks. As an example,communication interface 410 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and anysuitable communication interface 410 for it. As an example,computer system 400 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. - In particular embodiments,
bus 412 includes hardware, software, or both coupling components ofcomputer system 400 to each other. As an example,bus 412 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these.Bus 412 may include one ormore buses 412, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect. - Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.
- In particular embodiments,
computer system 400 may be configured to run an operating system software. An operating system manages computer system hardware and software resources and provides common services for computer programs. Modern operating systems are multi-tasking operating systems, which allow more than one program to run concurrently. The operating system may use time-sharing of available processor time by dividing the time between multiple processes. A process is an instance of a computer program that is being executed, containing the program code and its current activity. These processes are each interrupted repeatedly in time slices by a task-scheduling subsystem of the operating system. In particular embodiments, the operating system also allows the implementation of multiple threads of execution running within a process. A thread of execution (or simply a thread) is a smaller sequence of programmed instructions that is managed by a scheduling subsystem, and forms a component of a process. In general, multiple threads can exist within one process and share resources such as memory, while different processes may not share these resources. In particular, the threads of a process may share its executable code and the values of its variables at any given time. - It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections (if any), is intended to be used to interpret the claims. The Summary and Abstract sections (if any) may set forth one or more but not all exemplary embodiments of the invention as contemplated by the inventor(s), and thus, are not intended to limit the invention or the appended claims in any way.
- While the invention has been described herein with reference to exemplary embodiments for exemplary fields and applications, it should be understood that the invention is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of the invention. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.
- Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments may perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.
- References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein.
- The breadth and scope of the invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Claims (1)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/382,174 US20200233677A2 (en) | 2018-04-11 | 2019-04-11 | Dynamically-Updatable Deep Transactional Monitoring Systems and Methods |
US17/407,034 US11789752B1 (en) | 2018-04-11 | 2021-08-19 | Dynamically-updatable deep transactional monitoring systems and methods |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862656308P | 2018-04-11 | 2018-04-11 | |
US16/382,174 US20200233677A2 (en) | 2018-04-11 | 2019-04-11 | Dynamically-Updatable Deep Transactional Monitoring Systems and Methods |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/407,034 Continuation US11789752B1 (en) | 2018-04-11 | 2021-08-19 | Dynamically-updatable deep transactional monitoring systems and methods |
Publications (2)
Publication Number | Publication Date |
---|---|
US20190324771A1 US20190324771A1 (en) | 2019-10-24 |
US20200233677A2 true US20200233677A2 (en) | 2020-07-23 |
Family
ID=68236476
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/382,174 Abandoned US20200233677A2 (en) | 2018-04-11 | 2019-04-11 | Dynamically-Updatable Deep Transactional Monitoring Systems and Methods |
US17/407,034 Active US11789752B1 (en) | 2018-04-11 | 2021-08-19 | Dynamically-updatable deep transactional monitoring systems and methods |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/407,034 Active US11789752B1 (en) | 2018-04-11 | 2021-08-19 | Dynamically-updatable deep transactional monitoring systems and methods |
Country Status (1)
Country | Link |
---|---|
US (2) | US20200233677A2 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11900139B2 (en) * | 2019-11-04 | 2024-02-13 | Vmware, Inc. | Multisite service personalization hybrid workflow engine |
CN111276246B (en) * | 2020-01-16 | 2023-07-14 | 泰康保险集团股份有限公司 | Human physiological data analysis method and device based on v8 engine |
CN111538770B (en) * | 2020-04-21 | 2023-03-31 | 招商局金融科技有限公司 | Data monitoring method and device, electronic equipment and readable storage medium |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6819754B1 (en) | 2000-08-29 | 2004-11-16 | Cisco Technology, Inc. | Generation of communication system control scripts |
US6993683B2 (en) | 2002-05-10 | 2006-01-31 | Microsoft Corporation | Analysis of pipelined networks |
US8209680B1 (en) | 2003-04-11 | 2012-06-26 | Vmware, Inc. | System and method for disk imaging on diverse computers |
US9384345B2 (en) * | 2005-05-03 | 2016-07-05 | Mcafee, Inc. | Providing alternative web content based on website reputation assessment |
CN100342342C (en) * | 2005-12-14 | 2007-10-10 | 浙江大学 | Java virtual machine implementation method supporting multi-process |
US7788537B1 (en) | 2006-01-31 | 2010-08-31 | Emc Corporation | Techniques for collecting critical information from a memory dump |
US8229884B1 (en) | 2008-06-04 | 2012-07-24 | United Services Automobile Association (Usaa) | Systems and methods for monitoring multiple heterogeneous software applications |
US9928107B1 (en) * | 2012-03-30 | 2018-03-27 | Amazon Technologies, Inc. | Fast IP migration in a hybrid network environment |
GB201213072D0 (en) * | 2012-07-23 | 2012-09-05 | Design Multi Media Ltd I | A user terminal control system and method |
US9158512B1 (en) * | 2013-03-08 | 2015-10-13 | Ca, Inc. | Systems, processes and computer program products for communicating among different programming languages that are hosted on a Java Virtual Machine (JVM) |
US9231975B2 (en) * | 2013-06-27 | 2016-01-05 | Sap Se | Safe script templating to provide reliable protection against attacks |
US9195441B2 (en) * | 2013-07-30 | 2015-11-24 | Facebook, Inc. | Systems and methods for incremental compilation at runtime using relaxed guards |
US20150332043A1 (en) * | 2014-05-15 | 2015-11-19 | Auckland Uniservices Limited | Application analysis system for electronic devices |
US9727421B2 (en) * | 2015-06-24 | 2017-08-08 | Intel Corporation | Technologies for data center environment checkpointing |
US10140121B2 (en) * | 2015-07-21 | 2018-11-27 | Oracle International Corporation | Sending a command with client information to allow any remote server to communicate directly with client |
US10176329B2 (en) * | 2015-08-11 | 2019-01-08 | Symantec Corporation | Systems and methods for detecting unknown vulnerabilities in computing processes |
CN105490868B (en) | 2015-11-17 | 2019-11-01 | 世纪龙信息网络有限责任公司 | Remote room data double-way synchronous monitoring method and system |
CN105320563A (en) | 2015-12-07 | 2016-02-10 | 浪潮(北京)电子信息产业有限公司 | Process scheduling and optimization method |
US20190034246A1 (en) | 2017-07-28 | 2019-01-31 | SWFL, Inc., d/b/a "Filament" | Systems and methods for adaptive computer code processing by computing resource state-aware firmware |
US10498763B2 (en) * | 2017-08-31 | 2019-12-03 | International Business Machines Corporation | On-demand injection of software booby traps in live processes |
-
2019
- 2019-04-11 US US16/382,174 patent/US20200233677A2/en not_active Abandoned
-
2021
- 2021-08-19 US US17/407,034 patent/US11789752B1/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20190324771A1 (en) | 2019-10-24 |
US11789752B1 (en) | 2023-10-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11789752B1 (en) | Dynamically-updatable deep transactional monitoring systems and methods | |
US11720368B2 (en) | Memory management of data processing systems | |
US10482001B2 (en) | Automated dynamic test case generation | |
US11503070B2 (en) | Techniques for classifying a web page based upon functions used to render the web page | |
US8543991B2 (en) | Profile driven multicore background compilation | |
US10061682B2 (en) | Detecting race condition vulnerabilities in computer software applications | |
US9355003B2 (en) | Capturing trace information using annotated trace output | |
US8671397B2 (en) | Selective data flow analysis of bounded regions of computer software applications | |
US20180159724A1 (en) | Automatic task tracking | |
Zhao et al. | Leveraging program analysis to reduce user-perceived latency in mobile applications | |
US9442818B1 (en) | System and method for dynamic data collection | |
CN108121650B (en) | Method and device for testing page user interface | |
US9185513B1 (en) | Method and system for compilation with profiling feedback from client | |
US11055416B2 (en) | Detecting vulnerabilities in applications during execution | |
US8954932B2 (en) | Crash notification between debuggers | |
US9841960B2 (en) | Dynamic provision of debuggable program code | |
Johnson et al. | Dazed droids: A longitudinal study of android inter-app vulnerabilities | |
US9830253B2 (en) | Eliminating redundant interactions when testing computer software applications | |
CN112506781A (en) | Test monitoring method, test monitoring device, electronic device, storage medium, and program product | |
US10165074B2 (en) | Asynchronous custom exit points | |
CN111124627A (en) | Method, device, terminal and storage medium for determining application program caller | |
US11689630B2 (en) | Request processing method and apparatus, electronic device, and computer storage medium | |
Baird et al. | Automated dynamic detection of self-hiding behavior | |
Vasquez et al. | Mobile application monitoring | |
US20170104814A1 (en) | Distributed extension execution in computing systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
AS | Assignment |
Owner name: SMART ENTERPRISES, INC., COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DAWSON, PHYLLIS;REEL/FRAME:053303/0527 Effective date: 20200723 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: TECH HEIGHTS LLC, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMART ENTERPRISES, INC.;REEL/FRAME:064817/0442 Effective date: 20230906 |