[SpringBoot Series] Multi-environment development and logging

Pre-import

What is multi-environment? In fact, it means that the program written on your computer will eventually run on someone else's server. Every computer environment is different, this is multi-environment. The common multi-environment development mainly takes into account three kinds of environment settings, the development environment - used by yourself, the test environment - used by your company, and the production environment - used by Party A's father. Because these are absolutely different three computers, the environment must be different, such as the connected databases are different, the access ports set are different, and so on.

Multi-environment development (yaml single file version)

So what is multi-environment development? It is to set different configuration properties for different environments. For example, when you develop by yourself, configure your port as follows:

server:
  port: 80

​ How do you want to design two sets of environments? separated by three minus signs

server:
  port: 80
---
server:
  port: 81

How to distinguish the two environments? name it

spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81

Which one to use? Set which one to start by default

spring:
	profiles:
		active: pro		# 启动pro
---
spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81

​ It's as simple as that, it's OK to have another set of environments

spring:
	profiles:
		active: pro		# 启动pro
---
spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81
---
spring:
	profiles: test
server:
	port: 82

​ The above format for the definition of the environment name is an outdated format, and the standard format is as follows

spring:
	config:
    	activate:
        	on-profile: pro

Summarize

1. Multi-environment development requires setting up several common environments, such as development, production, and test environments
2. Set multi-environment usage in yaml format - distinguish environment setting boundaries
3. The difference between each environment is the configuration properties that are loaded
4. When enabling an environment, you need to specify the environment to use at startup

Multi-environment development (yaml multi-file version)

It is obviously unreasonable to put all configurations in one configuration file, especially each configuration application scenario is different, so we have the idea of ​​splitting a configuration file into multiple configuration files. After splitting, write your own configuration in each configuration file, and write clearly which configuration file to use in the main configuration file.

main configuration file

spring:
	profiles:
		active: pro		# 启动pro

environment configuration file

server:
	port: 80

​ Because each environment configuration file configures its own item, even the name does not need to be written in it. The question is how to distinguish which set of configurations this is? Use filenames to differentiate.

application-pro.yaml

server:
	port: 80

application-dev.yaml

server:
	port: 81

​The naming rule of the file is: application-environment name.yml

The application.yml in the above figure is the main configuration file we are talking about, and the others are environment configuration files.

In the configuration file, if some configuration items are the same in all environments, these items can be written into the main configuration, and only those items that are different are written into the environment configuration file.

• Set the public configuration in the main configuration file (global)
• Commonly used to set conflict properties in environment classification configuration files (local)

Summarize

1. Environment properties can be defined using a standalone configuration file

2. Independent configuration files facilitate online system maintenance and update and ensure system security

Multi-environment development (properties multi-file version)

The earliest configuration file format provided by SpringBoot is in the properties format, and you can also learn about the multi-environment configuration in this format.

main configuration file

spring.profiles.active=pro

environment configuration file

application-pro.properties

server.port=80

application-dev.properties

server.port=81

​The naming rule of the file is: application-environment name.properties

Summarize

1. properties文件多环境配置仅支持多文件格式

Multi-environment development independent configuration file writing skills

​As a programmer, when you are engaged in configuration, you are often in a situation where you must combine for a long time and must divide for a long time. At first, they were written together, and then they were split for the convenience of maintenance. The same is true for multi-environment development. Let me tell you how to do independent configuration management based on multi-environment development. Be sure to master it.

Preparation

​ All the configurations are split according to the function, and the information in the configuration file is split and made into independent configuration files. The naming rules are as follows

• application-devDB.yml
• application-devRedis.yml
• application-devMVC.yml

use

​ Use the include attribute to load multiple environments at the same time to make it take effect when the specified environment is activated, and separate multiple environments with commas

spring:
	profiles:
    	active: dev
        include: devDB,devRedis,devMVC

