Collecting Logs

Collecting Logs

This task shows how to configure Istio to automatically gather telemetry forservices in a mesh. At the end of this task, a new log stream will be enabledfor calls to services within your mesh.

The Bookinfo sample application is usedas the example application throughout this task.

Before you begin

Install Istio in your cluster and deploy anapplication. This task assumes that Mixer is setup in a default configuration(—configDefaultNamespace=istio-system). If you use a differentvalue, update the configuration and commands in this task to match the value.

Collecting new logs data

Apply a YAML file with configuration for the new logstream that Istio will generate and collect automatically.

Zip

$ kubectl apply -f @samples/bookinfo/telemetry/log-entry.yaml@

If you use Istio 1.1.2 or prior, please use the following configuration instead:

Zip

$ kubectl apply -f @samples/bookinfo/telemetry/log-entry-crd.yaml@

Send traffic to the sample application.

For the Bookinfo sample, visit http://$GATEWAY_URL/productpage in your webbrowser or issue the following command:

$ curl http://$GATEWAY_URL/productpage

Verify that the log stream has been created and is being populated forrequests.

In a Kubernetes environment, search through the logs for the istio-telemetry pods asfollows:

$ kubectl logs -n istio-system -l istio-mixer-type=telemetry -c mixer | grep "newlog" | grep -v '"destination":"telemetry"' | grep -v '"destination":"pilot"' | grep -v '"destination":"policy"' | grep -v '"destination":"unknown"'
{"level":"warn","time":"2018-09-15T20:46:36.009801Z","instance":"newlog.xxxxx.istio-system","destination":"details","latency":"13.601485ms","responseCode":200,"responseSize":178,"source":"productpage","user":"unknown"}
{"level":"warn","time":"2018-09-15T20:46:36.026993Z","instance":"newlog.xxxxx.istio-system","destination":"reviews","latency":"919.482857ms","responseCode":200,"responseSize":295,"source":"productpage","user":"unknown"}
{"level":"warn","time":"2018-09-15T20:46:35.982761Z","instance":"newlog.xxxxx.istio-system","destination":"productpage","latency":"968.030256ms","responseCode":200,"responseSize":4415,"source":"istio-ingressgateway","user":"unknown"}

Understanding the logs configuration

In this task, you added Istio configuration that instructed Mixer toautomatically generate and report a new log stream for alltraffic within the mesh.

The added configuration controlled three pieces of Mixer functionality:

Generation of instances (in this example, log entries)from Istio attributes
Creation of handlers (configured Mixer adapters) capable of processinggenerated instances
Dispatch of instances to handlers according to a set of rules

The logs configuration directs Mixer to send log entries to stdout. It usesthree stanzas (or blocks) of configuration: instance configuration, handler_configuration, and _rule configuration.

The kind: instance stanza of configuration defines a schema for generated log entries(or instances) named newlog. This instance configuration tells Mixer _how_to generate log entries for requests based on the attributes reported by Envoy.

The severity parameter is used to indicate the log level for any generatedlogentry. In this example, a literal value of "warning" is used. This value willbe mapped to supported logging levels by a logentry handler.

The timestamp parameter provides time information for all log entries. In thisexample, the time is provided by the attribute value of request.time, asprovided by Envoy.

The variables parameter allows operators to configure what values should beincluded in each logentry. A set of expressions controls the mapping from Istioattributes and literal values into the values that constitute a logentry.In this example, each logentry instance has a field named latency populatedwith the value from the attribute response.duration. If there is no knownvalue for response.duration, the latency field will be set to a duration of0ms.

The kind: handler stanza of configuration defines a handler named newloghandler. Thehandler spec configures how the stdio compiled adapter code processes receivedlogentry instances. The severity_levels parameter controls how logentryvalues for the severity field are mapped to supported logging levels. Here,the value of "warning" is mapped to the WARNING log level. TheoutputAsJson parameter directs the adapter to generate JSON-formatted loglines.

The kind: rule stanza of configuration defines a new rule named newlogstdio. Therule directs Mixer to send all newlog instances to thenewloghandler handler. Because the match parameter is set to true, therule is executed for all requests in the mesh.

A match: true expression in the rule specification is not required toconfigure a rule to be executed for all requests. Omitting the entire matchparameter from the spec is equivalent to setting match: true. It is includedhere to illustrate how to use match expressions to control rule execution.

Cleanup

Remove the new logs configuration:

Zip

$ kubectl delete -f @samples/bookinfo/telemetry/log-entry.yaml@

If you are using Istio 1.1.2 or prior:

Zip

$ kubectl delete -f @samples/bookinfo/telemetry/log-entry-crd.yaml@

If you are not planning to explore any follow-on tasks, refer to theBookinfo cleanup instructionsto shutdown the application.

Collecting Logs

Collecting Logs

Before you begin

Collecting new logs data

Understanding the logs configuration

Cleanup

See also