← 文章 / 云原生与基础设施

signoz 11天前 · 2026-10-24 06:02:46 · 16 阅读

在 SigNoz 中监控 GCP Cloud Storage 的指标和日志

Cloud Storage 集成可将 bucket 的指标和日志接入 SigNoz，并提供该服务的预置仪表盘。

Cloud Storage 将指标发布到 Cloud Monitoring，将审计日志发布到 Cloud Logging。SigNoz 通过运行在你 GCP 项目中的 OpenTelemetry Collector 读取这些数据。

选择配置方式

Manual setupSigNoz agent (coming soon)

现已可用。你在自己的 GCP 项目中运行 OpenTelemetry Collector，并在其配置中添加 Cloud Storage 指标。拉取哪些指标、拉取频率都由你控制。可采集指标；如配置了日志管道，还可采集日志。

先完成一次GCP 集成配置，然后对每个包含待监控 bucket 的项目，按以下步骤操作。

即将推出。SigNoz 将为你部署和管理 Collector：只需连接 GCP 账号并开启该服务，SigNoz 就会在后台自动配置指标接收器和日志路由，无需维护任何 Collector 配置。

在此之前，请使用 Manual setup 标签页。

前提条件

配置此服务之前，请先完成通用的 GCP 集成配置：

已在 SigNoz 中连接 GCP 账号，且拥有 bucket 的项目已加入 Projects to Monitor。
OpenTelemetry Collector 已部署并运行。
signoz-integration-collector 服务账号在拥有 bucket 的项目上具有 roles/monitoring.viewer 权限。参见创建服务账号。
该项目已启用 Cloud Monitoring API。
如需日志：该项目已启用 Cloud Logging API，且你已完成采集日志的第 1 至 5 步。

步骤 1：在 SigNoz 中启用服务

进入 SigNoz，打开集成（Integrations） > Google Cloud Platform。
在服务列表中选择GCP Cloud Storage。
开启指标收集（Metric Collection）以激活预制仪表盘。如果还需发送日志，也请开启日志收集（Log Collection）。
打开已收集的数据（Data Collected）选项卡，记录其中列出的指标。这些正是仪表盘各面板所查询的指标。

警告

仅开启开关并不会自动开始采集。SigNoz 接收到的指标，完全取决于 Collector 配置中的 metrics_list。如果在步骤 2 中遗漏了某项指标，对应的仪表盘面板将保持空白。

步骤 2：在 Collector 配置中添加指标

打开你在部署 Collector时创建的 otel-collector-config.yaml，在拥有你存储桶的项目对应的 googlecloudmonitoring 接收器的 metrics_list 中，加入 Cloud Storage 的指标名称。只需修改下方的 metrics_list，文件其余部分保持不变：

otel-collector-config.yaml

receivers:
  googlecloudmonitoring:
    project_id: "<monitored-project-id>"
    collection_interval: 300s   # 5 分钟；最小值为 60 秒
    metrics_list:
      # 存储数据
      - metric_name: "storage.googleapis.com/storage/v2/total_bytes"
      - metric_name: "storage.googleapis.com/storage/v2/total_count"
      - metric_name: "storage.googleapis.com/storage/v2/deleted_bytes"
      # API 活动
      - metric_name: "storage.googleapis.com/api/request_count"
      - metric_name: "storage.googleapis.com/authn/authentication_count"
      # 网络
      - metric_name: "storage.googleapis.com/network/received_bytes_count"
      - metric_name: "storage.googleapis.com/network/sent_bytes_count"

请核对以下值：

<monitored-project-id>：拥有你存储桶的 GCP 项目。它必须是你监控项目（Projects to Monitor）列表中的某一项。

提示

如果你的存储桶分布在多个项目中，请为每个项目添加一个命名 receiver（googlecloudmonitoring/<name>），并在 metrics pipeline 中列出它们。参见配置多个项目。

该 receiver 会按 collection_interval 轮询列表中的每一个指标，而 Monitoring API 按读取调用计费，因此列表中只保留仪表盘和告警实际用到的指标即可。参见成本与调优。

提示

Cloud Storage 每天（每桶）测量一次 storage/v2/total_bytes 和 storage/v2/total_count。测量结果可用后，Cloud Monitoring 会每 300 秒重复上报一次，直到下一次每日测量。空桶不会被这些指标追踪。storage/v2/deleted_bytes 同样每天上报一次，最长可能需要 24 小时才可用。API、身份验证和网络指标每 60 秒采样一次，更新更频繁。

