This is an automated email from the ASF dual-hosted git repository.
kezhenxu94 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/skywalking.git
The following commit(s) were added to refs/heads/master by this push:
new 5e455c4 Polish doc structure. (#6278)
5e455c4 is described below
commit 5e455c48b92c6c9fd9ec12195740279c4d71721d
Author: 吴晟 Wu Sheng <[email protected]>
AuthorDate: Fri Jan 29 14:26:10 2021 +0800
Polish doc structure. (#6278)
---
README.md | 9 ++-
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 +-
5 files changed, 77 insertions(+), 62 deletions(-)
diff --git a/README.md b/README.md
index 1f7b6e5..0b8ed22 100644
--- a/README.md
+++ b/README.md
@@ -25,21 +25,24 @@ The core features are following.
- Slow services and endpoints detected
- Performance optimization
- Distributed tracing and context propagation
-- Database access metrics. Detect slow database access statements(including
SQL statements).
+- Database access metrics. Detect slow database access statements(including
SQL statements)
- Alarm
- Browser performance monitoring
+- Infrastructure(VM, network, disk etc.) monitoring
+- Collaboration across metrics, traces, and logs
<img src="http://skywalking.apache.org/assets/frame-v8.jpg?u=20201105"/>
-SkyWalking supports to collect telemetry (traces and metrics) data from
multiple sources
+SkyWalking supports to collect telemetry (metrics, traces, and logs) data from
multiple sources
and multiple formats,
including
1. Java, .NET Core, NodeJS, PHP, and Python auto-instrument agents.
1. Go and C++ SDKs.
1. LUA agent especially for Nginx, OpenResty.
+1. Browser agent.
1. Service Mesh Observability. Control panel and data panel.
1. Metrics system, including Prometheus, OpenTelemetry, Spring
Sleuth(Micrometer).
-1. Browser application performance, including metrics and error logs.
+1. Logs.
1. Zipkin v1/v2 and Jaeger gRPC format with limited topology and metrics
analysis.(Experimental).
SkyWalking OAP is using the STAM(Streaming Topology Analysis Method) to
analysis topology in the tracing based agent scenario
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.
![http://skywalking.apache.org/assets/frame-v8.jpg?u=20201105"/](http://skywalking.apache.org/assets/frame-v8.jpg?u=20201105"/){kind=link}