LightOnOCR-2-1B实战教程使用PrometheusGrafana监控OCR服务QPS与错误率你是不是也遇到过这种情况部署了一个OCR服务刚开始用得好好的突然有一天用户反馈说识别变慢了或者干脆没反应了。你赶紧登录服务器查看CPU、内存、GPU看起来都正常但就是不知道问题出在哪里。这种“黑盒”状态让人很头疼。你不知道服务到底处理了多少请求不知道响应时间是否正常更不知道错误率有没有超标。等到用户投诉才发现问题往往已经晚了。今天我就来分享一个实战方案用PrometheusGrafana为LightOnOCR-2-1B搭建一套完整的监控系统。这套方案能让你实时看到服务的QPS每秒查询率、错误率、响应时间等关键指标就像给服务装上了“仪表盘”随时掌握运行状态。1. 为什么需要监控OCR服务在深入技术细节之前我们先聊聊为什么监控这么重要。很多人觉得服务能跑起来就行了监控是“锦上添花”的东西。但实际上监控是保障服务稳定性的“必需品”。没有监控你就像在开一辆没有仪表盘的车你不知道车速是多少不知道QPS你不知道油还剩多少不知道资源使用情况你不知道发动机温度是否正常不知道错误率出了问题只能靠“感觉”排查效率低下有了监控你能获得这些能力实时告警错误率超过阈值时立即收到通知性能分析找到瓶颈优化服务性能容量规划根据历史数据预测未来需求故障排查快速定位问题根源对于LightOnOCR-2-1B这样的OCR服务监控尤其重要。OCR处理的是图片识别每张图片的大小、复杂度都不同处理时间差异很大。如果没有监控你很难判断服务是否在正常工作。2. 监控方案整体设计我们的监控方案基于业界标准的“PrometheusGrafana”组合。这套方案成熟、稳定而且完全开源免费。整体架构很简单LightOnOCR服务 → 暴露指标 → Prometheus采集 → Grafana展示让我用大白话解释一下每个组件的作用LightOnOCR服务就是我们的主角提供OCR识别功能指标暴露在服务里加一段代码让它把自己的运行状态“说出来”Prometheus一个“数据收集器”定期去各个服务那里“问”数据Grafana一个“仪表盘”把Prometheus收集的数据用漂亮的图表展示出来这个方案有几个明显的优点轻量级不占用太多资源对OCR服务性能影响很小实时性数据几乎是实时的延迟只有几秒钟可视化图表直观一眼就能看懂服务状态可扩展以后增加其他服务监控方案可以复用3. 为LightOnOCR服务添加监控指标要让Prometheus能收集数据首先得让LightOnOCR服务“暴露”自己的运行指标。我们在原来的服务代码基础上做一些修改。3.1 安装必要的Python库首先确保你的环境安装了监控相关的库pip install prometheus-client pip install psutilprometheus-client是Prometheus官方提供的Python客户端库用来生成和暴露监控指标。psutil用来获取系统资源信息比如CPU、内存使用率。3.2 修改OCR服务代码我们需要修改LightOnOCR的服务代码在app.py中添加监控功能。下面是关键的修改部分# 在app.py开头添加导入 from prometheus_client import Counter, Histogram, Gauge, generate_latest, REGISTRY from prometheus_client.exposition import MetricsHandler import time import psutil import threading # 定义监控指标 # QPS每秒处理的请求数 REQUEST_COUNT Counter( lightonocr_requests_total, Total number of OCR requests, [method, endpoint, status] ) # 请求耗时分布 REQUEST_LATENCY Histogram( lightonocr_request_duration_seconds, OCR request latency in seconds, [method, endpoint], buckets[0.1, 0.5, 1.0, 2.0, 5.0, 10.0] ) # 错误率 ERROR_COUNT Counter( lightonocr_errors_total, Total number of OCR errors, [error_type] ) # 系统资源使用 CPU_USAGE Gauge(lightonocr_cpu_percent, CPU usage percentage) MEMORY_USAGE Gauge(lightonocr_memory_mb, Memory usage in MB) GPU_MEMORY_USAGE Gauge(lightonocr_gpu_memory_mb, GPU memory usage in MB) # 添加一个独立的监控端点 def metrics_handler(environ, start_response): 处理Prometheus的/metrics请求 data generate_latest(REGISTRY) status 200 OK response_headers [ (Content-type, text/plain), (Content-Length, str(len(data))) ] start_response(status, response_headers) return [data] # 在Gradio应用启动后添加系统监控线程 def monitor_system_resources(): 定期更新系统资源指标 while True: try: # CPU使用率 CPU_USAGE.set(psutil.cpu_percent()) # 内存使用MB memory psutil.virtual_memory() MEMORY_USAGE.set(memory.used / 1024 / 1024) # GPU内存使用如果有GPU # 这里需要根据实际情况调整比如使用pynvml库 # 为了简单起见我们先注释掉 # import pynvml # pynvml.nvmlInit() # handle pynvml.nvmlDeviceGetHandleByIndex(0) # info pynvml.nvmlDeviceGetMemoryInfo(handle) # GPU_MEMORY_USAGE.set(info.used / 1024 / 1024) except Exception as e: print(f监控资源出错: {e}) time.sleep(5) # 每5秒更新一次 # 修改OCR处理函数添加监控 def extract_text_with_monitoring(image): 带监控的OCR处理函数 start_time time.time() try: # 调用原来的OCR处理逻辑 result original_extract_text(image) # 假设这是原来的处理函数 # 记录成功的请求 REQUEST_COUNT.labels( methodPOST, endpoint/extract_text, statussuccess ).inc() # 记录请求耗时 duration time.time() - start_time REQUEST_LATENCY.labels( methodPOST, endpoint/extract_text ).observe(duration) return result except Exception as e: # 记录失败的请求 REQUEST_COUNT.labels( methodPOST, endpoint/extract_text, statuserror ).inc() ERROR_COUNT.labels(error_typestr(type(e).__name__)).inc() # 记录请求耗时即使出错 duration time.time() - start_time REQUEST_LATENCY.labels( methodPOST, endpoint/extract_text ).observe(duration) raise e # 在应用启动时启动监控线程 def start_monitoring(): 启动系统资源监控 monitor_thread threading.Thread(targetmonitor_system_resources, daemonTrue) monitor_thread.start() print(系统资源监控已启动) # 修改Gradio应用使用带监控的处理函数 # 这里需要根据你的实际代码调整 # demo gr.Interface(fnextract_text_with_monitoring, ...)这段代码做了几件事定义了各种监控指标QPS、错误率、响应时间等添加了一个/metrics端点让Prometheus能获取数据修改了OCR处理函数在处理前后记录指标启动了一个后台线程定期收集系统资源信息3.3 添加独立的监控服务如果你不想修改原来的Gradio应用也可以创建一个独立的监控服务。新建一个monitor.py文件# monitor.py from prometheus_client import start_http_server, Counter, Histogram, Gauge import time import psutil import requests import threading # 定义指标同上 REQUEST_COUNT Counter(lightonocr_requests_total, Total requests, [status]) REQUEST_LATENCY Histogram(lightonocr_request_duration_seconds, Request latency) CPU_USAGE Gauge(lightonocr_cpu_percent, CPU usage) MEMORY_USAGE Gauge(lightonocr_memory_mb, Memory usage) # 模拟请求监控实际使用时需要连接到真实服务 def monitor_ocr_service(): 监控OCR服务的请求 while True: try: # 这里可以定期测试服务是否正常 # 或者从日志中解析请求信息 pass except Exception as e: print(f监控出错: {e}) time.sleep(10) def monitor_system(): 监控系统资源 while True: CPU_USAGE.set(psutil.cpu_percent()) memory psutil.virtual_memory() MEMORY_USAGE.set(memory.used / 1024 / 1024) time.sleep(5) if __name__ __main__: # 启动Prometheus指标服务器端口9091 start_http_server(9091) print(监控服务已启动指标地址: http://localhost:9091/metrics) # 启动监控线程 threading.Thread(targetmonitor_system, daemonTrue).start() threading.Thread(targetmonitor_ocr_service, daemonTrue).start() # 保持运行 while True: time.sleep(1)这种方式更灵活不影响原来的服务代码。启动监控服务python monitor.py4. 部署Prometheus收集指标现在我们的OCR服务已经能提供监控数据了接下来需要部署Prometheus来收集这些数据。4.1 安装Prometheus在服务器上安装Prometheus# 下载Prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz # 解压 tar xvfz prometheus-2.45.0.linux-amd64.tar.gz cd prometheus-2.45.0.linux-amd64 # 创建配置文件目录 sudo mkdir -p /etc/prometheus sudo mkdir -p /var/lib/prometheus # 复制配置文件 sudo cp prometheus.yml /etc/prometheus/ sudo cp promtool /usr/local/bin/ sudo cp prometheus /usr/local/bin/4.2 配置Prometheus编辑Prometheus的配置文件/etc/prometheus/prometheus.ymlglobal: scrape_interval: 15s # 每15秒采集一次数据 evaluation_interval: 15s # 每15秒评估一次规则 # 告警规则配置可选 rule_files: # - first_rules.yml # - second_rules.yml # 采集目标配置 scrape_configs: # Prometheus自身监控 - job_name: prometheus static_configs: - targets: [localhost:9090] # LightOnOCR服务监控 - job_name: lightonocr static_configs: - targets: [localhost:9091] # 监控服务地址 labels: service: ocr instance: ocr-01 # 系统监控通过node_exporter - job_name: node static_configs: - targets: [localhost:9100]这个配置告诉Prometheus每15秒采集一次数据监控三个目标Prometheus自己、OCR监控服务、系统指标给OCR服务打上标签方便在Grafana中筛选4.3 安装node_exporter可选如果你想监控系统层面的指标CPU、内存、磁盘、网络等可以安装node_exporter# 下载node_exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz # 解压 tar xvfz node_exporter-1.6.0.linux-amd64.tar.gz cd node_exporter-1.6.0.linux-amd64 # 启动node_exporter ./node_exporter node_exporter默认在9100端口提供系统指标。4.4 启动Prometheus创建systemd服务文件让Prometheus开机自启sudo nano /etc/systemd/system/prometheus.service添加以下内容[Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file /etc/prometheus/prometheus.yml \ --storage.tsdb.path /var/lib/prometheus/ \ --web.console.templates/etc/prometheus/consoles \ --web.console.libraries/etc/prometheus/console_libraries [Install] WantedBymulti-user.target创建prometheus用户并启动服务# 创建用户 sudo useradd --no-create-home --shell /bin/false prometheus # 设置目录权限 sudo chown -R prometheus:prometheus /etc/prometheus sudo chown -R prometheus:prometheus /var/lib/prometheus # 启动服务 sudo systemctl daemon-reload sudo systemctl start prometheus sudo systemctl enable prometheus # 检查状态 sudo systemctl status prometheus现在Prometheus应该运行在9090端口可以通过http://服务器IP:9090访问。5. 使用Grafana可视化监控数据Prometheus收集了数据但它的界面比较简陋。我们需要Grafana来创建漂亮的监控仪表盘。5.1 安装Grafana# 添加Grafana仓库 sudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - # 安装Grafana sudo apt-get update sudo apt-get install grafana # 启动服务 sudo systemctl start grafana-server sudo systemctl enable grafana-server # 检查状态 sudo systemctl status grafana-serverGrafana默认运行在3000端口访问http://服务器IP:3000初始用户名和密码都是admin。5.2 配置数据源登录Grafana后首先添加Prometheus作为数据源点击左侧菜单的Configuration齿轮图标选择Data Sources点击Add data source选择Prometheus在URL处填写http://localhost:9090点击Save Test应该显示Data source is working5.3 创建OCR监控仪表盘现在我们来创建监控LightOnOCR服务的仪表盘。点击左侧号选择Dashboard然后Add new panel。面板1QPS每秒请求数这个面板显示OCR服务的请求频率。配置步骤选择数据源Prometheus输入查询语句rate(lightonocr_requests_total[5m])可视化类型选择Graph图表标题设置为OCR服务QPS单位设置为req/s请求/秒这个查询语句的意思是计算最近5分钟内每秒的平均请求数。面板2错误率显示服务错误率这是最重要的监控指标之一。配置步骤输入查询语句sum(rate(lightonocr_errors_total[5m])) / sum(rate(lightonocr_requests_total[5m])) * 100可视化类型选择Stat统计值标题设置为错误率单位设置为percent百分比设置阈值绿色0-1%、黄色1-5%、红色5%这个公式计算错误请求占总请求的百分比。面板3响应时间分布显示请求处理时间的分布情况帮你了解服务性能。配置步骤输入查询语句lightonocr_request_duration_seconds_bucket可视化类型选择Heatmap热力图标题设置为响应时间分布单位设置为seconds秒热力图能直观显示不同响应时间的请求数量分布。面板4CPU和内存使用监控系统资源使用情况。配置步骤输入查询语句CPUlightonocr_cpu_percent输入查询语句内存lightonocr_memory_mb可视化类型选择Gauge仪表盘或Graph图表标题设置为系统资源使用面板5请求状态统计显示成功和失败请求的数量。配置步骤输入查询语句lightonocr_requests_total可视化类型选择Pie chart饼图标题设置为请求状态分布按status标签分组5.4 完整的仪表盘配置如果你不想一个个面板创建也可以直接导入完整的仪表盘配置。点击左侧号选择Import然后输入仪表盘ID1860这是一个Node Exporter的通用仪表盘或者使用下面的JSON配置{ dashboard: { title: LightOnOCR服务监控, panels: [ { title: QPS, targets: [{ expr: rate(lightonocr_requests_total[5m]), legendFormat: {{status}} }], type: graph }, { title: 错误率, targets: [{ expr: sum(rate(lightonocr_errors_total[5m])) / sum(rate(lightonocr_requests_total[5m])) * 100 }], type: stat, fieldConfig: { defaults: { thresholds: { steps: [ {color: green, value: null}, {color: red, value: 5} ] } } } } ] } }5.5 设置告警规则监控不仅要看还要能告警。当指标异常时Grafana可以发送通知。设置错误率告警在错误率面板点击标题选择Edit切换到Alert标签页点击Create Alert设置条件WHEN last() OF query(A, 5m, now) IS ABOVE 5意思是当最近5分钟的错误率超过5%时触发告警设置通知渠道需要先配置点击Save常见的告警规则错误率 5%服务可能有问题QPS突降 50%服务可能挂了响应时间 5秒服务变慢CPU使用率 80%可能需要扩容内存使用率 90%可能内存泄漏6. 实际监控效果展示部署完监控系统后你能看到什么让我给你展示几个典型的监控场景。场景1正常服务状态当服务正常运行时你的仪表盘应该是这样的QPS图表呈现平稳的曲线根据业务时间有规律波动比如白天高、晚上低错误率保持在1%以下显示为绿色响应时间大部分请求在1秒内完成分布集中系统资源CPU和内存使用率在合理范围内场景2服务出现异常当服务出现问题时监控系统能立即发现错误率飙升从绿色变成红色超过阈值QPS下降因为部分请求失败总请求数减少响应时间变长热力图显示更多请求落在高延迟区域你收到告警邮件、钉钉、企业微信等渠道收到通知场景3性能瓶颈分析通过监控数据你可以分析服务瓶颈如果QPS上不去但CPU使用率很低可能是代码逻辑问题如果响应时间随QPS增加而线性增长可能需要优化算法如果内存使用率持续上升可能有内存泄漏如果错误集中在特定时间段可能是依赖服务问题7. 监控系统维护与优化部署监控系统只是第一步日常维护同样重要。7.1 数据保留策略Prometheus默认保存15天的数据。如果你需要更长的保留时间可以修改配置# 在prometheus.yml中添加 storage: tsdb: retention: 90d # 保留90天但要注意数据保留时间越长需要的磁盘空间越大。一般建议原始数据保留30天汇总数据按小时/天聚合保留1年7.2 监控系统本身的监控监控系统本身也需要被监控Prometheus状态监控prometheus_开头的指标Grafana状态Grafana有内置的监控端点系统资源确保监控服务器有足够资源7.3 性能优化建议如果监控数据量很大可以考虑这些优化采样频率调整非关键指标可以降低采集频率指标聚合相似指标合并减少指标数量长期存储使用Thanos或Cortex做长期存储和集群化数据归档旧数据可以归档到对象存储7.4 安全考虑监控系统包含敏感数据需要注意安全访问控制Grafana设置强密码限制访问IP网络隔离监控系统放在内网不对外暴露数据加密Prometheus和Grafana之间使用HTTPS定期备份备份Grafana的仪表盘配置8. 总结通过今天的教程我们为LightOnOCR-2-1B服务搭建了一套完整的监控系统。让我简单回顾一下关键步骤服务端改造在OCR服务中添加Prometheus客户端暴露监控指标数据收集部署Prometheus定期采集各个服务的指标数据可视化展示使用Grafana创建直观的监控仪表盘告警配置设置阈值异常时及时通知这套监控系统带来的价值是实实在在的问题早发现错误率刚有苗头就能发现不用等用户投诉性能可量化清楚地知道服务能承受多大压力什么时候需要扩容排查效率高出现问题能快速定位是代码问题、资源问题还是网络问题决策有依据基于数据做技术决策而不是凭感觉监控不是“有了就行”而是要“用好”。我建议你定期查看监控数据了解服务的正常状态设置合理的告警阈值既不过于敏感也不漏报根据监控数据优化服务比如调整资源配置、优化代码逻辑建立监控文化让团队每个人都关注服务质量最后记住监控的目的是为了保障服务稳定而不是增加负担。从简单的几个核心指标开始随着业务发展逐步完善。好的监控系统应该是“平时安静有事说话”默默守护你的服务稳定运行。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。