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/05/12 12:04:49 UTC
[skywalking] branch master updated: Refine protocols (#6931)
This is an automated email from the ASF dual-hosted git repository.
wusheng 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 6060464 Refine protocols (#6931)
6060464 is described below
commit 6060464743da4ef021e540914ea3f7378341794c
Author: Wing <69...@users.noreply.github.com>
AuthorDate: Wed May 12 19:57:10 2021 +0800
Refine protocols (#6931)
---
docs/en/protocols/Browser-HTTP-API-Protocol.md | 12 ++---
docs/en/protocols/README.md | 63 ++++++++++++--------------
2 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/docs/en/protocols/Browser-HTTP-API-Protocol.md b/docs/en/protocols/Browser-HTTP-API-Protocol.md
index 245711f..72265e0 100644
--- a/docs/en/protocols/Browser-HTTP-API-Protocol.md
+++ b/docs/en/protocols/Browser-HTTP-API-Protocol.md
@@ -1,15 +1,15 @@
# HTTP API Protocol
-HTTP API Protocol defines the API data format, including api request and response data format.
+HTTP API Protocol defines the API data format, including API request and response data format.
They use the HTTP1.1 wrapper of the official [SkyWalking Browser Protocol](Browser-Protocol.md). Read it for more details.
## Performance Data Report
-Detail information about data format can be found in [BrowserPerf.proto](https://github.com/apache/skywalking-data-collect-protocol/blob/master/browser/BrowserPerf.proto).
+Detailed information about data format can be found in [BrowserPerf.proto](https://github.com/apache/skywalking-data-collect-protocol/blob/master/browser/BrowserPerf.proto).
### POST http://localhost:12800/browser/perfData
-Send a performance data object with JSON format.
+Send a performance data object in JSON format.
Input:
@@ -41,11 +41,11 @@ Http Status: 204
## Error Log Report
-Detail information about data format can be found in [BrowserPerf.proto](https://github.com/apache/skywalking-data-collect-protocol/blob/master/browser/BrowserPerf.proto).
+Detailed information about data format can be found in [BrowserPerf.proto](https://github.com/apache/skywalking-data-collect-protocol/blob/master/browser/BrowserPerf.proto).
### POST http://localhost:12800/browser/errorLogs
-Send an error log object list with JSON format.
+Send an error log object list in JSON format.
Input:
@@ -84,7 +84,7 @@ Http Status: 204
### POST http://localhost:12800/browser/errorLog
-Send a single error log object with JSON format.
+Send a single error log object in JSON format.
Input:
diff --git a/docs/en/protocols/README.md b/docs/en/protocols/README.md
index 42b9179..8dfd87d 100644
--- a/docs/en/protocols/README.md
+++ b/docs/en/protocols/README.md
@@ -1,48 +1,44 @@
# Protocols
-There are two types of protocols list here.
+There are two different types of protocols.
-- [**Probe Protocol**](#probe-protocols). Include the descriptions and definitions about how agent send collected metrics data and traces, also the formats of each entities.
+- [**Probe Protocol**](#probe-protocols). It includes descriptions and definitions on how agents send collected metrics data and traces, as well as the format of each entity.
-- [**Query Protocol**](#query-protocol). The backend provide query capability to SkyWalking own UI and others. These queries are based on GraphQL.
+- [**Query Protocol**](#query-protocol). The backend enables the query function in SkyWalking's own UI and other UIs. These queries are based on GraphQL.
## Probe Protocols
-They also related to the probe group, for understand that, look [Concepts and Designs](../concepts-and-designs/overview.md) document.
-These groups are **Language based native agent protocol**, **Service Mesh protocol** and **3rd-party instrument protocol**.
-
-### Language based native agent protocol
-There are two types of protocols to make language agents work in distributed environments.
-1. **Cross Process Propagation Headers Protocol** and **Cross Process Correlation Headers Protocol** are in wire data format,
-agent/SDK usually uses HTTP/MQ/HTTP2 headers
-to carry the data with rpc request. The remote agent will receive this in the request handler, and bind the context
-with this specific request.
-1. **Trace Data Protocol** is out of wire data, agent/SDK uses this to send traces and metrics to skywalking or other
-compatible backend.
-
-[Cross Process Propagation Headers Protocol v3](Skywalking-Cross-Process-Propagation-Headers-Protocol-v3.md) is the new protocol for
-in-wire context propagation, started in 8.0.0 release.
-
-[Cross Process Correlation Headers Protocol v1](Skywalking-Cross-Process-Correlation-Headers-Protocol-v1.md) is a new in-wire context propagation additional and optional protocols.
-Please read SkyWalking language agents documentations to see whether it is supported.
+They also related to the probe group. For more information, see [Concepts and Designs](../concepts-and-designs/overview.md).
+These groups are **language-based native agent protocol**, **service mesh protocol** and **3rd-party instrument protocol**.
+
+### Language-based native agent protocol
+There are two types of protocols that help language agents work in distributed environments.
+1. **Cross Process Propagation Headers Protocol** and **Cross Process Correlation Headers Protocol** come in in-wire data format. Agent/SDK usually uses HTTP/MQ/HTTP2 headers
+to carry the data with the RPC request. The remote agent will receive this in the request handler, and bind the context with this specific request.
+1. **Trace Data Protocol** is in out-of-wire data format. Agent/SDK uses this to send traces and metrics to SkyWalking or other compatible backends.
+
+[Cross Process Propagation Headers Protocol v3](Skywalking-Cross-Process-Propagation-Headers-Protocol-v3.md) has been the new protocol for in-wire context propagation since the version 8.0.0 release.
+
+[Cross Process Correlation Headers Protocol v1](Skywalking-Cross-Process-Correlation-Headers-Protocol-v1.md) is a new in-wire context propagation protocol which is additional and optional.
+Please read SkyWalking language agents documentation to see whether it is supported.
This protocol defines the data format of transporting custom data with `Cross Process Propagation Headers Protocol`.
-SkyWalking javaagent begins to support this since 8.0.0.
+It has been supported by the SkyWalking javaagent since 8.0.0,
-[SkyWalking Trace Data Protocol v3](Trace-Data-Protocol-v3.md) defines the communication way and format between agent and backend.
+[SkyWalking Trace Data Protocol v3](Trace-Data-Protocol-v3.md) defines the communication method and format between the agent and backend.
-[SkyWalking Log Data Protocol](Log-Data-Protocol.md) defines the communication way and format between agent and backend.
+[SkyWalking Log Data Protocol](Log-Data-Protocol.md) defines the communication method and format between the agent and backend.
### Browser probe protocol
-The browser probe, such as [skywalking-client-js](https://github.com/apache/skywalking-client-js) could use this protocol to send to backend. This service provided by gRPC.
+The browser probe, such as [skywalking-client-js](https://github.com/apache/skywalking-client-js), could use this protocol to send data to the backend. This service is provided by gRPC.
-[SkyWalking Browser Protocol](Browser-Protocol.md) define the communication way and format between `skywalking-client-js` and backend.
+[SkyWalking Browser Protocol](Browser-Protocol.md) defines the communication method and format between `skywalking-client-js` and backend.
### Service Mesh probe protocol
-The probe in sidecar or proxy could use this protocol to send data to backendEnd. This service provided by gRPC, requires
-the following key info:
+The probe in sidecar or proxy could use this protocol to send data to the backend. This service provided by gRPC requires
+the following key information:
-1. Service Name or ID at both sides.
-1. Service Instance Name or ID at both sides.
+1. Service Name or ID on both sides.
+1. Service Instance Name or ID on both sides.
1. Endpoint. URI in HTTP, service method full signature in gRPC.
1. Latency. In milliseconds.
1. Response code in HTTP
@@ -52,14 +48,13 @@ the following key info:
### Events Report Protocol
-The protocol is used to report events to the backend. The [doc](../concepts-and-designs/event.md) introduces the definition of an event, and [the protocol repository](https://github.com/apache/skywalking-data-collect-protocol/blob/master/event) defines gRPC services and messages formats of events.
+The protocol is used to report events to the backend. The [doc](../concepts-and-designs/event.md) introduces the definition of an event, and [the protocol repository](https://github.com/apache/skywalking-data-collect-protocol/blob/master/event) defines gRPC services and message formats of events.
### 3rd-party instrument protocol
-3rd-party instrument protocols are not defined by SkyWalking. They are just protocols/formats, which SkyWalking is compatible and
-could receive from their existed libraries. SkyWalking starts with supporting Zipkin v1, v2 data formats.
+3rd-party instrument protocols are not defined by SkyWalking. They are just protocols/formats with which SkyWalking is compatible, and SkyWalking could receive them from their existing libraries. SkyWalking starts with supporting Zipkin v1, v2 data formats.
-Backend is based on modularization principle, so very easy to extend a new receiver to support new protocol/format.
+The backend has a modular design, so it is very easy to extend a new receiver to support a new protocol/format.
## Query Protocol
-Query protocol follows GraphQL grammar, provides data query capabilities, which depends on your analysis metrics.
+The query protocol follows GraphQL grammar, and provides data query capabilities, which depends on your analysis metrics.
Read [query protocol doc](query-protocol.md) for more details.