[GitHub] [skywalking] kezhenxu94 commented on a change in pull request #7130: Feature: support endpoint name grouping by OpenAPI definitions.

[GitBox <gi...@apache.org>]

kezhenxu94 commented on a change in pull request #7130:
URL: https://github.com/apache/skywalking/pull/7130#discussion_r654117709



##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.

Review comment:
       ```suggestion
      \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
      \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by set the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+<br />
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and a endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The the path which has the less variables. 

Review comment:
       ```suggestion
   2. The path which has the less variables.
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |

Review comment:
       ```suggestion
      | x-sw-service-name | true | The service name to which these endpoints belong | |
      | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by set the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+<br />
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and a endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The the path which has the less variables. 
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one.
+### Examples

Review comment:
       ```suggestion
      Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
   ### Examples
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by set the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+<br />

Review comment:
       ```suggestion
   3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
   ```

##########
File path: oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/config/group/EndpointNameGrouping.java
##########
@@ -21,20 +21,48 @@
 import lombok.Setter;
 import lombok.extern.slf4j.Slf4j;
 import org.apache.skywalking.apm.util.StringFormatGroup;
+import org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRule4Openapi;
 
 @Slf4j
 public class EndpointNameGrouping {
     @Setter
     private volatile EndpointGroupingRule endpointGroupingRule;
+    @Setter
+    private volatile EndpointGroupingRule4Openapi endpointGroupingRule4Openapi;
 
     public String format(String serviceName, String endpointName) {
-        if (endpointGroupingRule == null) {
-            return endpointName;
+        String formattedName = endpointName;
+        if (endpointGroupingRule4Openapi != null) {
+            formattedName = formatByOpenapi(serviceName, formattedName.toString());

Review comment:
       ```suggestion
               formattedName = formatByOpenapi(serviceName, formattedName);
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by set the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+<br />
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and a endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 

Review comment:
       ```suggestion
   We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
   1. The exact path matched first. 
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,320 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represent HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represent the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule use to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by set the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+<br />
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and a endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The the path which has the less variables. 
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one.
+### Examples
+If we have a OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml

Review comment:
       ```suggestion
   If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
   ```yaml
   ```

##########
File path: oap-server/server-core/pom.xml
##########
@@ -82,7 +82,11 @@
             <groupId>io.vavr</groupId>
             <artifactId>vavr</artifactId>
         </dependency>
-
+        <dependency>
+            <groupId>io.swagger.parser.v3</groupId>

Review comment:
       Where is it used?

##########
File path: oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/config/group/openapi/EndpointGroupingRule4Openapi.java
##########
@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+
+package org.apache.skywalking.oap.server.core.config.group.openapi;
+
+import java.util.Comparator;
+import java.util.HashMap;
+import java.util.Map;
+import lombok.Getter;
+import org.apache.skywalking.apm.util.StringFormatGroup;
+
+public class EndpointGroupingRule4Openapi {
+    private final Map<String/*serviceName*/, Map<String/*endpointName*/, String/*endpointGroupName*/>> directLookup = new HashMap<>();
+    @Getter
+    private final Map<String, Map<String, StringFormatGroup>> groupedRules = new HashMap<>();
+
+    void addDirectLookup(String serviceName, String endpointName, String endpointGroupName) {
+        Map<String, String> endpointNameLookup = directLookup.computeIfAbsent(serviceName, name -> new HashMap<>());
+        endpointNameLookup.put(endpointName, endpointGroupName);
+    }
+
+    void addGroupedRule(String serviceName, String endpointGroupName, String ruleRegex) {
+        String rulesGroupkey = getGroupedRulesKey(ruleRegex);
+        Map<String, StringFormatGroup> rules = groupedRules.computeIfAbsent(serviceName, name -> new HashMap<>());
+        StringFormatGroup formatGroup = rules.computeIfAbsent(rulesGroupkey, name -> new StringFormatGroup());
+        formatGroup.addRule(endpointGroupName, ruleRegex);
+    }
+
+    public StringFormatGroup.FormatResult format(String service, String endpointName) {
+        Map<String, String> endpointNameLookup = directLookup.get(service);
+        if (endpointNameLookup != null && endpointNameLookup.get(endpointName) != null) {
+            return new StringFormatGroup.FormatResult(true, endpointNameLookup.get(endpointName), endpointName);
+        }
+
+        Map<String, StringFormatGroup> rules = groupedRules.get(service);
+        if (rules != null) {
+            final StringFormatGroup stringFormatGroup = rules.get(getGroupedRulesKey(endpointName));
+            if (stringFormatGroup != null) {
+                return stringFormatGroup.format(endpointName);
+            }
+        }
+
+        return new StringFormatGroup.FormatResult(false, endpointName, endpointName);
+    }
+
+    void sortRulesAll() {
+        groupedRules.entrySet().forEach(rules -> {
+            sortRulesByService(rules.getKey());
+        });
+    }
+
+    void sortRulesByService(String serviceName) {
+        Map<String, StringFormatGroup> rules = groupedRules.get(serviceName);
+        if (rules != null) {
+            rules.entrySet().forEach(stringFormatGroup -> {
+                stringFormatGroup.getValue()
+                                 .sortRules(new EndpointGroupingRule4Openapi.EndpointGroupingRulesComparator());
+            });
+        }
+    }
+
+    String getGroupedRulesKey(String string) {
+        String[] ss = string.split("/");
+        if (ss.length == 1) {   //eg. POST:/
+            return ss[0] + "/";
+        }
+        if (ss.length > 1) {
+            return ss[0] + "/" + ss[1];
+        }
+        return "/";
+    }
+
+    static class EndpointGroupingRulesComparator implements Comparator<StringFormatGroup.PatternRule> {
+        private static final String VAR_PATTERN = "\\(\\[\\^\\/\\]\\+\\)";
+
+        @Override
+        public int compare(final StringFormatGroup.PatternRule rule1, final StringFormatGroup.PatternRule rule2) {
+
+            String pattern1 = rule1.getPattern().pattern();
+            String pattern2 = rule2.getPattern().pattern();
+
+            if (getPatternVarsCount(pattern1) < getPatternVarsCount(pattern2)) {
+                return -1;
+            } else if (getPatternVarsCount(pattern1) > getPatternVarsCount(pattern2)) {
+                return 1;
+            }
+
+            int length1 = getPatternLength(pattern1);
+            int length2 = getPatternLength(pattern2);
+            if (length1 != length2) {
+                return length2 - length1;
+            }
+
+            return 0;
+        }

Review comment:
       ```suggestion
               return length2 - length1;
           }
   ```

##########
File path: oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/config/group/openapi/EndpointGroupingRuleReader4Openapi.java
##########
@@ -0,0 +1,135 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+
+package org.apache.skywalking.oap.server.core.config.group.openapi;
+
+import java.io.File;
+import java.io.FileNotFoundException;
+import java.io.FileReader;
+import java.io.Reader;
+import java.util.HashMap;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import org.apache.skywalking.apm.util.StringUtil;
+import org.apache.skywalking.oap.server.library.util.ResourceUtils;
+import org.yaml.snakeyaml.Yaml;
+import org.yaml.snakeyaml.constructor.SafeConstructor;
+
+public class EndpointGroupingRuleReader4Openapi {
+
+    private final String openapiDefPath;
+    private final static String DEFAULT_ENDPOINT_NAME_FORMAT = "${METHOD}:${PATH}";
+    private final static String DEFAULT_ENDPOINT_NAME_MATCH_RULE = "${METHOD}:${PATH}";
+    private final Map<String, String> requestMethodsMap = new HashMap<String, String>() {
+        {
+            put("get", "GET");
+            put("post", "POST");
+            put("put", "PUT");
+            put("delete", "DELETE");
+            put("trace", "TRACE");
+            put("options", "OPTIONS");
+            put("head", "HEAD");
+            put("patch", "PATCH");
+        }
+    };
+
+    public EndpointGroupingRuleReader4Openapi(final String openapiDefPath) {
+
+        this.openapiDefPath = openapiDefPath;
+    }
+
+    public EndpointGroupingRule4Openapi read() throws FileNotFoundException {
+        EndpointGroupingRule4Openapi endpointGroupingRule = new EndpointGroupingRule4Openapi();
+
+        List<File> fileList = ResourceUtils.getPathFilesRecursive(openapiDefPath);
+        for (File file : fileList) {
+            Reader reader = new FileReader(file);
+            Yaml yaml = new Yaml(new SafeConstructor());
+            Map openapiData = yaml.load(reader);
+            if (openapiData != null) {
+                String serviceName = getServiceName(openapiData, file);
+                LinkedHashMap<String, LinkedHashMap<String, LinkedHashMap>> paths =
+                    (LinkedHashMap<String, LinkedHashMap<String, LinkedHashMap>>) openapiData.get("paths");
+
+                if (paths != null) {
+                    paths.forEach((pathString, pathItem) -> {
+                        pathItem.keySet().forEach(key -> {
+                            String requestMethod = requestMethodsMap.get(key);
+                            if (!StringUtil.isEmpty(requestMethod)) {
+                                String endpointGroupName = formatEndPointName(pathString, requestMethod, openapiData);
+                                String groupRegex = getGroupRegex(pathString, requestMethod, openapiData);
+                                if (isTemplatePath(pathString)) {
+                                    endpointGroupingRule.addGroupedRule(serviceName, endpointGroupName, groupRegex);
+                                } else {
+                                    endpointGroupingRule.addDirectLookup(serviceName, groupRegex, endpointGroupName);
+                                }
+                            }
+                        });
+                    });
+                }
+            }
+        }
+        endpointGroupingRule.sortRulesAll();
+        return endpointGroupingRule;
+    }
+
+    private String getServiceName(Map openapiData, File file) {
+        String serviceName = (String) openapiData.get("x-sw-service-name");
+        if (StringUtil.isEmpty(serviceName)) {
+            throw new IllegalArgumentException(
+                "OpenAPI definition: " + file.getAbsolutePath() + " x-sw-service-name can't be empty");
+        }
+
+        return serviceName;
+    }
+
+    private boolean isTemplatePath(String pathString) {
+        return pathString.matches("(.*)\\{(.+?)}(.*)");
+    }
+
+    private String getGroupRegex(String pathString, String requstMathod, Map openapiData) {
+        String endPointNameMatchRuleTemplate = (String) openapiData.get("x-sw-endpoint-name-match-rule");
+        String endPointNameMatchRule = replaceTemplateVars(DEFAULT_ENDPOINT_NAME_MATCH_RULE, pathString, requstMathod);
+
+        if (!StringUtil.isEmpty(endPointNameMatchRuleTemplate)) {
+            endPointNameMatchRule = replaceTemplateVars(endPointNameMatchRuleTemplate, pathString, requstMathod);
+        }
+
+        if (isTemplatePath(endPointNameMatchRule)) {
+            return endPointNameMatchRule.replaceAll("\\{(.+?)}", "([^/]+)");
+        }
+        return endPointNameMatchRule;
+    }
+
+    private String formatEndPointName(String pathString, String requstMathod, Map openapiData) {
+        String endPointNameFormat = (String) openapiData.get("x-sw-endpoint-name-format");

Review comment:
       ```suggestion
       private String formatEndPointName(String pathString, String requstMethod, Map openapiData) {
           String endPointNameFormat = (String) openapiData.get("x-sw-endpoint-name-format");
   ```

##########
File path: oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/config/group/EndpointNameGrouping.java
##########
@@ -21,20 +21,48 @@
 import lombok.Setter;
 import lombok.extern.slf4j.Slf4j;
 import org.apache.skywalking.apm.util.StringFormatGroup;
+import org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRule4Openapi;
 
 @Slf4j
 public class EndpointNameGrouping {
     @Setter
     private volatile EndpointGroupingRule endpointGroupingRule;
+    @Setter
+    private volatile EndpointGroupingRule4Openapi endpointGroupingRule4Openapi;
 
     public String format(String serviceName, String endpointName) {
-        if (endpointGroupingRule == null) {
-            return endpointName;
+        String formattedName = endpointName;
+        if (endpointGroupingRule4Openapi != null) {
+            formattedName = formatByOpenapi(serviceName, formattedName.toString());
+        }
+
+        if (endpointGroupingRule != null) {
+            formattedName = formatByCustom(serviceName, formattedName.toString());
         }

Review comment:
       ```suggestion
               formattedName = formatByCustom(serviceName, formattedName);
           }
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       I'd rather put these GET:/products, etc. etc. into `` so you don't need to escape the characters, which is error prone

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       I'd rather put these GET:/products, etc. etc. into `` so you don't need to escape the characters, which is error prone, same as other places

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,291 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+   |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`. For example, the document below has a full custom config.
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+1. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here are some cases:
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |

Review comment:
       See 
   ```suggestion
      | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}\>:\${PATH} | true | \<GET\>:/products/{id} |
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,291 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+   |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`. For example, the document below has a full custom config.
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+1. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here are some cases:
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |

Review comment:
       See
   ```suggestion
      | GET:/products/123 | serviceB | default | \${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
   ```

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       - `$`, `<`, and `>` has no special meanings in GitHub markdown, they may have in other extended markdown engine.
   
   - You don't have consistent style in terms of quoting in backticks or not, for example you quote them here 
   <img width="1065" alt="Screen Shot 2021-06-18 at 17 54 24" src="https://user-images.githubusercontent.com/15965696/122543360-46e75100-d05e-11eb-8d81-bbe8a1806e58.png">
   but not in this table
   
   - If you choose not to quote in `` but with `\` to escape those characters, see 
   
   - There are cases when users may look into the source codes and copy the example with those `\`, which doesn't work.

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       - `$`, `<`, and `>` has no special meanings in GitHub markdown, they may have in other extended markdown engine.
   
   - You don't have consistent style in terms of quoting in backticks or not, for example you quote them here 
   <img width="1065" alt="Screen Shot 2021-06-18 at 17 54 24" src="https://user-images.githubusercontent.com/15965696/122543360-46e75100-d05e-11eb-8d81-bbe8a1806e58.png">
   but not in this table
   
   - If you choose not to quote in `` but with `\` to escape those characters, see https://github.com/apache/skywalking/pull/7130#discussion_r654305167 and https://github.com/apache/skywalking/pull/7130#discussion_r654304411
   
   - There are cases when users may look into the source codes and copy the example with those `\`, which doesn't work.

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       - `$`, `<`, and `>` has no special meanings in GitHub markdown, their special meanings is in other extended markdown engines I think, such as StackOverflow, etc.
   
   - You don't have consistent style in terms of quoting in backticks or not, for example you quote them here 
   <img width="1065" alt="Screen Shot 2021-06-18 at 17 54 24" src="https://user-images.githubusercontent.com/15965696/122543360-46e75100-d05e-11eb-8d81-bbe8a1806e58.png">
   but not in this table
   
   - If you choose not to quote in `` but with `\` to escape those characters, see https://github.com/apache/skywalking/pull/7130#discussion_r654305167 and https://github.com/apache/skywalking/pull/7130#discussion_r654304411
   
   - There are cases when users may look into the source codes and copy the example with those `\`, which doesn't work.

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,319 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   \${METHOD} is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   \${PATH} is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+      |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |
+   | x-sw-endpoint-name-match-rule | false | The rule used to match the endpoint.| \${METHOD}:\${PATH} |
+   | x-sw-endpoint-name-format | false | The endpoint name after grouping.| \${METHOD}:\${PATH} |
+
+   These extensions are under `OpenAPI Object`.
+   We highly recommend using the default config, the custom config would be considered as part of the match rules (regex pattern).
+   We provide some cases in `org.apache.skywalking.oap.server.core.config.group.openapi.EndpointGroupingRuleReader4OpenapiTest`, you could validate your custom config as well.
+
+2. Put the OpenAPI definition documents into folder `openapi-definitions`, SkyWalking could read all documents or documents in subfolders from it, so you can organize these documents by yourself. For example:
+  ```
+├── openapi-definitions
+│   ├── serviceA-api-v1
+│   │   ├── customerAPI-v1.yaml
+│   │   └── productAPI-v1.yaml
+│   └── serviceB-api-v2
+│       └── productAPI-v2.yaml
+```
+3. Turn the feature on by setting the `Core Module` configuration `${SW_CORE_ENABLE_ENDPOINT_NAME_GROUPING_BY_OPAENAPI:true}`
+
+### Rules match priority 
+We recommend designing the API path as clear as possible. If the API path is fuzzy and an endpoint name might match multiple paths, SkyWalking would follow the match priority to select one as below orders:
+1. The exact path matched first. 
+   Eg. `/products or /products/inventory`
+2. The path which has the less variables.
+   Eg. `/products/{var1}/{var2} and /products/{var1}/abc`, endpoint name `/products/123/abc` will match the second one.
+3. If the paths have the same number of variables, match the longest path, and the vars are considered to be `1`.
+   Eg. `/products/abc/{var1} and products/{var12345}/ef`, endpoint name `/products/abc/ef` will match the first one, because `length("abc") = 3` is larger than `length("ef") = 2`.
+### Examples
+If we have an OpenAPI definition doc `productAPI-v2.yaml` like this:
+```yaml
+
+openapi: 3.0.0
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+
+tags:
+  - name: product
+    description: product
+  - name: relatedProducts
+    description: Related Products
+
+paths:
+  /products:
+    get:
+      tags:
+        - product
+      summary: Get all products list
+      description: Get all products list.
+      operationId: getProducts
+      responses:
+        "200":
+          description: Success
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: "#/components/schemas/Product"
+  /products/{region}/{country}:
+    get:
+      tags:
+        - product
+      summary: Get products regional
+      description: Get products regional with the given id.
+      operationId: getProductRegional
+      parameters:
+        - name: region
+          in: path
+          description: Products region
+          required: true
+          schema:
+            type: string
+        - name: country
+          in: path
+          description: Products country
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Product"
+        "400":
+          description: Invalid parameters supplied
+  /products/{id}:
+    get:
+      tags:
+        - product
+      summary: Get product details
+      description: Get product details with the given id.
+      operationId: getProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/ProductDetails"
+        "400":
+          description: Invalid product id
+    post:
+      tags:
+        - product
+      summary: Update product details
+      description: Update product details with the given id.
+      operationId: updateProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+        - name: name
+          in: query
+          description: Product name
+          required: true
+          schema:
+            type: string
+      responses:
+        "200":
+          description: successful operation
+    delete:
+      tags:
+        - product
+      summary: Delete product details
+      description: Delete product details with the given id.
+      operationId: deleteProduct
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+  /products/{id}/relatedProducts:
+    get:
+      tags:
+        - relatedProducts
+      summary: Get related products
+      description: Get related products with the given product id.
+      operationId: getRelatedProducts
+      parameters:
+        - name: id
+          in: path
+          description: Product id
+          required: true
+          schema:
+            type: integer
+            format: int64
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/RelatedProducts"
+        "400":
+          description: Invalid product id
+
+components:
+  schemas:
+    Product:
+      type: object
+      description: Product id and name
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+      required:
+        - id
+        - name
+    ProductDetails:
+      type: object
+      description: Product details
+      properties:
+        id:
+          type: integer
+          format: int64
+          description: Product id
+        name:
+          type: string
+          description: Product name
+        description:
+          type: string
+          description: Product description
+      required:
+        - id
+        - name
+    RelatedProducts:
+      type: object
+      description: Related Products
+      properties:
+        id:
+          type: integer
+          format: int32
+          description: Product id
+        relatedProducts:
+          type: array
+          description: List of related products
+          items:
+            $ref: "#/components/schemas/Product"
+
+
+```
+
+Here give some scenario we might use:
+1. Only set the `x-sw-service-name`, `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` are default:
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+2. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+3. Set the `x-sw-service-name` , `x-sw-endpoint-name-match-rule` and `x-sw-endpoint-name-format` :
+``` yaml
+openapi: 3.0.0
+x-sw-service-name: serviceB
+x-sw-endpoint-name-match-rule: "<${METHOD}>:${PATH}"
+x-sw-endpoint-name-format: "<${METHOD}>:${PATH}"
+
+info:
+  description: OpenAPI definition for SkyWalking test.
+  version: v2
+  title: Product API
+  ...
+```
+
+   | Incoming Endpiont | Incoming Service | x-sw-endpoint-name-match-rule | x-sw-endpoint-name-format | Matched | Grouping Result |
+   |-----|-----|-----|-----|-----|-----|
+   | GET:/products | serviceB | default | default | true | GET:/products |
+   | GET:/products/123 | serviceB | default |default |  true | GET:/products{id} |
+   | GET:/products/asia/cn | serviceB | default | default | true | GET:/products/{region}/{country} |
+   | GET:/products/123/abc/efg | serviceB | default |default |  false | GET:/products/123/abc/efg | 
+   | \<GET\>:/products/123 | serviceB | default | default | false | \<GET\>:/products/123|
+   | GET:/products/123 | serviceC | default | default | false | GET:/products/123 |
+   | \<GET\>:/products/123 | serviceB | \<\${METHOD}\>:\${PATH} | \<\${METHOD}>:\${PATH} | true | \<GET\>:/products/{id} |
+   | GET:/products/123 | serviceB | default | ${PATH}:\<\${METHOD}\> | true | /products/{id}:\<GET\> |
+   | /products/123:\<GET\> | serviceB | ${PATH}:\<\${METHOD}\> | default | true | GET:/products/{id} |

Review comment:
       - `$`, `<`, and `>` has no special meanings in GitHub markdown, their special meanings is in other extended markdown engines I think, such as StackOverflow, etc.
   
   - You don't have consistent style in terms of quoting in backticks or not, for example you quote them here 
   <img width="1065" alt="Screen Shot 2021-06-18 at 17 54 24" src="https://user-images.githubusercontent.com/15965696/122543360-46e75100-d05e-11eb-8d81-bbe8a1806e58.png">
   but not in this table
   
   - If you choose not to quote in `` but with `\` to escape those characters, you miss some of them, see https://github.com/apache/skywalking/pull/7130#discussion_r654305167 and https://github.com/apache/skywalking/pull/7130#discussion_r654304411
   
   - There are cases when users may look into the source codes and copy the example with those `\`, which doesn't work.

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,293 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   `${METHOD}` is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   `${PATH}` is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+   |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |

Review comment:
       Yes they matched 

##########
File path: docs/en/setup/backend/endpoint-grouping-rules.md
##########
@@ -1,15 +1,293 @@
 # Group Parameterized Endpoints
-In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution, 
+In most cases, the endpoint should be detected automatically through the language agents, service mesh observability solution,
 or configuration of meter system.
 
-There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name, 
+There are some special cases, especially when people use REST style URI, the application codes put the parameter in the endpoint name,
 such as putting order id in the URI, like `/prod/ORDER123` and `/prod/ORDER123`. But logically, people expect they could
 have an endpoint name like `prod/{order-id}`. This is the feature of parameterized endpoint grouping designed for.
 
+If the incoming endpoint name hit the rules, SkyWalking will grouping the endpoint by rules.
+
+SkyWalking provides 2 ways to support endpoint grouping:
+1. Endpoint name grouping by OpenAPI definitions.
+2. Endpoint name grouping by custom configuration.
+
+The 2 grouping features can work together in sequence.
+## Endpoint name grouping by OpenAPI definitions
+The OpenAPI definitions are the documents based on The [OpenAPI Specification (OAS)](https://github.com/OAI/OpenAPI-Specification) which used to define a standard, language-agnostic interface for HTTP APIs.
+SkyWalking now support `OAS v2.0+)`, could parse the documents `(yaml)` and build the grouping rules from them automatically.
+
+
+### How to use
+1. Add some `Specification Extensions` for SkyWalking in the OpenAPI definition documents:<br />
+   `${METHOD}` is a reserved placeholder which represents the HTTP method eg. `POST/GET...` <br />
+   `${PATH}` is a reserved placeholder which represents the path eg. `/products/{id}`.
+
+   | Extension Name | Required | Description | Default Value |
+   |-----|-----|-----|-----|
+   | x-sw-service-name | true | The service name to which these endpoints belong | |

Review comment:
       The folder can be any number depth
   
   
   ```
   a
    |--b
    |--|--c
    |--|--|--d
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org