You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by wu...@apache.org on 2021/01/29 02:10:27 UTC
[skywalking] branch polish-dc created (now 2c60950)
This is an automated email from the ASF dual-hosted git repository.
wusheng pushed a change to branch polish-dc
in repository https://gitbox.apache.org/repos/asf/skywalking.git.
at 2c60950 Polish doc structure.
This branch includes the following new commits:
new 2c60950 Polish doc structure.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
[skywalking] 01/01: Polish doc structure.
Posted by wu...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
wusheng pushed a commit to branch polish-dc
in repository https://gitbox.apache.org/repos/asf/skywalking.git
commit 2c609509be82510a35ff6b2da38984d5a303bf50
Author: Wu Sheng <wu...@foxmail.com>
AuthorDate: Fri Jan 29 10:10:10 2021 +0800
Polish doc structure.
---
docs/README.md | 5 +-
docs/en/setup/backend/backend-meter.md | 2 +-
docs/en/setup/backend/backend-receivers.md | 117 ++++++++++++++++-------------
docs/en/setup/backend/backend-setup.md | 6 +-
4 files changed, 71 insertions(+), 59 deletions(-)
diff --git a/docs/README.md b/docs/README.md
index eb1b638..4294031 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -82,7 +82,7 @@ If you are already familiar with SkyWalking, you could use this catalog to find
* [Deploy in kubernetes](en/setup/backend/backend-k8s.md). Guides you to build and use SkyWalking image, and deploy in k8s.
* [Choose storage](en/setup/backend/backend-storage.md). As we know, in default quick start, backend is running with H2 DB. But clearly, it doesn't fit the product env. In here, you could find what other choices do you have. Choose the one you like, we also welcome anyone to contribute new storage implementors.
* [Set receivers](en/setup/backend/backend-receivers.md). You could choose receivers by your requirements, most receivers are harmless, at least our default receivers are. You would set and active all receivers provided.
- * [Open fetchers](en/setup/backend/backend-fetcher.md). You could open different fetchers to read metrics from the target applications. These ones works like receivers, but in pulling mode, typically like Prometheus.
+ * [Open fetchers](en/setup/backend/backend-fetcher.md). You could open different fetchers to read metrics from the target applications. These ones work like receivers, but in pulling mode, typically like Prometheus.
* Do [trace sampling](en/setup/backend/trace-sampling.md) at backend. Trace sampling allows you to keep your metrics accurate, whilst only keeping some traces in storage based on rate.
* Follow [slow DB statement threshold](en/setup/backend/slow-db-statement.md) config document to understand how to detect slow database statements (including SQL statements) in your system.
* Official [OAL scripts](en/guides/backend-oal-scripts.md). As you known from our [OAL introduction](en/concepts-and-designs/oal.md), most of backend analysis capabilities based on the scripts. Here is the description of official scripts, which helps you to understand which metrics data are in process, also could be used in alarm.
@@ -95,8 +95,9 @@ If you are already familiar with SkyWalking, you could use this catalog to find
* [Apdex threshold](en/setup/backend/apdex-threshold.md). Configure the thresholds for different services if Apdex calculation is activated in the OAL.
* [Service Grouping](en/setup/backend/service-auto-grouping.md). An automatic grouping mechanism for all services based on name.
* [Group Parameterized Endpoints](en/setup/backend/endpoint-grouping-rules.md). Configure the grouping rules for parameterized endpoints, to improve the meaning of the metrics.
+ * [OpenTelemetry Metrics Analysis](backend-receivers.md#opentelemetry-receiver). Activate built-in configurations to convert the metrics forwarded from OpenTelemetry collector. And learn how to write your own conversion rules.
* [Meter Analysis](en/setup/backend/backend-meter.md). Set up the backend analysis rules, when use [SkyWalking Meter System Toolkit](en/setup/service-agent/java-agent/README.md#advanced-features) or meter plugins.
- * [Spring Sleuth Metrics Analysis](en/setup/backend/spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer.
+ * [Spring Sleuth Metrics Analysis](en/setup/backend/spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer.
* [UI setup document](en/setup/backend/ui-setup.md).
* [CLI setup document](https://github.com/apache/skywalking-cli).
* [UI Introduction](en/ui/README.md). Introduce the UI usage and features.
diff --git a/docs/en/setup/backend/backend-meter.md b/docs/en/setup/backend/backend-meter.md
index a86b1c2..6c5803d 100644
--- a/docs/en/setup/backend/backend-meter.md
+++ b/docs/en/setup/backend/backend-meter.md
@@ -27,7 +27,7 @@ are located at `$CLASSPATH/meter-analyzer-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-analyzer-config/spring-sleuth.yaml).
+An example can be found [here](../../../../oap-server/server-bootstrap/src/main/resources/meter-analyzer-config/spring-sleuth.yaml).
If you're using Spring sleuth, you could use [Spring Sleuth Setup](spring-sleuth-setup.md).
### Meters configure
diff --git a/docs/en/setup/backend/backend-receivers.md b/docs/en/setup/backend/backend-receivers.md
index 2a0e18d..e1777ff 100644
--- a/docs/en/setup/backend/backend-receivers.md
+++ b/docs/en/setup/backend/backend-receivers.md
@@ -10,14 +10,15 @@ We have following receivers, and `default` implementors are provided in our Apac
1. **service-mesh**. gRPC services accept data from inbound mesh probes.
1. **receiver-jvm**. gRPC services accept JVM metrics data.
1. **envoy-metric**. Envoy `metrics_service` and `ALS(access log service)` supported by this receiver. OAL script support all GAUGE type metrics.
-1. **receiver-profile**. gRPC services accept profile task status and snapshot reporter.
-1. **receiver_zipkin**. See [details](#zipkin-receiver).
-1. **receiver_jaeger**. See [details](#jaeger-receiver).
-1. **receiver-otel**. See [details](#opentelemetry-receiver).
-1. **receiver-meter**. See [details](backend-meter.md).
+1. **receiver-profile**. gRPC services accept profile task status and snapshot reporter.
+1. **receiver-otel**. See [details](#opentelemetry-receiver). Receiver for analyzing metrics data from OpenTelemetry
+1. **receiver-meter**. See [details](backend-meter.md). Receiver for analyzing metrics in SkyWalking native meter format.
1. **receiver-browser**. gRPC services to accept browser performance data and error log.
1. **receiver-log**. gRPC services accept log data.
1. **configuration-discovery**. gRPC services handle configurationDiscovery.
+1. Experimental receivers. All following receivers are in the POC stage, not production ready.
+ 1. **receiver_zipkin**. See [details](#zipkin-receiver). (Experimental)
+ 1. **receiver_jaeger**. See [details](#jaeger-receiver). (Experimental)
The sample settings of these receivers should be already in default `application.yml`, and also list here
```yaml
@@ -94,15 +95,60 @@ receiver-sharing-server:
Notice, if you add these settings, make sure they are not as same as core module,
because gRPC/HTTP servers of core are still used for UI and OAP internal communications.
-## Zipkin receiver
+## OpenTelemetry receiver
+
+OpenTelemetry receiver supports to ingest agent metrics by meter-system. 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/otel-<handler>-rules`.
+Eg, the `oc` handler loads fules from `$CLASSPATH/otel-oc-rules`,
+
+Supported handlers:
+ * `oc`: [OpenCensus](https://github.com/open-telemetry/opentelemetry-collector/blob/master/exporter/opencensusexporter/README.md) gRPC service handler.
+
+The rule file should be in YAML format, defined by the scheme described in [prometheus-fetcher](./backend-fetcher.md).
+Notice, `receiver-otel` only support `group`, `defaultMetricLevel` and `metricsRules` nodes of scheme due to the push mode it opts to.
+
+To active the `oc` handler and `istio` relevant rules:
+```yaml
+receiver-otel:
+ selector: ${SW_OTEL_RECEIVER:default}
+ default:
+ enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc"}
+ enabledOcRules: ${SW_OTEL_RECEIVER_ENABLED_OC_RULES:"istio-controlplane"}
+```
+The receiver adds labels with `key = node_identifier_host_name` and `key = node_identifier_pid` to the collected data samples，
+and values from `Node.identifier.host_name` and `Node.identifier.pid` defined in opencensus agent proto,
+to be the identification of the metric data.
+
+| Rule Name | Description | Configuration File | Data Source |
+|----|----|-----|----|
+|istio-controlplane| Metrics of Istio control panel | otel-oc-rules/istio-controlplane.yaml | Istio Control Panel -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
+|oap| Metrics of SkyWalking OAP server itself | otel-oc-rules/oap.yaml | SkyWalking OAP Server(SelfObservability) -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
+
+## Meter receiver
+
+Meter receiver supports accept the metrics into the meter-system. OAP can load the configuration at bootstrap.
+
+The file is written in YAML format, defined by the scheme described in [backend-meter](./backend-meter.md).
+
+To active the `default` implementation:
+```yaml
+receiver-meter:
+ selector: ${SW_RECEIVER_METER:default}
+ default:
+```
+
+## Experimental receivers
+All following receivers are in the POC stage, not production ready.
+
+### Zipkin receiver
Zipkin receiver could work in two different mode.
1. Tracing mode(default). Tracing mode is that, skywalking OAP acts like zipkin collector,
-fully supports Zipkin v1/v2 formats through HTTP service,
-also provide persistence and query in skywalking UI.
-But it wouldn't analysis metrics from them. In most case, I suggest you could use this feature, when metrics come from service mesh.
-Notice, in this mode, Zipkin receiver requires `zipkin-elasticsearch` storage implementation active.
-Read [this](backend-storage.md#elasticsearch-6-with-zipkin-trace-extension) to know
-how to active.
+ fully supports Zipkin v1/v2 formats through HTTP service,
+ also provide persistence and query in skywalking UI.
+ But it wouldn't analysis metrics from them. In most case, I suggest you could use this feature, when metrics come from service mesh.
+ Notice, in this mode, Zipkin receiver requires `zipkin-elasticsearch` storage implementation active.
+ Read [this](backend-storage.md#elasticsearch-6-with-zipkin-trace-extension) to know
+ how to active.
Use following config to active.
```yaml
@@ -120,8 +166,8 @@ receiver_zipkin:
```
2. Analysis mode(Not production ready), receive Zipkin v1/v2 formats through HTTP service. Transform the trace to skywalking
-native format, and analysis like skywalking trace. This feature can't work in production env right now,
-because of Zipkin tag/endpoint value unpredictable, we can't make sure it fits production env requirements.
+ native format, and analysis like skywalking trace. This feature can't work in production env right now,
+ because of Zipkin tag/endpoint value unpredictable, we can't make sure it fits production env requirements.
Active `analysis mode`, you should set `needAnalysis` config.
```yaml
@@ -141,10 +187,10 @@ receiver_zipkin:
NOTICE, Zipkin receiver is only provided in `apache-skywalking-apm-x.y.z.tar.gz` tar.
-## Jaeger receiver
+### Jaeger receiver
Jaeger receiver right now only works in `Tracing Mode`, and no analysis.
Jaeger receiver provides extra gRPC host/port, if absent, sharing-server host/port will be used, then core gRPC host/port.
-Receiver requires `jaeger-elasticsearch` storage implementation active.
+Receiver requires `jaeger-elasticsearch` storage implementation active.
Read [this](backend-storage.md#elasticsearch-6-with-jaeger-trace-extension) to know how to active.
Right now, you need [jaeger agent](https://www.jaegertracing.io/docs/1.11/architecture/#agent) to batch
@@ -160,41 +206,4 @@ receiver_jaeger:
gRPCPort: ${SW_RECEIVER_JAEGER_PORT:14250}
```
-NOTICE, Jaeger receiver is only provided in `apache-skywalking-apm-x.y.z.tar.gz` tar.
-
-## OpenTelemetry receiver
-
-OpenTelemetry receiver supports to ingest agent metrics by meter-system. 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/otel-<handler>-rules`.
-Eg, the `oc` handler loads fules from `$CLASSPATH/otel-oc-rules`,
-
-Supported handlers:
- * `oc`: [OpenCensus](https://github.com/open-telemetry/opentelemetry-collector/blob/master/exporter/opencensusexporter/README.md) gRPC service handler.
-
-The rule file should be in YAML format, defined by the scheme described in [prometheus-fetcher](./backend-fetcher.md).
-Notice, `receiver-otel` only support `group`, `defaultMetricLevel` and `metricsRules` nodes of scheme due to the push mode it opts to.
-
-To active the `oc` handler and `istio` relevant rules:
-```yaml
-receiver-otel:
- selector: ${SW_OTEL_RECEIVER:default}
- default:
- enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc"}
- enabledOcRules: ${SW_OTEL_RECEIVER_ENABLED_OC_RULES:"istio-controlplane"}
-```
-The receiver adds labels with `key = node_identifier_host_name` and `key = node_identifier_pid` to the collected data samples，
-and values from `Node.identifier.host_name` and `Node.identifier.pid` defined in opencensus agent proto,
-to be the identification of the metric data.
-
-## Meter receiver
-
-Meter receiver supports accept the metrics into the meter-system. OAP can load the configuration at bootstrap.
-
-The file is written in YAML format, defined by the scheme described in [backend-meter](./backend-meter.md).
-
-To active the `default` implementation:
-```yaml
-receiver-meter:
- selector: ${SW_RECEIVER_METER:default}
- default:
-```
+NOTICE, Jaeger receiver is only provided in `apache-skywalking-apm-x.y.z.tar.gz` tar.
\ No newline at end of file
diff --git a/docs/en/setup/backend/backend-setup.md b/docs/en/setup/backend/backend-setup.md
index 4ff27a4..c262b14 100755
--- a/docs/en/setup/backend/backend-setup.md
+++ b/docs/en/setup/backend/backend-setup.md
@@ -87,13 +87,13 @@ Choose the ones you like, we are also welcome anyone to contribute new storage i
1. [Set receivers](backend-receivers.md). You could choose receivers by your requirements, most receivers
are harmless, at least our default receivers are. You would set and active all receivers provided.
1. [Open fetchers](backend-fetcher.md). You could open different fetchers to read metrics from the target applications.
-These ones works like receivers, but in pulling mode, typically like Prometheus.
+These ones work like receivers, but in pulling mode, typically like Prometheus.
1. [Token authentication](backend-token-auth.md). You could add token authentication mechanisms to avoid `OAP` receiving untrusted data.
1. Do [trace sampling](trace-sampling.md) at backend. This sample keep the metrics accurate, only don't save some of traces
in storage based on rate.
1. Follow [slow DB statement threshold](slow-db-statement.md) config document to understand that,
how to detect the Slow database statements(including SQL statements) in your system.
-1. Official [OAL scripts](../../guides/backend-oal-scripts.md). As you known from our [OAL introduction](../../concepts-and-designs/oal.md),
+1. Official [OAL scripts](../../guides/backend-oal-scripts.md). As you have known from our [OAL introduction](../../concepts-and-designs/oal.md),
most of backend analysis capabilities based on the scripts. Here is the description of official scripts,
which helps you to understand which metrics data are in process, also could be used in alarm.
1. [Alarm](backend-alarm.md). Alarm provides a time-series based check mechanism. You could set alarm
@@ -111,6 +111,8 @@ to reflect the delegation in topology graph.
1. [Service Grouping](service-auto-grouping.md). An automatic grouping mechanism for all services based on name.
1. [Group Parameterized Endpoints](endpoint-grouping-rules.md). Configure the grouping rules for parameterized endpoints,
to improve the meaning of the metrics.
+1. [OpenTelemetry Metrics Analysis](backend-receivers.md#opentelemetry-receiver). Activate built-in configurations to convert the metrics forwarded from OpenTelemetry collector.
+And learn how to write your own conversion rules.
1. [Meter Analysis](backend-meter.md). Set up the backend analysis rules, when use [SkyWalking Meter System Toolkit](../service-agent/java-agent/README.md#advanced-features)
or meter plugins.
1. [Spring Sleuth Metrics Analysis](spring-sleuth-setup.md). Configure the agent and backend to receiver metrics from micrometer.