Google Cloud负载均衡访问日志每日低成本聚合方案咨询

方案1：Cloud Logging Sinks + BigQuery分区表 + 定时聚合 #

• 操作步骤：
  1. 创建Cloud Logging Sink，将负载均衡访问日志导出到BigQuery分区表（按timestamp字段按日分区），原始日志仅按日期存储，查询时仅扫描目标日期分区，大幅降低计算与存储成本。
  2. 在BigQuery中创建小型汇总表（如daily_endpoint_metrics），结构包含date、endpoint、request_count、unique_ip_count。
  3. 用Cloud Scheduler每日定时触发BigQuery聚合查询：

     INSERT INTO `project.dataset.daily_endpoint_metrics`
     SELECT
       DATE(timestamp) AS date,
       jsonPayload.requestUrl AS endpoint,
       COUNT(*) AS request_count,
       COUNT(DISTINCT jsonPayload.sourceIp) AS unique_ip_count
     FROM `project.dataset.load_balancer_logs_partitioned`
     WHERE DATE(timestamp) = CURRENT_DATE()
     GROUP BY date, endpoint
     

  4. 给原始日志分区表设置TTL（自动过期），比如保留7天自动删除，彻底避免长期存储原始日志的高额成本。
• 优势：支持短期回溯原始日志，聚合逻辑灵活，成本可控；适合需保留短期原始日志的场景。

方案2：Cloud Logging自定义指标 + Cloud Monitoring自动化拉取 #

此方案完全无需存储原始日志，成本最低：

• 操作步骤：
  1. 在Cloud Logging中创建两个自定义指标：
     • 请求计数指标：基于负载均衡日志，按jsonPayload.requestUrl（端点）分组，类型选「计数器」，统计每个端点的请求量。
     • 独立IP计数指标：按端点分组，以jsonPayload.sourceIp为维度，类型选「分布」或直接配置distinct count规则。
  2. 用Cloud Scheduler每日定时调用Monitoring API，拉取当日每个端点的请求总计数和独立IP数，将结果存入Cloud Storage的CSV或小型BigQuery汇总表。
  3. 调整Logging指标的保留期限（如30天），进一步压缩存储成本。
• 优势：完全规避原始日志存储成本，操作轻量；适合仅需指标、无需原始日志的场景。

方案3：Cloud Functions + Pub/Sub Sink实时聚合 #

适合需准实时统计且控制成本的场景：

• 操作步骤：
  1. 创建Cloud Logging Sink将日志导出到Pub/Sub主题，设置消息保留时间为1小时（避免不必要的存储）。
  2. 部署Cloud Functions订阅该Pub/Sub主题，每条日志触发时：
     • 提取endpoint和sourceIp字段。
     • 用Cloud Firestore或Memorystore（Redis）维护当日计数：以{date}_{endpoint}为键，存储请求计数和去重后的IP集合。
  3. 用Cloud Scheduler每日定时触发另一个Cloud Functions，将当日汇总数据导出到BigQuery或Cloud Storage，随后清理当日临时存储数据。
• 优势：准实时统计，无需存储大量原始日志；适合对统计时效性有要求的场景。

通用成本优化建议 #

• 所有涉及存储的服务（BigQuery、Cloud Firestore、Memorystore）都设置TTL或定期清理规则，避免长期存储无用数据。
• 优先选择按需付费的服务（Cloud Functions、Cloud Scheduler），规避预留资源的闲置成本。
• BigQuery优先使用分区表和聚类表，减少查询扫描的数据量，降低计算成本。

内容的提问来源于stack exchange，提问作者JazzCat