演示应用程序 emojivoto 有一些问题。让我们用它和 linker 来诊断一个应用程序，它的失败方式比整个服务崩溃要微妙得多。本指南假设您已经按照入门指南中的步骤进行了操作， 并在 Kubernetes 集群中运行了 linker 和演示应用程序。如果你还没做完，那就开始吧，做完就回来！
如果您看一眼 Linkerd 仪表板（通过运行 linkerd viz dashboard 命令）， 您应该会看到 emojivoto 命名空间中的所有资源，包括部署。运行 Linkerd 的每个部署都会显示 成功率(success rate)、每秒请求数(requests per second)和延迟百分位数(latency percentiles)。
这很不错，但您可能会注意到的第一件事是成功率远低于 100%！点击 web，让我们深入了解。
您现在应该查看 web deployment 的 Deployment 页面。您将在这里看到的第一件事是 Web deployment 正在从 vote-bot （emojivoto 中包含的 deployment 以持续生成低水平的实时流量）中获取流量。web deployment 还有两个传出依赖项，emoji 和 voting。
当 emoji deployment 成功处理来自网络的每个请求时， 看起来 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， 这是您从代码中看到的常见错误响应。Linkerd 无需任何其他配置即可了解 gRPC 的响应分类！
在这一点上，我们拥有修复端点和恢复应用程序整体健康所需的一切。
