Istio系列学习(十三)----istio的遥测 适配器 配置

一. prometheus适配器

prometheus:当前应用最广的开源系统监控和报警平台，存在数据此埃及能力强、查询语法灵活、扩展性强、方便集成的特点，尤其与云原生生态的结合，获得了越来越广泛的应用。

prometheus的工作原理如图所示：

prometheus主要工作为：抓取数据存储，提供PromQL语法进行查询，对接Grafana\Kiali等dashboard进行显示。

1. adapter的功能

一般可以使用Promethus提供的各种语言的sdk在业务代码中添加Metric的生成逻辑，通过http发不满足格式的metric接口。
更通用的方式是提供Prometheus Exporter的代理，和应用一起部署，收集应用的Metric并将其转换成Prometheus的格式发布出来。

Exporter方式的最大优点不需要修改用户的代码，所以应用非常广泛。Prometheus社区提供了丰富的 Exporter 实现(https://prometheus.io/docs/instrumenting/exporters/)，除了包括我们熟知的 Redis、 MySQL、TSDB、Elasticsearch、Kafka 等数据库、消息中间件，还包括硬件、存储、HTTP服务器、日志 监控系统等。

如图所示：

在Istio中通过Adapter收集服务生成的Metric供Prometheus采集，这个Adatper就是 Prometheus Exporter的一个实现。
上图中完整流程如下：
(1)Envoy通过Report接口上报数据给Mixer。
(2)Mixer根据配置将请求分发给Prometheus Adapter。
(3)Prometheus Adapter通过HTTP接口发布Metric数据。
(4)Prometheus 服务作为 Addon 在集群中进行安装，并拉取、存储 Metric 数据，提供Query接口进
行检索。
(5)集群内的Dashboard如Grafana通过Prometheus的检索API访问Metric数据。

2. prometheus的adapter的配置

1）hander配置
(1)metricsExpirationPolicy:配置 Metric 的老化策略，metricsExpiryDuration 定义老化周期， expiryCheckIntervalDuration定义老化的检查间隔。
实例如下图：

含义：可清理5分钟未更新的Metric，并且每隔30秒做一次检查，检查
周期 expiryCheckIntervalDuration 是个可选字段，若未配置，则使用老化周期的一半时间:
(2)metrics:配置在Prometheus中定义的Metric。这里是一个数组，每个元素都是一个MetricInfo类 型的结构，分别定义Metric的namespace、name、instanceName、description、kind、buckets、 labelNames，这些都是要传给Prometheus的定义。有以下几个注意点。
◎ Metric的namespace和name会决定Prometheus中的Metric全名。例如requests_total这个请求统计的 Metric对应图4-13中Prometheus的Metric:istio_requests_total，即由命名空间istio和Metric名称requests_total 拼接而成。
◎ instanceName是一个必选字段，表示instance定义的全名。
◎ kind 表示指标的类型，根据指标的业务特征，请求计数 requests_total 的类型为COUNTER，请求 耗时 request_duration_seconds 的类型为 DISTRIBUTION。对于DISTRIBUTION类型的指标可以定义其 buckets。

Prometheus Handler 的一个定义示例，定义了 15 秒的老化时间及Prometheus中的多个 Metric，有的是HTTP的Metric，有的是TCP的Metric

2. Instance的配置

Metric Instance的定义如图


说明：
dimensions记录每个请求上的重要属性信息。
value:"1"表示每个请求被记录一次。

3. rule配置

通过 Rule可以将 Handler 和 Instance建立关系，例如，下面两个 Rule可以分别处理HTTP和TCP的 Instance:
如图：

二、Fluentd适配器

Fluentd 是一个被广泛应用的开源日志数据收集器，提供了可高度定制化的功能，通过简单的配置，
可以将不同来源的日志收集到对应的日志后端。
Adapter通过Fluentd收集日志并与Elasticsearch、Kibana相结合的一个典型场景。

三、 statsD适配器

StatsD 接收客户端发送来的数据，将数据解析、聚合并定期推送给后端，一 般是个时序数据库，再通过Dashboard显示。StatsD默认在UDP上监听数据，速度很快。

四、 stdio适配器

Stdio只是将数据通过标准输出打印出来，Mixer的Stdio Adapter也是最简单的一种数据输出。

五、 zipkin适配器

Zipkin是较早出现的一种开源实时分布式调用链跟踪系统，也是对大名鼎鼎的Dapper论文的比较经典 的实现。Zipkin 提供了一种完整的从调用链埋点、收集、存储、检索到UI的完整方案。虽然后期出现的 Opentracing标准和以Jaeger为代表的新的调用链框架获得了越来越多的关注和使用，Zipkin的使用仍然广 泛。