指标、访问日志、追踪 — 代理白送的和不白送的
一句话总结
当请求经过代理时，Messenger会创建指标·访问日志·范围。但是，只有Trace才会断开，除非应用程序传递头。
为什么需要这个？
如果在应用程序中关注观测性，就会出现两种不一致之处。首先，**定义因服务而异。**有些团队以5xx为准，有些团队以4xx为准。有些团队以客户端为准，有些团队以服务器为准来衡量延迟。即使把仪表板并排放在一起，也不能进行比较。其次，**还有未被测量的服务。**匆忙制作的内部工具、接管团队的遗留技术、外包获得的组件都没有被测量，这总是障碍的盲点。
梅西解决了这个问题，说“请求反正会经过代理，所以就在那里重新计算”。标准指标的名字和标签在所有服务中都相同。这种一致性比重新附加测量值更有价值。
怎么行动
**指标。**每个侧卡在端口15090以普罗米修斯格式暴露统计数据。核心有三个。
| 指标 | 种类 | 使用地点 |
|---|---|---|
istio_requests_total |
柜台 | 请求次数、错误率 |
istio_request_duration_milliseconds |
直方图 | p50/p99 延迟 |
istio_request_bytes/istio_response_bytes |
直方图 | 数据包大小 |
标签中特别要记住的三样东西。reporter是source（发送方的代理）和destination分为（收到的方代理），因为相同的要求在双方分别记录，所以两个加起来是两倍。response_flags因为是访问日志的标志等值，所以仅凭指标就能区分503的性质。connection_security_policy是mutual_tls或者none并且，STRICT转换的完成标准就是这个标签none请求0件。
一个陷阱是 Cardinality。如果在标签中输入请求路径或用户ID等值，时间序列就会爆炸。自定义标签只能输入值种类有限的值。
应该了解一下架构的变化历史。以前，每次请求都会调用名为Mixer的单独服务来收集指标，这是延迟和故障的原因。现在，代理内部的过滤器直接制作（Telemetry API v2）。所以由于可观测性，请求路径上不再添加跳转。
**访问日志。**代理每次请求都会留下一行。需要人阅读的部分是响应代码和旁边的小标志。
| 标志 | 含义 | 第一眼看到的东西 |
|---|---|---|
UH |
没有健康的上游 | subset标签和pad标签 |
UF |
上游连接失败 | 只有一边是STRICT的mTLS不一致 |
UO |
连接池超出 | 电路断路器限度 |
NR |
无路由 | catch-all 路由存在与否 |
URX |
重新尝试用完 | 根本原因与其他标志一起 |
UAEX |
拒绝外部授权 | CUSTOM政策和授权状态 |
全量日志记录很贵。作为Telemetry资源的过滤器response.code >= 400以同样的条件设置，只留下失败的构成很常见。
**分散跟踪。这是“不是免费的”部分。代理甚至会创建范围并发送时间和库存收集器的计时信息。但是入站请求的跟踪头（B3系列或W3Ctraceparent)复制到出站请求的事情应该由应用程序来做。**如果不这样做，每个服务都会产生单独的跟踪，呼叫链就会中断。“虽然铺了消息，但跟踪看起来只有一个跳跃”的答案几乎总是这个。
采样基本值是1%。第一个代理决定采样是否，并通过头传递，所以后面会根据那个决定。只有在调试时才提高，不会一直保持100%。
可视化。 Kiali 使用普罗米修斯指标绘制服务图，读取 Kubernetes API 和 Istio 设置，并检查参考完整性。也就是说，Kiali 的设置验证是istioctl analyze将像这样的类型的工作显示在屏幕上。
在现场相遇的样子
**第一，将source和destination混合计数的仪表板。**如果请求数量准确翻倍的话，九成八分reporter是忽略了过滤器。从客户的角度来看source，从服务器角度来看destination必须固定为一。
第二，消息指标不能取代应用程序指标。代理只知道“请求出错200”。不知道响应正文是否错误，订单是否实际保存。消息观测性是基础设施层面的均匀底座，域指标仍然需要应用程序提供。
**第三，无法看到没有侧卡的路径。**消息以外的Cron或未注入的命名空间的流量完全不显示在图表上。图表干净并不意味着没有流量。
下次实习要做的事情
首先诚实地说。**在这个实习环境中，实际上没有传输流量的大量Envoy。**即使附带侧卡的帕德运行起来，请求也不会流畅，也不能触发15090或触发15000的管理API。所以没有制作产生指标值或跟踪图的实习。
相反，接下来直接在实训中讨论设计信号的一方。在整个消息中铺设基本访问日志，在响应代码上设置只留下失败的过滤器，在一个工作负载上附上采样率和字面标签，关闭一个标准指标。然后在部署标签之前制作一个过滤器来检查是否爆炸性地增加 Cardinality，如果有一个没有选择器的Telemetry放在一个命名空间中的话istioctl analyze甚至看是否被捕为错误。即使价格不流畅，是否设置有效和范围正确也会被直接验证，现场捕人的地方也大多是这两个地方。