监控、日志与告警

原始素材：7-基础设施与运维/7.12-monitoring-logging.md

0. 引言：系统上线只是开始

很多新手认为："代码部署上线，任务就完成了。"

大错特错！

系统上线只是运维工作的起点 。就像买了一辆新车，后续的保养、维修、加油才是常态。

运维的目标有三个：

1. 稳定性 (Stability) ：系统不宕机，服务一直可用
2. 性能 (Performance) ：响应快速，用户体验好
3. 安全 (Security) ：数据不泄露，防止被攻击

1. 监控体系 (Monitoring)

监控是运维的"眼睛"。没有监控的系统就像盲人开车，出了问题都不知道。

1.1 监控的三个层次

实时监控面板 — 运维的"眼睛"，让系统状态一目了然。

监控分类：基础设施 | 应用监控 | 业务监控

以「基础设施」为例：

状态说明：🟢 正常（Normal）· 🟡 警告（Warning）· 🔴 严重（Critical）

基础设施监控 ：关注服务器硬件资源

• CPU 使用率
• 内存使用率
• 磁盘空间和 I/O
• 网络带宽

应用监控 ：关注软件运行状态

• QPS（每秒请求数）
• 响应时间（延迟）
• 错误率
• 依赖服务调用情况

业务监控 ：关注业务健康度

• DAU/MAU（日活/月活）
• 订单量
• 支付成功率
• 用户留存率

1.2 监控工具栈

关键点 ：监控要分层，从基础设施到业务全方位覆盖，避免"盲区"。

2. 告警系统 (Alerting)

监控发现问题后，需要及时通知运维人员，这就是告警 。

2.1 告警流程

从发现异常到通知运维的自动化流程：

告警类型：CPU 过载 | 响应延迟 | 错误率飙升 | 磁盘空间不足

告警处理流水线：

告警级别说明：

2.2 告警级别设计

合理的告警分级能避免"告警疲劳"：

2.3 告警收敛与降噪

痛点 ：一个小问题可能触发成百上千条告警，导致值班人员麻木。

解决方案 ：

1. 告警分组 ：相似告警合并（如同一台服务器的多个问题合并为一条）
2. 告警抑制 ：如果父问题已触发，子问题不重复告警
3. 静默规则 ：维护期间自动暂停告警
4. 频率限制 ：同一告警短时间内不重复通知

关键点 ：告警要"少而精"，每条都要值得处理。

3. 日志管理 (Logging)

日志是排查问题的"黑匣子"。

3.1 日志分级

console.debug('详细调试信息') // 开发时使用
console.info('一般信息') // 正常流程记录
console.warn('警告信息') // 潜在问题
console.error('错误信息') // 需要关注的错误

3.2 结构化日志

传统日志（不好）：

2024-01-15 10:23:45 ERROR User john failed to login, attempts=3, ip=192.168.1.100

结构化日志（推荐）：

{
  "timestamp": "2024-01-15T10:23:45Z",
  "level": "ERROR",
  "message": "User login failed",
  "user": "john",
  "attempts": 3,
  "ip": "192.168.1.100",
  "service": "auth-service"
}

3.3 ELK 日志栈

ELK = Elasticsearch + Logstash + Kibana

• Logstash ：日志采集和过滤
• Elasticsearch ：日志存储和搜索
• Kibana ：日志可视化查询

最佳实践 ：

• ✅ 敏感信息（密码、token）不要记入日志
• ✅ 关键操作（登录、支付、权限变更）必须记录
• ✅ 日志要包含上下文（用户 ID、请求 ID、时间戳）
• ✅ 定期清理过期日志，避免磁盘爆满

4. 链路追踪 (Tracing)

在微服务架构中，一个请求可能经过十几个服务，如何追踪它的完整路径？

Trace ID 和 Span ID

• Trace ID ：整个请求链路的唯一标识（像快递单号）
• Span ID ：单个服务调用的标识（像每个中转站）

一个请求在微服务间流转的完整路径：

视图切换：正常流程 | 性能瓶颈 | 错误追踪

链路瀑布图（0ms ~ 450ms）：

图例：🟢 正常（≤200ms）· 🟡 慢调用（>200ms）· 🔴 错误

💡 每个 Span 都有唯一的 Span ID，通过 Trace ID 关联。时间条越长，表示该服务耗时越长。

4.2 OpenTelemetry 标准

