Docker部署SkyWalking与MySQL存储实践指南

1. 项目概述

SkyWalking作为一款开源的APM（应用性能监控）系统，在微服务架构中扮演着重要角色。而使用Docker部署SkyWalking配合MySQL作为存储后端，是一种兼顾便捷性和可靠性的方案。这种组合特别适合中小规模企业或团队快速搭建监控系统，既能利用Docker的标准化部署优势，又能发挥MySQL作为成熟关系型数据库的稳定性。

在实际生产环境中，我遇到过不少团队在监控系统选型时的困境：既希望有强大的分布式追踪能力，又不愿投入过多运维成本。这正是我推荐这种部署方式的原因——它平衡了功能与复杂度，让开发者能够快速获得一个功能完备的APM系统，同时保持架构的简洁性。

2. 环境准备与依赖检查

2.1 基础环境要求

在开始部署前，需要确保你的系统满足以下最低要求：

• Docker Engine版本不低于20.10.7
• Docker Compose版本不低于1.29.2
• 至少4GB可用内存（SkyWalking OAP服务本身需要约2GB）
• MySQL 5.7或更高版本（建议使用8.0以获得更好的性能）

提示：可以通过docker version和docker-compose version命令检查当前安装的版本。如果尚未安装Docker，可以参考官方文档进行安装，这里不再赘述。

2.2 MySQL存储规划

选择MySQL作为存储后端时，有几个关键参数需要特别注意：

• 字符集必须设置为utf8mb4，以支持完整的Unicode字符
• 事务隔离级别建议使用READ-COMMITTED
• 需要预先创建专用数据库用户并授予足够权限

我通常会为SkyWalking创建单独的MySQL实例，即使小规模部署也是如此。这是因为APM系统产生的数据量可能比你预期的要大得多，特别是当应用数量增多时。共享MySQL实例很容易导致性能问题。

3. Docker部署SkyWalking核心组件

3.1 编写docker-compose.yml

以下是经过生产验证的docker-compose.yml文件示例：

yaml复制version: '3.8'
services:
  oap:
    image: apache/skywalking-oap-server:9.2.0
    container_name: skywalking-oap
    restart: always
    ports:
      - "11800:11800"
      - "12800:12800"
    environment:
      SW_STORAGE: mysql
      SW_JDBC_URL: jdbc:mysql://mysql:3306/swtest?rewriteBatchedStatements=true
      SW_DATA_SOURCE_USER: skywalking
      SW_DATA_SOURCE_PASSWORD: yourpassword
      SW_JDBC_DRIVER: com.mysql.cj.jdbc.Driver
      JAVA_OPTS: "-Xms2g -Xmx2g"
    depends_on:
      - mysql
    networks:
      - skywalking

  ui:
    image: apache/skywalking-ui:9.2.0
    container_name: skywalking-ui
    restart: always
    ports:
      - "8080:8080"
    environment:
      SW_OAP_ADDRESS: oap:12800
    depends_on:
      - oap
    networks:
      - skywalking

  mysql:
    image: mysql:8.0
    container_name: skywalking-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: swtest
      MYSQL_USER: skywalking
      MYSQL_PASSWORD: yourpassword
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "3306:3306"
    command: 
      - --default-authentication-plugin=mysql_native_password
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
      - --max_connections=500
    networks:
      - skywalking

volumes:
  mysql_data:

networks:
  skywalking:
    driver: bridge

这个配置有几个关键点值得注意：

1. 为MySQL容器添加了关键参数，确保字符集和性能优化
2. 为OAP服务设置了合适的内存限制（2GB）
3. 使用了独立的Docker网络，确保组件间通信安全
4. 配置了容器自动重启策略，提高可用性

3.2 启动与验证服务

启动服务只需执行：

bash复制docker-compose up -d

启动后，可以通过以下命令检查服务状态：

bash复制docker-compose ps

正常情况下，你应该看到三个容器的状态都是"Up"。如果任何容器没有正常运行，可以使用docker logs <container_name>查看日志。

注意：首次启动时，OAP服务可能需要几分钟时间初始化数据库结构。这段时间内访问UI可能会看到错误，这是正常现象。

4. MySQL存储配置详解

4.1 数据库表结构分析

SkyWalking使用MySQL存储时，会创建约50张表，主要分为以下几类：

• 服务注册表（如：service、service_relation）
• 端点表（如：endpoint、endpoint_relation）
• 指标数据表（如：meter_*、metrics_*）
• 拓扑图表（如：topology_*）
• 告警相关表（如：alarm_record）

这些表的命名非常有规律，通常以数据类型和时间粒度组合命名。例如：metrics_sla_day表示按天存储的SLA指标数据。