步骤 3：应用配置

Collector 从 signoz-integration-collector-config secret 中加载配置，因此修改配置需要创建新的 secret 版本并重新部署：

保存更新后的 otel-collector-config.yaml。
添加新的 secret 版本（参见部署 Collector 的步骤 2）。
重新部署 Cloud Run 服务（步骤 3）。

步骤 4：发送日志（可选）

如果还想把 Cloud Storage 审计日志发送到 SigNoz，请按照收集日志设置 Pub/Sub topic、push subscription 和日志 receiver。在步骤 6「创建 log sink」中，使用以下过滤器：

复制

resource.type="gcs_bucket"

关于该过滤器会捕获哪些日志、哪些日志需要先在 GCP 中开启设置，请参见采集内容中的日志部分。

注意事项：

请将相同的筛选器作为排除条件添加到项目的 _Default 日志池中，否则你将为这些日志在 Cloud Logging 和 SigNoz 中重复存储支付费用。请参阅避免重复支付日志费用。

验证

等待一到两个采集周期（默认 300s 设置下最多约 10 分钟）。
在 SigNoz 中，进入仪表盘并打开 Cloud Storage 仪表盘。API、身份验证和网络面板应最先显示数据。
若要查看单个指标，打开指标浏览器并查询 storage.googleapis.com/api/request_count。
对于日志，打开日志并筛选 gcp.resource_type = 'gcs_bucket'。

说明：

对于包含对象的存储桶，请等待最多 24 小时后再将其视为空存储桶。Cloud Storage 每日测量这些值，且不跟踪空存储桶。

收集的内容

指标

参考 SigNoz 集成中的收集数据标签页获取仪表盘使用的完整指标列表，并参考GCP 指标列表以查看完整定义。

指标名称	单位	类型
`storage.googleapis.com/storage/v2/total_bytes`	字节	Gauge
`storage.googleapis.com/storage/v2/total_count`	计数	Gauge
`storage.googleapis.com/storage/v2/deleted_bytes`	字节	Sum
`storage.googleapis.com/api/request_count`	计数	Sum
`storage.googleapis.com/authn/authentication_count`	计数	Sum
`storage.googleapis.com/network/received_bytes_count`	字节	Sum
`storage.googleapis.com/network/sent_bytes_count`	字节	Sum

日志

启用日志收集后，SigNoz 会收集项目中存储桶的Cloud Storage 审计日志：

日志类型	包含内容	所需的 GCP 配置
管理活动审计日志	存储桶及其设置的变更，例如创建或删除存储桶、修改 IAM 策略	无需操作。GCP 始终会写入这些日志。
Data Access 审计日志	读取存储桶设置（`ADMIN_READ`）、读取和列出对象（`DATA_READ`），以及创建、更新和删除对象（`DATA_WRITE`）	为 Cloud Storage 开启 Data Access 审计日志

审计日志不会记录对公开对象的访问，也不会记录 Object Lifecycle Management 或 Autoclass 所做的变更。

在日志接收器中使用以下过滤条件：

Copy

resource.type="gcs_bucket"

故障排查

开启日志采集后没有日志。Admin Activity 日志只有在存储桶或其设置发生变更时才会产生，因此不活跃的项目起初可能什么都没有。在 GCP Console 中打开 Logs Explorer，用 resource.type="gcs_bucket" 过滤，看看 GCP 实际写入了哪些日志。对于对象的读写操作，请确认已为 Cloud Storage 开启 Data Access 审计日志。

日志没有到达。如果 GCP 的 Logs Explorer 中能看到日志，但 SigNoz 中没有，请沿日志管道逐步排查：push subscription 必须能到达 Collector，且 sink 的 writer identity 需要拥有该 topic 的 roles/pubsub.publisher 权限。参见 Collect logs troubleshooting。

仪表盘面板为空。说明该面板依赖的指标不在你的 metrics_list 中。将 Data Collected 标签页的内容与你的 otel-collector-config.yaml 进行比对，补齐缺失项，然后重新执行第 3 步。

存储桶大小和对象数一直为空，而其他面板正常。这两项数据来自 storage/v2/total_bytes 和 storage/v2/total_count，Cloud Storage 每天只测量一次。先确认所选存储桶中确实包含对象，然后等待最多 24 小时的下一次测量，再进一步排查。

完全没有 Cloud Storage 指标。确认 signoz-integration-collector 服务账号在目标资源上拥有 roles/monitoring.viewer 权限

原始来源： signoz