Telemetry FAQ

You can collect telemetry data about Istio using Prometheus. And then use Prometheus’s HTTP API to query that data.

It's sometimes useful to exclude access to specific URLs from being reported. For example, you might wish to exclude some health-checking URLs. You can skip telemetry reports specific to certain URLs by excluding them using a match clause of the telemetry configuration such as:

match: source.name != "health"

You can use docker-compose to install Prometheus, similar to when you install your application. Also, without the Kubernetes API server, components such as Mixer will need local configuration for rules/handlers/instances.

Istio does not currently provide support for pub/sub and event bus protocols. Any use of those technologies is best-effort and subject to breakage.

You can enable tracing to figure out the flow of a request in Istio.

Additionally, you can use following commands to know more about the state of the mesh:

• istioctl proxy-config: Retrieves proxy configuration for the specified pod from the endpoint proxy or Pilot when running in Kubernetes.

  # Retrieve all config for productpage-v1-bb8d5cbc7-k7qbm pod from the endpoint proxy
  $ istioctl proxy-config endpoint productpage-v1-bb8d5cbc7-k7qbm
  
  # Try the following to know more proxy-config command:
  $ istioctl proxy-config --help

• kubectl get: Gets information about different resources in mesh and routing configuration.

  # List all virtual services
  $ istioctl get virtualservices
  
  # Try following to know more proxy-config command:
  $ istioctl proxy-config --help

• Mixer AccessLogs: Mixer writes access logs that contain information about requests. You can get them as follows:

  # Fill <istio namespace> with the namespace of your istio mesh. Ex: istio-system
  $ TELEMETRY_POD=`kubectl get po -n <istio namespace> | grep istio-telemetry | awk '{print $1;}'`
  $ kubectl logs $TELEMETRY_POD -c mixer  -n istio-system  | grep accesslog

The Istio sidecar proxy (Envoy) generates the first headers.

If you already have tracing enabled, you can disable it as follows:

# Fill <istio namespace> with the namespace of your istio mesh.Ex: istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk ‘{print $1}`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# Remove reference of zipkin url from mixer deployment
$ kubectl -n istio-system edit deployment istio-telemetry
# Now, manually remove instances of trace_zipkin_url from the file and save it.

Then follow the steps of the cleanup section of the Distributed Tracing task.

If you don’t want tracing functionality at all, then disable tracing in istio-demo.yaml or istio-demo-auth.yaml or don’t enable it when installing Istio.

To do so, you must you use the fully qualified domain name of the Zipkin instance. For example: zipkin.mynamespace.svc.cluster.local.

Istio doesn't know when you make outbound calls from your application for which original request it was for unless you copy the headers. If you copy the headers, you can include it in your response headers too.