OpenTelemetry (OTel) 是链路追踪的行业标准 ，提供统一的 API 和 SDK。

// 示例：使用 OpenTelemetry 记录 Span
import { trace } from '@opentelemetry/api'

const tracer = trace.getTracer('my-service')

async function processOrder(orderId) {
  // 创建一个 Span
  const span = tracer.startSpan('processOrder')

  try {
    // 设置属性
    span.setAttribute('order.id', orderId)

    // 业务逻辑...
    await validateOrder(orderId)
    await saveToDatabase(orderId)

    span.setStatus({ code: SpanStatusCode.OK })
  } catch (error) {
    span.recordException(error)
    span.setStatus({ code: SpanStatusCode.ERROR, message: error.message })
  } finally {
    span.end() // 结束 Span
  }
}

关键点 ：链路追踪能快速定位性能瓶颈和故障点，是微服务必备工具。

5. 故障排查流程

线上故障不可避免，关键是快速响应、快速恢复 。

5.1 故障处理流程

专业团队如何处理线上故障：

故障响应 6 步流程：

以「1. 故障发现」为例：

• 关键动作：监控检测到订单服务错误率从 0.1% 飙升到 8.5% → Alertmanager 触发 P1 告警 → 值班人员收到钉钉和短信通知
• 常用工具：Prometheus Grafana Alertmanager

故障响应最佳实践：

5.2 常用排查工具

Arthas 示例 （阿里开源的 Java 诊断工具）：

$ top -H -p 12345

$ trace com.example.OrderService createOrder

$ getstatic com.example.Config MAX_CONNECTIONS

$ mc /tmp/Test.java
$ redefine /tmp/Test.class

5.3 故障复盘 (Post-mortem)

复盘不是追责会！

复盘的目的是：

1. 梳理故障时间线
2. 找出根本原因 (Root Cause Analysis)
3. 总结经验教训
4. 制定改进措施

5 Why 分析法 ：

问"为什么"至少 5 次，找到根本原因：

• 为什么服务宕机？
  • 因为内存溢出
• 为什么内存溢出？
  • 因为缓存数据过多
• 为什么缓存数据过多？
  • 因为没有设置过期时间
• 为什么没有设置过期时间？
  • 因为开发时遗漏了
• 根本原因 ：缺少代码审查和测试用例

关键点 ：建立 blameless 文化，关注流程改进而非个人责任。

6. 性能优化

6.1 性能瓶颈分析

从上到下的优化思路 ：

用户感知
  ↓
前端优化（减少请求、CDN、懒加载）
  ↓
网络优化（HTTP/2、压缩、长连接）
  ↓
后端优化（缓存、异步、批处理）
  ↓
数据库优化（索引、查询优化、分库分表）
  ↓
系统优化（内核参数、JVM 调优）

6.2 数据库优化

索引优化 ：

-- 查询慢（无索引）
SELECT * FROM orders WHERE user_id = 12345;

-- 创建索引后快 100 倍
CREATE INDEX idx_user_id ON orders(user_id);

查询优化 ：

-- ❌ 避免 SELECT *
SELECT * FROM users WHERE id = 123;

-- ✅ 只查需要的字段
SELECT id, name, email FROM users WHERE id = 123;

-- ❌ 避免 IN 子句太多
SELECT * FROM orders WHERE user_id IN (1, 2, 3, ..., 10000);

-- ✅ 使用 JOIN 或批量查询
SELECT * FROM orders o JOIN user_ids u ON o.user_id = u.id;

6.3 缓存优化

多级缓存架构 ：

浏览器缓存 (CDN)
  ↓
本地缓存 (内存/Guava)
  ↓
分布式缓存 (Redis/Memcached)
  ↓
数据库 (MySQL/PostgreSQL)

缓存更新策略 ：

关键点 ：缓存不是银弹，要考虑一致性、雪崩、穿透等问题（参考《系统缓存设计》章节）。

7. 容量规划

7.1 容量评估

估算系统需要多少台服务器才能满足需求：

各厂商参考价格（4核8G）：

容量规划四原则：

核心计算公式：

7.2 压力测试

工具选择 ：

wrk 示例 ：

$ brew install wrk  # macOS
$ apt install wrk   # Ubuntu

$ wrk -t10 -c100 -d30s http://example.com/api/users

7.3 弹性扩缩容

云原生时代的自动扩缩容 ：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

