Everyone knows that istio can help us achieve grayscale publishing, traffic monitoring, traffic management and other functions. Each function helps us realize different businesses in different scenarios. So how does Istio help us realize monitoring and log collection?
Here we still use the Bookinfo application as a sample program throughout this task. First install and deploy Istio in the cluster.
1
Collect telemetry data
Create a new YAML file to save the configuration of new metrics and log streams that Istio will automatically generate and collect . As shown in the figure below:
Use the command $ kubectl apply -f new_telemetry.yaml to push the YAML file just configured. Then go to request the application to generate traffic, for example, in this use case, you can access Bookinfo to complete the access.
Next we can verify whether we have collected the requested data just now. In the Kubernetes environment, set up port forwarding for Prometheus by executing the following command:
$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath ='{.items[0].metadata.name}’) 9090:9090 &
Check the value of the new indicator through the Prometheus UI. Perform a query on the istio_double_request_count metric value. The table displayed in the Console tab contains entries similar to the following:
Verify that the log stream has been created and is being filled for requests. In the Kubernetes environment, search for the log of the istio-telemetry pod, as shown below:
From the printed information, we can clearly see the log level, generation time, instance name, access component name and other information.
2
Telemetry configuration
In the above practice, we have completed a process of Istio collecting data and printing logs.
So how does Istio do it? In fact, we have already configured Istio to instruct Mixer to automatically generate and report the metric information and log streams collected in the service grid. In this configuration, we mainly set three functions of the mixer:
Generate instance information from Istio attributes, such as the metric and log information printed in our practice above.
Create an adapter adapter, which can help us process the generated instance.
Send instance information to the adapter according to the defined rules.
3
metrics configuration
The purpose of configuring metrics is to instruct Mixer to send metrics to Prometheus. It uses three modules for configuration: instance configuration, handler configuration, and rule configuration.
The metric configuration module defines the metric used to generate it. This example configuration tells Mixer how to generate metrics for any given request based on the attributes reported by Envoy (generated by Mixer itself).
dimensions specify a set of dimensions for each instance. Provides methods for slicing, aggregating and analyzing metric data according to different needs and directions of the query. For example, you may need to consider only requests for specific target services when troubleshooting application behavior.
4
Log configuration
Log configuration instructs Mixer to send log entries to stdout. It also uses three modules for configuration: instance configuration, handler configuration and rule configuration.
The logentry configuration section defines an instance for generating log entries. This example configuration tells Mixer how to generate log entries for requests based on the attributes reported by Envoy.
The severity parameter is used to indicate any generated log level logentry. In this example, the parameter value “warning” is used. This value will be mapped to the supported logging level by the logging handler.
The Timestamp parameter provides time information for all log entries. In this example, the time request.time is provided by the attribute value provided by Envoy.
The variables parameter allows the operator to configure the value logintry that should be included in each value. A set of expressions controls the mapping of Istio attributes and literal values to the values that make up a, logentry. In this example, each logging instance has a field response.duration named latency that is filled with attribute values. If there is no known value response.duration, the latency field will be set to a duration of 0ms.
The stdio configuration defines the handler named newhandler. The handler spec configures how the stdio adapter code handles receiving logentry instances. The severity_levels parameter controls how the severity value of the field is mapped to the supported logging levels. Here, the value “warning” is mapped to the WARNING log level. The outputAsJson parameter instructs the adapter to generate log lines in JSON format.
The rule configuration defines a new rule named newlogstdio. This rule instructs Mixer to send all instances of newlog.logentry to the newhandler.stdio handler. Since the match parameter is set to true, the rule will be executed for all requests in the grid.
For related services, please visit https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019