Follow the istio getting started guide if you do not have a cluster with istio already installed.
Deploy both the istio mesh and the sample application to test with.
https://istio.io/latest/docs/setup/getting-started/
The collector has been tested with istioctl
version 1.19.x
& 1.20.x
The istio collector can be deployed either as Istio telemetry or Istio Envoyfilter depending on the collector_mode in values.yaml. The main difference between them is the istio Envoyfilter can be configured when the request and response body need to be collected and APIs discovered from the installed application. In contrast, it is not available in Istio telemetry which collects only other data like Method, Path, Host, status_code, content_type, and so on.
Firstly a reference to the discovery collector (which will be deployed in the suqsequent steps) will need to be registered in the istio MeshConfig to send trace data to the discovery service.
See the Provider Selection section for some details: https://istio.io/latest/docs/tasks/observability/telemetry/#provider-selection
There is an example of the patch that will need to be configured on the mesh in the apidiscovery/patches directory.
This is a complete example of what the istio
configmap could look like but the salient lines from the example which need to be added to your own configuration under extensionProviders are the following
extensionProviders:
- name: "discoveryOtelCollector"
opentelemetry:
service: "management-api-discovery-otel-collector.istio-system.svc.cluster.local"
port: 5555
These can be added by doing an edit on the istio
configmap which will be in the namespace where istio is deployed.
e.g.
kubectl edit configmap istio -n <istio-system>
Or if you have deployed istio via the IstioOperator you can configure the same via the MeshConfig
See here for more details: https://istio.io/v1.10/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig
- Deploy any rest api app deployment and service and make sure the Istio VirtualService is deployed.
1.1 As part of the Istio deployment where the application is deployed will have been annotated so that all pods in that namespace will have the istio-proxy envoy sidecar deployed on them. - The EnvoyFilter Istio CR EnvoyFilter.yaml has been installed when the collector_mode is envoyfilter in values.yaml.
2.1istioctl proxy-config
allows you to see all the envoy configurations applied to a pod. It can be filtered to see the configured envoy clusters, listeners, routes, etc.
e.g. Running theistioctl proxy-config
against the created rest api pod will be used to validate that the Envoy Filter has been appliedistioctl pc listener <podname> -n <namespace> -o yaml
- Change the envoy logging level on the rest api pod so that the debug logs used in the wasm filter show up
istioctl pc log <podname> -n <namespace> --level debug
Example output :
wasmfiltertest-6df8655d7b-plg7w.default:
active loggers:
admin: debug
alternate_protocols_cache: debug
aws: debug
assert: debug
backtrace: debug
basic_auth: debug
cache_filter: debug
client: debug
config: debug
connection: debug
conn_handler: debug
compression: debug
credential_injector: debug
...
- Optionally, at this point any API calls which run through the rest api app will be collected by the envoy wasm filter to send to the Otel collector every 3 minutes and are discovered.
- The istio-proxy logs on the pod can be seen to check the wasm filter logs
kubectl logs <podname> -n <namespace> -c istio-proxy
The Envoy Filter can be uninstalled with the following steps
- Run
kubectl delete EnvoyFilter wasm-envoy-filter -n istio-system
- Restart all the pods that are configured in any namespaces to collect traces through EnvoyFilter.