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 2019/03/11 09:14:45 UTC

[incubator-skywalking] 01/01: New architecture graph, new documents.

This is an automated email from the ASF dual-hosted git repository.

wusheng pushed a commit to branch doc
in repository https://gitbox.apache.org/repos/asf/incubator-skywalking.git

commit 63cadbbe5a6ab3986f08d8b13974967c1c48c700
Author: Wu Sheng <wu...@foxmail.com>
AuthorDate: Mon Mar 11 17:14:36 2019 +0800

    New architecture graph, new documents.
---
 README.md                                    |  2 +-
 docs/en/setup/backend/advanced-deployment.md | 37 ++++++++++++++++++++++++++++
 docs/en/setup/backend/backend-receivers.md   | 19 +++++++++++++-
 docs/en/setup/backend/backend-setup.md       |  2 ++
 4 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index d40a315..438259e 100644
--- a/README.md
+++ b/README.md
@@ -31,7 +31,7 @@ The core features are following.
 - Alarm
 
 
-<img src="http://skywalking.apache.org/assets/frame.jpeg"/>
+<img src="http://skywalking.apache.org/assets/frame.jpeg?u=20190311"/>
 
 SkyWalking supports to collect telemetry (traces and metrics) data from multiple sources
 and multiple formats,
diff --git a/docs/en/setup/backend/advanced-deployment.md b/docs/en/setup/backend/advanced-deployment.md
new file mode 100644
index 0000000..0fa1eca
--- /dev/null
+++ b/docs/en/setup/backend/advanced-deployment.md
@@ -0,0 +1,37 @@
+# Advanced deployment
+OAP servers inter communicate with each other in a cluster environment. 
+In the cluster mode, you could run in different roles.
+- Mixed(default)
+- Receiver
+- Aggregator
+
+In some time, users want to deploy cluster nodes with explicit role. Then could use this.
+
+## Mixed
+Default role, the OAP should take responsibilities of
+1. Receive agent traces or metrics.
+1. Do L1 aggregation
+1. Internal communication(send/receive)
+1. Do L2 aggregation
+1. Persistence
+1. Alarm
+
+## Receiver
+The OAP should take responsibilities of
+1. Receive agent traces or metrics.
+1. Do L1 aggregation
+1. Internal communication(send)
+
+## Aggregator
+The OAP should take responsibilities of
+1. Internal communication(receive)
+1. Do L2 aggregation
+1. Persistence
+1. Alarm
+
+___
+These roles are designed for complex deployment requirements based on security and network policy.
+
+## Kubernetes
+If you are using our native [Kubernetes coordinator](backend-cluster.md#kubernetes), the `labelSelector`
+setting is used for `Aggregator` choose rules. Choose the right OAP deployment based on your requirements.
\ No newline at end of file
diff --git a/docs/en/setup/backend/backend-receivers.md b/docs/en/setup/backend/backend-receivers.md
index 5ffc24f..237240c 100644
--- a/docs/en/setup/backend/backend-receivers.md
+++ b/docs/en/setup/backend/backend-receivers.md
@@ -42,4 +42,21 @@ receiver_zipkin:
     host: 0.0.0.0
     port: 9411
     contextPath: /
-```
\ No newline at end of file
+```
+
+## gRPC/HTTP server for receiver
+In default, all gRPC/HTTP services should be served at `core/gRPC` and `core/rest`.
+But the `receiver-sharing-server` module provide a way to make all receivers serving at
+different ip:port, if you set them explicitly. 
+```yaml
+receiver-sharing-server:
+  default:
+    restHost: ${SW_SHARING_SERVER_REST_HOST:0.0.0.0}
+    restPort: ${SW_SHARING_SERVER_REST_PORT:12800}
+    restContextPath: ${SW_SHARING_SERVER_REST_CONTEXT_PATH:/}
+    gRPCHost: ${SW_SHARING_SERVER_GRPC_HOST:0.0.0.0}
+    gRPCPort: ${SW_SHARING_SERVER_GRPC_PORT:11800}
+```
+
+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.
\ 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 0c30535..61e39b9 100644
--- a/docs/en/setup/backend/backend-setup.md
+++ b/docs/en/setup/backend/backend-setup.md
@@ -75,6 +75,8 @@ most of backend analysis capabilities based on the scripts. Here is the descript
 which helps you to understand which metric 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 
 rules targeting the analysis oal metric objects.
+1. [Advanced deployment options](advanced-deployment.md). If you want to deploy backend in very large
+scale and support high payload, you may need this. 
 
 ## Telemetry for backend
 OAP backend cluster itself underlying is a distributed streaming process system. For helping the Ops team,