GLM-OCR服务监控与运维指南PrometheusGrafana构建监控看板部署好一个OCR服务只是第一步让它稳定、可靠地跑在生产环境里才是真正的挑战。你可能会遇到这些问题服务突然变慢了但不知道是哪个环节出了问题GPU使用率忽高忽低资源浪费严重或者某个接口的错误率悄悄升高直到用户投诉才发现。这些问题如果全靠人工盯着日志去排查效率低不说还容易遗漏。今天我们就来聊聊怎么给GLM-OCR服务装上“眼睛”和“警报器”——也就是搭建一套完整的监控运维体系。我们会用Prometheus来收集各种指标数据再用Grafana做成直观的监控看板让你对服务的运行状态一目了然。同时我们也会介绍如何聚合日志和设置异常告警真正做到防患于未然。通过这篇指南你将学会如何从零开始为你的OCR服务构建一套生产级的监控解决方案。1. 为什么需要监控GLM-OCR服务在深入技术细节之前我们先得想明白为什么要花力气做监控简单来说监控能帮你回答几个关键问题服务还活着吗它健康吗它表现得好吗对于GLM-OCR这类AI服务它的“健康”和“表现”体现在几个核心维度上。首先是可用性你得知道服务是不是7x24小时都能正常响应请求。其次是性能比如处理一张图片平均要花多少时间延迟一秒钟能处理多少张QPS。然后是资源消耗特别是GPU的使用率这直接关系到你的云服务器账单。最后是质量也就是识别结果的准确率虽然直接监控准确率比较难但我们可以通过监控请求的错误率来间接反映问题。没有监控你就像在开一辆没有仪表盘的车速度、油量、水温全凭感觉出问题是迟早的事。有了监控你就能提前发现性能瓶颈、资源异常或者潜在的错误在用户感知到问题之前就把它解决掉。2. 搭建监控基础设施Prometheus与Grafana工欲善其事必先利其器。我们这套监控方案的核心是两个开源神器Prometheus和Grafana。Prometheus是一个监控系统和时间序列数据库。你可以把它理解为一个超级能干的“数据收集员”。它定期去各个服务端点“问诊”这个过程叫抓取收集CPU、内存、请求数、错误数这些指标然后按照时间顺序存起来。它的特点是简单、可靠特别适合监控微服务。Grafana则是一个数据可视化平台是个“美术大师”。它能把Prometheus里那些枯燥的数字变成一张张色彩丰富、直观易懂的图表和仪表盘。你可以自定义看板把最重要的指标放在最显眼的位置。它们俩搭档一个负责收集和存储数据一个负责展示和分析数据完美。2.1 安装与配置Prometheus首先我们来安装Prometheus。这里以Linux系统为例使用Docker安装是最简单的方式。创建配置文件目录Prometheus需要一个配置文件来告诉它要去哪里抓取数据。mkdir -p /opt/prometheus cd /opt/prometheus编写配置文件创建一个名为prometheus.yml的文件。# prometheus.yml global: scrape_interval: 15s # 每15秒抓取一次数据 evaluation_interval: 15s # 每15秒评估一次告警规则 alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # 告警管理器地址后续可配置 rule_files: # - first_rules.yml # - second_rules.yml scrape_configs: - job_name: prometheus # 监控Prometheus自身 static_configs: - targets: [localhost:9090] - job_name: glm-ocr # 这是我们OCR服务的监控任务 static_configs: - targets: [your-ocr-service-host:8080] # 替换为你的OCR服务地址和端口 metrics_path: /metrics # Prometheus抓取指标的默认路径 scrape_interval: 10s # 对这个服务我们10秒抓取一次更频繁注意把your-ocr-service-host:8080换成你实际部署GLM-OCR服务的机器IP和端口。使用Docker运行Prometheusdocker run -d \ --nameprometheus \ -p 9090:9090 \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus运行后访问http://你的服务器IP:9090就能看到Prometheus自带的简单界面了。在“Status - Targets”页面应该能看到glm-ocr这个job的状态是“UP”前提是你的OCR服务已经暴露了/metrics端点我们下一步就做这个。2.2 安装与配置GrafanaGrafana的安装同样简单。使用Docker运行Grafanadocker run -d \ --namegrafana \ -p 3000:3000 \ grafana/grafana-oss初始登录访问http://你的服务器IP:3000默认用户名和密码都是admin。首次登录会要求修改密码。添加数据源这是最关键的一步告诉Grafana数据从哪里来。登录后点击左侧齿轮图标进入“Configuration”选择“Data Sources”。点击“Add data source”选择“Prometheus”。在URL一栏填写http://你的Prometheus服务器IP:9090如果Prometheus和Grafana在同一台机器且用Docker运行可以填http://host.docker.internal:9090或http://宿主机IP:9090。点击“Save Test”如果显示“Data source is working”就成功了。至此监控平台的基础设施就准备好了。接下来我们要让GLM-OCR服务“开口说话”暴露自己的健康指标。3. 为GLM-OCR服务添加监控指标Prometheus只能抓取那些按照它规定格式暴露数据的服务。对于Python的Web服务比如用FastAPI或Flask搭建的GLM-OCR服务最方便的方法是使用prometheus-client库。3.1 改造你的OCR服务假设你的OCR服务主文件是app.py下面是如何集成监控的步骤。安装依赖pip install prometheus-client在服务代码中集成修改你的app.py添加指标收集和暴露端点。# app.py from fastapi import FastAPI, Response # 或 from flask import Flask from prometheus_client import Counter, Histogram, Gauge, generate_latest, CONTENT_TYPE_LATEST import time app FastAPI() # 或 app Flask(__name__) # 1. 定义监控指标 # 请求总数计数器 REQUEST_COUNT Counter( glm_ocr_requests_total, Total number of OCR requests, [method, endpoint, status] ) # 请求延迟直方图单位秒 REQUEST_LATENCY Histogram( glm_ocr_request_duration_seconds, OCR request latency in seconds, [method, endpoint], buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0) # 自定义延迟分布桶 ) # 正在处理的请求数瞬时值 REQUEST_IN_PROGRESS Gauge( glm_ocr_requests_in_progress, Number of OCR requests currently in progress, [method, endpoint] ) # GPU内存使用率示例需要根据你的环境调整获取方式 GPU_MEMORY_USAGE Gauge( glm_ocr_gpu_memory_usage_percent, GPU memory usage percentage, [gpu_id] ) # 2. 创建 /metrics 端点供Prometheus抓取 app.get(/metrics) def get_metrics(): # 这里可以添加代码定期更新GPU指标例如每抓取一次更新 # update_gpu_metrics() return Response(generate_latest(), mimetypeCONTENT_TYPE_LATEST) # 3. 使用中间件或装饰器包装你的OCR接口自动记录指标 app.middleware(http) # FastAPI中间件 async def monitor_requests(request, call_next): method request.method endpoint request.url.path # 记录开始时间 start_time time.time() # 增加“处理中”计数 REQUEST_IN_PROGRESS.labels(methodmethod, endpointendpoint).inc() try: response await call_next(request) status_code response.status_code except Exception: status_code 500 raise finally: # 减少“处理中”计数 REQUEST_IN_PROGRESS.labels(methodmethod, endpointendpoint).dec() # 记录延迟 latency time.time() - start_time REQUEST_LATENCY.labels(methodmethod, endpointendpoint).observe(latency) # 记录请求计数注意状态码分类如‘2xx’ ‘4xx’ ‘5xx’ status_group f{status_code // 100}xx REQUEST_COUNT.labels(methodmethod, endpointendpoint, statusstatus_group).inc() return response # 4. 你的原始OCR接口 app.post(/ocr) async def ocr_endpoint(...): # ... 你原有的OCR处理逻辑 ... return {result: ...} # 5. 可选一个简单的健康检查端点 app.get(/health) def health_check(): return {status: healthy}关键点解释Counter只增不减的计数器适合记录请求总数、错误总数。Histogram直方图用来统计延迟的分布情况比如“有多少请求在1秒内完成”。Gauge仪表盘可增可减的瞬时值适合记录当前并发数、GPU使用率。中间件自动为每个请求计算延迟、计数无需修改每个业务接口。/metricsPrometheus会定期访问这个端点拉取数据。/health可用于Kubernetes等平台的存活探针。重启你的OCR服务并确保它能正常访问。然后访问http://你的OCR服务地址:端口/metrics你应该能看到一堆以glm_ocr_开头的指标数据格式是Prometheus标准的纯文本。现在你的GLM-OCR服务已经是一个“可观测”的服务了。回到Prometheus的Web界面:9090在Graph页面输入glm_ocr_requests_total并执行应该能看到这条指标曲线开始增长了。4. 在Grafana中构建监控看板数据有了可视化看板就好办了。Grafana的强大之处在于其丰富的图表和灵活的面板配置。4.1 创建你的第一个图表在Grafana侧边栏点击“Dashboards” - “New dashboard” - “Add visualization”。在查询编辑器Query editor中选择我们之前添加的Prometheus数据源。输入PromQL查询语句。例如每秒请求率QPSrate(glm_ocr_requests_total[5m])平均延迟rate(glm_ocr_request_duration_seconds_sum[5m]) / rate(glm_ocr_request_duration_seconds_count[5m])错误率5xx错误rate(glm_ocr_requests_total{status5xx}[5m]) / rate(glm_ocr_requests_total[5m])当前正在处理的请求数glm_ocr_requests_in_progress在右侧面板设置中可以修改图表标题、类型折线图、柱状图等、坐标轴单位等。4.2 设计一个完整的OCR服务监控看板一个好的看板应该能让运维人员一眼掌握服务的核心状态。我建议按以下区域来组织概览区顶部放置最重要的“红绿灯”指标。用“Stat”图表类型显示当前QPS平均延迟P95或P99延迟更能反映尾部体验错误率服务状态通过up{jobglm-ocr}判断流量与性能区中部左侧图表1请求QPS随时间变化折线图。图表2请求延迟分布热图或折线图展示平均延迟、P90、P99。资源与系统区中部右侧图表3GPU使用率内存、利用率。注需要额外部署node-exporter或使用NVIDIA DCGM等工具暴露GPU指标图表4服务所在容器的CPU、内存使用情况。错误与详情区底部图表5按状态码2xx, 4xx, 5xx分类的请求数量/比率。表格最近发生的错误请求日志需要与日志系统集成见下文。你可以不断调整和添加面板直到这个看板符合你的运维习惯。Grafana支持将看板保存为JSON文件方便分享和版本管理。5. 日志聚合与异常告警监控看板解决了“看得见”的问题但我们不可能一直盯着屏幕。我们还需要“听得见”的警报。5.1 集中化日志收集ELK/Loki方案服务的日志分散在各个容器或服务器上排查问题时非常不便。我们需要一个集中化的日志系统。经典ELK栈Elasticsearch存储、Logstash/Fluentd收集、Kibana展示。功能强大但相对重量级。轻量级选择LokiGrafana Labs推出的日志聚合系统设计理念是“像Prometheus但是用于日志”。它和Grafana集成得非常好语法也类似PromQL叫LogQL。这里简单提一下使用Grafana Loki的方案在你的OCR服务中确保日志以结构化格式如JSON输出到标准输出stdout。使用Docker的logging driver或PromtailLoki的日志收集客户端将日志发送到Loki服务。在Grafana中添加Loki数据源就可以在“Explore”页面用LogQL查询日志也可以在看板中创建日志面板。5.2 配置Prometheus告警规则Prometheus不仅可以存储数据还能根据规则计算并触发告警。定义告警规则在Prometheus配置目录/opt/prometheus下创建一个新文件例如ocr_alerts.yml。# ocr_alerts.yml groups: - name: glm-ocr-alerts rules: - alert: OCRServiceDown expr: up{jobglm-ocr} 0 for: 1m # 持续1分钟为0才触发避免网络抖动误报 labels: severity: critical annotations: summary: GLM-OCR服务下线 (实例 {{ $labels.instance }}) description: {{ $labels.job }} 服务已宕机超过1分钟。 - alert: HighErrorRate expr: rate(glm_ocr_requests_total{status5xx}[5m]) / rate(glm_ocr_requests_total[5m]) 0.05 for: 2m labels: severity: warning annotations: summary: OCR服务错误率过高 (实例 {{ $labels.instance }}) description: 5分钟内5xx错误率超过5%当前值: {{ $value | humanizePercentage }} - alert: HighRequestLatency expr: histogram_quantile(0.95, rate(glm_ocr_request_duration_seconds_bucket[5m])) 3 for: 3m labels: severity: warning annotations: summary: OCR服务延迟过高 (实例 {{ $labels.instance }}) description: 95分位请求延迟超过3秒当前值: {{ $value }}s在prometheus.yml中引用这个规则文件rule_files: - ocr_alerts.yml # 添加这一行重启Prometheus容器以加载新规则。5.3 配置Alertmanager发送告警通知Prometheus触发告警后需要另一个组件Alertmanager来负责去重、分组并通过各种渠道如邮件、钉钉、企业微信、Slack发送通知。安装Alertmanager同样用Docker并配置其alertmanager.yml设置接收器Receiver比如邮件SMTP信息或Webhook地址。在Prometheus的配置中指向Alertmanager的地址就是之前配置里注释掉的那部分。当告警触发时Alertmanager就会按照配置将信息发送到你指定的频道。这样一旦服务出现异常你就能第一时间在手机或电脑上收到通知而不是等到业务受影响。6. 总结走完这一整套流程你的GLM-OCR服务就从“黑盒”变成了“白盒”。通过Prometheus你能源源不断地收集到服务的各项关键指标通过Grafana这些指标变成了直观的图表让你对服务的运行状况了如指掌通过告警规则你可以在问题萌芽阶段就得到通知。这套监控体系的价值不仅仅在于出了问题能快速定位。更重要的是它让你能趋势分析比如业务量增长是否会导致资源不足、容量规划根据历史数据决定何时需要扩容以及验证优化效果代码优化后延迟是否真的下降了。刚开始搭建可能会觉得有点繁琐但一旦跑起来你就会发现它带来的安心感和效率提升是巨大的。建议你先从核心的QPS、延迟、错误率这几个指标开始把看板和基础告警搭起来然后再逐步完善日志和更细粒度的资源监控。监控是一个不断迭代的过程随着你对服务理解的加深监控体系也会越来越完善。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
GLM-OCR服务监控与运维指南：Prometheus+Grafana构建监控看板
GLM-OCR服务监控与运维指南PrometheusGrafana构建监控看板部署好一个OCR服务只是第一步让它稳定、可靠地跑在生产环境里才是真正的挑战。你可能会遇到这些问题服务突然变慢了但不知道是哪个环节出了问题GPU使用率忽高忽低资源浪费严重或者某个接口的错误率悄悄升高直到用户投诉才发现。这些问题如果全靠人工盯着日志去排查效率低不说还容易遗漏。今天我们就来聊聊怎么给GLM-OCR服务装上“眼睛”和“警报器”——也就是搭建一套完整的监控运维体系。我们会用Prometheus来收集各种指标数据再用Grafana做成直观的监控看板让你对服务的运行状态一目了然。同时我们也会介绍如何聚合日志和设置异常告警真正做到防患于未然。通过这篇指南你将学会如何从零开始为你的OCR服务构建一套生产级的监控解决方案。1. 为什么需要监控GLM-OCR服务在深入技术细节之前我们先得想明白为什么要花力气做监控简单来说监控能帮你回答几个关键问题服务还活着吗它健康吗它表现得好吗对于GLM-OCR这类AI服务它的“健康”和“表现”体现在几个核心维度上。首先是可用性你得知道服务是不是7x24小时都能正常响应请求。其次是性能比如处理一张图片平均要花多少时间延迟一秒钟能处理多少张QPS。然后是资源消耗特别是GPU的使用率这直接关系到你的云服务器账单。最后是质量也就是识别结果的准确率虽然直接监控准确率比较难但我们可以通过监控请求的错误率来间接反映问题。没有监控你就像在开一辆没有仪表盘的车速度、油量、水温全凭感觉出问题是迟早的事。有了监控你就能提前发现性能瓶颈、资源异常或者潜在的错误在用户感知到问题之前就把它解决掉。2. 搭建监控基础设施Prometheus与Grafana工欲善其事必先利其器。我们这套监控方案的核心是两个开源神器Prometheus和Grafana。Prometheus是一个监控系统和时间序列数据库。你可以把它理解为一个超级能干的“数据收集员”。它定期去各个服务端点“问诊”这个过程叫抓取收集CPU、内存、请求数、错误数这些指标然后按照时间顺序存起来。它的特点是简单、可靠特别适合监控微服务。Grafana则是一个数据可视化平台是个“美术大师”。它能把Prometheus里那些枯燥的数字变成一张张色彩丰富、直观易懂的图表和仪表盘。你可以自定义看板把最重要的指标放在最显眼的位置。它们俩搭档一个负责收集和存储数据一个负责展示和分析数据完美。2.1 安装与配置Prometheus首先我们来安装Prometheus。这里以Linux系统为例使用Docker安装是最简单的方式。创建配置文件目录Prometheus需要一个配置文件来告诉它要去哪里抓取数据。mkdir -p /opt/prometheus cd /opt/prometheus编写配置文件创建一个名为prometheus.yml的文件。# prometheus.yml global: scrape_interval: 15s # 每15秒抓取一次数据 evaluation_interval: 15s # 每15秒评估一次告警规则 alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # 告警管理器地址后续可配置 rule_files: # - first_rules.yml # - second_rules.yml scrape_configs: - job_name: prometheus # 监控Prometheus自身 static_configs: - targets: [localhost:9090] - job_name: glm-ocr # 这是我们OCR服务的监控任务 static_configs: - targets: [your-ocr-service-host:8080] # 替换为你的OCR服务地址和端口 metrics_path: /metrics # Prometheus抓取指标的默认路径 scrape_interval: 10s # 对这个服务我们10秒抓取一次更频繁注意把your-ocr-service-host:8080换成你实际部署GLM-OCR服务的机器IP和端口。使用Docker运行Prometheusdocker run -d \ --nameprometheus \ -p 9090:9090 \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus运行后访问http://你的服务器IP:9090就能看到Prometheus自带的简单界面了。在“Status - Targets”页面应该能看到glm-ocr这个job的状态是“UP”前提是你的OCR服务已经暴露了/metrics端点我们下一步就做这个。2.2 安装与配置GrafanaGrafana的安装同样简单。使用Docker运行Grafanadocker run -d \ --namegrafana \ -p 3000:3000 \ grafana/grafana-oss初始登录访问http://你的服务器IP:3000默认用户名和密码都是admin。首次登录会要求修改密码。添加数据源这是最关键的一步告诉Grafana数据从哪里来。登录后点击左侧齿轮图标进入“Configuration”选择“Data Sources”。点击“Add data source”选择“Prometheus”。在URL一栏填写http://你的Prometheus服务器IP:9090如果Prometheus和Grafana在同一台机器且用Docker运行可以填http://host.docker.internal:9090或http://宿主机IP:9090。点击“Save Test”如果显示“Data source is working”就成功了。至此监控平台的基础设施就准备好了。接下来我们要让GLM-OCR服务“开口说话”暴露自己的健康指标。3. 为GLM-OCR服务添加监控指标Prometheus只能抓取那些按照它规定格式暴露数据的服务。对于Python的Web服务比如用FastAPI或Flask搭建的GLM-OCR服务最方便的方法是使用prometheus-client库。3.1 改造你的OCR服务假设你的OCR服务主文件是app.py下面是如何集成监控的步骤。安装依赖pip install prometheus-client在服务代码中集成修改你的app.py添加指标收集和暴露端点。# app.py from fastapi import FastAPI, Response # 或 from flask import Flask from prometheus_client import Counter, Histogram, Gauge, generate_latest, CONTENT_TYPE_LATEST import time app FastAPI() # 或 app Flask(__name__) # 1. 定义监控指标 # 请求总数计数器 REQUEST_COUNT Counter( glm_ocr_requests_total, Total number of OCR requests, [method, endpoint, status] ) # 请求延迟直方图单位秒 REQUEST_LATENCY Histogram( glm_ocr_request_duration_seconds, OCR request latency in seconds, [method, endpoint], buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0) # 自定义延迟分布桶 ) # 正在处理的请求数瞬时值 REQUEST_IN_PROGRESS Gauge( glm_ocr_requests_in_progress, Number of OCR requests currently in progress, [method, endpoint] ) # GPU内存使用率示例需要根据你的环境调整获取方式 GPU_MEMORY_USAGE Gauge( glm_ocr_gpu_memory_usage_percent, GPU memory usage percentage, [gpu_id] ) # 2. 创建 /metrics 端点供Prometheus抓取 app.get(/metrics) def get_metrics(): # 这里可以添加代码定期更新GPU指标例如每抓取一次更新 # update_gpu_metrics() return Response(generate_latest(), mimetypeCONTENT_TYPE_LATEST) # 3. 使用中间件或装饰器包装你的OCR接口自动记录指标 app.middleware(http) # FastAPI中间件 async def monitor_requests(request, call_next): method request.method endpoint request.url.path # 记录开始时间 start_time time.time() # 增加“处理中”计数 REQUEST_IN_PROGRESS.labels(methodmethod, endpointendpoint).inc() try: response await call_next(request) status_code response.status_code except Exception: status_code 500 raise finally: # 减少“处理中”计数 REQUEST_IN_PROGRESS.labels(methodmethod, endpointendpoint).dec() # 记录延迟 latency time.time() - start_time REQUEST_LATENCY.labels(methodmethod, endpointendpoint).observe(latency) # 记录请求计数注意状态码分类如‘2xx’ ‘4xx’ ‘5xx’ status_group f{status_code // 100}xx REQUEST_COUNT.labels(methodmethod, endpointendpoint, statusstatus_group).inc() return response # 4. 你的原始OCR接口 app.post(/ocr) async def ocr_endpoint(...): # ... 你原有的OCR处理逻辑 ... return {result: ...} # 5. 可选一个简单的健康检查端点 app.get(/health) def health_check(): return {status: healthy}关键点解释Counter只增不减的计数器适合记录请求总数、错误总数。Histogram直方图用来统计延迟的分布情况比如“有多少请求在1秒内完成”。Gauge仪表盘可增可减的瞬时值适合记录当前并发数、GPU使用率。中间件自动为每个请求计算延迟、计数无需修改每个业务接口。/metricsPrometheus会定期访问这个端点拉取数据。/health可用于Kubernetes等平台的存活探针。重启你的OCR服务并确保它能正常访问。然后访问http://你的OCR服务地址:端口/metrics你应该能看到一堆以glm_ocr_开头的指标数据格式是Prometheus标准的纯文本。现在你的GLM-OCR服务已经是一个“可观测”的服务了。回到Prometheus的Web界面:9090在Graph页面输入glm_ocr_requests_total并执行应该能看到这条指标曲线开始增长了。4. 在Grafana中构建监控看板数据有了可视化看板就好办了。Grafana的强大之处在于其丰富的图表和灵活的面板配置。4.1 创建你的第一个图表在Grafana侧边栏点击“Dashboards” - “New dashboard” - “Add visualization”。在查询编辑器Query editor中选择我们之前添加的Prometheus数据源。输入PromQL查询语句。例如每秒请求率QPSrate(glm_ocr_requests_total[5m])平均延迟rate(glm_ocr_request_duration_seconds_sum[5m]) / rate(glm_ocr_request_duration_seconds_count[5m])错误率5xx错误rate(glm_ocr_requests_total{status5xx}[5m]) / rate(glm_ocr_requests_total[5m])当前正在处理的请求数glm_ocr_requests_in_progress在右侧面板设置中可以修改图表标题、类型折线图、柱状图等、坐标轴单位等。4.2 设计一个完整的OCR服务监控看板一个好的看板应该能让运维人员一眼掌握服务的核心状态。我建议按以下区域来组织概览区顶部放置最重要的“红绿灯”指标。用“Stat”图表类型显示当前QPS平均延迟P95或P99延迟更能反映尾部体验错误率服务状态通过up{jobglm-ocr}判断流量与性能区中部左侧图表1请求QPS随时间变化折线图。图表2请求延迟分布热图或折线图展示平均延迟、P90、P99。资源与系统区中部右侧图表3GPU使用率内存、利用率。注需要额外部署node-exporter或使用NVIDIA DCGM等工具暴露GPU指标图表4服务所在容器的CPU、内存使用情况。错误与详情区底部图表5按状态码2xx, 4xx, 5xx分类的请求数量/比率。表格最近发生的错误请求日志需要与日志系统集成见下文。你可以不断调整和添加面板直到这个看板符合你的运维习惯。Grafana支持将看板保存为JSON文件方便分享和版本管理。5. 日志聚合与异常告警监控看板解决了“看得见”的问题但我们不可能一直盯着屏幕。我们还需要“听得见”的警报。5.1 集中化日志收集ELK/Loki方案服务的日志分散在各个容器或服务器上排查问题时非常不便。我们需要一个集中化的日志系统。经典ELK栈Elasticsearch存储、Logstash/Fluentd收集、Kibana展示。功能强大但相对重量级。轻量级选择LokiGrafana Labs推出的日志聚合系统设计理念是“像Prometheus但是用于日志”。它和Grafana集成得非常好语法也类似PromQL叫LogQL。这里简单提一下使用Grafana Loki的方案在你的OCR服务中确保日志以结构化格式如JSON输出到标准输出stdout。使用Docker的logging driver或PromtailLoki的日志收集客户端将日志发送到Loki服务。在Grafana中添加Loki数据源就可以在“Explore”页面用LogQL查询日志也可以在看板中创建日志面板。5.2 配置Prometheus告警规则Prometheus不仅可以存储数据还能根据规则计算并触发告警。定义告警规则在Prometheus配置目录/opt/prometheus下创建一个新文件例如ocr_alerts.yml。# ocr_alerts.yml groups: - name: glm-ocr-alerts rules: - alert: OCRServiceDown expr: up{jobglm-ocr} 0 for: 1m # 持续1分钟为0才触发避免网络抖动误报 labels: severity: critical annotations: summary: GLM-OCR服务下线 (实例 {{ $labels.instance }}) description: {{ $labels.job }} 服务已宕机超过1分钟。 - alert: HighErrorRate expr: rate(glm_ocr_requests_total{status5xx}[5m]) / rate(glm_ocr_requests_total[5m]) 0.05 for: 2m labels: severity: warning annotations: summary: OCR服务错误率过高 (实例 {{ $labels.instance }}) description: 5分钟内5xx错误率超过5%当前值: {{ $value | humanizePercentage }} - alert: HighRequestLatency expr: histogram_quantile(0.95, rate(glm_ocr_request_duration_seconds_bucket[5m])) 3 for: 3m labels: severity: warning annotations: summary: OCR服务延迟过高 (实例 {{ $labels.instance }}) description: 95分位请求延迟超过3秒当前值: {{ $value }}s在prometheus.yml中引用这个规则文件rule_files: - ocr_alerts.yml # 添加这一行重启Prometheus容器以加载新规则。5.3 配置Alertmanager发送告警通知Prometheus触发告警后需要另一个组件Alertmanager来负责去重、分组并通过各种渠道如邮件、钉钉、企业微信、Slack发送通知。安装Alertmanager同样用Docker并配置其alertmanager.yml设置接收器Receiver比如邮件SMTP信息或Webhook地址。在Prometheus的配置中指向Alertmanager的地址就是之前配置里注释掉的那部分。当告警触发时Alertmanager就会按照配置将信息发送到你指定的频道。这样一旦服务出现异常你就能第一时间在手机或电脑上收到通知而不是等到业务受影响。6. 总结走完这一整套流程你的GLM-OCR服务就从“黑盒”变成了“白盒”。通过Prometheus你能源源不断地收集到服务的各项关键指标通过Grafana这些指标变成了直观的图表让你对服务的运行状况了如指掌通过告警规则你可以在问题萌芽阶段就得到通知。这套监控体系的价值不仅仅在于出了问题能快速定位。更重要的是它让你能趋势分析比如业务量增长是否会导致资源不足、容量规划根据历史数据决定何时需要扩容以及验证优化效果代码优化后延迟是否真的下降了。刚开始搭建可能会觉得有点繁琐但一旦跑起来你就会发现它带来的安心感和效率提升是巨大的。建议你先从核心的QPS、延迟、错误率这几个指标开始把看板和基础告警搭起来然后再逐步完善日志和更细粒度的资源监控。监控是一个不断迭代的过程随着你对服务理解的加深监控体系也会越来越完善。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
