我们已经在apiserver中跟踪了过滤器延迟。有一个每个过滤器的指标来跟踪失败会很有用。换句话说，如果一个过滤器终止了请求传播并写入了一个错误响应，将其记录为与过滤器名称一起的失败。如果请求在链中的更远处的过滤器中传播并失败，那么这不应被视为父过滤器中的失败(但如果请求在子过滤器返回后失败，则应计入)。
/sig api-machinery instrumentation
/area apiserver monitoring我们已经在apiserver中跟踪了过滤器延迟。有一个每个过滤器的指标来跟踪失败会很有用。换句话说，如果一个过滤器终止了请求传播并写入了一个错误响应，将其记录为与过滤器名称一起的失败。如果请求在链中的更远处的过滤器中传播并失败，那么这不应被视为父过滤器中的失败(但如果请求在子过滤器返回后失败，则应计入)。
/sig api-machinery instrumentation
/area apiserver monitoring
6条答案
按热度按时间k2arahey1#
看起来#117167中包含了一些工作。
icomxhvb2#
拥有类似的东西对我来说是有意义的👍
似乎#117167中包含了一些工作。
就我所知，这里的目标似乎有些不同。指标来自117167的目标是最终用户。这些指标提供了关于过滤器如何处理请求的更多信息，可以帮助用户更好地理解顶级错误。而这个暴露了实现细节，所以更可能是面向开发者的，可以帮助了解详细信息的人更快地对apiserver错误进行排错。所以我完全支持两者共存。
dffbzjpn3#
我甚至可以看到一个互补的世界，通过遵循下面的调查路径：
4xy9mtcn4#
js81xvg65#
这个问题已经超过一年没有更新了，应该重新进行优先级评估。
你可以：
/triage accepted(仅组织成员)相关/close关闭这个问题有关优先级评估过程的更多详细信息，请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估
doinxwow6#
/triage accepted