如何开启 Query Insights 并保留 30 天历史数据？ - 问题详情 - 创脉思

解读

在国内 Google Cloud 面试中，这道题考察的是候选人对 Cloud SQL 可观测性能力 的落地经验，尤其是 Query Insights（查询洞察） 这一企业级诊断特性的配置细节。面试官希望听到你不仅知道“开关在哪”，还能讲清 数据留存策略、费用影响、权限模型以及对生产库的性能干扰。30 天保留期是高频合规需求（等保、SOX、上市审计），答出“控制台点两下”只能拿及格分；必须补充 Terraform 代码、IAM 最小权限、成本估算、灰度验证 才能体现资深水平。

知识点

Query Insights 组件：由 pg_stat_statements 内核插件 + 谷歌托管的 Timeseries 后端组成，支持 TOP N 慢 SQL、CPU/IO/锁归因、执行计划漂移检测。
保留期参数：insightsConfig.queryPlansPerMinute 与 queryStringLength 决定基数，recordApplicationTags 影响标签维度；历史数据保留上限由 retentionDurationDays 控制，最大 30 天，不可延长。
开启级别：可在 实例创建时（terraform 里 settings.insights_config 块）或 在线热更新（不重启主库，但会触发 1 次控制面滚动）。
费用：国内结算美元账单，保留 30 天约增加 3%–7% 存储费用（与 QPS 正相关），需提前评估 cloudsql.googleapis.com/insights/bytes_used 指标。
权限模型：
- 开启/修改需 roles/cloudsql.admin 或自定义角色含 cloudsql.instances.update；
- 查看慢 SQL 明文需 roles/cloudsql.viewer + roles/iam.serviceAccountUser（因数据存储在谷歌内部项目，走 IAM 条件级授权）。
性能影响：开启后额外 2%–4% CPU 开销，国内北京/上海地域实测延迟增加 <1 ms；若实例为 db-f1-micro 等共享核，建议先升配再开。
合规与脱敏：Query Insights 默认记录完整 SQL，含手机号、身份证等敏感字段；国内金融客户需开启 queryStringLength=256 做截断，或搭配 DLP 数据脱敏流 二次处理。

答案

分三种场景给出最严谨的 30 天保留方案，面试时按“控制台→CLI→Terraform”递进回答，体现梯度能力。

控制台（应急演示用）
a. 登陆 Google Cloud 中国版控制台（vpc.google.com），选对应项目；
b. 进入 SQL → 实例 → Overview → 修改；
c. 展开 “性能优化” → 勾选 “启用 Query Insights”；
d. 查询计划保留天数 下拉选 30（若灰显，先关闭“自定义保留”开关）；
e. “记录应用标签” 按业务需要勾选，“记录查询字符串” 默认开启；
f. 点保存，控制面滚动约 2 分钟，无连接闪断；
g. 验证：在 Query Insights 面板 选择 “Past 30 days”，确认数据落盘。

gcloud CLI（国内 CI/CD 主流）

# 设置国内镜像源，加速拉取
export CLOUDSDK_API_ENDPOINT_OVERRIDES_SQL=https://sqladmin.googleapis.com

# 热更新开启并保留 30 天
gcloud sql instances patch <实例ID> \
  --project=<项目ID> \
  --insights-config-query-insights-enabled \
  --insights-config-query-string-length=1024 \
  --insights-config-record-application-tags \
  --insights-config-query-plans-per-minute=5 \
  --retention-duration-days=30

回显 operationId 后，轮询状态为 DONE 即生效；国内网络建议加 --verbosity=error 避免日志刷屏。

Terraform IaC（生产推荐，可重复审计）

resource "google_sql_database_instance" "default" {
  name             = "prod-mysql"
  database_version = "MYSQL_8_0"
  region           = "asia-northeast3"  # 首尔区域，国内延迟低
  settings {
    tier = "db-n1-standard-2"
    insights_config {
      query_insights_enabled  = true
      query_string_length     = 1024
      record_application_tags = true
      query_plans_per_minute  = 5
    }
    # 30 天保留
    backup_configuration {
      enabled                        = true
      start_time                     = "03:00"
      retained_backups               = 30
      retention_unit                 = "COUNT"
    }
    # 注意：insights 保留天数不在 backup_configuration，
    # 而是靠 insights_config 内部实现，terraform 4.75+ 已支持
  }
}

计划阶段 terraform plan 会提示 “Adding insights_config will not restart the instance”，可安全执行。

权限收尾：给 SRE 组绑定自定义角色

gcloud iam roles create cloudsql_insights_viewer --project=<项目ID> \
  --permissions=cloudsql.instances.get,cloudsql.instances.list,cloudsql.instances.listServerCas,resourcemanager.projects.get
gcloud projects add-iam-policy-binding <项目ID> \
  --member="group:sre@company.cn" \
  --role="projects/<项目ID>/roles/cloudsql_insights_viewer"

成本告警：在 Budgets & alerts 里新建预算，指标选 “Cloud SQL Insights Storage Byte-Hours”，阈值 80% 提前通知财务。

拓展思考

如果面试官追问“30 天不够，能否自建仓库存 90 天？”
答：Query Insights 后端是谷歌托管，硬上限 30 天；正确姿势是 将 cloudsql.googleapis.com/insights/query_metrics 指标导出到 BigQuery，按 分区表 + 90 天生命周期规则 自建数据仓，同时用 Looker Studio 做可视化，兼顾合规与成本。
若实例已开 Private IP 且未开通 Google APIs 私有访问，Insights 数据仍可通过 VPC Service Controls 边界内网写入，不经过公网，满足国内金融 VPC 封闭要求；但需留意 PSC（Private Service Connect） 的 DNS 转发配置，否则控制台面板会报 “数据暂时不可用”。
国内双十二大促场景，临时把 query_plans_perMinute 调到 50 做细粒度排查，结束后再调回 5，避免持续高基数导致费用翻倍；此操作同样热更新，无需停服，体现你对 成本可观测性 的闭环思维。