Fix a duplicate config key and polish doc (#9521)
This commit is contained in:
kezhenxu94
GitHub
parent
f8b89b78cd
commit
e1a5ee198f
|
|
@ -4,11 +4,11 @@ Probe protocols describe and define how agents send collected metrics, logs, tra
|
|||
### Tracing
|
||||
There are two types of protocols that help language agents work in distributed tracing.
|
||||
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
[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.
|
||||
[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.
|
||||
|
||||
- **Trace Data Protocol** is an out-of-wire data format. Agent/SDK uses this to send traces to SkyWalking OAP server.
|
||||
|
|
@ -21,7 +21,7 @@ Please read SkyWalking language agents documentation to see whether it is suppor
|
|||
|
||||
### Metrics
|
||||
|
||||
SkyWalking has a native metrics format, and supports widely used metric formats, such as Prometheus, OpenCensus, and Zabbix.
|
||||
SkyWalking has a native metrics format, and supports widely used metric formats, such as Prometheus, OpenCensus, OpenTelemetry, and Zabbix.
|
||||
|
||||
The native metrics format definition could be found [here](https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto).
|
||||
Typically, the agent meter plugin (e.g. [Java Meter Plugin](https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/java-plugin-development-guide/#meter-plugin)) and
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ SkyWalking leverages K8s kube-state-metrics (KSM) and cAdvisor for collecting me
|
|||
|
||||
## Data flow
|
||||
1. K8s kube-state-metrics and cAdvisor collect metrics data from K8s.
|
||||
2. OpenTelemetry Collector fetches metrics from kube-state-metrics and cAdvisor via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus GRPC Exporter.
|
||||
2. OpenTelemetry Collector fetches metrics from kube-state-metrics and cAdvisor via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus gRPC Exporter or OpenTelemetry gRPC exporter.
|
||||
3. The SkyWalking OAP Server access to K8s's `API Server` gets meta info and parses the expression with [MAL](../../concepts-and-designs/mal.md) to filter/calculate/aggregate and store the results.
|
||||
|
||||
## Setup
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ SkyWalking leverages prometheus/mysqld_exporter for collecting metrics data from
|
|||
|
||||
## Data flow
|
||||
1. mysqld_exporter collect metrics data from MySQL.
|
||||
2. OpenTelemetry Collector fetches metrics from mysqld_exporter via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus GRPC Exporter.
|
||||
2. OpenTelemetry Collector fetches metrics from mysqld_exporter via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus gRPC Exporter or OpenTelemetry gRPC exporter.
|
||||
3. The SkyWalking OAP Server parses the expression with [MAL](../../concepts-and-designs/mal.md) to filter/calculate/aggregate and store the results.
|
||||
|
||||
## Set up
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# PostgreSQL monitoring
|
||||
# PostgreSQL monitoring
|
||||
SkyWalking leverages postgres-exporter for collecting metrics data from PostgreSQL. It leverages OpenTelemetry Collector to transfer the metrics to
|
||||
[OpenTelemetry receiver](opentelemetry-receiver.md) and into the [Meter System](./../../concepts-and-designs/meter.md).
|
||||
[OpenTelemetry receiver](opentelemetry-receiver.md) and into the [Meter System](./../../concepts-and-designs/meter.md).
|
||||
|
||||
## Data flow
|
||||
1. postgres-exporter collect metrics data from PostgreSQL.
|
||||
2. OpenTelemetry Collector fetches metrics from postgres-exporter via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus GRPC Exporter.
|
||||
3. The SkyWalking OAP Server parses the expression with [MAL](../../concepts-and-designs/mal.md) to filter/calculate/aggregate and store the results.
|
||||
2. OpenTelemetry Collector fetches metrics from postgres-exporter via Prometheus Receiver and pushes metrics to SkyWalking OAP Server via the OpenCensus gRPC Exporter or OpenTelemetry gRPC exporter.
|
||||
3. The SkyWalking OAP Server parses the expression with [MAL](../../concepts-and-designs/mal.md) to filter/calculate/aggregate and store the results.
|
||||
|
||||
## Set up
|
||||
## Set up
|
||||
1. Set up [postgres-exporter](https://github.com/prometheus-community/postgres_exporter#quick-start).
|
||||
2. Set up [OpenTelemetry Collector ](https://opentelemetry.io/docs/collector/getting-started/#docker). For details on Prometheus Receiver in OpenTelemetry Collector, refer to [here](../../../../test/e2e-v2/cases/postgresql/postgres-exporter/otel-collector-config.yaml).
|
||||
2. Set up [OpenTelemetry Collector ](https://opentelemetry.io/docs/collector/getting-started/#docker). For details on Prometheus Receiver in OpenTelemetry Collector, refer to [here](../../../../test/e2e-v2/cases/postgresql/postgres-exporter/otel-collector-config.yaml).
|
||||
3. Config SkyWalking [OpenTelemetry receiver](opentelemetry-receiver.md).
|
||||
|
||||
## PostgreSQL Monitoring
|
||||
|
|
@ -22,7 +22,7 @@ PostgreSQL monitoring provides monitoring of the status and resources of the Pos
|
|||
| Effective Cache | GB | meter_pg_effective_cache | The planner's assumption about the total size of the data caches | postgres-exporter|
|
||||
| Maintenance Work Mem | MB | meter_pg_maintenance_work_mem | The maximum memory to be used for maintenance operations| postgres-exporter|
|
||||
| Seq Page Cost | | meter_pg_seq_page_cost | The planner's estimate of the cost of a sequentially fetched disk page.| postgres-exporter|
|
||||
| Random Page Cost| | meter_pg_random_page_cost | The planner's estimate of the cost of a nonsequentially fetched disk page. | postgres-exporter|
|
||||
| Random Page Cost| | meter_pg_random_page_cost | The planner's estimate of the cost of a nonsequentially fetched disk page. | postgres-exporter|
|
||||
| Max Worker Processes | | meter_pg_max_worker_processes | Maximum number of concurrent worker processes | postgres-exporter|
|
||||
| Max WAL Size | GB | meter_max_wal_size | The WAL size that triggers a checkpoint | postgres-exporter|
|
||||
| Max Parallel Workers | | meter_pg_max_parallel_workers | The maximum number of parallel processes per executor node| postgres-exporter|
|
||||
|
|
@ -46,8 +46,6 @@ PostgreSQL monitoring provides monitoring of the status and resources of the Pos
|
|||
|
||||
|
||||
## Customizations
|
||||
You can customize your own metrics/expression/dashboard panel.
|
||||
The metrics definition and expression rules are found in `/config/otel-rules/postgresql.yaml`.
|
||||
You can customize your own metrics/expression/dashboard panel.
|
||||
The metrics definition and expression rules are found in `/config/otel-rules/postgresql.yaml`.
|
||||
The PostgreSQL dashboard panel configurations are found in `/config/ui-initialized-templates/postgresql`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ VM entity as a `Service` in OAP and on the `Layer: OS_LINUX`.
|
|||
|
||||
## Data flow
|
||||
1. The Prometheus node-exporter collects metrics data from the VMs.
|
||||
2. The OpenTelemetry Collector fetches metrics from node-exporter via Prometheus Receiver and pushes metrics to the SkyWalking OAP Server via the OpenCensus gRPC Exporter.
|
||||
2. The OpenTelemetry Collector fetches metrics from node-exporter via Prometheus Receiver and pushes metrics to the SkyWalking OAP Server via the OpenCensus gRPC Exporter or OpenTelemetry gRPC exporter.
|
||||
3. The SkyWalking OAP Server parses the expression with [MAL](../../concepts-and-designs/mal.md) to filter/calculate/aggregate and store the results.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -338,7 +338,6 @@ receiver-meter:
|
|||
receiver-otel:
|
||||
selector: ${SW_OTEL_RECEIVER:default}
|
||||
default:
|
||||
enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc"}
|
||||
enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc,otlp"}
|
||||
enabledOtelRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_RULES:"istio-controlplane,k8s-node,oap,vm,mysql,postgresql"}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,17 +15,17 @@
|
|||
|
||||
receivers:
|
||||
prometheus:
|
||||
config:
|
||||
scrape_configs:
|
||||
- job_name: 'postgresql-monitoring'
|
||||
scrape_interval: 5s
|
||||
static_configs:
|
||||
- targets: ['postgres-exporter:9187']
|
||||
config:
|
||||
scrape_configs:
|
||||
- job_name: "postgresql-monitoring"
|
||||
scrape_interval: 5s
|
||||
static_configs:
|
||||
- targets: ["postgres-exporter:9187"]
|
||||
processors:
|
||||
batch:
|
||||
|
||||
exporters:
|
||||
opencensus:
|
||||
otlp:
|
||||
endpoint: oap:11800
|
||||
tls:
|
||||
insecure: true
|
||||
|
|
@ -35,9 +35,9 @@ service:
|
|||
pipelines:
|
||||
metrics:
|
||||
receivers:
|
||||
- prometheus
|
||||
- prometheus
|
||||
processors:
|
||||
- batch
|
||||
- batch
|
||||
exporters:
|
||||
- logging
|
||||
- opencensus
|
||||
- logging
|
||||
- otlp
|
||||
|
|
|
|||
|
|
@ -17,16 +17,16 @@ receivers:
|
|||
prometheus:
|
||||
config:
|
||||
scrape_configs:
|
||||
- job_name: 'vm-monitoring' # make sure to use this in the vm.yaml to filter only VM metrics
|
||||
- job_name: "vm-monitoring" # make sure to use this in the vm.yaml to filter only VM metrics
|
||||
scrape_interval: 10s
|
||||
static_configs:
|
||||
- targets: [ 'vm-service:9100' ]
|
||||
- targets: ["vm-service:9100"]
|
||||
|
||||
processors:
|
||||
batch:
|
||||
|
||||
exporters:
|
||||
opencensus:
|
||||
otlp:
|
||||
endpoint: "oap:11800" # The OAP Server address
|
||||
###############################################################################
|
||||
# OTEL previous version before 0.34.0 the config format, eg. 0.29.0 should be:#
|
||||
|
|
@ -38,7 +38,7 @@ exporters:
|
|||
tls:
|
||||
insecure: true
|
||||
#insecure: true
|
||||
# Exports data to the console
|
||||
# Exports data to the console
|
||||
logging:
|
||||
logLevel: debug
|
||||
|
||||
|
|
@ -47,4 +47,4 @@ service:
|
|||
metrics:
|
||||
receivers: [prometheus]
|
||||
processors: [batch]
|
||||
exporters: [opencensus,logging]
|
||||
exporters: [otlp, logging]
|
||||
|
|
|
|||
Loading…
Reference in New Issue