The author | Montos seasoning (a backend roads within the volume) source | alibaba cloud native public number

Arthas is An open source Java diagnostic tool from Alibaba. It allows us to troubleshoot problems with the project online. In addition to knowing that it exists, we also need to know how we install and use it to improve our daily BUG solving efficiency.

Plan to introduce

Solution 1: Run locally

Often the simplest method is actually the most effective. It is an executable program in itself, so we can just run it.

  • We can directly download the corresponding JAR from the official website, and then run the jar again to execute the corresponding command.

  • The command is as follows:

java -jar arthas-boot.jar [option]
Copy the code
  • The demo is as follows:

Scheme 2: Web Console implementation

Instead of running the program every time we go into SSH, we can access it through the Web. Arthas Web Console is described on the arthas website to give you an idea of how to build it.

  • Download arthas-tunnel-Server. We can get the server side of arthas. Download it and run it directly (I’m running it directly on ECS).

  • Start arthas-boot on the corresponding client. And append the server’s address (I’m running it locally) with the startup parameter.

  • Select the corresponding process and attach. The agent-ID is displayed, and then the AGent-ID is added to the corresponding HTTP page on the server.

  • Finally, we are ready to go back to the server and the Web Console implementation is complete.

Plan 3: Project dependency

Spring-based projects add dependencies directly (requiring appropriate environment support, such as tools.jar).

  • The SpringBoot project depends on:
<dependency>
            <groupId>com.taobao.arthas</groupId>
            <artifactId>arthas-spring-boot-starter</artifactId>
            <version>${arthas.version}</version>
        </dependency>
Copy the code
  • Non-springboot project dependencies:
<dependency>
            <groupId>com.taobao.arthas</groupId>
            <artifactId>arthas-agent-attach</artifactId>
            <version>${arthas.version}</version>
        </dependency>
        <dependency>
            <groupId>com.taobao.arthas</groupId>
            <artifactId>arthas-packaging</artifactId>
            <version>${arthas.version}</version>
        </dependency>
Copy the code
  • After the local project is started, it can be accessed directly:
http://127.0.0.1:3658/
Copy the code
  • You can also combine this with the Web Console described above. For example, add the following configuration information to the configuration file:
Arthas. agent-id=qwejqjnnnunnq arthas.tunnel-server=ws:// Server address :7777/wsCopy the code
  • The demo is as follows:

The preceding steps are to start the tunnel-server and connect to the tunnel-server locally. Then enter the configured Id to complete debugging.

Solution 4: Container configuration

Based on docker configuration, there are many enterprises on the container service at present. This is also true for container services. After downloading the JAR, ADD, or each time you build a Dockerfile, a corresponding image file containing arthas is generated.

Here’s how to build with Dockerfile:

FROM openjdk:8-jdk-alpine
ADD target/*.jar app.jar
# copy arthas
COPY --from=hengyunabc/arthas:latest /opt/arthas /opt/arthas
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
MAINTAINER Montos [email protected]
Copy the code

This is done by building a Dockerfile, pasting the image file directly, copying the current arthas file into the appropriate container, and then executing it using exec-it, similar to method 1.

conclusion

Based on the above introduction, I actually recommend Web access for the following reasons:

  • In the case of services deployed directly on a server or ECS cloud server. We can run directly on the corresponding client, but how do we access the server where each service is located? By jumpers? Then, is it possible that the corresponding server will be affected when we operate? It is definitely not possible to directly connect to the server.

  • Service in the case of a running POD. The impact of allowing you to connect to the service at this time is much smaller than the above situation, and if it does occur, it will only affect the pod currently running. But if you want to connect to the POD directly, you need to map the corresponding POD port to the corresponding host, and then provide external access to the ECS link. This will make each POD needs to map out the port needs certain rules, is undoubtedly increased operation and maintenance work, running also consumes the current resources (access to the page and so on through HTTP interface request, if through WS connection, reduce the consumption of 7 layers).

  • If the above method is adopted, we can just run the server on another machine. We can connect to the corresponding client by accessing the server every time. Meanwhile, the corresponding agent-ID can be specified. We can specify the current Agent-ID every time pod runs as a client and bind it to the current POD for easy connection through the server.

Of course, that is a matter of opinion. The above describes several ways to deploy and run ArthAS, and enterprises can choose the right deployment based on their current project architecture. Why ？？？？ Because can help development to solve the problem, do not need to send version back and forth!

Arthas 57 hands-on experiments at start.aliyun.com:Start.aliyun.com/handson-lab…

Arthas Experimental preview

In an effort to get more developers to start using Arthas as a Java diagnostic tool, the Arthas community has teamed up with JetBrains to launch an Arthas essay campaign: ** Talk about your relationship with Arthas over the years. ** activity is still in progress, click to participate, welcome everyone to contribute, participation is likely to win!