请问HN：将Kubernetes依赖项连接到应用程序遥测
我正在构建Cardinal（cardinalhq.io）。关于Kubernetes调试，有一件事让我感到非常烦恼，那就是从应用程序问题到其底层Kubernetes根本原因所需的步骤数量。例如，如果我看到错误率激增，并且按部署进行分组，我希望能够立即看到该部署的K8s环境，这样我就能看到最近被错误更新的配置映射。
同样，如果一个节点的磁盘空间不足，这会对尝试写入新文件的有状态集造成连锁反应，从而影响请求延迟。
这种情况还有很多。
为了解决这个问题，我们有一个想法：构建一个智能图表图例，能够识别K8s标签（基于OTEL语义约定），然后为每个条目弹出一个“基础设施地图”图标。点击后，你可以看到该实体的完整K8s环境及其健康状态注释。这样，从应用程序遥测到K8s基础设施就变得更容易了。
我很好奇这个用户体验是否合理，如果不合理，你们今天是如何解决这个关联问题的？
https://cardinalhq.io/use-cases/kubernetes
查看原文
I’m building Cardinal (cardinalhq.io). One thing that drives me nuts about Kubernetes debugging is the number of steps it takes to go from an application issue to its underlying kubernetes root cause.<p>Like for example, if I am seeing an error rate spike, and I group by deployment, I want to immediately see the deployment's k8s neighborhood, which would then show me the configmap that was updated recently and incorrectly.<p>Similarly, say a node is low on disk and that is causing a ripple effect on a statefulset trying to write new files, which then affects request latency.<p>The list goes on.<p>To solve this, one idea we had was: build a smart chart legend that recognizes a k8s tag (based on OTEL semantic conventions), and then for every entry pops an "infra map" icon. Click and you see the full k8s neighborhood of that entity with health annotations. So now it's easier to go from app telemetry to k8s infra.<p>I am curious if this UX makes sense, and if not how do you solve this correlation problem today?<p>https://cardinalhq.io/use-cases/kubernetes