Today we will discuss the observability part of the code that we skipped before. I would like to briefly explain here that at that time this part of the code was a fixed template that had to be written, so we skipped it in the initial discussion. Although this part of the code may appear complex at first glance, in fact its core function is just the implementation of link tracking. In this case, we will not go into details next and look directly at this part of the key code, as shown in the figure:
Our purpose today is also very clear, that is, we don’t have to worry too much about how the underlying source code operates and is injected and parsed. What we are more concerned about is the actual role this code plays in the Spring AI framework.
micrometer
If you clicked on the reference at that time, you could find the package dependency information related to it. If you want to get more detailed information, it is recommended to visit its official documentation. For details, please see:/micrometer/reference/
JMX observations
In order to understand the specific working principle of micrometer more clearly, today we will use two practical examples to lead you to quickly understand how it works. The first example is about a tool that many Java programming developers are very familiar with - jconsole. If you are not familiar with this tool, don’t worry. You can go directly to the bin directory of jdk to search. The specific location is as shown in the figure.
All that remains is to add relevant dependencies to the project dependencies of our demo chat example. The code is as follows:
<groupId></groupId>
<artifactId>micrometer-observation</artifactId>
</dependency>
<dependency>
<groupId></groupId>
<artifactId>micrometer-registry-jmx</artifactId>
</dependency>
We basically don't need to modify the remaining parts. Next, just double-click to launchjconsoletool and connect to our local program. Then, entering the MBean tab, we can easily view the relevant configuration information and monitoring data. However, it is important to note that this information is concise and not comprehensive. The specific situation can be seen in the figure below:
Here, we do not see that the specific keys added in the source code are included in the observation scope. As shown below:
So currently, distributed link tracking is widely used in system monitoring and performance tuning. For ease of demonstration, we simply demonstrate the basic functions of the lightweight Zipkin for link tracing observations. Of course, in addition to Zipkin, you can also choose to use other tools, such as the combination of Prometheus and Grafana, or more comprehensive solutions such as SkyWalking
zipkin observation
Here I'm going to run it directly on the server using a Docker container. Please ensure that when starting the container, the relevant ports are exposed so that our demo program can communicate with the container and upload information through these ports. The following are the specific commands:
docker run --name zipkin -d -p 9411:9411 openzipkin/zipkin
Then you need to add some dependencies, as shown below:
<dependency>
<groupId></groupId>
<artifactId>micrometer-observation</artifactId>
</dependency>
<dependency>
<groupId></groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
<groupId>.reporter2</groupId>
<artifactId>zipkin-reporter-brave</artifactId>
</dependency>
<dependency>
<groupId></groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
Since Zipkin needs to configure some key project information during use, such as specifying our Zipkin server address, as well as other related service endpoints and connection parameters, this necessary information needs to be added to the configuration file. The specific project information configuration is as follows:
=*
-details=always
=http://ip:9411/api/v2/spans
=1.0
After starting our project normally, we can perform an interface call and directly access Zipkin to view the interface call status at that time. In this way, you will be able to clearly observe the observability information related to the interface call, including all keys and values. The specific results are shown in the figure:
You can just read this part without doing any important analysis.
Summarize
Through today's discussion, we briefly explored the observability part of the code and its actual role in the Spring AI framework. Although the underlying implementation may appear complex, its core function is nothing more than the implementation of link tracking, helping us better understand and optimize system performance. Through practical examples, we demonstrate how to use tools such as jconsole and Zipkin to observe system behavior and performance indicators. The use of these tools can provide clear monitoring data and help developers conduct system diagnosis and performance tuning more effectively. In future work, proper use of these tools will greatly improve our observability practices.
I am Xiaoyu, a diligent Java server developer in Northeast China. I have been pondering the mysteries of AI technology all day long. I especially like to communicate with people about technology and share my experiences with everyone. He has also become a Tencent Cloud Creative Star, an Alibaba Cloud Expert Blogger, a Huawei Cloud Cloud Enjoyment Expert, and an Outstanding Nuggets Author. I also won various brands for essay writing and open source competitions.
💡 I want to share all the detours and experiences I have taken on the technical road, so as to bring some inspiration and help to your learning and growth.
🌟 Welcome to pay attention to Xiaoyu’s hard work, let’s make progress together! 🌟