Refine protocols (#6949)
This commit is contained in:
Wing
GitHub
parent
9ffa07f626
commit
86dab08354
|
|
@ -7,38 +7,38 @@ also implemented in [HTTP 1.1](HTTP-API-Protocol.md)
|
|||
|
||||
### Report service instance status
|
||||
1. Service Instance Properties
|
||||
Service instance has more information than a name, once the agent wants to report this, use `ManagementService#reportInstanceProperties` service
|
||||
providing a string-key/string-value pair list as the parameter. `language` of target instance is expected at least.
|
||||
Service instance contains more information than just a name. Once the agent wants to report this, use `ManagementService#reportInstanceProperties` service
|
||||
to provide a string-key/string-value pair list as the parameter. `language` of target instance is expected at least.
|
||||
|
||||
2. Service Ping
|
||||
Service instance should keep alive with the backend. The agent should set a scheduler using `ManagementService#keepAlive` service in every minute.
|
||||
Service instance should keep alive with the backend. The agent should set a scheduler using `ManagementService#keepAlive` service every minute.
|
||||
|
||||
### Send trace and metrics
|
||||
After you have service id and service instance id, you could send traces and metrics. Now we
|
||||
After you have the service ID and service instance ID ready, you could send traces and metrics. Now we
|
||||
have
|
||||
1. `TraceSegmentReportService#collect` for skywalking native trace format
|
||||
1. `JVMMetricReportService#collect` for skywalking native jvm format
|
||||
1. `TraceSegmentReportService#collect` for the SkyWalking native trace format
|
||||
1. `JVMMetricReportService#collect` for the SkyWalking native jvm format
|
||||
|
||||
For trace format, there are some notices
|
||||
1. Segment is a concept in SkyWalking, it should include all span for per request in a single OS process, usually single thread based on language.
|
||||
2. Span has 3 different groups.
|
||||
For trace format, note that:
|
||||
1. The segment is a unique concept in SkyWalking. It should include all spans for each request in a single OS process, which is usually a single language-based thread.
|
||||
2. There are three types of spans.
|
||||
|
||||
* EntrySpan
|
||||
EntrySpan represents a service provider, also the endpoint of server side. As an APM system, we are targeting the
|
||||
application servers. So almost all the services and MQ-consumer are EntrySpan(s).
|
||||
EntrySpan represents a service provider, which is also the endpoint on the server end. As an APM system, SkyWalking targets the
|
||||
application servers. Therefore, almost all the services and MQ-consumers are EntrySpans.
|
||||
|
||||
* LocalSpan
|
||||
LocalSpan represents a normal Java method, which don't relate with remote service, neither a MQ producer/consumer
|
||||
nor a service(e.g. HTTP service) provider/consumer.
|
||||
LocalSpan represents a typical Java method which is not related to remote services. It is neither a MQ producer/consumer
|
||||
nor a provider/consumer of a service (e.g. HTTP service).
|
||||
|
||||
* ExitSpan
|
||||
ExitSpan represents a client of service or MQ-producer, as named as `LeafSpan` at early age of SkyWalking.
|
||||
e.g. accessing DB by JDBC, reading Redis/Memcached are cataloged an ExitSpan.
|
||||
ExitSpan represents a client of service or MQ-producer. It is known as the `LeafSpan` in the early stages of SkyWalking.
|
||||
For example, accessing DB by JDBC, and reading Redis/Memcached are classified as ExitSpans.
|
||||
|
||||
3. Span across thread or process parent info is called Reference. Reference carries trace id,
|
||||
segment id, span id, service name, service instance name, endpoint name and target address used at client side(not required in across thread)
|
||||
3. Cross-thread/process span parent information is called "reference". Reference carries the trace ID,
|
||||
segment ID, span ID, service name, service instance name, endpoint name, and target address used on the client end (note: this is not required in cross-thread operations)
|
||||
of this request in the parent.
|
||||
Follow [Cross Process Propagation Headers Protocol v3](Skywalking-Cross-Process-Propagation-Headers-Protocol-v3.md) to get more details.
|
||||
See [Cross Process Propagation Headers Protocol v3](Skywalking-Cross-Process-Propagation-Headers-Protocol-v3.md) for more details.
|
||||
|
||||
4. `Span#skipAnalysis` could be TRUE, if this span doesn't require backend analysis.
|
||||
4. `Span#skipAnalysis` may be TRUE, if this span doesn't require backend analysis.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ native visualization tool or 3rd party system, including Web UI, CLI or private
|
|||
Query protocol official repository, https://github.com/apache/skywalking-query-protocol.
|
||||
|
||||
### Metadata
|
||||
Metadata includes the brief info of the whole under monitoring services and their instances, endpoints, etc.
|
||||
Use multiple ways to query this meta data.
|
||||
Metadata contains concise information on all services and their instances, endpoints, etc. under monitoring.
|
||||
You may query the metadata in different ways.
|
||||
```graphql
|
||||
extend type Query {
|
||||
getGlobalBrief(duration: Duration!): ClusterBrief
|
||||
|
|
@ -35,7 +35,7 @@ extend type Query {
|
|||
```
|
||||
|
||||
### Topology
|
||||
Show the topology and dependency graph of services or endpoints. Including direct relationship or global map.
|
||||
The topology and dependency graphs of services and endpoints. Includes direct relationships or global maps.
|
||||
|
||||
```graphql
|
||||
extend type Query {
|
||||
|
|
@ -51,13 +51,13 @@ extend type Query {
|
|||
```
|
||||
|
||||
### Metrics
|
||||
Metrics query targets all the objects defined in [OAL script](../concepts-and-designs/oal.md). You could get the
|
||||
Metrics query targets all objects defined in [OAL script](../concepts-and-designs/oal.md). You may obtain the
|
||||
metrics data in linear or thermodynamic matrix formats based on the aggregation functions in script.
|
||||
|
||||
3 types of metrics could be query
|
||||
1. Single value. The type of most default metrics is single value, consider this as default. `getValues` and `getLinearIntValues` are suitable for this.
|
||||
1. Multiple value. One metrics defined in OAL include multiple value calculations. Use `getMultipleLinearIntValues` to get all values. `percentile` is a typical multiple value func in OAL.
|
||||
1. Heatmap value. Read [Heatmap in WIKI](https://en.wikipedia.org/wiki/Heat_map) for detail. `thermodynamic` is the only OAL func. Use `getThermodynamic` to get the values.
|
||||
3 types of metrics can be queried:
|
||||
1. Single value. Most default metrics are in single value. `getValues` and `getLinearIntValues` are suitable for this purpose.
|
||||
1. Multiple value. A metric defined in OAL includes multiple value calculations. Use `getMultipleLinearIntValues` to obtain all values. `percentile` is a typical multiple value function in OAL.
|
||||
1. Heatmap value. Read [Heatmap in WIKI](https://en.wikipedia.org/wiki/Heat_map) for details. `thermodynamic` is the only OAL function. Use `getThermodynamic` to get the values.
|
||||
```graphql
|
||||
extend type Query {
|
||||
getValues(metric: BatchMetricConditions!, duration: Duration!): IntValues
|
||||
|
|
@ -74,10 +74,10 @@ extend type Query {
|
|||
Metrics are defined in the `config/oal/*.oal` files.
|
||||
|
||||
### Aggregation
|
||||
Aggregation query means the metrics data need a secondary aggregation in query stage, which makes the query
|
||||
interfaces have some different arguments. Such as, `TopN` list of services is a very typical aggregation query,
|
||||
metrics stream aggregation just calculates the metrics values of each service, but the expected list needs ordering metrics data
|
||||
by the values.
|
||||
Aggregation query means that the metrics data need a secondary aggregation at query stage, which causes the query
|
||||
interfaces to have some different arguments. A typical example of aggregation query is the `TopN` list of services.
|
||||
Metrics stream aggregation simply calculates the metrics values of each service, but the expected list requires ordering metrics data
|
||||
by their values.
|
||||
|
||||
Aggregation query is for single value metrics only.
|
||||
|
||||
|
|
@ -95,16 +95,16 @@ extend type Query {
|
|||
```
|
||||
|
||||
### Others
|
||||
The following query(s) are for specific features, including trace, alarm or profile.
|
||||
The following queries are for specific features, including trace, alarm, and profile.
|
||||
1. Trace. Query distributed traces by this.
|
||||
1. Alarm. Through alarm query, you can have alarm trend and details.
|
||||
1. Alarm. Through alarm query, you can find alarm trends and their details.
|
||||
|
||||
The actual query GraphQL scrips could be found inside `query-protocol` folder in [here](../../../oap-server/server-query-plugin/query-graphql-plugin/src/main/resources).
|
||||
The actual query GraphQL scripts can be found in the `query-protocol` folder [here](../../../oap-server/server-query-plugin/query-graphql-plugin/src/main/resources).
|
||||
|
||||
## Condition
|
||||
### Duration
|
||||
Duration is a widely used parameter type as the APM data is time related. The explanations are as following.
|
||||
Step is related the precision.
|
||||
Duration is a widely used parameter type as the APM data is time-related. See the following for more details.
|
||||
Step relates to precision.
|
||||
```graphql
|
||||
# The Duration defines the start and end time for each query operation.
|
||||
# Fields: `start` and `end`
|
||||
|
|
|
|||
Loading…
Reference in New Issue