Receiver is a defined concept in SkyWalking's backend. All modules which are responsible for receiving telemetry or tracing data from other systems being monitored are all called receivers. If you are looking for the pull mode, take a look at the fetcher document.
We have the following receivers, and default
implementors are provided in our Apache distribution.
metrics_service
and ALS(access log service)
are supported by this receiver. The OAL script supports all GAUGE type metrics.The sample settings of these receivers are by default included in application.yml
, and also listed here:
receiver-register: selector: ${SW_RECEIVER_REGISTER:default} default: receiver-trace: selector: ${SW_RECEIVER_TRACE:default} default: receiver-jvm: selector: ${SW_RECEIVER_JVM:default} default: service-mesh: selector: ${SW_SERVICE_MESH:default} default: envoy-metric: selector: ${SW_ENVOY_METRIC:default} default: acceptMetricsService: ${SW_ENVOY_METRIC_SERVICE:true} alsHTTPAnalysis: ${SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS:""} receiver_zipkin: selector: ${SW_RECEIVER_ZIPKIN:-} default: host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0} port: ${SW_RECEIVER_ZIPKIN_PORT:9411} contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/} jettyMinThreads: ${SW_RECEIVER_ZIPKIN_JETTY_MIN_THREADS:1} jettyMaxThreads: ${SW_RECEIVER_ZIPKIN_JETTY_MAX_THREADS:200} jettyIdleTimeOut: ${SW_RECEIVER_ZIPKIN_JETTY_IDLE_TIMEOUT:30000} jettyAcceptorPriorityDelta: ${SW_RECEIVER_ZIPKIN_JETTY_DELTA:0} jettyAcceptQueueSize: ${SW_RECEIVER_ZIPKIN_QUEUE_SIZE:0} receiver-profile: selector: ${SW_RECEIVER_PROFILE:default} default: receiver-browser: selector: ${SW_RECEIVER_BROWSER:default} default: sampleRate: ${SW_RECEIVER_BROWSER_SAMPLE_RATE:10000} log-analyzer: selector: ${SW_LOG_ANALYZER:default} default: lalFiles: ${SW_LOG_LAL_FILES:default} malFiles: ${SW_LOG_MAL_FILES:""} configuration-discovery: selector: ${SW_CONFIGURATION_DISCOVERY:default} default: receiver-event: selector: ${SW_RECEIVER_EVENT:default} default:
By default, all gRPC/HTTP services should be served at core/gRPC
and core/rest
. But the receiver-sharing-server
module allows all receivers to be served at different ip:port, if you set them explicitly.
receiver-sharing-server: selector: ${SW_RECEIVER_SHARING_SERVER:default} default: host: ${SW_RECEIVER_JETTY_HOST:0.0.0.0} contextPath: ${SW_RECEIVER_JETTY_CONTEXT_PATH:/} authentication: ${SW_AUTHENTICATION:""} jettyMinThreads: ${SW_RECEIVER_SHARING_JETTY_MIN_THREADS:1} jettyMaxThreads: ${SW_RECEIVER_SHARING_JETTY_MAX_THREADS:200} jettyIdleTimeOut: ${SW_RECEIVER_SHARING_JETTY_IDLE_TIMEOUT:30000} jettyAcceptorPriorityDelta: ${SW_RECEIVER_SHARING_JETTY_DELTA:0} jettyAcceptQueueSize: ${SW_RECEIVER_SHARING_JETTY_QUEUE_SIZE:0}
Note: If you add these settings, make sure that they are not the same as the core module. This is because gRPC/HTTP servers of the core are still used for UI and OAP internal communications.
The OpenTelemetry receiver supports ingesting agent metrics by meter-system. The OAP can load the configuration at bootstrap. If the new configuration is not well-formed, the OAP may fail to start up. The files are located at $CLASSPATH/otel-<handler>-rules
. E.g. The oc
handler loads rules from $CLASSPATH/otel-oc-rules
.
Supported handlers:
oc
: OpenCensus gRPC service handler.Notice: Set SW_OTEL_RECEIVER=default
through system environment or change receiver-otel/selector=${SW_OTEL_RECEIVER:default}
to activate the OpenTelemetry receiver.
The rule file should be in YAML format, defined by the scheme described in prometheus-fetcher. Note: receiver-otel
only supports the group
, defaultMetricLevel
, and metricsRules
nodes of the scheme due to its push mode.
To activate the oc
handler and relevant rules of istio
:
receiver-otel: // Change selector value to default, for activating the otel receiver. selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc"} enabledOcRules: ${SW_OTEL_RECEIVER_ENABLED_OC_RULES:"istio-controlplane"}
The receiver adds labels with key = node_identifier_host_name
and key = node_identifier_pid
to the collected data samples, and values from Node.identifier.host_name
and Node.identifier.pid
defined in OpenCensus Agent Proto, for identification of the metric data.
Rule Name | Description | Configuration File | Data Source |
---|---|---|---|
istio-controlplane | Metrics of Istio control panel | otel-oc-rules/istio-controlplane.yaml | Istio Control Panel -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
oap | Metrics of SkyWalking OAP server itself | otel-oc-rules/oap.yaml | SkyWalking OAP Server(SelfObservability) -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
vm | Metrics of VMs | otel-oc-rules/vm.yaml | Prometheus node-exporter(VMs) -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
k8s-cluster | Metrics of K8s cluster | otel-oc-rules/k8s-cluster.yaml | K8s kube-state-metrics -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
k8s-node | Metrics of K8s cluster | otel-oc-rules/k8s-node.yaml | cAdvisor & K8s kube-state-metrics -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
k8s-service | Metrics of K8s cluster | otel-oc-rules/k8s-service.yaml | cAdvisor & K8s kube-state-metrics -> OpenTelemetry Collector --OC format--> SkyWalking OAP Server |
The meter receiver supports accepting the metrics into the meter-system. The OAP can load the configuration at bootstrap.
The file is written in YAML format, defined by the scheme described in backend-meter.
To activate the default
implementation:
receiver-meter: selector: ${SW_RECEIVER_METER:default} default:
To activate the meter rule files:
Put your customized meter file xxx.yaml ( mal format) in the config/meter-analyzer-config
directory and configure meteranalyzer activefiles=${SW_ METER_ ANALYZER_ ACTIVE_ FILES:xxx}
agent-analyzer: selector: ${SW_AGENT_ANALYZER:default} default: meterAnalyzerActiveFiles: ${SW_METER_ANALYZER_ACTIVE_FILES:} # Which files could be meter analyzed, files split by ","
The receiver adds labels with key = service
and key = instance
to the collected data samples, and values from service and service instance name defined in SkyWalking Agent, for identification of the metric data.
The Zipkin receiver makes the OAP server work as an alternative Zipkin server implementation. It supports Zipkin v1/v2 formats through HTTP service. Make sure you use this with SW_STORAGE=zipkin-elasticsearch
option to activate Zipkin storage implementation. Once this receiver and storage are activated, SkyWalking‘s native traces would be ignored, and SkyWalking wouldn’t analyze topology, metrics, and endpoint dependency from Zipkin's trace.
Use the following config to activate it.
receiver_zipkin: selector: ${SW_RECEIVER_ZIPKIN:-} default: host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0} port: ${SW_RECEIVER_ZIPKIN_PORT:9411} contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/} jettyMinThreads: ${SW_RECEIVER_ZIPKIN_JETTY_MIN_THREADS:1} jettyMaxThreads: ${SW_RECEIVER_ZIPKIN_JETTY_MAX_THREADS:200} jettyIdleTimeOut: ${SW_RECEIVER_ZIPKIN_JETTY_IDLE_TIMEOUT:30000} jettyAcceptorPriorityDelta: ${SW_RECEIVER_ZIPKIN_JETTY_DELTA:0} jettyAcceptQueueSize: ${SW_RECEIVER_ZIPKIN_QUEUE_SIZE:0}
NOTE: Zipkin receiver requires zipkin-elasticsearch
storage implementation to be activated. Read this doc to learn about Zipkin as a storage option.