​ For comparison, now it is equivalent to loading the dev configuration, and then loading the corresponding 3 sets of configurations, the structure is very clear, what is used, and what is the corresponding name

Notice

​ When the main environment dev has the same attributes as other environments, the main environment attributes take effect; when other environments have the same attributes, the last loaded environment attributes take effect

improve

​ But there is also a problem with the above settings. For example, when I want to switch the dev environment to pro, the include should also be modified. Because the include attribute can only be used once, this is more troublesome. Since version 2.4, SpringBoot uses the group attribute to replace the include attribute, which reduces the amount of configuration writing. Simply put, I will write it first, whichever you like to use.

spring:
	profiles:
    	active: dev
        group:
        	"dev": devDB,devRedis,devMVC
      		"pro": proDB,proRedis,proMVC
      		"test": testDB,testRedis,testMVC

​ Now let’s look at it, if you switch from dev to pro, you just need to change it, is it over? Perfect!

Summarize

1. Multi-environment development uses the group attribute to set configuration file groups, which is convenient for online maintenance and management

Multi-environment development control

Finally, let's talk about conflict. That is, what if maven and SpringBoot set up multiple environments at the same time.

To deal with this conflict, you must first clarify a relationship, who is the dominant player in multi-environment development. That is to say, if both environments are set up now, which one should be kept, and the other one should follow the same settings.

What does maven do? Project build management, and finally generate code packages, what does SpringBoot do? Simplified development. Simplification is not its leading role. In the end, maven is required to manage the entire project, so SpringBoot should listen to maven. After the whole confirmation, the following is done. The general idea is as follows:

• First set what specific environment to use in the maven environment
• Just read the environment set by maven in SpringBoot

Set up multiple environments in maven (use properties to distinguish environments)

<profiles>
    <profile>
        <id>env_dev</id>
        <properties>
            <profile.active>dev</profile.active>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>		<!--默认启动环境-->
        </activation>
    </profile>
    <profile>
        <id>env_pro</id>
        <properties>
            <profile.active>pro</profile.active>
        </properties>
    </profile>
</profiles>

Reading maven settings in SpringBoot

spring:
	profiles:
    	active: @profile.active@

​ The above @property name@ is the syntax format for reading the property value configured in maven.

Summarize

1. When Maven and SpringBoot control multiple environments at the same time, Maven is the main one, and SpringBoot uses the @…@ placeholder to read the configuration property values ​​corresponding to Maven
2. Based on the premise that SpringBoot reads Maven configuration properties, if you test the project under Idea, you need to manually compile each update of pom.xml to take effect (this problem has been resolved in IDEA 21 and 22 versions)

log preamble

The log is actually the information that records the daily operation of the program. The main functions are as follows:

• Debug code during programming
• Recording information during the operation period
• Record important information for daily operations (peak traffic, average response time...)
• Record application error information (error stack)
• Record operation and maintenance process data (expansion, downtime, alarm...)

Use the logging tool to record logs in the code

The usage format of the log is very fixed, go directly to the operation steps:

Step ① : Add logging operation

@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
    
    
    private static final Logger log = LoggerFactory.getLogger(BookController.class);
    @GetMapping
    public String getById(){
    
    
        log.debug("debug...");
        log.info("info...");
        log.warn("warn...");
        log.error("error...");
        return "springboot is running...2";
    }
}

​ The log object in the above code is the object used to record the log. The operations of log.debug and log.info below are the API for writing logs.

result:

By default, when our system starts up, the log level is info level, so here we can only see info and the log information on it

Step ② : Set the log output level

​ After the log is set, you can choose which participating records to follow according to the settings. This is set according to the level of the log. There are 6 log levels, which are:

• TRACE: running stack info, low usage
• DEBUG: Programmers debug code using
• INFO: record operation and maintenance process data
• WARN: Record the alarm data of the operation and maintenance process
• ERROR: log error stack information
• FATAL: disaster information, combined into ERROR

​ In general, DEBUG is used for development, INFO is used after going online, and WARN is used for operation and maintenance information records. Set the log level as follows:

# 开启debug模式，输出调试信息，常用于检查系统运行状况
debug: true

After the debug mode is turned on, we will have a large amount of text when we start the project. This mode is usually only used in the detection after the project is launched.

​ This setting is too simple and rude, and the log system usually provides fine-grained control

# 开启debug模式，输出调试信息，常用于检查系统运行状况
debug: true

# 设置日志级别，root表示根节点，即整体应用日志级别
logging:
	level:
    	root: debug

After we set it to the debug level, we can see it when we run it again:

​ You can also set more fine-grained controls (for example, we don’t want to see the debug log in the framework)

Step 3 : Set the log group to control the log output level corresponding to the specified package, or directly control the log output level corresponding to the specified package

logging:
	# 设置日志组
    group:
    	# 自定义组名，设置当前组中所包含的包
        ebank: com.nefu.controller,com.nefu.service
    level:
    	root: warn
        # 为对应组设置日志级别
        ebank: debug
    	# 为对包设置日志级别
        com.nefu.controller: debug

​ To put it bluntly, it is to set the overall settings, and set each package. If you feel that it is troublesome to set up, first divide the packages into groups and set the groups.

Summarize

1. The log is used to record development debugging and operation and maintenance process messages
2. There are 6 types of log levels, usually 4 types can be used, namely DEBUG, INFO, WARN, ERROR
3. The log display level can be controlled in the form of log groups or code packages

Optimize log object creation code

When writing code, each class must write and create a logging object. This can be optimized by using the tool class provided by the lombok technology used earlier.

@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
    
    
    private static final Logger log = LoggerFactory.getLogger(BookController.class);	//这一句可以不写了
}

​ After importing lombok, use the annotation to get it, the log object name is log

@Slf4j		//这个注解替代了下面那一行
@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
    
    
    private static final Logger log = LoggerFactory.getLogger(BookController.class);	//这一句可以不写了
}

Log output format control

The log has been recorded, but the current recording format is provided by SpringBoot. If you want to customize the control, you need to set it yourself. First analyze the record format of the current log.

• PID: Process ID, used to indicate the process in which the current operation is located. When multiple services record logs at the same time, this value can be used to assist programmers in debugging programs.
• Class/Interface Name: The currently displayed information is the information rewritten by SpringBoot. When the name is too long, the simplified package name is written as the first letter, or even deleted directly.

​ For a single log message, the date, trigger location, and record information are the core information. The level is used for filtering, and the PID and thread name are used for precise analysis. After knowing this information, you can DIY the log format.

The writing format of the simulated official log template:

logging:
	pattern:
    	console: "%d %clr(%p) --- [%16t] %clr(%-40.40c){cyan} : %m %n"

log file

The log information shows that the record has been controlled. Now let's talk about the dumping of the log. The log cannot only be displayed on the console, and the log should be recorded in a file to facilitate later maintenance and reference.

​ There are various strategies for the use of log files, such as daily records, classified records, post-alarm records, etc. Here we mainly study how log files are recorded.

​ The format of recording logs to a file is very simple, just set the log file name.

logging:
	file:
    	name: server.log

​ Although the above format can be used to record logs, in the face of complex online situations, a file record must not be able to meet the operation and maintenance requirements. Usually log files are recorded every day. size of log files. The common configuration methods for log files are given below:

logging:
	logback:
    	rollingpolicy:   #代表日志的滚动
        	max-file-size: 3KB   #文件大小限度
            file-name-pattern: server.%d{
    
    yyyy-MM-dd}.%i.log   #滚动日志的文件名怎么启

​ The above format is based on the logback log technology to set the format of the daily log file. It is required to transfer the information to the second file after the capacity reaches 3KB .%d in the file naming convention identifies the date, and %i is an incrementing variable used to distinguish log files.