【问题标题】:How to check number of gRPC requests hits?如何检查 gRPC 请求命中数?
【发布时间】:2019-03-10 23:30:46
【问题描述】:

Java gRPC 服务器在 kubernetes 中作为容器运行,我无法弄清楚如何检查该服务器的 gRPC 请求命中总数。它不等于成功点击次数,可能服务器已关闭,无法处理请求,但点击次数无论如何都会增加。

任何帮助将不胜感激。

【问题讨论】:

    标签: networking kubernetes grpc grpc-java


    【解决方案1】:

    您可以使用logging via interceptors 在您的服务器中构建日志记录。 这允许在您的服务器运行时收集数据,但显然在不运行时不会

    如果您为您的服务实现TCP liveness probe,Kubernetes 可以自动处理一些停机时间来源,例如您的服务需要重新启动或移动到另一个节点。

    这可能会减少您实际需要计算失败请求的情况。

    您可以使用位于您的服务器和集群/外部世界之间的 gRPC 感知代理,例如nginx.

    这将允许您计算所有请求,无论成功或失败(假设集群一直在运行)。

    【讨论】:

    • 您好彼得,感谢您的回复。主要问题是收集总数,可以轻松记录正在处理的请求。是否有任何 gRPC 感知代理的实现,因为我认为这对系统来说是一个很大的开销。
    • 你是说不能使用代理吗?我想不出任何其他选择。
    【解决方案2】:

    您可以使用 prometheus 和 Grafana 设置 kubernetes ingres 监控和指标。您的 k8s 集群可能已经设置好了,请咨询您的运维人员

    这里有更多

    https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/monitoring.md

    一旦您的指标在 prometheus 中,您就可以使用 Grafana 设置自定义指标并根据该数据发出警报

    【讨论】:

    • 这将为您提供与 kubernetes 相关的指标,即所有可见的内容。但我的疑问是关于在 grpc 服务器内部运行的应用程序
    • 您可能已经知道这一点,在 kubernetes 中,服务器/pod 是短暂的。你可能有 N 个服务器,也就是 Pod。而且通常单个 pod 的指标是无关紧要的,因为它不传达任何信息,你为什么需要它?
    • 这是牛的概念,你会有你总牛的数量,你会命名个体牛吗?可能不会
    猜你喜欢
    • 1970-01-01
    • 2017-09-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-11-04
    • 1970-01-01
    相关资源
    最近更新 更多