2026 本地 AI 运维助手综合实战：把系统监控、API 和 MySQL 性能周报一键串起来（Ollama + Qwen3.5）-育师

一、这篇是在前几篇监控 & 性能文章基础上的「整合版」

到目前为止，你这个系列已经有了几篇很实用的文章：

技术监控周报：CPU、内存、错误率整体情况；
API 性能分析周报：接口调用量、P95/P99 延迟、错误率分布；
MySQL 性能分析周报：CPU、慢查询、锁等待等核心指标。

这些文章各自都是一个“点”的实战 Demo，但真正写周报 / 做汇报时，领导或者团队其实更想看到的是：

一份统一视角的性能周报：
系统资源层（CPU/内存/磁盘）
接口/API 层（流量 & 延迟 & 错误）
数据库层（慢查询 & 锁竞争 & 连接数）
三者之间的关联和归因：

比如：

「周五晚 8 点 QPS 上了高峰，同时 CPU/慢查询/错误率都有抬头」
「本周性能问题的根因主要集中在订单写入链路的几条接口 + 对应的几条 SQL」

这篇文章要做的，就是把你前面已经写好的那几块“单点分析能力”，用本地 Qwen3.5 串起来，自动生成一份统一的‘系统 + API + DB’综合性能周报段落。

二、整体架构：三个分析器 + 一个总控大脑

可以把这个综合性能周报助手拆成四部分：

系统监控分析器
- 输入：一周的系统指标（CPU、内存、磁盘、错误率、告警）
- 输出：一段「本周系统监控核心分析」
API 性能分析器（你上一篇已经实现）
- 输入：一周 API 调用数据（调用量、P95、错误率）
- 输出：一段「本周 API 性能核心分析」
MySQL 性能分析器（你刚刚这篇已经实现）
- 输入：一周 MySQL 性能数据（慢查询、锁、连接数、CPU 等）
- 输出：一段「本周数据库性能核心分析」
综合分析大脑（本篇的重点）
- 输入：上面三段「Markdown 文本 + 关键统计摘要」
- 输出：一段统一视角的「端到端性能综合分析」，包括：
  - 整体健康度评价
  - 关键风险点归因（系统 / API / DB）
  - 下周性能工作重点

简单理解为：

前三篇是“分科报告”，这篇是“总检报告”。

三、环境前提：基于你现有的三套分析脚本

假设你已经有了三份脚本（名字可以按你自己前面的命名来，下面以示例为主）：

monitor_analyzer.py
- 暴露函数：generate_monitor_report() -> str
- 返回：系统监控分析的 Markdown 字符串
api_performance_analyzer.py
- 暴露函数：generate_api_report() -> str
- 返回：API 性能分析的 Markdown 字符串
mysql_performance_analyzer.py
- 暴露函数：generate_mysql_report() -> str
- 返回：MySQL 性能分析的 Markdown 字符串

并且你已经在本机配置好：

ollama pull qwen3.5:7b-instruct-q4_0 python -m venv perf_env # Windows: # perf_env\Scripts\activate # macOS / Linux: source perf_env/bin/activate pip install --upgrade pip pip install "ollama>=0.1.1"

四、写一个「综合性能分析器」：把三块内容喂给 Qwen3.5

在你的项目根目录中新建一个脚本，比如：overall_performance_summarizer.py：

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ 整体性能周报综合分析器 功能： 1. 调用已有的系统监控 / API / MySQL 三个分析器，获取三段 Markdown 文本 2. 将三段分析结果作为上下文，交给本地 Qwen3.5 做更高层次的综合归纳 3. 输出一段统一视角的「本周整体性能与稳定性分析」，可直接插入周报 """ from pathlib import Path import datetime import ollama # 按你自己前几篇脚本的实际名称来 import from monitor_analyzer import generate_monitor_report from api_performance_analyzer import generate_api_report from mysql_performance_analyzer import generate_mysql_report MODEL_NAME = "qwen3.5:7b-instruct-q4_0" OUTPUT_DIR = Path("overall_reports") def build_overall_prompt( monitor_md: str, api_md: str, db_md: str, start_date: str, end_date: str, ) -> str: """ 构造给 Qwen3.5 的综合分析提示词 """ prompt = f""" 你现在是一名资深技术负责人（Tech Lead），需要根据本周的系统监控、API 性能和数据库性能三份分析报告，写一段可以直接放进技术周报开头部分的【本周整体性能与稳定性分析】。 时间范围：{start_date} ~ {end_date} 以下是三份子报告的内容（Markdown 形式）： 【系统监控分析】： -------------------- {monitor_md} -------------------- 【API 性能分析】： -------------------- {api_md} -------------------- 【数据库性能分析】： -------------------- {db_md} -------------------- 请基于以上三份报告，输出一段更高层次的综合分析，要求： 1. 输出格式为 Markdown，结构建议如下（可以略微调整）： ### 本周整体性能与稳定性分析 1. **整体健康度评价** - 用 2～3 句话给出本周整体系统的健康度结论（例如：整体稳定 / 有轻微波动 / 存在明显风险），并简单说明依据（从系统、API、数据库三个层面各引用一两点关键结论）。 2. **主要风险点与可能根因** - 综合三份报告，归纳本周最值得关注的 2～4 个性能 / 稳定性风险点； - 对每个风险点，说明它发生在哪一层（系统 / API / DB / 组合），对业务有什么潜在影响（例如：接口超时、下单失败、峰值时段体验变差等），以及可能的根因方向（例如：某些高峰时段 CPU + 某几条慢 SQL + 某几条慢接口同时抬头）。 3. **本周改进进展与效果评估**（如报告中有提及） - 如果子报告中提到本周已有的优化措施（例如压测、限流、索引优化），请简要评价其效果； - 如未提及，可写“本周暂无较大规模的性能优化动作，以常规巡检为主”。 4. **下周性能工作重点建议** - 根据上述风险点和分析结果，给出 3～6 条下周在性能与稳定性方面的工作重点建议； - 建议尽量具体到“接口 / 场景 / 指标”，例如“针对 /api/order/create 做一次慢查询专项优化”“在晚间 20~22 点压测网关和数据库链路”等。 2. 语言要求： - 使用简体中文，语气偏「技术负责人对内团队汇报」风格，专业但不过度堆砌术语； - 注意区分事实（已发生的数据与现象）和推断（可能的原因），推断部分请用“可能 / 推测 / 需要进一步验证”等词语表述。 3. 不要重复完整粘贴子报告内容，重点是「提炼 + 归纳 + 关联」。 4. 控制整体长度在 300～500 字之间，保证条理清晰、信息密度高。 请开始输出综合分析内容： """ return prompt.strip() def call_qwen(prompt: str) -> str: """ 调用本地 Qwen3.5 生成综合分析文本 """ res = ollama.chat( model=MODEL_NAME, messages=[{"role": "user", "content": prompt}], temperature=0.3, ) return res["message"]["content"].strip() def generate_overall_report() -> str: """ 对外暴露的主函数： - 先拿到三段子报告 - 再生成一段整体性能与稳定性分析 """ # 按“上周一 ~ 上周日”为统计区间（和前面几篇保持一致） today = datetime.date.today() start_date = today - datetime.timedelta(days=today.weekday() + 7) end_date = start_date + datetime.timedelta(days=6) print(">>> 1. 生成系统监控分析...") monitor_md = generate_monitor_report() print("\n>>> 2. 生成 API 性能分析...") api_md = generate_api_report() print("\n>>> 3. 生成数据库性能分析...") db_md = generate_mysql_report() print("\n>>> 4. 生成整体性能与稳定性综合分析...") prompt = build_overall_prompt( monitor_md=monitor_md, api_md=api_md, db_md=db_md, start_date=str(start_date), end_date=str(end_date), ) overall_md = call_qwen(prompt) OUTPUT_DIR.mkdir(exist_ok=True) out_path = OUTPUT_DIR / f"overall_performance_{start_date}_to_{end_date}.md" out_path.write_text(overall_md, encoding="utf-8-sig") print(f"\n综合性能分析报告已保存到：{out_path}") return overall_md if __name__ == "__main__": summary = generate_overall_report() print("\n===== 综合性能分析内容预览 =====\n") print(summary)

这个脚本的核心点在于：

不需要你重新写任何监控逻辑；
直接复用之前已经写过的三个分析函数；
再让 Qwen3.5 对“三段现有分析结果”做一次更高层次的归纳。

五、把这段「综合分析」当成周报的“开头部分”

你现在已经有了：

monitor_md：系统监控分析
api_md：API 性能分析
db_md：MySQL 性能分析
overall_md：整合这三者的「整体性能与稳定性分析」

你可以把整个技术周报的结构调整为：

# 本周技术工作周报（{start_date} ~ {end_date}） ## 一、本周整体性能与稳定性分析 {overall_md} ## 二、本周系统监控核心分析 {monitor_md} ## 三、本周 API 性能核心分析 {api_md} ## 四、本周数据库性能核心分析 {db_md} ## 五、本周具体工作内容 {work_md} <!-- 原来你写的需求/开发/联调等内容 --> ## 六、本周问题与风险 {risk_md} ## 七、下周工作计划 {plan_md}

从领导或团队视角看，这样有几个优点：

先给结论，再看细节：一上来就看到“整体健康度 + 风险点 + 下周重点”，非常符合管理者的阅读习惯；
中间三块是“证据”：系统、API、DB 三层分析各自独立、互相印证；
后面的工作内容和计划与上面的风险和分析对齐：周报显得非常有逻辑、有闭环。

六、让这整套东西真正“自动化”起来

目前为止，你已经：

有三份数据分析器（系统 / API / DB）；
有一个综合性能分析器；
再加上你早前的「日报/周报自动生成」脚本。

接下来，你只需要加一层“调度”：

定时任务（crontab / Windows 任务计划）
- 每周一早上 8:00，自动执行：
  - 拉取上周监控数据（可由其他脚本提前完成）
  - 运行 4 个分析脚本：
    - monitor_analyzer.py
    - api_performance_analyzer.py
    - mysql_performance_analyzer.py
    - overall_performance_summarizer.py
  - 运行“工作内容周报生成脚本”（基于 daily logs）
输出统一存档
- 把所有生成的 Markdown 文件统一保存到：
  weekly_reports/
  2026-03-02_to_2026-03-08/
  overall_performance.md
  monitor_analysis.md
  api_performance.md
  mysql_performance.md
  work_summary.md
  final_weekly_report.md
人工只做最后 5 分钟
- 打开final_weekly_report.md
- 检查结论是否准确
- 如有偏差（例如 AI 对某些风险推断过头），简单修正两三句话
- 复制到公司内部周报系统/飞书文档/邮箱即可。