Shulou(Shulou.com)05/31 Report--

The main content of this article is "how to transform the Sentinel console". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to transform the Sentinel console.

As a powerful tool of Sentinel, Sentinel console provides multi-dimensional monitoring and rule configuration functions. The Sentinel client is now available in a production environment, but some modifications are needed if you want to use the Sentinel console in a production environment.

Using the Sentinel console in a production environment requires only two steps:

Modify push logic to support push to regular data sources

Transform the monitoring logic to support the persistence of monitoring data

Dynamic rule data source

Sentinel's dynamic rule data source is used to read and write rules from it. Starting with version 0.2.0, Sentinel divides dynamic rule data sources into two types: read data sources (ReadableDataSource) and write data sources (WritableDataSource):

The read data source is only responsible for listening or polling for remote storage changes.

The write data source is only responsible for writing rule changes to the rule source.

The common ways to read data sources are as follows:

Pull mode: the client actively polls a rule management center for pulling rules on a regular basis, which can be RDBMS, files, etc. The way to do this is simple, but the disadvantage is that you may not be able to get changes in time, and pulling too often may have performance problems.

Push mode: the rule center is pushed uniformly, and the client listens for changes all the time by registering the listener, such as using Nacos, Zookeeper and other configuration centers. This method has better real-time and consistency guarantee.

In the actual scenario, different storage types correspond to different data source types. Writes are generally not supported for push schema data sources, while pull schema data sources are writable.

Let's analyze their usage scenarios in conjunction with the Sentinel console and the corresponding points that need to be modified.

| | original condition |

If the application does not register any data sources, the process of pushing rules directly from the Sentinel console is very simple:

Cdn.nlark.com/lark/0/2018/png/47688/1536660296273-4f440bba-5b9e-4205-9402-fb6083b66912.png ">

The Sentinel console pushes the rules to the client through API and updates them directly to memory. In this case, the restart rule disappears and can only be used for simple testing and cannot be used in a production environment. In general, in a production environment, we need to configure rule data sources on the application side.

| | data source of pull mode |

Pull schema data sources (such as local files, RDBMS, and so on) are generally writable. When using it, you need to register the data source on the client side: register the corresponding read data source to the corresponding RuleManager and the write data source to the WritableDataSourceRegistry of transport. Take the local file data source as an example:

Public class FileDataSourceInit implements InitFunc {@ Override public void init () throws Exception {String flowRulePath = "xxx"; ReadableDataSource ds = new FileRefreshableDataSource (flowRulePath, source-> JSON.parseObject (source, new TypeReference () {})); / / register the readable data source with FlowRuleManager. FlowRuleManager.register2Property (ds.getProperty ()); WritableDataSource wds = new FileWritableDataSource (flowRulePath, this::encodeJson); / / registers the writable data source with the WritableDataSourceRegistry of the transport module. / / when you receive a rule pushed by the console, Sentinel will update it to memory first, and then write the rule to a file. WritableDataSourceRegistry.registerFlowDataSource (wds);} private String encodeJson (T t) {return JSON.toJSONString (t);}}

The local file data source regularly polls for changes to the file and reads the rules. In this way, we can either modify the file locally to update the rules, or we can push the rules through the Sentinel console. Taking the local file data source as an example, the push process is shown in the following figure:

First, the Sentinel console pushes the rules to the client through API and updates them to memory, and then the registered write data source saves the new rules to a local file. There is generally no need to modify the Sentinel console when using data sources in pull mode.

| | data source of push mode |

For push mode data sources (such as remote configuration center), the push operation should not be done by the Sentinel data source, but should be pushed through the console. The data source is only responsible for obtaining the configuration pushed by the configuration center and updating it locally.

Assuming that the written operation is also carried out by the data source, the Sentinel client receives the rules pushed by the console, updates the new rules to memory and pushes the rules to the remote configuration center. At this point, the data source monitors the new rules pushed by the configuration center and updates them to memory again. In other words, after the rules are updated locally and pushed to the remote, it is obviously unreasonable to receive the changes and update them again. Therefore, the correct approach to the push rule should be to configure the central console / Sentinel console → configuration center → Sentinel data source → Sentinel, rather than push to the configuration center through the Sentinel data source. The process is very clear:

Note that because different production environments may use different data sources, the implementation of pushing from the Sentinel console to the configuration center needs to be modified by the user. Take ZooKeeper as an example, we can modify it as follows (assuming that the push dimension is the application dimension):

Implement a common ZooKeeper client for push rules. You need to specify the address of the ZooKeeper in the Sentinel console configuration item, and create the ZooKeeper Client at startup.

We need to set a different path for each appName (which can be modified at any time), or the convention is greater than the configuration (for example, the mode of path is unified as / sentinel_rules/ {appName} / {ruleType}, e.g. Sentinel_rules/appA/flowRule).

The rule configuration page needs to be modified to configure rules directly for the application dimension. When you modify the rules of the same application with multiple resources, you can push them in batches or separately. The Sentinel console caches rules in memory (such as InMemFlowRuleStore), which can be modified to support the rule cache of the application dimension (key is appName). Every time you add / modify / delete rules, update the rule cache in memory first, then get all the rules from the rule cache when you need to push, and then push the rules to ZooKeeper through the Client implemented above.

The application client needs to register the corresponding read data source to listen for changes. You can refer to the relevant documentation.

Monitoring data persistence

Sentinel records the second-level data accessed by the resource (if there is no access, it is not recorded) and saves it in the local log. For more information, please see the second-level monitoring log document. The Sentinel console pulls the monitoring data from the second monitoring log through the API reserved by the Sentinel client and aggregates it. Currently, the monitoring data in the Sentinel console is directly stored in memory after aggregation, is not persisted, and only the monitoring data of the last 5 minutes is retained. If you need to monitor data persistence, you can extend and implement the MetricsRepository API (version 0.2.0), then register as Spring Bean and specify the corresponding bean name with @ Qualifier annotation in the appropriate location. The MetricsRepository interface defines the following functions:

Save and saveAll: store the corresponding monitoring data

QueryByAppAndResourceBetween: query the monitoring data of a resource in an application within a certain period of time

ListResourcesOfApp: query all resources under an application

The default monitoring data type is MetricEntity, including application name, timestamp, resource name, number of exceptions, number of passed requests, number of request block, aPCge response time and other information.

At the same time, users can expand themselves to adapt to visualization platforms such as Grafana, so as to better visualize the monitoring data.

At this point, I believe you have a deeper understanding of "how to transform the Sentinel console". 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.