12. 使用请求跟踪调试 gRPC 应用程序

演示应用程序 emojivoto 有一些问题。 让我们用它和 linker 来诊断一个应用程序，它的失败方式比整个服务崩溃要微妙得多。 本指南假设您已经按照入门指南中的步骤进行了操作， 并在 Kubernetes 集群中运行了 linker 和 demo。 如果你还没做完，那就开始吧，做完就回来！

如果您看一眼 Linkerd 仪表板（通过运行 linkerd viz dashboard 命令）， 您应该会看到 emojivoto 命名空间中的所有资源，包括部署。 运行 Linkerd 的每个 deployment 都会显示 成功率、每秒请求数和延迟百分位数。

这很不错，但您可能会注意到的第一件事是成功率远低于 100%！点击 web，让我们深入了解。

您现在应该查看 web deployment 的 Deployment 页面。 您将在这里看到的第一件事是 web deployment 正在从 vote-bot （emojivoto 中包含的 deployment 以持续生成低水平的实时流量）中获取流量。 web deployment 还有两个传出依赖项，emoji 和 voting。

当 emoji deployment 成功处理来自 web 的每个请求时， 看起来 voting deployment 失败了一些请求！ 在依赖 deployment 中的故障可能正是导致 Web 返回错误的原因。

让我们进一步向下滚动页面，我们将看到传入和传出 web 的所有流量的实时列表。这是有趣的：

有两个调用不是 100%：第一个是 vote-bot 对 /api/vote 端点的调用。 第二个是 VoteDoughnut 调用从 web deployment 到它的依赖 deployment，voting。 很有意思！由于 /api/vote 是传入调用，而 VoteDoughnut 是传出调用， 这是一个很好的线索，表明该端点是导致问题的原因！

最后，为了更深入地挖掘，我们可以单击最右侧栏中的 tap 图标。 这将带我们进入仅与此端点匹配的请求的实时列表。 您将在 GRPC status 列下看到 Unknown。 这是因为请求失败并显示 gRPC status code 2， 这是您从 the code中看到的常见错误响应。 Linkerd 无需任何其他配置即可了解 gRPC 的响应分类！

在这一点上，我们拥有修复端点和恢复应用程序整体健康所需的一切。