Google ACE: 监控、日志记录和运维排障 — 学习指南
属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.
概述
Google Cloud 上的卓越运营取决于将遥测数据转化为行动。监控、日志记录和问题排查共同提供了保持服务可靠所需的信号、护栏和工作流。本节涵盖核心的可观测性服务、诊断工具、可靠性实践和事件操作，并探讨其设计原理、权衡取舍和常见故障模式。
监控与提醒基础
Cloud Monitoring 从 Google Cloud 服务、代理和自定义指标中注入时间序列数据，以提供信息中心、正常运行时间检查、SLO 和提醒功能。
指标和基数
- 受监控的资源类型（例如 gce_instance、aws_ec2_instance、global）限定了项目、区域和实例 ID 等维度的范围。
- 尽量减少无边界的标签值（例如 user_id），以防止高基数爆炸，这会减慢查询速度并增加成本。
- 优先使用分布指标来衡量延迟（p50/p90/p99），并使用对齐窗口进行一致的汇总。
信息中心
- 使用内置的服务信息中心进行快速入门。创建自定义信息中心以对跨项目指标进行分组。在面板组织上，应先按症状（延迟、错误、饱和度）再按原因（CPU、内存）进行组织。
- 对于大规模实例集群，避免使用单实例图表；应按服务、可用区或 MIG 进行聚合，以减少噪音并增强信号。
提醒政策
- 设计与用户体验相关的基于症状的提醒：可用性 SLO 消耗、延迟百分位数、错误率。使用多窗口、多消耗率提醒来捕捉快速和慢速消耗（例如，1 小时内消耗 2% 和 5 分钟内消耗 5%）。
- 设置合理的通知速率限制和自动关闭行为。使用事件自动缓解注释来记录操作手册。
- 对具有严格时间表的关键批处理作业和数据管道，使用指标缺失提醒。
- 基于日志的指标支持针对应用程序或安全事件（例如，重复的 permissionDenied）的提醒。
通知渠道
- 根据严重性配置渠道：SEV1 使用寻呼（on-call、短信、电话），SEV2/3 使用聊天工具，低优先级使用电子邮件或 Webhook。使用 Pub/Sub 与工单或自动化系统集成。
- 定期测试通知渠道；过时的渠道是一种静默的失败模式。
正常运行时间检查和合成监控
- 从全球探测点发起的 HTTP(S) 和 TCP 检查可验证外部可达性。将检查与内容匹配相结合以检测部分故障。
- 对于内部服务，通过混合连接或 Private Service Connect 使用私有正常运行时间检查。
- 故障模式：检查可能因 DNS TTL 延迟、TLS 证书轮换问题或区域性中断而失败；在发起寻呼前，应与指标相互印证。
多项目监控
- 使用单个 Monitoring 工作区并关联所有项目，以实现统一的信息中心和提醒。这可以简化整个实例集群的 SLO 管理并减少重复工作。
日志记录、审计和应用诊断
Cloud Logging 是平台日志和应用日志的日志路由器、存储和查询平面。配套的 APM 工具（Error Reporting、Trace、Profiler）可加速根本原因的隔离。
日志路由、存储桶、接收器和保留
- 使用接收器将日志路由到日志存储桶（默认或自定义）、BigQuery（用于分析）、Pub/Sub（用于流处理）或 Cloud Storage（用于归档）。
- 使用区域范围的日志存储桶以满足数据驻留和性能要求。如果合规性要求，请应用 CMEK。
- 按存储桶设置保留期（例如，运营日志保留 30-90 天，审计日志保留数年）。更长的保留期会增加成本；应积极使用过滤器来控制开销。
- 排除项可减少详细日志（例如，健康检查）的注入量。验证过滤器以避免无意中丢弃关键日志。
示例：为审计日志创建 BigQuery 接收器
- gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT_ID/datasets/audit_ds –log-filter=‘logName:cloudaudit.googleapis.com AND protoPayload.methodName:*’ –include-children
示例：创建排除项
- gcloud logging exclusions create drop-health-checks –description=“Exclude load balancer health checks” –log-filter=‘resource.type=“gce_instance” AND httpRequest.requestUrl:"/healthz"’
查询和日志浏览器
- 在 resource.type、严重性、标签和 JSON 负载上使用高级过滤器。保存查询以用于常见的分类路径（启动失败、permissionDenied、quotaExceeded）。
- 创建基于日志的分布指标和计数器指标，用于提醒和信息中心。
Cloud Audit Logs
- 管理员活动日志：始终开启，注入不收费；记录管理员的写入操作（例如，createInstance）。
- 数据访问日志：记录数据平面的读取和写入操作（例如，storage.objects.get）。默认情况下对许多服务是禁用的；由于其日志量和成本可能很高，应选择性地启用。
- 系统事件日志：Google 系统的操作（例如，自动扩缩、维护实时迁移）。
- 政策拒绝日志：明确记录 IAM 和组织政策的拒绝事件。对于访问问题排查和安全审查至关重要。
- 将审计日志路由到 BigQuery 以进行保留和调查；为 authenticationInfo.principalEmail 等标签编制索引以便于归因。
Error Reporting、Trace 和 Profiler
- Error Reporting 按服务和版本自动对堆栈跟踪进行分组；与通知渠道集成，以便在新错误组出现和错误量突然激增时收到通知。
- Cloud Trace 收集请求延迟分布和跨度信息；设置采样率以平衡开销和保真度（例如，对于高 QPS 的服务，采样率为千分之一，如果使用 OpenTelemetry 收集器，则可采用基于尾部的采样）。
- Profiler 在生产环境中提供低开销的持续 CPU/堆分析。将其限制在热路径或代表性工作负载上，以控制数据量和开销。使用源映射以获得可读的调用图。
- 权衡：更高的采样率可以改善诊断，但会增加成本和潜在的 PII 暴露风险；应清理敏感字段并使用令牌化。
服务、资源和网络故障排查
高效的故障排查始于表象，然后界定系统边界，最后深入到资源和依赖项。
托管服务的健康状况、服务状态、配额、区域性事件
- 验证事件是否源于上游：检查服务健康状况和近期的区域性通告。关注错误突增、延迟升高或配额错误。
- 配额是每个项目以及通常是每个区域的；日志中的
quotaExceeded和rateLimitExceeded表明存在节流。应在流量高峰事件前申请提高配额。 - 故障模式：部分区域性中断可能表现为间歇性错误；在可能的情况下配置多区域故障转移。
资源健康状况与虚拟机诊断
- 使用实例操作、维护事件和健康检查。对于 MIGs，检查自动修复重启和健康检查失败的情况，以隔离有问题的镜像或配置。
虚拟机串行控制台用于查看启动和内核消息：
undefined
- 常见原因：内核崩溃 (kernel panic)、错误的 fstab 条目导致启动受阻、不正确的网络配置、OS Login 配置错误导致 SSH 失败。
确保使用 OS Login，并结合每个用户的 SSH 密钥和 IAM 角色（
compute.osLogin或compute.osAdminLogin），以实现可追溯的访问。使用 Logs Explorer 进行故障分析
- 从表象日志（5xx、deadlineExceeded）入手，按资源标签进行筛选分析，然后与部署变更和配额日志进行关联。使用直方图视图定位变更点。
网络可观测性
VPC Flow Logs：对每个 VNIC 的 5 元组流量进行采样；在子网上启用。调整采样率（例如 0.5）和元数据选项，以在性能与细节之间取得平衡。
undefined
防火墙日志记录：捕获关键规则的允许/拒绝决策，以诊断意外的阻止或规则遮蔽 (shadowing)。
undefined
Connectivity Tests：建模并验证跨 VPC、对等互连、Cloud VPN、Cloud Interconnect 和防火墙规则的可达性。可用于变更前验证和事件分类处理。
undefined
- 补充信号：Cloud NAT 和负载均衡器日志用于排查出站和边缘问题。故障模式包括非对称路由、路由缺失、防火墙规则顺序错误以及策略限制。
可靠性、SLO 与事件运维
运维纪律将遥测数据与用户影响目标以及一致的事件执行流程联系起来。
SLO、错误预算和基线
- 基于以用户为中心的 SLI（可用性、延迟、正确性）来定义 SLO。例如：在 30 天内，99.9% 的读取请求在 200 毫秒内完成。
- 按服务和发布版本跟踪错误预算并设计汇总仪表盘。根据预算消耗情况来决定是否放行新版本发布。
- 在流量上升前建立性能基线；性能衰退是通过与基线的偏差来检测，而非绝对值。
告警降噪
- 优先使用服务级别告警，而非实例级别告警。使用变化率和基于百分位的条件。应用通知节流、事件自动关闭，并在维护窗口期间静音告警。
- 通过通用标签和策略对告警进行去重；使用具备依赖感知的路由，以避免因同一事件而同时呼叫数据库和应用的 on-call 人员。
事件响应工作流
- 进行分诊并宣布严重等级；分配角色（事件指挥官、运维、沟通、记录员）。
- 升级路径：on-call 轮班、主题专家和供应商支持（在支持工单中包含项目 ID、请求 ID、时间戳和区域）。
- 沟通：维护单一事实来源（聊天频道和事件文档）。向利益相关者定期提供更新，包括影响、缓解措施和预计解决时间 (ETA)。
- 缓解措施手册：回滚、故障切换、禁用功能标志或增加容量。优先选择爆炸半径小且可逆的变更。
事件后复盘与 RCA
- 证据驱动：关联指标、日志、追踪和变更事件。复盘内容应包括哪些检测信号触发了、为什么触发或未触发，以及检测/缓解所需的时间。
- 识别促成因素，而不仅仅是直接原因。记录具体的行动项，明确负责人和截止日期；并相应地更新运维手册和告警。
- 无指责文化鼓励充分披露信息并进行系统性修复。
运维手册 (Runbook)
- 结构：触发与检测、快速诊断树、安全缓解措施、回滚/恢复步骤、验证和退出标准。
- 保持命令和过滤器处于可随时复制粘贴的状态；为响应者验证最小权限 IAM（例如，为只写备份授予
storage.objectCreator权限；为工作负载身份使用专用的服务账号）。 - 通过变更管理对运维手册进行版本控制；在攻防演练期间进行测试。
实际问题场景
Northwind Outfitters 在 Google Cloud 上运行一个区域性电子商务平台。在最近一次流量高峰后，用户间歇性地报告结账超时和产品搜索缓慢。运维团队需要快速恢复可靠性，减少告警噪音，并加强跨多个项目的诊断能力。
方法：
- 整合跨项目的监控
- 行动：创建一个单一的 Monitoring 工作区，并关联 prod、payments 和 search 项目。构建一个“用户旅程”仪表盘，显示结账和搜索的可用性、延迟和错误率。
- 理由：集中化的可见性支持服务级别的分诊，并能关联跨服务问题（例如，搜索延迟级联导致结账超时）。
- 实施 SLO 和消耗率告警
- 行动：定义 SLO：99.9% 的结账在 400 毫秒内完成，99.95% 的搜索在 250 毫秒内完成。基于延迟和错误率 SLI 创建多窗口消耗率告警（1 小时内消耗 2%，5 分钟内消耗 5%）。通过寻呼通知 on-call 人员，通过聊天通知利益相关者。
- 理由：消耗率告警能够捕捉到快速的性能衰退和持续的缓慢消耗，而不会因为正常的波动而触发呼叫。
- 添加带内容匹配的合成正常运行时间检查
- 行动：为公共入口点配置 TCP 和 HTTPS 正常运行时间检查，并为内部支付 API 配置一个私有正常运行时间检查，验证响应体中包含“ok”。
- 理由：检测可达性和部分故障，如后端路由错误或上游服务降级。
- 优化日志路由和保留策略
- 行动：创建专用的日志存储桶：ops（90 天）、security-audit（2 年，使用 CMEK）。通过接收器将 Admin Activity、Data Access、System Event 和 Policy Denied 日志路由到 BigQuery 进行分析。为产生大量日志的健康检查添加排除规则。
- 理由：适当的保留期可以控制成本；BigQuery 支持快速的数字取证。排除规则在不丢失关键证据的情况下减少了噪音。
- 启用应用诊断
- 行动：使用 OpenTelemetry 检测服务以启用 Trace；为后端和前端启用 Error Reporting；以保守的采样率向结账服务推出 Profiler，进行 CPU 和堆内存分析。
- 理由：Trace 可识别延迟热点路径；Error Reporting 能高亮显示新的错误分组；Profiler 以低开销揭示 CPU 争用和内存泄漏。
- 加强网络可观测性
- 行动：在 prod 子网上启用 VPC Flow Logs（0.5 采样率，包含所有元数据），并为到 search 和 payments 的入站流量的 allow/deny 规则启用防火墙日志记录。创建从 Web 层到 search 以及从 payments 到 Cloud SQL 的 Connectivity Tests。
- 理由：流日志和防火墙日志可暴露丢包、重传和被覆盖的规则；Connectivity Tests 可验证可达性并识别错误配置。
- 资源级诊断与安全访问
- 行动：对于不稳定的虚拟机，使用串行控制台检查启动问题：
undefined
- 如果需要 SSH，则强制执行 OS Login，并将
compute.osAdminLogin权限授予“ops-admins”组。每个管理员使用自己的 SSH 密钥。 - 理由：串行日志能揭示内核和初始化失败。使用 OS Login 和每个用户的独立密钥可确保访问的可追溯性和最小权限。
- 配额与区域健康状况验证
- 行动：审查日志中最近的
quotaExceeded事件；为 search 自动扩缩提高区域性 API 和 IP 配额。检查受影响区域的服务健康通告；通过负载均衡器权重临时转移流量。 - 理由：配额限制和区域性事件是常见的间歇性故障源；主动扩容和流量导向可以减轻影响。
- 降噪与运维手册更新
- 行动：用服务级别的饱和度告警替换单实例的 CPU 告警。添加维护窗口以静音非行动性告警。用新的分诊查询、追踪仪表盘和回滚流程更新运维手册。
- 理由：减少 on-call 疲劳，并加速一致、安全的响应。
- 事件后复盘与行动项
- 行动：进行一次无指责的复盘。将消耗率事件与搜索尾部延迟增加及最近的索引发布关联起来。行动项：为 search 添加金丝雀发布、索引大小防护机制和自动扩缩器的预留空间；承诺定期测试告警渠道。
- 理由：证据驱动的 RCA 可以防止问题再次发生，并改进检测、缓解和恢复能力。
← 部署、配置和自动化 · 所有领域 · 安全性、合规性和数据保护 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →