Shulou(Shulou.com)06/01 Report--

This article focuses on "Common problems and Solutions of Nacos". Friends who are interested may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the common problems and solutions of Nacos.

How to rely on the latest Nacos client?

Many users rely on Nacos clients through Spring Cloud Alibaba or Dubbo, so the Nacos client versions relied on in Spring Cloud Alibaba and Dubbo tend to lag behind the latest releases of Nacos. In some cases, users need to force the Nacos client to be upgraded to the latest, but they often do not know which dependency to upgrade. The dependency upgrade for Spring Cloud Alibaba and Dubbo is described as follows:

Spring Cloud Alibaba

Users typically configure the following Maven dependencies to use Nacos:

Com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery [latest version] com.alibaba.cloud spring-cloud-starter-alibaba-nacos-config [latest version]

These two JAR packages actually rely on the following JAR packages:

Com.alibaba.nacos nacos-client [a particular version]

If nacos-client is upgraded, the corresponding spring-cloud client version may not be upgraded synchronously. At this time, you can use the following ways to force nacos-client upgrade (take nacos-discovery as an example):

Com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery [latest version] com.alibaba.nacos nacos-client com.alibaba.nacos nacos-client [latest version]

Dubbo

The same is true for Dubbo, where users usually introduce the following dependencies:

Com.alibaba dubbo-registry-nacos [latest version] com.alibaba dubbo [latest version]

When you need to upgrade the Nacos client, you only need to modify the dependency as follows:

Com.alibaba.nacos nacos-client [latest version]

High CPU or memory exhaustion on the client

The phenomenon of the problem is that it depends on the application of Nacos client. After running for a period of time, there are high CPU occupancy rate, high memory occupation and even memory overflow. Please refer to Issue.

The first thing to do in this case is to analyze the reasons for high CPU or high memory footprint. The commonly used commands are top, jstack, jmap, jhat and so on. One of the cases is that the Nacos client instance is constructed repeatedly in the Spring Cloud Alibaba service framework. You can refer to Issue

This issue has been fixed and is expected to be released in the next version of Spring Cloud Alibaba.

The problem of frequent log printing

In the old version of Nacos, there are often a large number of invalid logs printed, and the printing of these logs will quickly take up users' disk space and make it difficult to find valid logs. At present, the frequent printing of community feedback logs is mainly in the following situations: 1. Access logs are printed in large quantities. Click here for the relevant Issue.

The main performance is that the logs of {nacos.home} / logs/access_log.2019-xx-xx.log file names in similar format are printed in large quantities, and they can not be cleaned and scrolled automatically. This log is printed by the Tomcat access log provided by Spring Boot. Spring Boot does not have the option of maximum retention days or log size control among the options for this log. Therefore, the cleaning of this log must be completed by applying the new Crontab task, or the output of the log must be turned off with the following command (in the production environment, we still recommend that you open the log so that you can have the first site access record):

Server.tomcat.accesslog.enabled=false

2. A large number of server business logs are printed and the log level cannot be adjusted dynamically. This problem has been optimized in 1.1.3. You can adjust the log level by API. The log level can be adjusted as follows:

# adjust the naming-raft.log level of naming module to error:curl-X PUT'$nacos_server:8848/nacos/v1/ns/operator/log?logName=naming-raft&logLevel=error'# and the config-dump.log level of config module to warn:curl-X PUT'$nacos_server:8848/nacos/v1/cs/ops/log?logName=config-dump&logLevel=warn'

3. A large number of client logs are printed, mainly heartbeat logs, polling logs and so on. This problem has been resolved in 1.1.3, please upgrade to version 1.1.3.

Cluster management page, Raft Term displays inconsistent issues

In Nacos version 1.0.1, the Nacos console supports the display of status information for each machine in the current cluster. This feature has attracted the attention of more users, and one of the feedback issues is that the cluster tenure of each node in the list is different. As shown in the following figure, the picture information is from Issue

For this problem of inconsistent tenure, the main reason is that there are some problems with the logic of obtaining this information, and the cluster term is not obtained from the corresponding node. This issue will be fixed in the next version of Nacos. Currently, one way to manually check the tenure of a cluster is to execute the following command on each node:

Curl '127.0.0.1MAG 8848Universe nacosUnix v1max nsUnix raftUnix state'

Then look up the cluster tenure of this node in the returned information. Because in the cluster term returned by each node, only the information of the current node is accurate, and the information of other nodes returned is inaccurate.

At this point, I believe you have a deeper understanding of "common problems and solutions to Nacos". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.