Use SkyWalking for OpenFunction as an Observability Solution
Learn how to use SkyWalking for OpenFunction as an observability solution.
This document describes how to use SkyWalking for OpenFunction as an observability solution.
Overview
Although FaaS allows developers to focus on their business code without worrying about the underlying implementations, it is difficult to troubleshoot the service system. OpenFunction tries to introduce capabilities of observability to improve its usability and stability.
SkyWalking provides solutions for observing and monitoring distributed systems in many different scenarios. OpenFunction has bundled go2sky(SkyWalking’s Golang agent) in OpenFunction tracer options to provide distributed tracing, statistics of function performance, and functions dependency map.
Prerequisites
- You have installed OpenFunction.
- You have followed the OpenFunction prerequisites to create a container registry secret, a Kafka cluster and a Kafka topic.
- You have installed SkyWalking v9.
Tracing Parameters
The following table describes the tracing parameters.
Name | Description | Example |
---|---|---|
enabled | Switch for tracing, default to false . | true, false |
provider.name | Provider name can be set to “skywalking”, “opentelemetry” (pending). | “skywalking” |
provider.oapServer | The oap server address. | “skywalking-opa:11800” |
tags | A collection of key-value pairs for Span custom tags in tracing. | |
tags.func | The name of function. It will be automatically filled. | “function-a” |
tags.layer | Indicates the type of service being tracked. It should be set to “faas” when you use the function. | “faas” |
baggage | A collection of key-value pairs, exists in the tracing and also needs to be transferred across process boundaries. |
The following is a JSON formatted configuration reference that guides the formatting structure of the tracing configuration.
{
"enabled": true,
"provider": {
"name": "skywalking",
"oapServer": "skywalking-oap:11800"
},
"tags": {
"func": "function-a",
"layer": "faas",
"tag1": "value1",
"tag2": "value2"
},
"baggage": {
"key": "key1",
"value": "value1"
}
}
Enable Tracing Configuration of OpenFunction
Option 1: global configuration
This document uses skywalking-oap.default:11800
as an example of the skywalking-oap address in the cluster.
Run the following command to modify the configmap
openfunction-config
in theopenfunction
namespace.kubectl edit configmap openfunction-config -n openfunction
Modify the content under
data.plugins.tracing
by referring to the following example and save the change.data:
tracing: |
enabled: true
provider:
name: "skywalking"
oapServer: "skywalking-oap:11800"
tags:
func: tracing-function
layer: faas
tag1: value1
tag2: value2
baggage:
key: "key1"
value: "value1"
Option 2: function-level configuration
To enable tracing configuration in the function-level, add the field plugins.tracing
under metadata.annotations
in the function manifest as the following example.
metadata:
name: tracing-function
spec:
serving:
tracing:
enabled: true
provider:
name: "skywalking"
oapServer: "skywalking-oap:11800"
tags:
func: tracing-function
layer: faas
tag1: value1
tag2: value2
baggage:
key: "key1"
value: "value1"
It is recommended that you use the global tracing configuration, or you have to add function-level tracing configuration for every function you create.
Use SkyWalking as a Distributed Tracing Solution
Create functions by referring to this document. You can find more examples to create sync and async functions in OpenFunction Quickstarts.
Then, you can observe the flow of entire link on the SkyWalking UI.
You can also observe the comparison of the response time of the Knative runtime function (function-front) in the running state and under cold start.
In cold start:
In running: