日志分析

适用场景

1 生产环境服务突发500错误，需快速定位是代码异常、依赖超时还是资源瓶颈

2 Kubernetes集群Pod频繁重启，需从容器日志中识别OOM、探针失败或镜像拉取错误

3 数据库连接池耗尽导致应用响应缓慢，需关联分析应用日志与数据库慢查询日志

4 安全审计场景下，从Nginx访问日志中识别异常IP、暴力破解或注入攻击特征

核心Prompt（安装配置用）

你是企业级日志分析专家，精通分布式系统故障排查。你的任务是对输入的日志内容进行深度分析，输出结构化的根因定位与修复建议。

分析要求：
1. 错误分类：将日志中的异常归入以下类别之一——代码异常、配置错误、资源瓶颈、网络问题、依赖服务故障、安全事件、数据问题。
2. 根因定位：结合日志时间线、错误堆栈、关键字（如Timeout、OOM、Connection refused、500、Exception）推断最可能的根因，给出置信度（高/中/低）。
3. 影响评估：说明该错误对业务的影响范围（单请求、单节点、全集群）。
4. 修复建议：给出至少两条可立即执行的修复动作，按优先级排序，包含具体命令或配置修改示例。
5. 预防措施：给出一条长期改进建议，如增加监控指标、调整超时参数或补充日志埋点。

输出格式：
【错误分类】
【根因定位】置信度：高/中/低
【影响评估】
【修复建议】1. ... 2. ...
【预防措施】

约束条件：
- 仅基于提供的日志内容分析，不臆造未出现的错误。
- 若日志信息不足，明确说明需要补充哪些日志字段或上下文。
- 修复命令需注明适用环境（Linux/K8s/中间件）。
- 避免输出与日志无关的通用建议。

所需工具 / API对接

需对接：ELK/OpenSearch日志检索API、Prometheus指标API、Kubernetes API（获取Pod事件与状态）、企业IM Webhook（钉钉/飞书/企微）用于告警推送、工单系统API（Jira/禅道）用于自动创建修复任务。

安装部署步骤

11. 环境准备：确认服务器已安装Docker 20.10+与Docker Compose，分配至少4核8G资源，开放9200/5601端口。

22. 安装依赖：执行 docker pull elasticsearch:8.11.0 与 docker pull kibana:8.11.0，启动ELK基础服务并验证 curl http://localhost:9200 返回集群信息。

33. 配置参数：创建 agent-config.yaml，填入日志索引模式（如 filebeat-*）、分析时间窗口（默认15分钟）、告警阈值（错误数>10触发）。

44. 导入Prompt：将核心Prompt写入 config/prompts/log_analysis.txt，并在Agent配置中引用该文件路径，确保编码为UTF-8。

55. 连接工具API：在 config/tools.yaml 中配置Prometheus地址、K8s kubeconfig路径、IM Webhook URL，执行 python tool_check.py 验证各接口连通性。

66. 测试验证：导入 sample_logs/error_500.log，运行 python run_agent.py --test，检查输出是否包含错误分类、根因与修复建议，确认无误后进入下一步。

77. 上线部署：执行 docker-compose up -d agent，查看 docker logs -f agent 确认服务正常，配置定时任务每5分钟拉取最新日志分析一次。

88. 监控告警：在Kibana中创建Agent分析结果看板，设置当置信度为高且未自动修复时，通过Webhook推送至运维群。

配置参数

参数名	说明	默认值
`log_index`	日志索引模式，指定从哪个索引拉取日志	filebeat-*
`time_window`	分析时间窗口，单位分钟	15
`error_threshold`	触发告警的错误条数阈值	10
`confidence_level`	最低输出置信度，低于此值仅记录不告警	中
`notify_channel`	告警推送渠道，支持dingtalk/feishu/wecom	dingtalk

效果示例

输入：2024-05-20 10:23:45 ERROR [order-service] java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms. 同时段数据库日志显示 max_connections=200 已满。
输出：【错误分类】资源瓶颈
【根因定位】数据库连接池耗尽，置信度：高
【影响评估】order-service全部实例请求超时，影响下单业务
【修复建议】1. 临时扩容：ALTER SYSTEM SET max_connections=500; 2. 检查连接泄漏：排查未关闭的Connection，增加HikariCP leakDetectionThreshold=60000
【预防措施】增加连接池使用率监控，超过80%告警。

常见问题

Q：日志量太大，Agent分析超时怎么办？
A：调整time_window参数缩小分析窗口，或在ELK侧先做聚合过滤，仅将ERROR/WARN级别日志送入Agent。
Q：Agent给出的根因不准确如何优化？
A：补充日志上下文（如堆栈完整信息、关联TraceID），并在Prompt中增加企业特有的错误码对照表。
Q：能否自动执行修复命令？
A：默认仅建议不执行。如需自动修复，需在配置中开启auto_fix并严格限定白名单命令，且首次上线建议人工确认。
Q：支持哪些日志格式？
A：支持JSON、纯文本、Syslog格式。非结构化日志建议先用Logstash做Grok解析。
Q：如何保证日志数据安全？
A：Agent部署在内网，日志不出企业边界；对接外部IM时仅推送分析摘要，不传原始日志。

企业落地建议

建议采用内网Docker Compose单机部署，初期覆盖1-2个核心服务，成本主要为服务器资源（约4核8G）和人力投入（1人日部署+持续调优）。注意事项：先以只读方式分析日志，不自动执行修复；Prompt需结合企业实际错误码迭代优化；建议与现有监控告警系统联动，避免重复告警。上线后每周复盘根因准确率，持续补充日志样本。需要我们帮你落地吗？可以试试免费AI诊断→