* Finish step one, source and entity changed. * Step 2, finish the basic and core DAO changes. * Step 3. Change all source codes of backend, and make project compiling successfully. * Make startup successful and persistence works. * Fix dead codes in the MySQLTableInstaller. * Fix mischange. * Fix MySQL storage bootstrap error. * Rollback dependency change. * Simply enable tailing logs from container no mater it's in CI or not * Fix segment table issue. * Fix MySQL Instanller. * Support Influxdb implementation of new endpoint traffic. * Set and modify timeout to 90mins * Remove unnecessary entity in the EndpointTraffic. * Fix wrong entity builder and make name more clear. * Fix 2 equal methods bug. * Fix InfluxDB identifier(name) conflict issue. * Fix endpoint topology query, endpoint id should be changed as a string. * Fix a missing change. * Fix a wrong commit. * Column name can't be changed, due to it affect the hybrid metadb(h2/mysql) query, change it explicitly with double quotation marks. * Fix formats. * Remove endpoint/operation register from the agent. and change the plugin tests(without local tests). operationId relation codes have been removed from agent too. * Try to fix the hytrix case. * Fix 3 cases. * Try to fix cases. * Fix 2. * Fix one. * Fix the serviceId type mis-change. * Fix int query * Fix hystrix case. * Fix a case. * Fix EndpointCallRelationDispatcher set the source/dest endpoint without id encoding. * Update documentation and add 2 test cases. Co-authored-by: kezhenxu94 <kezhenxu94@163.com> |
||
|---|---|---|
| .. | ||
| HTTP-API-Protocol.md | ||
| JVM-Protocol.md | ||
| README.md | ||
| Skywalking-Cross-Process-Correlation-Headers-Protocol-v1.md | ||
| Skywalking-Cross-Process-Propagation-Headers-Protocol-v2.md | ||
| Trace-Data-Protocol-v2.md | ||
| query-protocol.md | ||
README.md
Protocols
There are two types of protocols list here.
-
Probe Protocol. Include the descriptions and definitions about how agent send collected metrics data and traces, also the formats of each entities.
-
Query Protocol. The backend provide query capability to SkyWalking own UI and others. These queries are based on GraphQL.
Probe Protocols
They also related to the probe group, for understand that, look Concepts and Designs document. These groups are Language based native agent protocol, Service Mesh protocol and 3rd-party instrument protocol.
Register Protocol
Register protocol is shared in Language based native agent protocol[Required] and Service Mesh probe protocol[Optional].
Service, Service Instance, Network address and Endpoint could do register to get an unique integer ID to replace the literal string name and attributes. The probe could use IDs to reduce the cost of memory and network bandwidth. Service and Instance register are required in the language agent. All other cases, register are optional.
Language based native agent protocol
There is two types of protocols to make language agents work in distributed environments.
- 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.
- 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 v2 is the new protocol for in-wire context propagation, started in 6.0.0-beta release, v1 is no longer supported.
Cross Process Correlation Headers Protocol v1 is a new in-wire context propagation additional and optional protocols.
Please read SkyWalking language agents documentations to see whether it is supported.
This protocol defines the data format of transporting custom data with Cross Process Propagation Headers Protocol v2.
SkyWalking javaagent begins to support this since 7.1.0.
Since SkyWalking v7.1.0, SkyWalking agent and backend are using Trace Data Protocol v2.1. SkyWalking Trace Data Protocol v2.1 defines the communication way and format between agent 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:
- Service Name or ID at both sides.
- Service Instance Name or ID at both sides.
- Endpoint. URI in HTTP, service method full signature in gRPC.
- Latency. In milliseconds.
- Response code in HTTP
- Status. Success or fail.
- Protocol. HTTP, gRPC
- DetectPoint. In Service Mesh sidecar,
clientorserver. In normal L7 proxy, value isproxy.
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.
Backend is based on modularization principle, so very easy to extend a new receiver to support new protocol/format.
Query Protocol
Query protocol follows GraphQL grammar, provides data query capabilities, which depends on your analysis metrics. Read query protocol doc for more details.