如果错误日志暴增，如何设置日志采样率？ - 问题详情 - 创脉思

解读

在国内金融、电商等高并发场景下，Cloud SQL 实例一旦因慢查询、连接风暴或业务异常导致错误日志瞬间膨胀，会直接触发以下风险：

Stackdriver Logging 费用飙升：国内账单以 GiB 为单位，超出免费额度后单价约 0.5 元/GiB/月，日志暴增 100 GB 即可带来 50 元/月 的额外成本；
审计平台拥堵：很多公司把 Cloud SQL 日志接入自建 ELK 或阿里云 SLS，暴增日志会把 Kafka 队列打爆，导致审计合规断流；
实例性能抖动：当日志写入量超过 50 MB/s 时，Cloud SQL 的底层 Persistent Disk IOPS 可能被日志写占满，业务 QPS 下跌 10% 以上。

因此，面试官想考察的是：能否在不丢核心错误的前提下，用最小成本把日志流量降下来，同时保证国内合规审计“可追溯”要求。

知识点

Cloud SQL 日志分类：ERROR、WARNING、INFO、慢查询日志（slow_query）、审计日志（cloudaudit.googleapis.com）；
采样控制层级：
- 数据库层：MySQL 的 log_warnings、sql_log_bin；PostgreSQL 的 log_min_error_statement、log_statement；
- Google Cloud 层：Logging sinks 的 sampling 策略（exponentialBucket 与 sampleRate）；
- 代理层：Cloud SQL Auth Proxy 的 --log_debug_stdout=false 可关闭冗余 debug；
国内合规限制：银保监会《银行业金融机构数据治理指引》要求“关键错误 100% 留存”，因此采样率不能一刀切，必须按日志级别做分层采样；
Terraform 模板：国内多云架构常用 Terraform 做 GitOps，采样率必须能 IaC 化，否则无法过审计。

答案

回答时分三步，先给思路再给命令，最后补一句“可灰度”。

定位日志来源
在 Cloud Console 的 Logs Explorer 里用过滤语句
```
resource.type="cloudsql_database"
severity>=ERROR
```
统计过去 1 小时条数，如果单实例 >10 万条，即可判定为“暴增”。
分层设置采样率
国内合规要求 ERROR 必须全量，WARNING 可采样，INFO 直接丢弃。
在 Logging sink 配置里加 sampleRate 与 severity 组合：
```
gcloud logging sinks update my-sink \
  --log-filter='resource.type="cloudsql_database"
                severity=ERROR
                OR (severity=WARNING AND sample(0.1))' \
  --project=my-project
```
含义：ERROR 100% 留存，WARNING 只留 10%，其余级别丢弃。
若实例为 PostgreSQL，还想在库内减少生成量，可改参数：
```
gcloud sql instances patch my-instance \
  --database-flags=log_min_error_statement=ERROR,log_statement=none
```
这样 PostgreSQL 本身就不再输出 NOTICE 与 INFO，从源头减负。

灰度与回滚
先对 只读实例 生效，观察 30 分钟，确认审计平台无“丢关键错误”告警后再推生产；全程用 Terraform 管理，代码片段：

resource "google_logging_project_sink" "sql_sink" {
  name        = "sql-error-sampled"
  destination = "bigquery.googleapis.com/projects/my-project/datasets/sql_log"
  filter      = <<EOF
    resource.type="cloudsql_database"
    (severity=ERROR OR (severity=WARNING AND sample(0.1)))
  EOF
  unique_writer_identity = true
}

回滚时只需把 sample(0.1) 改成 sample(1.0) 再 terraform apply，5 秒完成，满足国内金融级变更时效要求。

拓展思考

动态采样：结合 Cloud Monitoring 自定义指标 logging.googleapis.com/byte_count，用 Cloud Alerting Policy 触发 Cloud Function，当日志字节数 >1 GB/15min 时自动把采样率从 1.0 降到 0.1，实现“自适应节流”；
冷热分层：国内合规要求日志存 5 年以上，可把全量日志先写入 BigQuery 近热区（90 天），再通过 BigQuery Data Transfer 把采样后的汇总表转存到 OSS 冷区，成本下降 70%；
多云一致性：若公司同时用阿里云 RDS，可把 Cloud SQL 的采样策略封装成 OPA Gatekeeper 模板，在 Kubernetes 多集群下发，保证“一套策略，多云复用”，面试时提到这一点可体现 云原生治理 视野。