大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等功能。每一个功能都帮助我们在不同场景中实现不同的业务。那Istio是如何帮助我们实现监控和日志采集的呢？
这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序。首先在集群中安装并部署Istio。
1 收集遥测数据
创建一个新的YAML文件，用来保存Istio将自动生成和收集的新度量标准和日志流的配置。如下图所示：
通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件。然后去请求应用程序来生成流量，例如在本用例中就可以访问Bookinfo完成访问。
接下来我们就可以验证是否采集到了刚刚的请求数据。在Kubernetes环境中，通过执行以下命令为Prometheus设置端口转发：
$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &
通过Prometheus UI查看新指标的值。执行对istio_double_request_count度量值的查询。Console选项卡中显示的表 包含类似于以下内容的条目：
验证是否已创建日志流并正在为请求填充日志流。在Kubernetes环境中，搜索istio-telemetry pod的日志，如下所示：
从打印的信息中，我们可以清楚的看到日志级别、生成时间、实例名称、访问组件名称等等信息。
2 遥测配置
在上面的实践中，我们已经完成了Istio收集数据并打印日志的一个过程。
那么Istio是如何做到的呢？其实我们已经给Istio做了配置，指示Mixer自动生成并上报服务网格中采集的metric信息和日志流。在这个配置中我们主要设置了mixer的三个功能：
-
从Istio的属性中生成实例信息，比如在我们上面的实践中打印的metric和日志信息。
-
创建出adapter适配器，可以帮助我们处理生成的实例。
-
根据定义的规则向adapter发送实例信息。
3 metrics配置
配置metrics是为了指示Mixer将metric发送到Prometheus。它使用三个模块来进行配置：实例配置、处理程序配置和规则配置。
metric配置的模块定义了用于生成metric。此实例配置根据Envoy报告的属性（由Mixer自身生成）告诉Mixer 如何为任何给定请求生成metric。
dimensions为每个实例指定一组维度。提供了根据查询的不同需求和方向对metric据进行分片，聚合和分析的方法。例如，可能需要在对应用程序行为进行故障排除时仅考虑对特定目标服务的请求。
4 日志配置
日志配置指示Mixer将日志条目发送到stdout。它同样使用三个模块来进行配置：实例配置，处理程序 配置和规则配置。
logentry配置的部分定义了用于生成日志条目实例。此实例配置告诉Mixer 如何 根据Envoy报告的属性为请求生成日志条目。
severity参数用于指示任何生成的日志级别 logentry。在此示例中，使用了参数值"warning"。此值将由logentry 处理程序映射到支持的日志记录级别。
Timestamp参数提供所有日志条目的时间信息。在此示例中，时间request.time由Envoy 提供的属性值提供。
variables参数允许操作员配置每个值中应包含的值logentry。一组表达式控制从Istio属性和文字值到构成a的值的映射logentry。在此示例中，每个logentry实例都有一个名为latency使用属性值填充的字段response.duration。如果没有已知值response.duration，则该latency字段将设置为持续时间 0ms。
stdio配置定义了处理程序命名newhandler。处理程序spec配置stdio适配器代码处理接收 logentry实例的方式。该severity_levels参数控制字段的logentry 值如何severity映射到支持的日志记录级别。这里，值"warning"被映射到WARNING日志级别。该 outputAsJson参数指示适配器生成JSON格式的日志行。
rule配置定义一个新的规则命名newlogstdio。该规则指示Mixer将所有newlog.logentry实例发送到 newhandler.stdio处理程序。由于match参数设置为true，因此将对网格中的所有请求执行规则。