丹青识画系统运维实战监控、告警与自动化扩缩容最近在星图GPU平台上部署了丹青识画系统看着它稳定运行处理着源源不断的图片识别请求心里挺有成就感。但作为运维咱们都清楚部署上线只是第一步真正的挑战在于如何让它长期、稳定、高效地跑下去。特别是对于这种依赖GPU资源的AI服务资源使用率、响应延迟、服务可用性每一个指标都牵动着神经。这篇文章我就结合自己的实践经验聊聊在星图平台上为丹青识画系统搭建一套“看得见、管得住、能自愈”的运维体系。核心就三件事监控、告警和自动化扩缩容。目标很明确就是让系统运维从“救火”变成“防火”甚至“预测火情”确保服务SLA服务水平协议稳稳当当。1. 为什么丹青识画的运维需要特别关注你可能觉得运维嘛不就是看看日志、重启服务但对于丹青识画这类AI推理服务还真有点不一样。首先它的核心是GPU计算。一张显卡成本不菲用少了是浪费用爆了服务就卡顿甚至崩溃。你没法像对待CPU那样简单看个负载百分比就完事得深入看显存占用、GPU利用率、SM流多处理器活跃度这些更细的指标。其次它的服务体验直接体现在API响应时间上。用户上传一张图等个一两秒可能还行要是经常超过五秒体验就大打折扣了。这个延迟不仅受GPU影响还跟模型加载、预处理、网络I/O都有关。最后它的流量可能波动很大。白天上班时间请求多深夜请求少搞个营销活动流量可能瞬间翻几倍。靠手动调整副本数根本来不及反应。所以咱们的运维体系必须能精准感知GPU状态、实时追踪API性能并能根据流量变化自动伸缩。下面我就分步拆解这套体系的搭建。2. 搭建监控体系让系统状态一目了然监控是运维的眼睛。我们选用经典的Prometheus Grafana组合因为它足够灵活、生态丰富能很好地集成到星图平台的环境中。2.1 监控数据采集暴露关键指标丹青识画系统本身假设是基于类似FastAPI的框架需要暴露一些内置指标比如请求数、延迟、错误率。这通常可以通过引入prometheus-client库来实现。# 示例在丹青识画API服务中暴露Prometheus指标 from prometheus_client import Counter, Histogram, generate_latest, REGISTRY from fastapi import FastAPI, Response import time app FastAPI() # 定义指标 REQUEST_COUNT Counter(danqing_api_requests_total, Total API requests) REQUEST_LATENCY Histogram(danqing_api_request_duration_seconds, API request latency in seconds) ERROR_COUNT Counter(danqing_api_errors_total, Total API errors) app.middleware(http) async def monitor_requests(request, call_next): start_time time.time() REQUEST_COUNT.inc() try: response await call_next(request) return response except Exception: ERROR_COUNT.inc() raise finally: latency time.time() - start_time REQUEST_LATENCY.observe(latency) app.get(/metrics) async def get_metrics(): return Response(generate_latest(REGISTRY), media_typetext/plain) # 你的图片识别主接口 app.post(/v1/recognize) async def recognize_image(...): # ... 你的业务逻辑 pass更重要的是GPU监控。我们使用NVIDIA DCGM Exporter它是专门为Prometheus收集GPU指标的工具比简单的nvidia-smi输出更丰富、更规范。在星图平台的容器环境里可以将其作为Sidecar容器与丹青识画服务部署在同一个Pod中。# Kubernetes Pod 配置片段示例 (概念示意) apiVersion: v1 kind: Pod metadata: name: danqing-service-pod spec: containers: - name: danqing-api image: your-danqing-image:latest # ... 你的应用容器配置 - name: dcgm-exporter image: nvidia/dcgm-exporter:latest args: [-f, /etc/dcgm-exporter/dcp-metrics-included.csv] ports: - containerPort: 9400 securityContext: capabilities: add: [SYS_ADMIN]这样丹青识画服务的业务指标在/metrics端点和GPU指标在DCGM Exporter的:9400/metrics端点就都准备好了。2.2 配置Prometheus抓取与Grafana可视化接下来在星图平台上部署Prometheus并配置它去抓取上述两个目标。# prometheus.yml 配置片段 scrape_configs: - job_name: danqing-service static_configs: - targets: [danqing-service-pod-ip:8000] # 应用自身指标 labels: service: danqing-api - job_name: danqing-gpu static_configs: - targets: [danqing-service-pod-ip:9400] # GPU指标 labels: service: danqing-gpu部署好Grafana后添加Prometheus数据源然后就可以创建仪表盘了。一个实用的丹青识画运维仪表盘通常包含这几个面板GPU资源面板显示每张卡的利用率、显存使用量、温度、功耗。设置阈值线比如利用率80%显存90%。API性能面板显示请求QPS、平均/分位延迟P50, P90, P99、错误率。这是判断服务健康度的直接依据。系统资源面板容器/节点的CPU、内存使用情况。业务面板可选如果丹青识画有不同识别类型可以按类型统计请求量和成功率。看着Grafana上跳动的曲线系统是忙是闲是健康还是亚健康就一清二楚了。3. 设置智能告警从“被动救火”到“主动预警”光有监控看板还不够我们不能24小时盯着。告警的作用就是在问题发生或即将发生时主动通知我们。我们使用Prometheus Alertmanager来处理告警。首先在Prometheus中定义告警规则。# alert_rules.yml groups: - name: danqing-alerts rules: - alert: HighGPUUtilization expr: avg(rate(DCGM_FI_DEV_GPU_UTIL{servicedanqing-gpu}[5m])) by (gpu) 85 for: 5m labels: severity: warning annotations: summary: GPU利用率持续过高 (实例 {{ $labels.instance }}) description: GPU {{ $labels.gpu }} 平均利用率在过去5分钟超过85%当前值 {{ $value }}% - alert: HighAPILatency expr: histogram_quantile(0.95, rate(danqing_api_request_duration_seconds_bucket[5m])) 3 for: 2m labels: severity: critical annotations: summary: API延迟过高 (服务 {{ $labels.service }}) description: 95分位API请求延迟在过去2分钟超过3秒当前值 {{ $value }}秒 - alert: ServiceDown expr: up{jobdanqing-service} 0 for: 1m labels: severity: critical annotations: summary: 丹青识画服务下线 (实例 {{ $labels.instance }}) description: 服务实例 {{ $labels.instance }} 已超过1分钟无法连接。这里定义了三条核心规则GPU利用率告警持续过高可能意味着需要扩容或优化模型。API延迟告警直接影响用户体验需要立即关注。服务下线告警最严重的故障。然后配置Alertmanager将告警发送到钉钉、企业微信、Slack或邮件。一个关键的实践是设置合理的阈值和持续时间。避免因瞬时抖动产生“告警风暴”也要避免阈值太宽松错过真正的问题。比如for: 5m表示持续5分钟才触发过滤掉了短时高峰。4. 实现自动化扩缩容让系统弹性自如监控和告警解决了“发现问题”自动化扩缩容则是为了“解决问题”或“预防问题”。对于丹青识画扩缩容主要针对API服务副本数。在星图这类Kubernetes环境中我们使用Horizontal Pod Autoscaler (HPA)。但默认的HPA基于CPU/内存这对GPU服务不敏感。我们需要基于自定义指标Custom Metrics来扩容这里选择QPS每秒查询数作为核心指标。首先需要安装Prometheus Adapter它可以将Prometheus中的指标转换成Kubernetes API能理解的格式供HPA使用。假设我们已经通过监控采集到了danqing_api_requests_total计数器可以在Prometheus Adapter中配置一个规则将其转换为每秒速率指标。# prometheus-adapter 配置片段 (概念示意) rules: custom: - seriesQuery: danqing_api_requests_total{namespace!,pod!} resources: overrides: namespace: {resource: namespace} pod: {resource: pod} name: matches: ^(.*)_total$ as: ${1}_per_second metricsQuery: sum(rate(.Series{.LabelMatchers}[2m])) by (.GroupBy)接着创建基于QPS的HPAapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: danqing-api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: danqing-api-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: danqing_api_requests_per_second target: type: AverageValue averageValue: 50 # 每个Pod平均每秒处理50个请求这个配置的意思是HPA会监控每个Pod的请求速率QPS目标是让每个Pod的平均QPS维持在50。如果所有Pod的平均QPS高于50就增加副本低于50就减少副本。minReplicas和maxReplicas设置了伸缩的范围。为什么选择QPS而不是GPU利用率因为QPS更直接反映业务压力且增长通常先于GPU利用率达到瓶颈。当流量上涨时QPS会立刻上升HPA可以快速扩容在GPU被打满之前就增加处理能力更好地保障延迟SLA。GPU利用率更适合作为告警指标而非伸缩指标。5. 实战经验与避坑指南这套体系跑起来后确实省心不少但也踩过一些坑分享几点经验指标选择要精准除了QPS也可以考虑将P95延迟作为伸缩指标之一但这需要更精细的调优因为延迟受多种因素影响单纯增加副本不一定能立即降低延迟。冷却时间设置HPA有--horizontal-pod-autoscaler-downscale-stabilization等参数控制缩容的冷却时间默认5分钟。避免流量短时波动导致副本数频繁抖动。扩容可以快一点冷却时间短缩容建议慢一点。资源限制要合理一定要给丹青识画的容器设置合理的GPU资源limits和requests。这样Kubernetes调度器才能正确分配节点HPA扩容时也有足够的资源可用。准备好镜像预热扩容出新Pod时如果镜像拉取慢会拖慢扩容速度。确保你的镜像体积适中并可以利用星图平台的镜像缓存功能。监控HPA本身把HPA的current_replicas和desired_replicas也加到Grafana里直观看到伸缩动态。定期演练通过模拟流量高峰测试整个监控-告警-扩容链条是否顺畅。这比线上真出问题时再验证要稳妥得多。6. 写在最后回过头看为丹青识画搭建这套运维体系投入是值得的。它带来的最大改变是运维心态——从每天提心吊胆地“看仪表盘”变成了设定好规则后系统能自己照顾自己大部分时间。你只需要在告警真正响起时去处理那些更复杂、需要人工判断的问题。当然没有一劳永逸的方案。业务在变模型在更新流量模式也可能改变。这套监控和自动化的规则也需要定期回顾和调整。但有了这个基础框架所有的优化都变得有据可依风险也更可控。如果你也在星图平台上运行类似的AI服务不妨从最核心的GPU监控和API延迟告警开始先把“眼睛”和“警报器”装上。然后逐步引入基于流量的自动伸缩让系统真正“活”起来。运维的价值就在于用自动化和智能化的手段把复杂系统的确定性牢牢抓在手里。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
丹青识画系统运维实战：监控、告警与自动化扩缩容
丹青识画系统运维实战监控、告警与自动化扩缩容最近在星图GPU平台上部署了丹青识画系统看着它稳定运行处理着源源不断的图片识别请求心里挺有成就感。但作为运维咱们都清楚部署上线只是第一步真正的挑战在于如何让它长期、稳定、高效地跑下去。特别是对于这种依赖GPU资源的AI服务资源使用率、响应延迟、服务可用性每一个指标都牵动着神经。这篇文章我就结合自己的实践经验聊聊在星图平台上为丹青识画系统搭建一套“看得见、管得住、能自愈”的运维体系。核心就三件事监控、告警和自动化扩缩容。目标很明确就是让系统运维从“救火”变成“防火”甚至“预测火情”确保服务SLA服务水平协议稳稳当当。1. 为什么丹青识画的运维需要特别关注你可能觉得运维嘛不就是看看日志、重启服务但对于丹青识画这类AI推理服务还真有点不一样。首先它的核心是GPU计算。一张显卡成本不菲用少了是浪费用爆了服务就卡顿甚至崩溃。你没法像对待CPU那样简单看个负载百分比就完事得深入看显存占用、GPU利用率、SM流多处理器活跃度这些更细的指标。其次它的服务体验直接体现在API响应时间上。用户上传一张图等个一两秒可能还行要是经常超过五秒体验就大打折扣了。这个延迟不仅受GPU影响还跟模型加载、预处理、网络I/O都有关。最后它的流量可能波动很大。白天上班时间请求多深夜请求少搞个营销活动流量可能瞬间翻几倍。靠手动调整副本数根本来不及反应。所以咱们的运维体系必须能精准感知GPU状态、实时追踪API性能并能根据流量变化自动伸缩。下面我就分步拆解这套体系的搭建。2. 搭建监控体系让系统状态一目了然监控是运维的眼睛。我们选用经典的Prometheus Grafana组合因为它足够灵活、生态丰富能很好地集成到星图平台的环境中。2.1 监控数据采集暴露关键指标丹青识画系统本身假设是基于类似FastAPI的框架需要暴露一些内置指标比如请求数、延迟、错误率。这通常可以通过引入prometheus-client库来实现。# 示例在丹青识画API服务中暴露Prometheus指标 from prometheus_client import Counter, Histogram, generate_latest, REGISTRY from fastapi import FastAPI, Response import time app FastAPI() # 定义指标 REQUEST_COUNT Counter(danqing_api_requests_total, Total API requests) REQUEST_LATENCY Histogram(danqing_api_request_duration_seconds, API request latency in seconds) ERROR_COUNT Counter(danqing_api_errors_total, Total API errors) app.middleware(http) async def monitor_requests(request, call_next): start_time time.time() REQUEST_COUNT.inc() try: response await call_next(request) return response except Exception: ERROR_COUNT.inc() raise finally: latency time.time() - start_time REQUEST_LATENCY.observe(latency) app.get(/metrics) async def get_metrics(): return Response(generate_latest(REGISTRY), media_typetext/plain) # 你的图片识别主接口 app.post(/v1/recognize) async def recognize_image(...): # ... 你的业务逻辑 pass更重要的是GPU监控。我们使用NVIDIA DCGM Exporter它是专门为Prometheus收集GPU指标的工具比简单的nvidia-smi输出更丰富、更规范。在星图平台的容器环境里可以将其作为Sidecar容器与丹青识画服务部署在同一个Pod中。# Kubernetes Pod 配置片段示例 (概念示意) apiVersion: v1 kind: Pod metadata: name: danqing-service-pod spec: containers: - name: danqing-api image: your-danqing-image:latest # ... 你的应用容器配置 - name: dcgm-exporter image: nvidia/dcgm-exporter:latest args: [-f, /etc/dcgm-exporter/dcp-metrics-included.csv] ports: - containerPort: 9400 securityContext: capabilities: add: [SYS_ADMIN]这样丹青识画服务的业务指标在/metrics端点和GPU指标在DCGM Exporter的:9400/metrics端点就都准备好了。2.2 配置Prometheus抓取与Grafana可视化接下来在星图平台上部署Prometheus并配置它去抓取上述两个目标。# prometheus.yml 配置片段 scrape_configs: - job_name: danqing-service static_configs: - targets: [danqing-service-pod-ip:8000] # 应用自身指标 labels: service: danqing-api - job_name: danqing-gpu static_configs: - targets: [danqing-service-pod-ip:9400] # GPU指标 labels: service: danqing-gpu部署好Grafana后添加Prometheus数据源然后就可以创建仪表盘了。一个实用的丹青识画运维仪表盘通常包含这几个面板GPU资源面板显示每张卡的利用率、显存使用量、温度、功耗。设置阈值线比如利用率80%显存90%。API性能面板显示请求QPS、平均/分位延迟P50, P90, P99、错误率。这是判断服务健康度的直接依据。系统资源面板容器/节点的CPU、内存使用情况。业务面板可选如果丹青识画有不同识别类型可以按类型统计请求量和成功率。看着Grafana上跳动的曲线系统是忙是闲是健康还是亚健康就一清二楚了。3. 设置智能告警从“被动救火”到“主动预警”光有监控看板还不够我们不能24小时盯着。告警的作用就是在问题发生或即将发生时主动通知我们。我们使用Prometheus Alertmanager来处理告警。首先在Prometheus中定义告警规则。# alert_rules.yml groups: - name: danqing-alerts rules: - alert: HighGPUUtilization expr: avg(rate(DCGM_FI_DEV_GPU_UTIL{servicedanqing-gpu}[5m])) by (gpu) 85 for: 5m labels: severity: warning annotations: summary: GPU利用率持续过高 (实例 {{ $labels.instance }}) description: GPU {{ $labels.gpu }} 平均利用率在过去5分钟超过85%当前值 {{ $value }}% - alert: HighAPILatency expr: histogram_quantile(0.95, rate(danqing_api_request_duration_seconds_bucket[5m])) 3 for: 2m labels: severity: critical annotations: summary: API延迟过高 (服务 {{ $labels.service }}) description: 95分位API请求延迟在过去2分钟超过3秒当前值 {{ $value }}秒 - alert: ServiceDown expr: up{jobdanqing-service} 0 for: 1m labels: severity: critical annotations: summary: 丹青识画服务下线 (实例 {{ $labels.instance }}) description: 服务实例 {{ $labels.instance }} 已超过1分钟无法连接。这里定义了三条核心规则GPU利用率告警持续过高可能意味着需要扩容或优化模型。API延迟告警直接影响用户体验需要立即关注。服务下线告警最严重的故障。然后配置Alertmanager将告警发送到钉钉、企业微信、Slack或邮件。一个关键的实践是设置合理的阈值和持续时间。避免因瞬时抖动产生“告警风暴”也要避免阈值太宽松错过真正的问题。比如for: 5m表示持续5分钟才触发过滤掉了短时高峰。4. 实现自动化扩缩容让系统弹性自如监控和告警解决了“发现问题”自动化扩缩容则是为了“解决问题”或“预防问题”。对于丹青识画扩缩容主要针对API服务副本数。在星图这类Kubernetes环境中我们使用Horizontal Pod Autoscaler (HPA)。但默认的HPA基于CPU/内存这对GPU服务不敏感。我们需要基于自定义指标Custom Metrics来扩容这里选择QPS每秒查询数作为核心指标。首先需要安装Prometheus Adapter它可以将Prometheus中的指标转换成Kubernetes API能理解的格式供HPA使用。假设我们已经通过监控采集到了danqing_api_requests_total计数器可以在Prometheus Adapter中配置一个规则将其转换为每秒速率指标。# prometheus-adapter 配置片段 (概念示意) rules: custom: - seriesQuery: danqing_api_requests_total{namespace!,pod!} resources: overrides: namespace: {resource: namespace} pod: {resource: pod} name: matches: ^(.*)_total$ as: ${1}_per_second metricsQuery: sum(rate(.Series{.LabelMatchers}[2m])) by (.GroupBy)接着创建基于QPS的HPAapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: danqing-api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: danqing-api-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: danqing_api_requests_per_second target: type: AverageValue averageValue: 50 # 每个Pod平均每秒处理50个请求这个配置的意思是HPA会监控每个Pod的请求速率QPS目标是让每个Pod的平均QPS维持在50。如果所有Pod的平均QPS高于50就增加副本低于50就减少副本。minReplicas和maxReplicas设置了伸缩的范围。为什么选择QPS而不是GPU利用率因为QPS更直接反映业务压力且增长通常先于GPU利用率达到瓶颈。当流量上涨时QPS会立刻上升HPA可以快速扩容在GPU被打满之前就增加处理能力更好地保障延迟SLA。GPU利用率更适合作为告警指标而非伸缩指标。5. 实战经验与避坑指南这套体系跑起来后确实省心不少但也踩过一些坑分享几点经验指标选择要精准除了QPS也可以考虑将P95延迟作为伸缩指标之一但这需要更精细的调优因为延迟受多种因素影响单纯增加副本不一定能立即降低延迟。冷却时间设置HPA有--horizontal-pod-autoscaler-downscale-stabilization等参数控制缩容的冷却时间默认5分钟。避免流量短时波动导致副本数频繁抖动。扩容可以快一点冷却时间短缩容建议慢一点。资源限制要合理一定要给丹青识画的容器设置合理的GPU资源limits和requests。这样Kubernetes调度器才能正确分配节点HPA扩容时也有足够的资源可用。准备好镜像预热扩容出新Pod时如果镜像拉取慢会拖慢扩容速度。确保你的镜像体积适中并可以利用星图平台的镜像缓存功能。监控HPA本身把HPA的current_replicas和desired_replicas也加到Grafana里直观看到伸缩动态。定期演练通过模拟流量高峰测试整个监控-告警-扩容链条是否顺畅。这比线上真出问题时再验证要稳妥得多。6. 写在最后回过头看为丹青识画搭建这套运维体系投入是值得的。它带来的最大改变是运维心态——从每天提心吊胆地“看仪表盘”变成了设定好规则后系统能自己照顾自己大部分时间。你只需要在告警真正响起时去处理那些更复杂、需要人工判断的问题。当然没有一劳永逸的方案。业务在变模型在更新流量模式也可能改变。这套监控和自动化的规则也需要定期回顾和调整。但有了这个基础框架所有的优化都变得有据可依风险也更可控。如果你也在星图平台上运行类似的AI服务不妨从最核心的GPU监控和API延迟告警开始先把“眼睛”和“警报器”装上。然后逐步引入基于流量的自动伸缩让系统真正“活”起来。运维的价值就在于用自动化和智能化的手段把复杂系统的确定性牢牢抓在手里。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
