作者 | Michael Bogan译者 | Luga Lee策划 | Luga Lee
基于关键的可观测性指标，我们更能了解我们的应用服务运行状态，以便提升服务运行效能。
如今，一种最为流行的架构设计模式便是将应用程序单体分解为更小的微服务。然后，每个微服务负责应用程序的特定方面或功能。例如，一个微服务可能负责提供外部 API 请求，而另一个可能处理前端的数据获取。
以这种方式设计一个强大且故障安全的基础设施可能具有挑战性；一起监控所有这些微服务的操作可能更加困难。最好不要简单地依靠应用程序日志来了解系统的成功和错误。设置适当的监控将为我们提供更完整的观测图，但可能很难知道从哪里开始。在这篇文章中，我们将介绍可观测性指标应该关注的那些服务领域，以确保大家不会错过关键信息。
在开始本文内容之前，我们将对所运行的应用程序设置做一些假设。别担心——我们不需要使用任何特定框架来开始跟踪指标。但是，它确实有助于对所涉及的组件有一个大致的了解。换句话说，你如何设置你的可观察性工具比你跟踪什么更重要。
由于足够大的微服务集需要某种程度的协调，我们将假设使用 Kubernetes 进行编排。我们还假设有一个时间序列数据库，如 Prometheus 或 InfluxDB，用于存储我们的指标数据。同时，我们可能还需要一个入口控制器（例如 Kong 提供的用于控制流量的控制器）和服务网格（例如 Kuma）以更好地促进服务之间的连接。
在实施任何监控之前，必须了解我们的应用服务实际上如何进行相互交互。编写一份文档，确定哪些服务和功能相互依赖，以及可用性问题将如何影响它们，可以帮助我们制定战略，围绕为构成适当阈值的内容设置基线数字。
指标类型
我们应该能够从两个角度查看数据点：影响数据和因果数据。影响数据表示识别谁受到影响的信息。例如，如果服务中断并且响应变慢，Impact Data 可以帮助确定受影响的活跃用户的百分比。
Impact Data 确定谁受到影响，Causal Data 确定受影响的对象及其原因。 Kong Ingress 可以监控网络活动，可以让我们深入了解影响数据。同时，Kuma 可以收集和报告因果数据。
让我们看一下几个数据源，并探索可以收集到的影响数据和因果数据之间的差异。
1、延迟
延迟是用户执行操作与其最终结果之间所花费的时间。例如，如果用户将一件商品添加到他们的购物车中，则延迟将衡量从添加商品到用户看到表明添加成功的响应之间的时间。如果负责执行此操作的服务降级，则延迟会增加，并且如果没有立即响应，用户可能会怀疑该站点是否正在运行。
为了在影响数据上下文中正确跟踪延迟，有必要在整个生命周期中跟踪单个事件。继续我们的采购示例，我们可能希望事件的完整流程如下所示：
- 客户点击“加入购物车”按钮
- 浏览器发起服务器端请求，发起事件
- 服务器接受请求
- 数据库查询确保产品仍有库存
- 解析数据库响应，向用户发送响应，事件完成
要成功地遵循此顺序，我们应该标准化一个命名模式，以标识正在发生的事情和发生的时间，例如 customer_purchase.initiate、customer_purchase.queried、customer_purchase.finalized 等。基于所采用的编程语言，我们可能能够为指标服务提供功能块或 lambda：
statsd.timing('customer_purchase.initiate') do # ... end
通过提供特定的关键字，我们应该确定在出现延迟问题时事件的哪个部分变慢。
跟踪因果数据上下文中的延迟需要我们跟踪服务之间事件的速度，而不仅仅是执行的操作。实际上，这意味着定时服务到服务请求：
statsd.histogram('customer_purchase.initiate') do statsd.histogram('customer_purchase.external_database_query') do # ... end end
这不应仅限于捕获整个端点请求/响应周期。这种延迟跟踪太广泛了，应该更细化。假设我们有一个带有发出内部数据库请求的端点的微服务。在这种情况下，我们可能希望计算收到请求的时间、查询花费的时间、服务响应请求的时间以及原始客户端收到该请求的时间。通过这种方式，我们可以精确地确定服务如何相互通信。
2、流量
如果希望我们的应用程序有用且受欢迎——但此时，我们还没有做好准备，大量用户涌入可能是一件好事！网站流量的变化很难预测。我们可能能够每天为用户负载提供服务，但事件（预期的和意外的）可能会产生意想不到的后果。我们的电子商务网站是否在进行周末促销？我们的网站是否因为一些意外的赞美而走红？流量差异也会受到地理位置的影响。也许日本用户正在以一种法国用户没有的方式体验流量负载。我们可能认为我们的系统正在按预期工作，但所需要的只是大量用户涌入来测试这种信念。如果一个事件需要 200 毫秒才能完成，但我们的系统一次只能处理一个事件，那么看起来似乎没有问题——直到事件队列突然被工作堵塞为止。
与延迟类似，跟踪整个事件生命周期中正在处理的事件数量以了解任何瓶颈很有用。例如，跟踪队列中的作业数、每秒完成的 HTTP 请求数和活动用户数是监控流量的良好起点。
对于因果数据，监控流量涉及捕获服务如何相互传输信息，类似于我们如何处理延迟。我们的监控设置应该跟踪对特定服务的请求数量、它们的响应代码、它们的有效负载大小等——尽可能多地了解请求和响应周期。当我们需要调查恶化的性能时，了解哪个服务遇到问题将有助于我们更快地跟踪可能的来源。
3、错误率
跟踪错误率相当简单。我们的服务器作为 HTTP 响应发出的任何 5xx（甚至 4xx）都应该被标记和计数。即使我们已经考虑到的情况，例如捕获的异常，也应该受到监视，因为它们仍然代表非理想状态。这些问题可以作为防御性编码产生的更深层次问题的警告，这些问题没有解决实际问题。
Kuma 可以捕获我们的服务抛出的错误代码和消息，但这仅代表可操作数据的一部分。例如，我们还可以捕获导致错误的参数（万一查询格式错误）、发出的数据库查询（万一超时）、执行用户的权限（万一他们进行了未经授权的尝试）、等等。简而言之，捕获产生错误时的服务状态可以帮助我们在开发和测试环境中复制问题。
4、饱和度
除此之外，我们还应该跟踪每个微服务的内存使用情况、CPU 使用情况、磁盘读/写和可用存储。如果我们服务的资源使用在某些时间或操作期间经常激增或以稳定的速度增加，则表明应用服务过度使用了服务器资源。虽然服务器可能按预期运行，但再次涌入的流量或其他不可预见的事件可能会迅速推翻它。
Kong Ingress 只监控网络活动，因此不太适合跟踪饱和度。但是，有许多工具可用于使用 Kubernetes 进行跟踪。
实施监控和可观察性
到目前为止，我们已经讨论了在云应用程序中跟踪很重要的指标类型。接下来，让我们深入了解我们可以采取的一些具体步骤来实现这种监控和可观察性。
1、安装 Prometheus
Prometheus 是监控的首选标准，是一个易于安装并与 Kubernetes 设置集成的开源系统。如果基于 Helm 部署，则安装会特别简单。
首先，我们创建一个监控命名空间：
[administrator@JavaLangOutOfMemory ~] % kubectl create namespace monitoring
接下来，我们使用 Helm 安装 Prometheus。我们确保也将 Prometheus 图表添加到 Helm：
[administrator@JavaLangOutOfMemory ~] % helm repo add prometheus-community https://prometheus-community.github.io/helm-charts [administrator@JavaLangOutOfMemory ~] % helm repo add stable https://kubernetes-charts.storage.googleapis.com/ [administrator@JavaLangOutOfMemory ~] % helm repo update [administrator@JavaLangOutOfMemory ~] % helm install -f https://bit.ly/2RgzDtg -n monitoring prometheus prometheus-community/prometheus
https://bit.ly/2RgzDtg 中引用的值文件将 Prometheus 的数据抓取间隔设置为 10 秒。
在 Kong 中启用 Prometheus 插件
假设正在为 Kubernetes 使用 Kong Ingress Controller (KIC)，我们的下一步将是创建一个自定义资源——KongPlugin 资源——它集成到 KIC 中。创建一个名为 prometheus-plugin.yml 的文件：
apiVersion: configuration.konghq.com/v1 kind: KongClusterPlugin metadata: name: prometheus annotations: kubernetes.io/ingress.class: kong labels: global: "true" plugin: prometheus
安装 Grafana
Grafana 是一个可观察性平台，它为 Prometheus 抓取的数据的可视化提供了出色的仪表板。我们使用 Helm 安装 Grafana 如下：
administrator@JavaLangOutOfMemory ~ % helm install grafana stable/grafana -n monitoring --values http://bit.ly/2FuFVfV
我们可以查看上述命令中的 bit.ly URL，以查看我们在安装时提供的 Grafana 的具体配置值。
启用端口转发
现在 Prometheus 和 Grafana 在我们的 Kubernetes 集群中启动并运行，我们需要访问他们的仪表板。在本文中，我们将设置基本端口转发以公开这些服务。这是一种简单但不是很安全的访问方式，但不建议用于生产部署。
[administrator@JavaLangOutOfMemory ~] % POD_NAME=$(kubectl get pods --namespace monitoring -l "app=prometheus,component=server" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9090 & [administrator@JavaLangOutOfMemory ~] % POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/instance=grafana" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 3000 &
以上两个命令在端口 9090 上公开 Prometheus 服务器，在端口 3000 上公开 Grafana 仪表板。
这些简单的步骤应该足以让其开始运行。使用 Kong Ingress Controller 及其集成的 Prometheus 插件，使用 Prometheus 捕获指标并使用 Grafana 将它们可视化设置起来既快速又简单。
结论
每当我们需要调查恶化的性能时，我们的影响数据指标都可以帮助我们确定问题的严重程度：它应该告诉我们有多少人受到影响。同样，我们的因果数据确定什么不起作用以及为什么。前者将我们指向一缕烟，后者将我们指向火。
除了上述所有因素外，我们还应该考虑指标变化的速度。例如，假设我们的流量数字正在增加。观察这些数字的变化速度可以帮助我们确定何时（或是否）它会成为问题。这对于通过定期部署和服务更改来管理即将进行的工作至关重要。它还确定了理想的性能指标应该是什么。
Google 写了整本关于站点可靠性的书，这是任何开发人员的必读之书。如果我们已经在集群旁边运行 Kong，那么像这样的插件直接与 Prometheus 集成，这意味着我们可以减少用于监控和存储服务指标的配置。