4.2 性能优化建议

基于实际运维经验，我总结了以下MySQL优化建议：

1. 索引优化：

   • 为所有time_bucket列添加索引
   • 为常用查询条件的列添加复合索引

2. 参数调整：

   sql复制innodb_buffer_pool_size = 2G  # 建议设置为可用内存的50-70%
   innodb_log_file_size = 256M
   innodb_flush_log_at_trx_commit = 2  # 在可接受少量数据丢失风险的场景下
   

3. 定期维护：

   • 设置定期任务清理过期数据
   • 每周执行一次OPTIMIZE TABLE（在业务低峰期）

5. SkyWalking UI配置与使用

5.1 访问与基本配置

服务启动后，可以通过http://<your-server-ip>:8080访问SkyWalking UI。首次访问时，建议进行以下配置：

1. 在"设置"菜单中调整时区
2. 配置适当的监控时间范围（默认为最近30分钟）
3. 根据需要调整自动刷新间隔

5.2 关键功能解析

1. 拓扑图：

   • 展示服务间调用关系
   • 节点大小反映流量大小
   • 颜色反映健康状态（红/黄/绿）

2. 追踪：

   • 查看具体请求的调用链
   • 支持按条件筛选
   • 可查看每个Span的详细信息

3. 性能分析：

   • 展示服务/端点的响应时间
   • 支持百分位统计（P75/P90/P95等）
   • 可对比历史数据

6. 生产环境注意事项

6.1 数据保留策略

SkyWalking默认会保留以下数据：

• 指标数据：7天
• 追踪数据：30天
• 元数据：永久

可以通过修改OAP服务的环境变量调整这些设置：

yaml复制environment:
  SW_CORE_RECORD_DATA_TTL: 3  # 指标数据保留天数
  SW_CORE_METRICS_DATA_TTL: 7  # 指标数据保留天数
  SW_CORE_TRACE_TTL: 30  # 追踪数据保留天数

6.2 高可用方案

对于生产环境，建议考虑以下高可用措施：

1. MySQL高可用：

   • 配置主从复制
   • 考虑使用云数据库服务

2. OAP集群：

   yaml复制oap:
     image: apache/skywalking-oap-server:9.2.0
     deploy:
       replicas: 2
   

3. 负载均衡：

   • 为UI配置多个OAP后端
   • 使用Nginx做负载均衡

7. 常见问题排查

7.1 启动问题

问题1：OAP服务不断重启

• 检查MySQL连接配置是否正确
• 查看OAP日志中的错误信息
• 确认MySQL版本兼容性

问题2：UI无法连接OAP

• 检查SW_OAP_ADDRESS配置
• 确认网络连通性
• 验证OAP的12800端口是否正常监听

7.2 性能问题

问题1：MySQL负载过高

• 检查慢查询日志
• 优化索引
• 考虑增加MySQL资源

问题2：数据延迟

• 调整OAP的JAVA_OPTS增加内存
• 检查网络延迟
• 考虑减少监控粒度

8. 进阶配置与优化

8.1 告警配置

SkyWalking支持灵活的告警规则配置。在config/alarm-settings.yml中可以定义各种告警条件，例如：

yaml复制rules:
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 3
    silence-period: 5
    message: Response time of service {name} is more than 1000ms

8.2 自定义监控指标

除了内置指标，你还可以通过以下方式添加自定义监控：

1. 使用@Trace注解标记方法
2. 通过Meter API记录自定义指标
3. 配置高级OAL脚本

9. 备份与迁移

9.1 数据备份策略

建议的备份方案：

1. MySQL dump：

   bash复制docker exec skywalking-mysql mysqldump -u skywalking -p yourpassword swtest > backup.sql
   

2. 定时任务：

   • 每天全量备份
   • 保留最近7天的备份

9.2 迁移步骤

迁移到新环境的流程：

1. 备份原数据库
2. 在新环境部署相同版本的SkyWalking
3. 恢复数据库
4. 验证数据完整性

10. 监控与维护

10.1 监控SkyWalking自身

建议监控以下指标：

• OAP服务CPU/内存使用率
• MySQL连接数
• 存储空间使用情况
• 数据写入延迟

10.2 日常维护任务

1. 定期检查存储空间
2. 监控慢查询
3. 定期升级版本
4. 检查告警规则有效性

在实际运维中，我发现这套部署方案特别适合20-50个微服务规模的环境。它提供了足够的性能，同时维护成本相对较低。对于刚接触SkyWalking的团队，建议从小规模开始，随着对系统理解的深入再逐步扩展功能。