InterceptFramework of middleware enhancement framework


This time we will bring you the last article on the topic of middleware enhancement framework (MOF), explaining the InterceptFramework framework in MOF. The framework can obtain portrait information during application startup, and realize the collection and storage of application portrait data.


In intelligent operation and maintenance, relevant information such as components and JAR packages used by application services are very important. These information can clearly depict the skeleton of an application service, which we call application portrait. In UAVStack, InterceptFramework under Middleware Enhancement Framework (MOF) can obtain portrait information during application startup. This paper mainly introduces the framework principle of InterceptFramework and the application portrait data collection and storage based on it.

Overall structure


Key technology



Key classes and functions

Profile data and client monitoring indicators are mainly captured and monitored through InterceptSupport and hookProxy mechanisms.

Profile is also installed to DataObserver object and exposes JMX/HTTP interface.

Preparations before interception

1. Rewrite bytecode in the specific life cycle of application startup and implant specific logic processing code to intercept.

2. The Supporter corresponding to the interception framework starts, obtains the Listener to be loaded from the configuration file, constructs the InterceptSupport instance, and adds the Listener to the InterceptSupport instance.

Specific interception logic

During a specific life cycle in the application startup process, the previously implanted code interception logic starts to execute the doIntercept method of InterceptSupport and traverses the registered Listener. Each listener inherits from the InterceptEventListener class. Different sub-Listener collect and process corresponding types of portraits: AppProfilingListener is responsible for monitoring all service portrait events, and AppFrkHookFactoryListener is responsible for monitoring client portrait events.

Architecture description

  • InterceptSupport: single case as unified Profile/Client hook capture entry point
  • InterceptContext: capture Context interface, all capture parameters are encapsulated by context
  • InterceptEventListener: Event hijack listener, all listeners need to inherit and register listening
  • AppProfilingListener: Service Portrait Listener, which listens to all service portrait events
  • AppFrkHookFactoryListener: Client Portrait Monitoring Agent

Key class description

  • StandardProfile: Implements the Profile interface, is the portrait data capture implementation class, and provides doProfiling method to be responsible for capture behavior and generate capture results.
  • ProfileHandler: Common Interface of Different Grabbing Logic and Grabbing Points to Realize Different Grabbing Logic; DoProfiling method for grasping behavior is provided.
  • StandardProfileRepository: Stores the image data capture data structure;
  • DataObserver: exposed JMX/HTTP interface data;
  • Profile real-time monitoring installs Profile objects into DataObserver objects when startProfiling is called from AppProfilingListener class;
  • DataObserver provides JMX/Http service for subsequent retrieval, of which HTTP service is registered with HttpJEEProfileObserver and is mainly responsible for retrieving portrait data.

Each Handler class specifically processes all kinds of captured data.

Portrait data

Portrait data is static data, which can be obtained when the process is started, including information related to the operating system, program and initialization information after the program is started.


Portrait data mainly includes service portrait, traceability perception portrait and client portrait, as shown in the above figure. The following are three aspects of portrait collection:

Service portrait collection


The service portrait describes the information of the service ontology, including application unique identification (AppID), service name (Service ID), URI of service instance, URI of service interface, metadata of service interface (class, method, input and output parameters, annotation, deployment descriptor).

Taking Tomcat as an example, the start process of the application needs to go through the StandardContext start method. We can embed code logic at the end of this method to intercept, and the following information can be obtained through interception:

Container context information such as application name, webworkdir (working directory), servletcontext, contextpath, basepath (application actual path);

According to the corresponding technical specifications (Servlet, JAXRS, JAXWS, Spring, etc.) to obtain the portrait data, mainly including: obtaining the class and method names, as well as the input and output parameter information, scanning the annotation class, obtaining the annotation information, parsing the deployment descriptor file (web.xml, etc.) information by reflection.

In addition to the above information, the service portrait also obtains information such as the log path of the application and JAR packages used.

Tracing Image Collection


Tracing portrait collection mainly uses the fields in HTTP Header to trace the source, and intercepts StandardEngineValve’s Invoke method in Tomcat through middleware hijacking technology to obtain tracing data.

The data collected are as follows:

  • Client Address: directly connected clientip address;
  • X-Forwarded-For: if it exists, it is a proxy routing address chain, and directly connected clients are proxy services;
  • Host: Indicates the remote Host and even port information. If the directly connected client is a proxy service, HOST is the proxy IP address and port;
  • User-Agent: Agent description, which can be used to distinguish between browser and program client, and can also extract a lot of browser terminal information;
  • UAV-client-src: http client hijacks the Header field added for fitting calls between UAV applications.

Client portrait collection


The client portrait is realized by hijacking a series of common middleware clients. Currently, it supports synchronous/asynchronous http, database jdbc, redis(jedis,aredis,lettuce), mongodb, rocketmq/rabbitmq/Kafka, ESClient, etc.

Hijacking uses AOP technologies such as javaassist bytecode rewriting and dynamic proxy to embed specific processing logic in client call codes to obtain call-related information, such as call address, call protocol, call result, etc.

The portrait data determines the target service based on the call address, access protocol and feature extraction of the call result.

Call Address: Expressed in Class URI Format

Http/https service (business/proxy service):http://

Relational Database (Data Source Service): jdbc:

Non-relational database or cache (data source service):

Message Queuing (Message Service): mq:

Access Protocol: An access action. For example, HTTP POST, SQL insert, send/subscribe message, Redis hgethashall, Mongo Collection operation, etc.

The characteristics of access results: the basic stack type of the service and whether it is clustered, such as Nginx, Tomcat, Apache, etc.

Taking ESClient as an example, we can hijack the sendRequest method of TransportService and implant our interception code logic.

Different from the service portrait, the client portrait occurs in the specific client call process, not in the start-up phase of the application.

Picture storage structure

Portrait storage is hierarchically stored according to the following structure:

StandardProfileRespository stores the entire portrait of an application;

StandardProfileElement stores some component portraits (server, client, log, jar, etc.);

ProfileElementInstance stores a component portrait of a type of component. Take service component portrait as an example. For example, components JAXRS and Servlets are each a ProfileElementInstance, but they both belong to the StandardProfileElement of service component.


DataObserver provides JMX and HTTP modes to expose interface portrait data, which is similar to real-time data and has been described in detail in our brother MOF series “CaptureFramework for Middleware Plus Framework” and will not be repeated here.

Author: Li Xingsheng

Yixin Institute of Technology