Do you think programmers just sit around writing bugs and release them to the server?

No, you have bugs to fix! But before that, you’ve got bugs to find!


So the problem comes, the program is deployed all server, how to find bugs? Here are a few ways to find bugs in your programs.

Journal article

In the last article, I introduced “What should I Notice about logging in Java Code?” . Logging is very important because logging provides runtime information that can help you quickly locate problems.

So how do logs analyze problems? Let’s start with the stand-alone server, because sometimes bugs may be found in the test, and the test environment is generally less machines, may not build a special LOG collector such as ELK, so it may be to the server to see the log.

Unified log configuration standards

This is actually very important because we need to find the path of the log file before we can find the log for analysis. Especially in a larger team, there are a lot of services, and it is taboo to put the log file path of each service in disorder, looking for a long time to find the log.


Therefore, it is recommended that teams have a unified logging configuration standard. Keep the format, path, save date, and cleanup strategy consistent and included in the team’s build documentation so that developers can quickly find the logs they want.

Common commands for analyzing logs

Most servers are deployed on Linux servers, so this section describes some common commands for analyzing logs on Linux.

tail

The tail command is my favorite. As we know, log files are mostly appending. So the most recent problems are usually at the end of the log file. The tail command prints logs on the NTH row from last to last. You can also use the -f parameter to track logs in real time.

Print the last 1000 lines of x. log. default is 10
tail x.log -n1000;

# print the last 10 lines of x.log and continue to print the new logs
tail x.log -f
 # This is equivalent to the above tailf x.log Copy the code

cat + grep

The tail command, introduced above, prints the last n lines of a file. But sometimes we find the problem a little too late and can look through the entire log file.

You can run the cat command to print the contents of the entire log file. But the entire log file is so large that we usually pipe it together with grep to extract only the information we need.

cat x.log | grep 'xxx'
Copy the code

The value of “XXX” in grep is usually recommended as follows:

  • The ID or UID of the log data, for example, 43432413.
  • TraceId in logs.
  • Problem description in logs, for example, Call userService failed.
  • Files in the log, such as “UserServiceImpl”

Of course, the pipe and grep here can also be combined with the tail command above. In addition, if the output of grep is too much and you want to analyze it later, the pipeline can also output the output stream to a file, for example:

cat x.log | grep 'xxx' > temp.log
Copy the code

Once the output is in a single file, we can analyze it further, such as the number of exceptions, and extract key information from it. You can also do this with the sed command.

Such as:

# print temp. The log
$ cat temp.log
error data: 124
error data: 121j
error data: 124fdsfsd
 # fetch the id inside with the re $ cat temp.log | sed -r "s/error data: (.*)/\1/g" 124 121j 124fdsfsd Copy the code

vi

Cat + grep is good, but not very convenient to view the logs around exceptions. For example, if we want to see the full daily stack, we can do so through VI’s search function.

Vi is a powerful text editor commonly used on Linux platforms. Of course, many friends are more used to using the more powerful Vim, the usage is similar. Today I will introduce some of its commonly used search functions and jump functions.

# Search from front to back
/searchKey
Search from back to front
? SearchKeyPosition the cursor to the next search location
Shortcuts n# Locate a search location above the cursor Shortcuts N# set the display line number :set nu Copy the code

This is almost enough to locate and analyze logs on the server. If your server is distributed and deployed on many machines, such as a UAT or production environment, it is not recommended to manually analyze the logs on the server, but to collect and analyze the logs using a mature logging framework.

Common open source log collection frameworks such as ELK and Splunk provide Web interfaces and rich query statement support.

The remote Debug article

The JVM now supports remote debugging. This works because Java is cross-platform, and as long as the remote bytecode file is the same as the local bytecode file, the two JVMS can communicate via a debugging protocol.


❝

Make sure that the local and server-side code is consistent, otherwise an endpoint may not be able to enter. Especially if you are using branch development, you need to pay attention to whether the branches are consistent

❞

IDEA has a very useful remote Debug tool, the following simple introduction to how to Debug IDEA. First go in through Run -> EditConfigurations, and then add a Remote.

Note that the port is a new port on the server and does not conflict with the web port of the service itself. You can pass in the JVM parameters shown in the following figure to specify the port and remote debug configuration when the application starts.

remote debug

Once created, open your remote debug in IDEA and debug happily.

❝

Remote debugging is not recommended in the production environment

❞

Artifact Arthas

Arthas is an open source Java diagnostic tool from Alibaba. There is an online interactive tutorial on the website, which is very easy to get started in just a few minutes. Support automatic command completion, historical command completion, pipeline, etc. Here are some of its common functions.

Dashboard

Arthas’ Dashboard command displays the real-time status of the current system and JVM. This includes thread state, JVM state.

dashboard

Look at the thread

The stack whose thread ID is 1 can be printed through Thread 1. Arthas also supports pipes through which you can grep the output:

[arthas@37]$ thread 1
"main" Id=1 TIMED_WAITING
    at java.lang.Thread.sleep(Native Method)
    at java.lang.Thread.sleep(Thread.java:340)
    at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
 at demo.MathGame.main(MathGame.java:17)  Affect(row-cnt:0) cost in 9 ms. [arthas@37]$ thread 1 | grep main(  at demo.MathGame.main(MathGame.java:17) Copy the code

View the runtime information for the method

You can run the watch command to view the runtime parameters, return values, and exception information of a method.

[arthas@37]$ watch demo.MathGame primeFactors returnObj
Press Q or Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:1) cost in 40 ms.
ts=2020-05-10 02:53:46; [cost] = 1.129697 ms result = nullts=2020-05-10 02:53:47; [cost] = 0.056254 ms result = nullts=2020-05-10 02:53:48; [cost] = 0.056249 ms result = nullts=2020-05-10 02:53:49; [cost] = 0.210126 ms result = @ ArrayList [ @Integer[2],  @Integer[3],  @Integer[5],  @Integer[1039], ] ts=2020-05-10 02:53:50; [cost] = 0.204834 ms result = @ ArrayList [ @Integer[3],  @Integer[3],  @Integer[3],  @Integer[7],  @Integer[839], ] Copy the code

Dynamically executing code

This is one of the most powerful features OF Arthas in my opinion! Use the ogNL command to let your application code execute any method, with any parameters you specify! Such as:

[arthas@37]$ ognl '@[email protected]("hello ognl")'
Copy the code

At this point, your application code will print “Hello ogNL”.

Arthas also has a lot of very powerful features. It can even hot-update code, which is to dynamically replace a class that you want to replace!

Of course, I find Arthas’s commands powerful, but a bit complicated to use, as it is a command-line application. Arthas IDEA – arthas IDEA – arthas IDEA – arthas IDEA

arthas idea

So that’s how you can find bugs faster and easier. The sooner you find a bug, the sooner you save your losses, the sooner you may get a promotion or a raise

About the author

Wechat public number: made up a process

Personal website: https://yasinshaw.com

Pseudonym Yasin, a programmer with depth, attitude and warmth. After work to share programming technology and life, if you like my article, you can easily “follow” the public account, also welcome to “forward” to share with your friends ~

Reply “interview” or “study” on the official account to receive corresponding resources oh ~

The public,