深入解析 Eventarc 平台日志格式googleapis 仓库中的结构化活动日志 Proto 定义【免费下载链接】googleapisPublic interface definitions of Google APIs.项目地址: https://gitcode.com/GitHub_Trending/go/googleapisEventarc Advanced 在处理事件时会生成面向平台遥测的结构化日志本指南基于 googleapis 仓库中google/cloud/eventarc/logging/v1目录下的 Proto 定义完整解读四类活动日志MessageBusActivity、GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity的字段语义、枚举取值与触发时机并结合同仓库的 Eventarc 资源定义MessageBus、Pipeline、Enrollment、GoogleApiSource 等说明其背后的事件处理链路。读完本文你将能够按字段级精度读懂 Eventarc Advanced 的日志输出并掌握如何依据message_uid、attributes、google.rpc.Status等核心字段排查事件投递、匹配与转换过程中的问题。背景日志格式文档的定位在 googleapis 仓库中google/cloud/eventarc/logging/v1/README.md 明确指出该目录下的 Proto 文件用于文档化 Eventarc API 的日志格式serve as documentation for the format of the logs。这意味着这些 Proto 定义并不是某个客户端 SDK 的请求/响应模型而是描述 Eventarc 平台在运行期间会发出的结构化日志条目形态供使用者在 Cloud Logging / 平台遥测中理解日志内容。README 还特别说明了两点发布状态这些 Proto目前尚未作为库发布not currently published as libraries。部分语言可能存在适当的库但覆盖面远不及用于发起 API 调用的 Google Cloud Client Libraries。为了便于后续发布库语言相关选项language-specific options可能在将来补充。与之对应目录下的 BUILD.bazel 已经为 Java、Go、Python、PHP、Ruby、C#、C 等语言生成了对应的 proto 库目标如logging_java_proto、logging_go_proto、logging_py_proto、logging_php_proto、logging_ruby_proto、logging_csharp_proto、logging_cc_proto这从构建体系层面印证了为多语言发布做准备的意图。目录构成与消息全景该目录共包含 4 个 Proto 文件对应 4 个顶层消息类型Proto 文件顶层消息对应 Eventarc 处理环节message_bus_activity.protoMessageBusActivity事件被消息总线Message Bus接收google_api_source_activity.protoGoogleApiSourceActivityGoogle API 事件被发送到消息总线enrollment_activity.protoEnrollmentActivity事件与 Enrollment注册规则匹配pipeline_activity.protoPipelineActivity消息在 Pipeline 中流转接收/转换/投递/响应四个文件均声明package google.cloud.eventarc.logging.v1采用 proto3 语法并统一依赖三份公共 Protogoogle/api/field_info.proto提供字段格式注解、google/protobuf/timestamp.proto时间戳与 google/rpc/status.proto错误状态。这一依赖关系在 BUILD.bazel 的logging_proto目标中也有完整呈现。所有活动日志共用的消息骨架四个顶层消息共享同一套头字段 oneof 活动体的结构设计这是理解整个日志体系的关键// 以 MessageBusActivity 为例message_bus_activity.proto message MessageBusActivity { // 系统生成的事件唯一 IDUUID4 格式 string message_uid 1 [(google.api.field_info).format UUID4]; // 来自事件属性的 CloudEvent ID 与 source mapstring, string attributes 2; // 活动发生的时间点 google.protobuf.Timestamp activity_time 3; // 可记录的具体活动之一 oneof activity { Received received 4; } }三个头字段承担着跨阶段追踪与检索的职责message_uid系统为消息总线收到的每个事件生成的唯一 IDgoogle.api.field_info注解声明为UUID4格式并在整个请求链路中传播原文注释This ID is propagated throughout the request。它是把 Message Bus → Enrollment → Pipeline 各阶段日志串联成一条完整事件轨迹的核心键。attributes取自 CloudEvent 属性的 ID 与 source 等键值对用于标识事件来源与事件身份。activity_time活动发生的精确时间点类型为google.protobuf.Timestamp。activityoneof本次日志具体记录的活动类型。proto3 的oneof语义保证一条日志条目只会携带一种活动内容避免歧义。关于UUID4注解的具体语义可参见 google/api/field_info.proto它表示符合 RFC 4122 的 UUID v4 值可归一化为全小写例如F47AC10B-58CC-0372-8567-0E02B2C3D479会被归一化为f47ac10b-58cc-0372-8567-0e02b2c3d479便于日志去重与索引。MessageBusActivity事件进入消息总线message_bus_activity.proto 记录事件被发布到消息总线这一环节的日志触发注释为Logged during the processing of an event published to a message bus。它唯一的活动体是Received子消息Logged when an event is received by a message bus即事件被消息总线接收时发出字段如下message Received { // 关于收到事件的信息性细节 string details 4; // 当 enrollment 遇到错误时记录 google.rpc.Status error 5; }值得注意两点字段编号不连续4、5而非1、2。这是 Proto 定义的常见兼容性策略——为后续可能插入的字段预留编号避免破坏既有 wire 格式兼容性。error复用google.rpc.Status成功路径下error为空出错时则携带标准 gRPC 状态码与错误消息与 Eventarc 底层 gRPC 错误模型保持一致。MessageBusActivity对应的事件源头资源是 google/cloud/eventarc/v1/message_bus.proto 中定义的MessageBus资源资源名格式projects/{project}/locations/{location}/messageBuses/{message_bus}该资源上可配置LoggingConfig以控制平台日志的级别详见后文。GoogleApiSourceActivityGoogle API 事件投递google_api_source_activity.proto 记录Google API 事件被发送到消息总线环节的日志触发注释为Logged during the processing of a Google API event being sent to a message bus。其唯一活动体为Published子消息Logged when an event is published to a message bus即事件被发布到消息总线时发出message Published { // 与该 GoogleApiEvent 配置关联的消息总线 string message_bus 1; // 产生该事件的事件提供方 string event_provider 2; // 关于发送事件的附加信息 string details 3; // 事件遇到错误时记录 google.rpc.Status error 4; }Published给出了三个定位信息message_bus目标消息总线资源名、event_provider产生事件的提供方例如某 Google 服务、details事件附加信息。该日志对应的资源配置在 google/cloud/eventarc/v1/google_api_source.proto 中GoogleApiSource表示从消息总线订阅 1Pfirst-party事件支持按项目列表订阅ProjectSubscriptions最多 100 个项目或组织级订阅OrganizationSubscription。从源码结构可以推断GoogleApiSourceActivity正是这些订阅源产生的事件在进入消息总线前被记录的位置。EnrollmentActivity事件命中注册规则enrollment_activity.proto 记录事件在消息总线上匹配到 Enrollment环节的日志触发注释为Logged during the processing of an enrollment on an event in a message bus。其唯一活动体为Matched子消息Logged when an event matches an enrollment即事件与注册规则匹配时发出message Matched { // 关于匹配事件的信息性细节 string details 1; // 该 enrollment 匹配到的目的地例如 Pipeline 的名称 string event_destination 2; // enrollment 遇到错误时记录 google.rpc.Status error 3; }event_destination字段尤其关键它指明匹配到的事件将被送往何处注释示例为 pipeline 名称。与之对应的资源定义在 google/cloud/eventarc/v1/enrollment.protoEnrollment表示消息总线上某一类消息的订阅通过必需的cel_match字段一个 CEL 表达式定义匹配条件并将匹配消息投递到订阅端点。可以推断Matched日志中的event_destination通常就是该 Enrollment 配置的投递目标如 Pipeline。PipelineActivity消息在 Pipeline 中的全生命周期pipeline_activity.proto 是内容最丰富的日志类型记录消息在 Pipeline 中处理的各个环节触发注释Logged during the processing of a message in a pipeline。它包含 5 种活动体完整覆盖了消息从进入 Pipeline 到响应返回的整个流转过程。公共枚举PayloadFormatPipelineActivity定义了全局枚举PayloadFormat用于标注消息负载格式enum PayloadFormat { // 默认值未使用 PAYLOAD_FORMAT_UNSPECIFIED 0; // JSON 负载格式 JSON 1; // Proto 负载格式 PROTO 2; // Avro 负载格式 AVRO 3; }该枚举与 google/cloud/eventarc/v1/pipeline.proto 中Pipeline.MessagePayloadFormat的三种格式JsonFormat、ProtobufFormat、AvroFormat一一对应日志中的input_payload_format/output_payload_format正是 Pipeline 上input_payload_format与Destination.output_payload_format配置的实际反映。活动一MessageReceived消息接收记录消息从来源进入 Pipeline或遇到错误的时刻message MessageReceived { // 从来源收到消息时的信息性细节 string details 1; // 消息的输入负载格式 PayloadFormat input_payload_format 2; // 从 Channel 接收消息或消息格式错误时遇到的错误 google.rpc.Status error 3; }注意其error注释明确列举了两种错误来源从 Channel 接收失败与消息格式非法malformed。活动二MessageTransformed消息转换记录消息在**中介处理mediation**阶段被转换或出错的时刻message MessageTransformed { // 中介转换消息时的信息性细节 string details 1; // 转换消息时遇到的错误 google.rpc.Status error 2; }在 pipeline.proto 中Mediation.Transformation通过 CEL 表达式模板transformation_template转换消息因此MessageTransformed通常对应 Pipeline 配置了 mediation 转换时的日志输出。活动三MessageConverted消息格式转换记录消息在中介处理中被转换格式或出错的时刻同时携带输入与输出两种负载格式message MessageConverted { string details 1; PayloadFormat input_payload_format 2; PayloadFormat output_payload_format 3; google.rpc.Status error 4; }input_payload_format与output_payload_format成对出现便于直接观察格式转换前后的变化如 JSON → Proto。活动四MessageRequestDispatched请求投递记录消息请求被投递到目的地或出错的时刻message MessageRequestDispatched { string details 1; // 事件被发送到的目的地 string destination 2; // 投递前遇到的错误例如非法目的地 google.rpc.Status error 3; }destination对应 Pipeline 的Destination配置。根据 pipeline.proto目的地可以是 HTTP 端点HttpEndpoint、Workflow、Message Bus 或 Pub/Sub Topicdestination_descriptoroneofMessageRequestDispatched中的错误还可能源于目的地非法malformed destination。活动五MessageResponseReceived响应接收与重试决策记录从目的地收到**响应或错误**的时刻并内置重试决策枚举RetryStatusenum RetryStatus { // 默认值未使用 RETRY_STATUS_UNSPECIFIED 0; // Pipeline 将重试向目的地投递消息 WILL_RETRY 1; // Pipeline 不再重试该消息 RETRY_EXHAUSTED 2; } message MessageResponseReceived { // 目标收到响应或请求失败时的信息性细节 string details 1; // 收到响应后对消息的重试决策 RetryStatus retry_status 2; // 未来将重试消息请求的时间仅当 retry_status 为 WILL_RETRY 时存在 google.protobuf.Timestamp retry_time 3; // 消息响应携带的 HTTP 响应码 int32 http_response_code 4; // 收到的消息响应状态 google.rpc.Status error 5; }这一活动体揭示了 Eventarc Advanced 的重试语义与 pipeline.proto 中的RetryPolicy定义相互印证retry_statusWILL_RETRY表示还会重试RETRY_EXHAUSTED表示重试次数已耗尽、不再重试。retry_time仅当retry_status WILL_RETRY时存在指明下次重试的未来时间点。http_response_code记录目的地的 HTTP 响应码如 4xx/5xx是判断重试诱因的直接证据。error记录响应层面的状态。从源码看Pipeline 默认的RetryPolicy语义为指数退避从 5 秒开始、每次失败翻倍10 秒、20 秒、40 秒……上限默认 60 秒max_attempts取值范围 1~100默认 5min_retry_delay与max_retry_delay取值范围 1~600 秒默认分别为 5 与 60。因此retry_time的取值可以预期落在该退避策略的时间窗口内。PipelineActivity 的 oneof 全貌oneof activity { MessageReceived message_received 4; MessageTransformed message_transformed 5; MessageConverted message_converted 6; MessageRequestDispatched message_request_dispatched 7; MessageResponseReceived message_response_received 8; }这条oneof把消息在 Pipeline 内的流转顺序接收 → 转换 → 格式转换 → 投递 → 响应建模为互斥的活动状态任意一条 PipelineActivity 日志只对应其中一个环节。结合相同的message_uid即可把同一条消息在 Pipeline 内多个环节的日志串联起来还原完整处理轨迹。日志级别控制LoggingConfig这些活动日志归属于 Eventarc Advanced 的平台遥测Platform Logging / Platform Telemetry其产生与级别由资源上的LoggingConfig控制。定义见 google/cloud/eventarc/v1/logging_config.protoLoggingConfig.log_severity发送到平台遥测的最低日志级别级别 ≥ 该值且非NONE的日志会被发送。可选值包括LOG_SEVERITY_UNSPECIFIED、NONE资源创建默认值视为关闭日志、DEBUG、INFO、NOTICE、WARNING、ERROR、CRITICAL、ALERT、EMERGENCY。该枚举被注释为完整且冻结FROZEN不会新增取值。LoggingConfig可以配置在MessageBus上作用于消息总线本身及其下所有 Enrollment见 message_bus.proto 中logging_config字段注释也可以配置在Pipeline上见 pipeline.proto 的logging_config字段。这意味着想让某条消息总线及旗下注册规则产生活动日志需要在对应MessageBus资源上配置LoggingConfig想让 Pipeline 各环节产生活动日志需要在对应Pipeline资源上配置LoggingConfig。多语言构建与发布现状从 BUILD.bazel 可以看到这些日志 Proto 已具备完整的跨语言构建目标Gologging_go_proto的importpath为cloud.google.com/go/eventarc/logging/apiv1/loggingpb并组装出google-cloud-eventarc-logging-v1-go发布包Javalogging_java_protogoogle-cloud-eventarc-logging-v1-java发布包Pythonlogging_py_gapictransport 为grpcrestrest_numeric_enums Falsegoogle-cloud-eventarc-logging-v1-pyPHP / Ruby / C# / C分别有google-cloud-eventarc-logging-v1-php、logging_ruby_proto/logging_ruby_grpc、google-cloud-eventarc-logging-v1-csharp包名Google.Cloud.Eventarc.Logging.V1、logging_cc_proto/logging_cc_grpc。需要再次强调 README 的说明这些定义当前未以库的形式发布构建目标是为将来发布做准备在日志分析场景中它们首先承担的是格式文档的角色——即当你看到一条 Eventarc Advanced 平台日志时可以依据本文所述的字段结构解读其含义。实践建议如何利用这些日志定义基于上述 Proto 定义的字段设计可给出以下可直接落地的排查思路均以仓库内的定义为依据按message_uid关联全链路消息总线收到事件时会生成message_uid并在请求中传播后续GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity中的同名消息应携带同一message_uid。检索时以message_uid为过滤键即可还原事件从来源到投递的完整轨迹。优先看error与http_response_codegoogle.rpc.Status携带标准错误码与消息Pipeline 投递环节的http_response_code直接反映目的地返回码retry_statusWILL_RETRY/RETRY_EXHAUSTED结合retry_time可判断当前是否处于重试周期及重试是否已耗尽。用attributes与event_provider/destination定位来源去向attributes中的 CloudEvent ID/source 标识事件身份event_provider标识事件提供方event_destination/destination标识投递目标便于按业务维度筛选。关注负载格式字段MessageReceived.input_payload_format与MessageConverted的input/output_payload_format可确认消息格式是否按预期转换结合 Pipeline 的input_payload_format与Destination.output_payload_format配置进行核对当输入格式与预期不符时pipeline.proto 注释说明消息会被视为持久性错误此类失败会体现在相应活动的error字段中。确认日志是否开启若日志缺失先检查对应MessageBus/Pipeline资源上的LoggingConfig.log_severity是否被设置为NONE默认值或高于期望的级别。小结Eventarc Advanced 的日志体系以统一骨架 分环节活动体的 Proto 设计呈现四类顶层消息MessageBusActivity、GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity共用message_uid、attributes、activity_time头字段并以oneof activity承载 8 种具体活动体Received、Published、Matched以及 Pipeline 的MessageReceived、MessageTransformed、MessageConverted、MessageRequestDispatched、MessageResponseReceived。这些定义与 message_bus.proto、pipeline.proto、enrollment.proto、google_api_source.proto、logging_config.proto 中的资源模型一一呼应构成一套可跨阶段追踪、可定位错误、可核对配置的平台日志规范。理解这套格式是高效运维 Eventarc Advanced 事件管道的第一步。【免费下载链接】googleapisPublic interface definitions of Google APIs.项目地址: https://gitcode.com/GitHub_Trending/go/googleapis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 Eventarc 平台日志格式：googleapis 仓库中的结构化活动日志 Proto 定义
深入解析 Eventarc 平台日志格式googleapis 仓库中的结构化活动日志 Proto 定义【免费下载链接】googleapisPublic interface definitions of Google APIs.项目地址: https://gitcode.com/GitHub_Trending/go/googleapisEventarc Advanced 在处理事件时会生成面向平台遥测的结构化日志本指南基于 googleapis 仓库中google/cloud/eventarc/logging/v1目录下的 Proto 定义完整解读四类活动日志MessageBusActivity、GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity的字段语义、枚举取值与触发时机并结合同仓库的 Eventarc 资源定义MessageBus、Pipeline、Enrollment、GoogleApiSource 等说明其背后的事件处理链路。读完本文你将能够按字段级精度读懂 Eventarc Advanced 的日志输出并掌握如何依据message_uid、attributes、google.rpc.Status等核心字段排查事件投递、匹配与转换过程中的问题。背景日志格式文档的定位在 googleapis 仓库中google/cloud/eventarc/logging/v1/README.md 明确指出该目录下的 Proto 文件用于文档化 Eventarc API 的日志格式serve as documentation for the format of the logs。这意味着这些 Proto 定义并不是某个客户端 SDK 的请求/响应模型而是描述 Eventarc 平台在运行期间会发出的结构化日志条目形态供使用者在 Cloud Logging / 平台遥测中理解日志内容。README 还特别说明了两点发布状态这些 Proto目前尚未作为库发布not currently published as libraries。部分语言可能存在适当的库但覆盖面远不及用于发起 API 调用的 Google Cloud Client Libraries。为了便于后续发布库语言相关选项language-specific options可能在将来补充。与之对应目录下的 BUILD.bazel 已经为 Java、Go、Python、PHP、Ruby、C#、C 等语言生成了对应的 proto 库目标如logging_java_proto、logging_go_proto、logging_py_proto、logging_php_proto、logging_ruby_proto、logging_csharp_proto、logging_cc_proto这从构建体系层面印证了为多语言发布做准备的意图。目录构成与消息全景该目录共包含 4 个 Proto 文件对应 4 个顶层消息类型Proto 文件顶层消息对应 Eventarc 处理环节message_bus_activity.protoMessageBusActivity事件被消息总线Message Bus接收google_api_source_activity.protoGoogleApiSourceActivityGoogle API 事件被发送到消息总线enrollment_activity.protoEnrollmentActivity事件与 Enrollment注册规则匹配pipeline_activity.protoPipelineActivity消息在 Pipeline 中流转接收/转换/投递/响应四个文件均声明package google.cloud.eventarc.logging.v1采用 proto3 语法并统一依赖三份公共 Protogoogle/api/field_info.proto提供字段格式注解、google/protobuf/timestamp.proto时间戳与 google/rpc/status.proto错误状态。这一依赖关系在 BUILD.bazel 的logging_proto目标中也有完整呈现。所有活动日志共用的消息骨架四个顶层消息共享同一套头字段 oneof 活动体的结构设计这是理解整个日志体系的关键// 以 MessageBusActivity 为例message_bus_activity.proto message MessageBusActivity { // 系统生成的事件唯一 IDUUID4 格式 string message_uid 1 [(google.api.field_info).format UUID4]; // 来自事件属性的 CloudEvent ID 与 source mapstring, string attributes 2; // 活动发生的时间点 google.protobuf.Timestamp activity_time 3; // 可记录的具体活动之一 oneof activity { Received received 4; } }三个头字段承担着跨阶段追踪与检索的职责message_uid系统为消息总线收到的每个事件生成的唯一 IDgoogle.api.field_info注解声明为UUID4格式并在整个请求链路中传播原文注释This ID is propagated throughout the request。它是把 Message Bus → Enrollment → Pipeline 各阶段日志串联成一条完整事件轨迹的核心键。attributes取自 CloudEvent 属性的 ID 与 source 等键值对用于标识事件来源与事件身份。activity_time活动发生的精确时间点类型为google.protobuf.Timestamp。activityoneof本次日志具体记录的活动类型。proto3 的oneof语义保证一条日志条目只会携带一种活动内容避免歧义。关于UUID4注解的具体语义可参见 google/api/field_info.proto它表示符合 RFC 4122 的 UUID v4 值可归一化为全小写例如F47AC10B-58CC-0372-8567-0E02B2C3D479会被归一化为f47ac10b-58cc-0372-8567-0e02b2c3d479便于日志去重与索引。MessageBusActivity事件进入消息总线message_bus_activity.proto 记录事件被发布到消息总线这一环节的日志触发注释为Logged during the processing of an event published to a message bus。它唯一的活动体是Received子消息Logged when an event is received by a message bus即事件被消息总线接收时发出字段如下message Received { // 关于收到事件的信息性细节 string details 4; // 当 enrollment 遇到错误时记录 google.rpc.Status error 5; }值得注意两点字段编号不连续4、5而非1、2。这是 Proto 定义的常见兼容性策略——为后续可能插入的字段预留编号避免破坏既有 wire 格式兼容性。error复用google.rpc.Status成功路径下error为空出错时则携带标准 gRPC 状态码与错误消息与 Eventarc 底层 gRPC 错误模型保持一致。MessageBusActivity对应的事件源头资源是 google/cloud/eventarc/v1/message_bus.proto 中定义的MessageBus资源资源名格式projects/{project}/locations/{location}/messageBuses/{message_bus}该资源上可配置LoggingConfig以控制平台日志的级别详见后文。GoogleApiSourceActivityGoogle API 事件投递google_api_source_activity.proto 记录Google API 事件被发送到消息总线环节的日志触发注释为Logged during the processing of a Google API event being sent to a message bus。其唯一活动体为Published子消息Logged when an event is published to a message bus即事件被发布到消息总线时发出message Published { // 与该 GoogleApiEvent 配置关联的消息总线 string message_bus 1; // 产生该事件的事件提供方 string event_provider 2; // 关于发送事件的附加信息 string details 3; // 事件遇到错误时记录 google.rpc.Status error 4; }Published给出了三个定位信息message_bus目标消息总线资源名、event_provider产生事件的提供方例如某 Google 服务、details事件附加信息。该日志对应的资源配置在 google/cloud/eventarc/v1/google_api_source.proto 中GoogleApiSource表示从消息总线订阅 1Pfirst-party事件支持按项目列表订阅ProjectSubscriptions最多 100 个项目或组织级订阅OrganizationSubscription。从源码结构可以推断GoogleApiSourceActivity正是这些订阅源产生的事件在进入消息总线前被记录的位置。EnrollmentActivity事件命中注册规则enrollment_activity.proto 记录事件在消息总线上匹配到 Enrollment环节的日志触发注释为Logged during the processing of an enrollment on an event in a message bus。其唯一活动体为Matched子消息Logged when an event matches an enrollment即事件与注册规则匹配时发出message Matched { // 关于匹配事件的信息性细节 string details 1; // 该 enrollment 匹配到的目的地例如 Pipeline 的名称 string event_destination 2; // enrollment 遇到错误时记录 google.rpc.Status error 3; }event_destination字段尤其关键它指明匹配到的事件将被送往何处注释示例为 pipeline 名称。与之对应的资源定义在 google/cloud/eventarc/v1/enrollment.protoEnrollment表示消息总线上某一类消息的订阅通过必需的cel_match字段一个 CEL 表达式定义匹配条件并将匹配消息投递到订阅端点。可以推断Matched日志中的event_destination通常就是该 Enrollment 配置的投递目标如 Pipeline。PipelineActivity消息在 Pipeline 中的全生命周期pipeline_activity.proto 是内容最丰富的日志类型记录消息在 Pipeline 中处理的各个环节触发注释Logged during the processing of a message in a pipeline。它包含 5 种活动体完整覆盖了消息从进入 Pipeline 到响应返回的整个流转过程。公共枚举PayloadFormatPipelineActivity定义了全局枚举PayloadFormat用于标注消息负载格式enum PayloadFormat { // 默认值未使用 PAYLOAD_FORMAT_UNSPECIFIED 0; // JSON 负载格式 JSON 1; // Proto 负载格式 PROTO 2; // Avro 负载格式 AVRO 3; }该枚举与 google/cloud/eventarc/v1/pipeline.proto 中Pipeline.MessagePayloadFormat的三种格式JsonFormat、ProtobufFormat、AvroFormat一一对应日志中的input_payload_format/output_payload_format正是 Pipeline 上input_payload_format与Destination.output_payload_format配置的实际反映。活动一MessageReceived消息接收记录消息从来源进入 Pipeline或遇到错误的时刻message MessageReceived { // 从来源收到消息时的信息性细节 string details 1; // 消息的输入负载格式 PayloadFormat input_payload_format 2; // 从 Channel 接收消息或消息格式错误时遇到的错误 google.rpc.Status error 3; }注意其error注释明确列举了两种错误来源从 Channel 接收失败与消息格式非法malformed。活动二MessageTransformed消息转换记录消息在**中介处理mediation**阶段被转换或出错的时刻message MessageTransformed { // 中介转换消息时的信息性细节 string details 1; // 转换消息时遇到的错误 google.rpc.Status error 2; }在 pipeline.proto 中Mediation.Transformation通过 CEL 表达式模板transformation_template转换消息因此MessageTransformed通常对应 Pipeline 配置了 mediation 转换时的日志输出。活动三MessageConverted消息格式转换记录消息在中介处理中被转换格式或出错的时刻同时携带输入与输出两种负载格式message MessageConverted { string details 1; PayloadFormat input_payload_format 2; PayloadFormat output_payload_format 3; google.rpc.Status error 4; }input_payload_format与output_payload_format成对出现便于直接观察格式转换前后的变化如 JSON → Proto。活动四MessageRequestDispatched请求投递记录消息请求被投递到目的地或出错的时刻message MessageRequestDispatched { string details 1; // 事件被发送到的目的地 string destination 2; // 投递前遇到的错误例如非法目的地 google.rpc.Status error 3; }destination对应 Pipeline 的Destination配置。根据 pipeline.proto目的地可以是 HTTP 端点HttpEndpoint、Workflow、Message Bus 或 Pub/Sub Topicdestination_descriptoroneofMessageRequestDispatched中的错误还可能源于目的地非法malformed destination。活动五MessageResponseReceived响应接收与重试决策记录从目的地收到**响应或错误**的时刻并内置重试决策枚举RetryStatusenum RetryStatus { // 默认值未使用 RETRY_STATUS_UNSPECIFIED 0; // Pipeline 将重试向目的地投递消息 WILL_RETRY 1; // Pipeline 不再重试该消息 RETRY_EXHAUSTED 2; } message MessageResponseReceived { // 目标收到响应或请求失败时的信息性细节 string details 1; // 收到响应后对消息的重试决策 RetryStatus retry_status 2; // 未来将重试消息请求的时间仅当 retry_status 为 WILL_RETRY 时存在 google.protobuf.Timestamp retry_time 3; // 消息响应携带的 HTTP 响应码 int32 http_response_code 4; // 收到的消息响应状态 google.rpc.Status error 5; }这一活动体揭示了 Eventarc Advanced 的重试语义与 pipeline.proto 中的RetryPolicy定义相互印证retry_statusWILL_RETRY表示还会重试RETRY_EXHAUSTED表示重试次数已耗尽、不再重试。retry_time仅当retry_status WILL_RETRY时存在指明下次重试的未来时间点。http_response_code记录目的地的 HTTP 响应码如 4xx/5xx是判断重试诱因的直接证据。error记录响应层面的状态。从源码看Pipeline 默认的RetryPolicy语义为指数退避从 5 秒开始、每次失败翻倍10 秒、20 秒、40 秒……上限默认 60 秒max_attempts取值范围 1~100默认 5min_retry_delay与max_retry_delay取值范围 1~600 秒默认分别为 5 与 60。因此retry_time的取值可以预期落在该退避策略的时间窗口内。PipelineActivity 的 oneof 全貌oneof activity { MessageReceived message_received 4; MessageTransformed message_transformed 5; MessageConverted message_converted 6; MessageRequestDispatched message_request_dispatched 7; MessageResponseReceived message_response_received 8; }这条oneof把消息在 Pipeline 内的流转顺序接收 → 转换 → 格式转换 → 投递 → 响应建模为互斥的活动状态任意一条 PipelineActivity 日志只对应其中一个环节。结合相同的message_uid即可把同一条消息在 Pipeline 内多个环节的日志串联起来还原完整处理轨迹。日志级别控制LoggingConfig这些活动日志归属于 Eventarc Advanced 的平台遥测Platform Logging / Platform Telemetry其产生与级别由资源上的LoggingConfig控制。定义见 google/cloud/eventarc/v1/logging_config.protoLoggingConfig.log_severity发送到平台遥测的最低日志级别级别 ≥ 该值且非NONE的日志会被发送。可选值包括LOG_SEVERITY_UNSPECIFIED、NONE资源创建默认值视为关闭日志、DEBUG、INFO、NOTICE、WARNING、ERROR、CRITICAL、ALERT、EMERGENCY。该枚举被注释为完整且冻结FROZEN不会新增取值。LoggingConfig可以配置在MessageBus上作用于消息总线本身及其下所有 Enrollment见 message_bus.proto 中logging_config字段注释也可以配置在Pipeline上见 pipeline.proto 的logging_config字段。这意味着想让某条消息总线及旗下注册规则产生活动日志需要在对应MessageBus资源上配置LoggingConfig想让 Pipeline 各环节产生活动日志需要在对应Pipeline资源上配置LoggingConfig。多语言构建与发布现状从 BUILD.bazel 可以看到这些日志 Proto 已具备完整的跨语言构建目标Gologging_go_proto的importpath为cloud.google.com/go/eventarc/logging/apiv1/loggingpb并组装出google-cloud-eventarc-logging-v1-go发布包Javalogging_java_protogoogle-cloud-eventarc-logging-v1-java发布包Pythonlogging_py_gapictransport 为grpcrestrest_numeric_enums Falsegoogle-cloud-eventarc-logging-v1-pyPHP / Ruby / C# / C分别有google-cloud-eventarc-logging-v1-php、logging_ruby_proto/logging_ruby_grpc、google-cloud-eventarc-logging-v1-csharp包名Google.Cloud.Eventarc.Logging.V1、logging_cc_proto/logging_cc_grpc。需要再次强调 README 的说明这些定义当前未以库的形式发布构建目标是为将来发布做准备在日志分析场景中它们首先承担的是格式文档的角色——即当你看到一条 Eventarc Advanced 平台日志时可以依据本文所述的字段结构解读其含义。实践建议如何利用这些日志定义基于上述 Proto 定义的字段设计可给出以下可直接落地的排查思路均以仓库内的定义为依据按message_uid关联全链路消息总线收到事件时会生成message_uid并在请求中传播后续GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity中的同名消息应携带同一message_uid。检索时以message_uid为过滤键即可还原事件从来源到投递的完整轨迹。优先看error与http_response_codegoogle.rpc.Status携带标准错误码与消息Pipeline 投递环节的http_response_code直接反映目的地返回码retry_statusWILL_RETRY/RETRY_EXHAUSTED结合retry_time可判断当前是否处于重试周期及重试是否已耗尽。用attributes与event_provider/destination定位来源去向attributes中的 CloudEvent ID/source 标识事件身份event_provider标识事件提供方event_destination/destination标识投递目标便于按业务维度筛选。关注负载格式字段MessageReceived.input_payload_format与MessageConverted的input/output_payload_format可确认消息格式是否按预期转换结合 Pipeline 的input_payload_format与Destination.output_payload_format配置进行核对当输入格式与预期不符时pipeline.proto 注释说明消息会被视为持久性错误此类失败会体现在相应活动的error字段中。确认日志是否开启若日志缺失先检查对应MessageBus/Pipeline资源上的LoggingConfig.log_severity是否被设置为NONE默认值或高于期望的级别。小结Eventarc Advanced 的日志体系以统一骨架 分环节活动体的 Proto 设计呈现四类顶层消息MessageBusActivity、GoogleApiSourceActivity、EnrollmentActivity、PipelineActivity共用message_uid、attributes、activity_time头字段并以oneof activity承载 8 种具体活动体Received、Published、Matched以及 Pipeline 的MessageReceived、MessageTransformed、MessageConverted、MessageRequestDispatched、MessageResponseReceived。这些定义与 message_bus.proto、pipeline.proto、enrollment.proto、google_api_source.proto、logging_config.proto 中的资源模型一一呼应构成一套可跨阶段追踪、可定位错误、可核对配置的平台日志规范。理解这套格式是高效运维 Eventarc Advanced 事件管道的第一步。【免费下载链接】googleapisPublic interface definitions of Google APIs.项目地址: https://gitcode.com/GitHub_Trending/go/googleapis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考