当 CPU 使用率超过 70% 时，自动扩容 Pod（最多 10 个）

关键点 ：结合业务预测（如双 11）提前扩容，避免来不及。

8. 安全运维

8.1 访问控制

最小权限原则 ：

• 开发人员只能访问开发环境
• 运维人员只能访问生产环境，且需要审批
• 数据库敏感操作需要二次确认

堡垒机 (Jump Server) ：

所有运维操作通过堡垒机进行，记录完整操作日志。

8.2 数据备份

3-2-1 备份原则 ：

• 3 份数据副本（1 份原始 + 2 份备份）
• 2 种不同存储介质（本地磁盘 + 云存储）
• 1 份异地备份（防止单点灾难）

备份策略 ：

RTO (Recovery Time Objective) ：恢复时间目标（服务最多中断多久） RPO (Recovery Point Objective) ：恢复点目标（最多丢失多少数据）

8.3 漏洞扫描

定期扫描 ：

• 代码扫描 ：SonarQube、ESLint（发现潜在漏洞）
• 依赖扫描 ：npm audit、Snyk（检测第三方库漏洞）
• 容器扫描 ：Trivy、Clair（检测镜像漏洞）

$ npm audit

found 3 vulnerabilities (1 moderate, 2 high)

Package         Severity  Vulnerable versions
lodash          high      <4.17.21
express         moderate  4.0.0 - 4.18.2

$ npm audit fix

9. 自动化运维 (DevOps)

9.1 CI/CD 流水线

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - npm install
    - npm test
  tags:
    - docker

build:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker push registry.example.com/myapp:$CI_COMMIT_SHA
  only:
    - main

deploy:
  stage: deploy
  script:
    - kubectl set image deployment/myapp myapp=registry.example.com/myapp:$CI_COMMIT_SHA
  environment:
    name: production
  when: manual # 手动触发部署

9.2 基础设施即代码 (IaC)

Terraform 示例 （管理云资源）：

hcl

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "WebServer"
    Env  = "production"
  }
}

resource "aws_security_group" "web" {
  name = "web-sg"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

优势 ：

• ✅ 版本控制：所有配置在 Git 中
• ✅ 可重复：环境一致性
• ✅ 可审计：变更历史清晰
• ✅ 可回滚：快速恢复到之前版本

9.3 GitOps 实践

GitOps = Git + IaC + Automation

核心理念：Git 仓库是基础设施的唯一真实来源

工作流程：

1. 修改配置文件（push 到 Git）
   ↓
2. Git 仓库变更触发 CI/CD
   ↓
3. 自动执行terraform apply/kubectl apply
   ↓
4. 基础设施自动更新
   ↓
5. 监控对比实际状态与期望状态

工具 ：ArgoCD、Flux（Kubernetes 部署）

10. 总结与最佳实践

运维是一个庞大的体系，但核心可以概括为：

10.1 运维成熟度模型

10.2 运维工程师的一天

09:00 - 查看夜间告警，确认系统状态
10:00 - 处理用户反馈的问题
11:00 - 参加研发周会，评估新方案运维风险
14:00 - 优化慢查询，提升性能
15:00 - 代码审查（Code Review）
16:00 - 编写部署文档，更新监控规则
17:00 - 故障演练（Chaos Engineering）
18:00 - 值班交接

10.3 学习路线

入门阶段 （1-3 个月）：

• 学会 Linux 常用命令
• 了解监控系统（Prometheus + Grafana）
• 掌握日志查询（ELK）

进阶阶段 （3-6 个月）：

• 深入理解容器技术（Docker + K8s）
• 掌握一门诊断工具（Arthas、tcpdump）
• 实践 CI/CD 流水线

高级阶段 （6-12 个月）：

• 性能调优（数据库、JVM、网络）
• 容量规划与成本优化
• 故障复盘与流程改进

专家阶段 （1 年以上）：

• 架构设计（高可用、容灾）
• 混沌工程（主动注入故障）
• AIOps（智能运维）

11. 名词速查表 (Glossary)

12. 延伸阅读

• 系统缓存设计 - 缓存原理、模式与最佳实践
• 消息队列设计 - 削峰填谷、异步解耦
• 鉴权原理与实战 - 认证授权、安全加固
• 后端进化史 - 从单体到微服务到 Serverless
• 部署与上线 - 从开发到生产的最后一公里