wu-sheng commented on a change in pull request #4972:
URL: https://github.com/apache/skywalking/pull/4972#discussion_r456863960
##########
File path: docs/en/setup/backend/backend-receivers.md
##########
@@ -14,6 +14,7 @@ We have following receivers, and `default` implementors are
provided in our Apac
1. **receiver_zipkin**. See [details](#zipkin-receiver).
1. **receiver_jaeger**. See [details](#jaeger-receiver).
1. **receiver-oc**. See [details](#oc-receiver).
+1. **receiver-meter**. See [details](backend-meter.md).
Review comment:
You missed the receiver set up doc in this page.
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
Review comment:
This file is still in `server-bootstrap/src/main/resources/`, so, once
this file exists, does it mean the index will be created after the OAP starts
up? I think all meter system config should be OFF in default.
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
+
+### Meters configure
+
+```yaml
+# Meter config allow your to recompute
+meters:
+ # Meter name which combines with a prefix 'meter_' as the index/table name
in storage.
+ - name: <string>
+ # The meter scope
+ scope:
+ # Scope type should be one of SERVICE, SERVICE_INSTANCE, ENDPOINT
+ type: <string>
+ # <Optional> Appoint the endpoint name if using ENDPOINT scope
+ endpoint: <string>
+ # The agent source of the transformation operation.
+ meter:
+ # The transformation operation from prometheus metrics to Skywalking
ones.
+ operation: <string>
+ # Meter value parse groovy script.
+ value: <string>
+ # <Optional> Appoint percentiles if using avgHistogramPercentile
operation.
+ percentile:
+ - <rank>
+```
+
+#### Meter transform operation
+
+The available operations are `avg`, `avgHistogram` and
`avgHistogramPercentile`. The `avg` and `avgXXX` mean to average
+the raw received metrics.
+
+When you specify `avgHistogram` and `avgHistogramPercentile`, the source
should be the type of `histogram`.
+
+#### Meter value script
+
+The script is provide a easy way to custom build a complex value, and it also
support combine multiple meter into one.
+
+##### Meter value grammar
+```
+// Declare the meter value.
+meter[METER_NAME]
+[.tagFilter(TAG_KEY, TAG_VALUE)]
+.FUNCTION(VALUE | METER)
+```
+##### Meter Name
+
+Use name to refer the metrics raw data from agent side.
+
+##### Tag Filter
+
+Use the meter tag to filter the meter value.
+> meter["test_meter"].tagFilter("k1", "v1")
+
+In this case, filter the tag key equals `k1` and tag value equals `v1` value
from `test_meter`.
+
+##### Aggregation Function
+
+Use multiple build-in methods to help operate the value.
+
+Provided functions
+- `add`. Add value into meter. Support single value.
+> meter["test_meter"].add(2)
+
+In this case, all of the meter values will add `2`.
+> meter["test_meter1"].add(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will add value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `subtract`. Subtract value into meter. Support single value.
+> meter["test_meter"].subtract(2)
+
+In this case, all of the meter values will subtract `2`.
+> meter["test_meter1"].subtract(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will subtract value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `multiply`. Multiply value into meter. Support single value.
+> meter["test_meter"].multiply(2)
+
+In this case, all of the meter values will multiply `2`.
+> meter["test_meter1"].multiply(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will multiply value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `divide`. Divide value into meter. Support single value.
+> meter["test_meter"].divide(2)
+
+In this case, all of the meter values will divide `2`.
+> meter["test_meter1"].divide(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will divide value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `scale`. Scale value into meter. Support single value.
+> meter["test_meter"].scale(2)
+
+In this case, all of the meter values will scale `2`.
+- `rate`. Rate value from the time range. Support single value and Histogram.
Review comment:
```suggestion
- `rate`.(Not Recommended) Rate value from the time range. Support single
value and Histogram.
```
##########
File path:
oap-server/server-bootstrap/src/main/resources/ui-initialized-templates.yml
##########
@@ -1067,4 +1067,124 @@ templates:
# False means providing a basic template, user needs to add it manually.
activated: true
# True means wouldn't show up on the dashboard. Only keeps the definition
in the storage.
+ disabled: false
+ - name: Spring
+ type: "DASHBOARD"
+ configuration: |-
+ [
+ {
+ "name":"Spring",
Review comment:
```suggestion
"name":"Spring ",
```
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
Review comment:
`Spring Sleuth Metrics Analysis` provides a fully detailed documents
including
1. Set up agent
1. Set up backend receiver
1. Add UI dashboard
And the screenshot could be hosted in `skywalking-website` repo, there are a
lot of screenshots hosted there.
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
+
+### Meters configure
+
+```yaml
+# Meter config allow your to recompute
+meters:
+ # Meter name which combines with a prefix 'meter_' as the index/table name
in storage.
+ - name: <string>
+ # The meter scope
+ scope:
+ # Scope type should be one of SERVICE, SERVICE_INSTANCE, ENDPOINT
+ type: <string>
+ # <Optional> Appoint the endpoint name if using ENDPOINT scope
+ endpoint: <string>
+ # The agent source of the transformation operation.
+ meter:
+ # The transformation operation from prometheus metrics to Skywalking
ones.
+ operation: <string>
+ # Meter value parse groovy script.
+ value: <string>
+ # <Optional> Appoint percentiles if using avgHistogramPercentile
operation.
+ percentile:
+ - <rank>
+```
+
+#### Meter transform operation
+
+The available operations are `avg`, `avgHistogram` and
`avgHistogramPercentile`. The `avg` and `avgXXX` mean to average
+the raw received metrics.
+
+When you specify `avgHistogram` and `avgHistogramPercentile`, the source
should be the type of `histogram`.
+
+#### Meter value script
+
+The script is provide a easy way to custom build a complex value, and it also
support combine multiple meter into one.
+
+##### Meter value grammar
+```
+// Declare the meter value.
+meter[METER_NAME]
+[.tagFilter(TAG_KEY, TAG_VALUE)]
+.FUNCTION(VALUE | METER)
+```
+##### Meter Name
+
+Use name to refer the metrics raw data from agent side.
+
+##### Tag Filter
+
+Use the meter tag to filter the meter value.
+> meter["test_meter"].tagFilter("k1", "v1")
+
+In this case, filter the tag key equals `k1` and tag value equals `v1` value
from `test_meter`.
+
+##### Aggregation Function
+
+Use multiple build-in methods to help operate the value.
+
+Provided functions
+- `add`. Add value into meter. Support single value.
+> meter["test_meter"].add(2)
+
+In this case, all of the meter values will add `2`.
+> meter["test_meter1"].add(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will add value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `subtract`. Subtract value into meter. Support single value.
+> meter["test_meter"].subtract(2)
+
+In this case, all of the meter values will subtract `2`.
+> meter["test_meter1"].subtract(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will subtract value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `multiply`. Multiply value into meter. Support single value.
+> meter["test_meter"].multiply(2)
+
+In this case, all of the meter values will multiply `2`.
+> meter["test_meter1"].multiply(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will multiply value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `divide`. Divide value into meter. Support single value.
+> meter["test_meter"].divide(2)
+
+In this case, all of the meter values will divide `2`.
+> meter["test_meter1"].divide(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will divide value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `scale`. Scale value into meter. Support single value.
+> meter["test_meter"].scale(2)
+
+In this case, all of the meter values will scale `2`.
+- `rate`. Rate value from the time range. Support single value and Histogram.
+> meter["test_meter"].rate("P15S")
+
+In this case, all of the meter values will rate from `15s` before.
+- `irate`. IRate value from the time range. Support single value and Histogram.
+> meter["test_meter"].irate("P15S")
+
+In this case, all of the meter values will irate from `15s` before.
+- `increase`. increase value from the time range. Support single value and
Histogram.
+> meter["test_meter"].increase("P15S")
+
+In this case, all of the meter values will increase from `15s` before.
+
+If you want to use `rate`, `irate`, `increase` function, use client-side API.
+- FAQ, why no `rate`, `irate`, `increase` at the backend.
+Once the agent reconnected to another OAP instance, the time windows of rate
calculation will break. Then, the result would not be accurate.
Review comment:
```suggestion
Even we supported `rate`, `irate`, `increase` function in the backend, but
we still recommend user to consider using client-side APIs to do these. Because
1. The OAP has to set up caches to calculate the value.
1. Once the agent reconnected to another OAP instance, the time windows of
rate calculation will break. Then, the result would not be accurate.
```
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
+
+### Meters configure
+
+```yaml
+# Meter config allow your to recompute
+meters:
+ # Meter name which combines with a prefix 'meter_' as the index/table name
in storage.
+ - name: <string>
+ # The meter scope
+ scope:
+ # Scope type should be one of SERVICE, SERVICE_INSTANCE, ENDPOINT
+ type: <string>
+ # <Optional> Appoint the endpoint name if using ENDPOINT scope
+ endpoint: <string>
+ # The agent source of the transformation operation.
+ meter:
+ # The transformation operation from prometheus metrics to Skywalking
ones.
+ operation: <string>
+ # Meter value parse groovy script.
+ value: <string>
+ # <Optional> Appoint percentiles if using avgHistogramPercentile
operation.
+ percentile:
+ - <rank>
+```
+
+#### Meter transform operation
+
+The available operations are `avg`, `avgHistogram` and
`avgHistogramPercentile`. The `avg` and `avgXXX` mean to average
+the raw received metrics.
+
+When you specify `avgHistogram` and `avgHistogramPercentile`, the source
should be the type of `histogram`.
+
+#### Meter value script
+
+The script is provide a easy way to custom build a complex value, and it also
support combine multiple meter into one.
+
+##### Meter value grammar
+```
+// Declare the meter value.
+meter[METER_NAME]
+[.tagFilter(TAG_KEY, TAG_VALUE)]
+.FUNCTION(VALUE | METER)
+```
+##### Meter Name
+
+Use name to refer the metrics raw data from agent side.
+
+##### Tag Filter
+
+Use the meter tag to filter the meter value.
+> meter["test_meter"].tagFilter("k1", "v1")
+
+In this case, filter the tag key equals `k1` and tag value equals `v1` value
from `test_meter`.
+
+##### Aggregation Function
+
+Use multiple build-in methods to help operate the value.
+
+Provided functions
+- `add`. Add value into meter. Support single value.
+> meter["test_meter"].add(2)
+
+In this case, all of the meter values will add `2`.
+> meter["test_meter1"].add(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will add value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `subtract`. Subtract value into meter. Support single value.
+> meter["test_meter"].subtract(2)
+
+In this case, all of the meter values will subtract `2`.
+> meter["test_meter1"].subtract(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will subtract value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `multiply`. Multiply value into meter. Support single value.
+> meter["test_meter"].multiply(2)
+
+In this case, all of the meter values will multiply `2`.
+> meter["test_meter1"].multiply(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will multiply value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `divide`. Divide value into meter. Support single value.
+> meter["test_meter"].divide(2)
+
+In this case, all of the meter values will divide `2`.
+> meter["test_meter1"].divide(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will divide value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `scale`. Scale value into meter. Support single value.
+> meter["test_meter"].scale(2)
+
+In this case, all of the meter values will scale `2`.
+- `rate`. Rate value from the time range. Support single value and Histogram.
+> meter["test_meter"].rate("P15S")
+
+In this case, all of the meter values will rate from `15s` before.
+- `irate`. IRate value from the time range. Support single value and Histogram.
Review comment:
```suggestion
- `irate`.(Not Recommended) IRate value from the time range. Support single
value and Histogram.
```
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
+
+### Meters configure
+
+```yaml
+# Meter config allow your to recompute
+meters:
+ # Meter name which combines with a prefix 'meter_' as the index/table name
in storage.
+ - name: <string>
+ # The meter scope
+ scope:
+ # Scope type should be one of SERVICE, SERVICE_INSTANCE, ENDPOINT
+ type: <string>
+ # <Optional> Appoint the endpoint name if using ENDPOINT scope
+ endpoint: <string>
+ # The agent source of the transformation operation.
+ meter:
+ # The transformation operation from prometheus metrics to Skywalking
ones.
+ operation: <string>
+ # Meter value parse groovy script.
+ value: <string>
+ # <Optional> Appoint percentiles if using avgHistogramPercentile
operation.
+ percentile:
+ - <rank>
+```
+
+#### Meter transform operation
+
+The available operations are `avg`, `avgHistogram` and
`avgHistogramPercentile`. The `avg` and `avgXXX` mean to average
+the raw received metrics.
+
+When you specify `avgHistogram` and `avgHistogramPercentile`, the source
should be the type of `histogram`.
+
+#### Meter value script
+
+The script is provide a easy way to custom build a complex value, and it also
support combine multiple meter into one.
+
+##### Meter value grammar
+```
+// Declare the meter value.
+meter[METER_NAME]
+[.tagFilter(TAG_KEY, TAG_VALUE)]
+.FUNCTION(VALUE | METER)
+```
+##### Meter Name
+
+Use name to refer the metrics raw data from agent side.
+
+##### Tag Filter
+
+Use the meter tag to filter the meter value.
+> meter["test_meter"].tagFilter("k1", "v1")
+
+In this case, filter the tag key equals `k1` and tag value equals `v1` value
from `test_meter`.
+
+##### Aggregation Function
+
+Use multiple build-in methods to help operate the value.
+
+Provided functions
+- `add`. Add value into meter. Support single value.
+> meter["test_meter"].add(2)
+
+In this case, all of the meter values will add `2`.
+> meter["test_meter1"].add(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will add value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `subtract`. Subtract value into meter. Support single value.
+> meter["test_meter"].subtract(2)
+
+In this case, all of the meter values will subtract `2`.
+> meter["test_meter1"].subtract(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will subtract value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `multiply`. Multiply value into meter. Support single value.
+> meter["test_meter"].multiply(2)
+
+In this case, all of the meter values will multiply `2`.
+> meter["test_meter1"].multiply(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will multiply value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `divide`. Divide value into meter. Support single value.
+> meter["test_meter"].divide(2)
+
+In this case, all of the meter values will divide `2`.
+> meter["test_meter1"].divide(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will divide value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `scale`. Scale value into meter. Support single value.
+> meter["test_meter"].scale(2)
+
+In this case, all of the meter values will scale `2`.
+- `rate`. Rate value from the time range. Support single value and Histogram.
+> meter["test_meter"].rate("P15S")
+
+In this case, all of the meter values will rate from `15s` before.
+- `irate`. IRate value from the time range. Support single value and Histogram.
+> meter["test_meter"].irate("P15S")
+
+In this case, all of the meter values will irate from `15s` before.
+- `increase`. increase value from the time range. Support single value and
Histogram.
Review comment:
```suggestion
- `increase`.(Not Recommended) increase value from the time range. Support
single value and Histogram.
```
##########
File path:
oap-server/server-bootstrap/src/main/resources/ui-initialized-templates.yml
##########
@@ -1067,4 +1067,124 @@ templates:
# False means providing a basic template, user needs to add it manually.
activated: true
# True means wouldn't show up on the dashboard. Only keeps the definition
in the storage.
+ disabled: false
+ - name: Spring
Review comment:
```suggestion
- name: Spring-Sleuth
```
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
+
+### Meters configure
+
+```yaml
+# Meter config allow your to recompute
+meters:
+ # Meter name which combines with a prefix 'meter_' as the index/table name
in storage.
+ - name: <string>
+ # The meter scope
+ scope:
+ # Scope type should be one of SERVICE, SERVICE_INSTANCE, ENDPOINT
+ type: <string>
+ # <Optional> Appoint the endpoint name if using ENDPOINT scope
+ endpoint: <string>
+ # The agent source of the transformation operation.
+ meter:
+ # The transformation operation from prometheus metrics to Skywalking
ones.
+ operation: <string>
+ # Meter value parse groovy script.
+ value: <string>
+ # <Optional> Appoint percentiles if using avgHistogramPercentile
operation.
+ percentile:
+ - <rank>
+```
+
+#### Meter transform operation
+
+The available operations are `avg`, `avgHistogram` and
`avgHistogramPercentile`. The `avg` and `avgXXX` mean to average
+the raw received metrics.
+
+When you specify `avgHistogram` and `avgHistogramPercentile`, the source
should be the type of `histogram`.
+
+#### Meter value script
+
+The script is provide a easy way to custom build a complex value, and it also
support combine multiple meter into one.
+
+##### Meter value grammar
+```
+// Declare the meter value.
+meter[METER_NAME]
+[.tagFilter(TAG_KEY, TAG_VALUE)]
+.FUNCTION(VALUE | METER)
+```
+##### Meter Name
+
+Use name to refer the metrics raw data from agent side.
+
+##### Tag Filter
+
+Use the meter tag to filter the meter value.
+> meter["test_meter"].tagFilter("k1", "v1")
+
+In this case, filter the tag key equals `k1` and tag value equals `v1` value
from `test_meter`.
+
+##### Aggregation Function
+
+Use multiple build-in methods to help operate the value.
+
+Provided functions
+- `add`. Add value into meter. Support single value.
+> meter["test_meter"].add(2)
+
+In this case, all of the meter values will add `2`.
+> meter["test_meter1"].add(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will add value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `subtract`. Subtract value into meter. Support single value.
+> meter["test_meter"].subtract(2)
+
+In this case, all of the meter values will subtract `2`.
+> meter["test_meter1"].subtract(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will subtract value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `multiply`. Multiply value into meter. Support single value.
+> meter["test_meter"].multiply(2)
+
+In this case, all of the meter values will multiply `2`.
+> meter["test_meter1"].multiply(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will multiply value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `divide`. Divide value into meter. Support single value.
+> meter["test_meter"].divide(2)
+
+In this case, all of the meter values will divide `2`.
+> meter["test_meter1"].divide(meter["test_meter2"])
+
+In this case, all of the `test_meter1` values will divide value from
`test_meter2`, ensure `test_meter2` only has single value to operate, could use
`tagFilter`.
+- `scale`. Scale value into meter. Support single value.
Review comment:
What is `scale` N? Do you have some public doc to explain this name?
##########
File path:
oap-server/server-bootstrap/src/main/resources/ui-initialized-templates.yml
##########
@@ -1067,4 +1067,124 @@ templates:
# False means providing a basic template, user needs to add it manually.
activated: true
# True means wouldn't show up on the dashboard. Only keeps the definition
in the storage.
+ disabled: false
+ - name: Spring
+ type: "DASHBOARD"
+ configuration: |-
+ [
+ {
+ "name":"Spring",
+ "type":"service",
+ "children":[
+ {
+ "name":"micro-meter",
Review comment:
```suggestion
"name":"Sleuth",
```
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
Review comment:
This example should be listed separately about `Spring Sleuth Setup
Doc`. Both agent doc(Application-toolkit-meter.md) and here should provide a
link to that separated documentation.
##########
File path: docs/en/setup/backend/backend-meter.md
##########
@@ -0,0 +1,125 @@
+# Meter Receiver
+Meter receiver is accepting the metrics of [meter
protocol](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto)
format into the [Meter System](./../../concepts-and-designs/meter.md).
+
+## Module define
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+
+## Configuration file
+Meter receiver is configured via a configuration file. The configuration file
defines everything related to receiving
+ from agents, as well as which rule files to load.
+
+OAP can load the configuration at bootstrap. If the new configuration is not
well-formed, OAP fails to start up. The files
+are located at `$CLASSPATH/meter-receive-config`.
+
+The file is written in YAML format, defined by the scheme described below.
Brackets indicate that a parameter is optional.
+
+A example can be found
[here](../../../../oap-server/server-bootstrap/src/main/resources/meter-receive-config/spring.yaml)
Review comment:
And `backend-setup.md` should add a link of `Spring Sleuth Metrics
Analysis` section in `Advanced feature document link list`
----------------------------------------------------------------
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:
[email protected]
