Inference Observability -KServe

最新推荐文章于 2024-07-04 18:05:43 发布

蓝净云

最新推荐文章于 2024-07-04 18:05:43 发布

阅读量421

点赞数

分类专栏： Kserve 文章标签： Kserve

原文链接：https://kserve.github.io/website/0.10/modelserving/observability/prometheus_metrics/

版权

Kserve 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

Inference Observability

Prometheus度量
Grafana Dashboards

https://kserve.github.io/website/0.10/modelserving/observability/prometheus_metrics/

Prometheus度量

暴露Prometheus度量端口

所有支持的服务运行时都支持在推理服务的pod中的指定端口上导出prometheus度量。模型服务器的适配端口在kserve/config/runtimes YAML文件中定义。例如，torchserve在kserve-archserve.yaml中将其prometheus端口定义为8082。

metadata:
  name: kserve-torchserve
spec:
  annotations:
    prometheus.kserve.io/port: '8082'
    prometheus.kserve.io/path: "/metrics"

如果需要，可以在推理服务YAML中重写此值。

要启用prometheus度量，请将注释serving.kserve.io/enable-prometheus-scraping添加到推理服务YAML中。

apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "sklearn-irisv2"
  annotations:
    serving.kserve.io/enable-prometheus-scraping: "true"
spec:
  predictor:
    sklearn:
      protocolVersion: v2
      storageUri: "gs://seldon-models/sklearn/iris"

serving.kserve.io/enable-prometheus-scraping的默认值可以在推理服务配置映射中设置。有关详细信息，请参阅文档。

模型服务器当前没有导出一组统一的度量。每个模型服务器可以实现其自己的一组要导出的度量。

lgbserver, paddleserver, pmmlserver, sklearnserver, xgbserver, custom transformer/predictor的度量¶

每个步骤都会发出Prometheus latency histograms（预/后处理、解释、预测）。此外，每个请求都会记录每个步骤的延迟。另请参阅modelserver prometheus标签定义和度量实现。

Metric Name	Description	Type
request_preprocess_seconds	pre-processing request latency	Histogram
request_explain_seconds	explain request latency	Histogram
request_predict_seconds	prediction request latency	Histogram
request_postprocess_seconds	pre-processing request latency	Histogram

其他服务运行时指标

一些模型服务器定义了自己的度量。

导出度量(metrics)

在无服务器模式下导出度量要求使用queue-proxy扩展映像。
有关如何导出度量的更多信息，请参阅Queue Proxy Extension文档。

Knative/Queue-Proxy度量

Queue proxy在端口9091上默认发出度量。如果使用queue proxy扩展设置聚合度量，则聚合度量的默认端口将为9088。有关度量queue-proxy公开的更多信息，请参阅Knative文档（以及代码中定义的其他度量）。

Grafana Dashboards

GrafanaLabs中提供了一些Grafana仪表板示例。

Knative HTTP Dashboard（如果使用无服务器模式）

Knative HTTP Grafana dasbhoard是根据Knative的沙箱监控示例构建的。

KServe ModelServer延迟面板

KServe ModelServer Latency的模板面板包含使用prometheus度量的示例查询，用于以毫秒为单位的前/后处理、预测和解释。查询是一个histogram quantile。第五张图显示了对预测端点的请求总数。该图涵盖了KServe的所有ModelServer运行时 - lgbserver, paddleserver, pmmlserver, sklearnserver, xgbserver, custom transformer/predictor。

KServe TorchServe延迟面板

KServe TorchServe Latency的模板面板包含一个推断延迟图，该图以毫秒为单位绘制了TorchServe度量ts_inference_latency_microseconds的速率。第二张图绘制了TorchServe的内部队列延迟度量ts_queue_latency_microseconds的
（以毫秒为单位）。第三张图描绘了对TorchServe推理服务的总请求。有关更多信息，请参阅TorchServe度量文档。

KServe Triton Latency Dashboard

KServe Triton Latency的模板仪表板包含五个延迟图，其中以毫秒为单位绘制了Triton的输入（预处理）、推断（预测）、输出（后处理）、内部队列和总延迟指标的速率。Triton还输出GPU使用情况的指标，该模板绘制了GPU内存使用百分比的度量（以字节为单位）。有关更多信息，请参阅Triton推理服务器文档。

调试性能

设置这些Grafana仪表板后，通过以下步骤调试延迟问题

首先，（如果在无服务器模式下）从Knative HTTP Dashboard开始检查是否存在queue-proxy的排队延迟

√ 将网关延迟百分比指标与目标SLO进行比较
√ 检查观察到的并发度量，查看您的服务是否因大量空中请求而过载，这表明该服务已超出容量，无法跟上请求数量
√ 检查GPU/CPU内存指标，看看服务是否接近其极限——如果您的服务有大量的机上请求/高CPU/GPU使用率，那么一个可能的解决方案是添加更多的资源/副本

接下来，查看相应的服务运行时面板，看看代码中是否存在瓶颈

√ 检查处理前/处理后的延迟，预测，解释——在任何一个步骤中，延迟是否高于预期？如果是这样的话，您可能需要对此步骤进行更改/调整（注意：TorchServe目前没有公开此级别的可观察性，只有一个包含这些步骤的推断延迟图）
√ 检查队列延迟指标（TorchServe和Triton）-如果请求滞留在队列中，则模型无法跟上请求数量，请考虑添加更多资源/副本
√ （Triton）检查GPU利用率指标，看看您的服务是否已满负荷，是否需要更多GPU资源

如果仪表板中的数字符合您的SLO，请检查客户端指标，以调查是否会导致额外的网络延迟。