Skip to main content

Partner Integrations

Exam guide§3.4

Google Cloud Observability (logging, monitoring, error reporting) publishes open APIs, so a growing ecosystem of third-party tools plugs in to extend IT ops, security, and incident-response capabilities. Two patterns matter for the exam: ingesting on-prem or third-party signals into Cloud Logging / Cloud Monitoring, and exporting logs out to an external SIEM. Pub/Sub is the bridge in both directions.

The partner ecosystem​

Partners are grouped by the capability they extend - a growing matrix across observability, logging/SIEM, security, IT ops, AIOps, and incident response.

ObservabilityBlue MedoraBindPlaneLogging/ SIEMSumo LogicSecuritynetskopetenableIT opsBMCAIOpsInsightFinderIncidentresponseOpsGeniexMatters
A growing ecosystem of technology partners plugs into the open observability APIs, extending Google Cloud’s IT ops, security, and incident-response capabilities across categories.
GotchaThe API is the integration point

Partners don't bolt onto a private internal system - they read from and write to the open observability APIs (Logging API, Monitoring API). That's why the same log-based metrics, real-time viewing, and alerting work whether a log came from a Google Cloud service or was pushed in by a partner collector.

Ingesting on-prem signals: BindPlane​

Adding Blue Medora's BindPlane lets you monitor on-premises resources as if they were native. A BindPlane collector gathers metrics and logs on-prem; BindPlane pushes them into the Cloud Logging API and Cloud Monitoring API. From there they behave like any other GCP signal - searchable in Logs Explorer, chartable in Monitoring, and routable to export destinations (Pub/Sub, Cloud Storage, BigQuery). BindPlane ships 150+ built-in data sources and carries no additional licensing cost with Google Cloud Observability - you only pay for any custom metrics it generates.

On-premisesMetric Src1Metric Src2Metric Src3BindPlane CollectorBindPlaneBindPlane MonitoringGoogle CloudCloudLogging APICloudMonitoring APIExport optionsPub/Sub, CloudStorage, BigQueryLog ingestionCloud LoggingMonitoringCloud MonitoringDevOps/SRE
A BindPlane collector gathers on-prem metrics and logs; BindPlane pushes them through the Cloud Logging and Cloud Monitoring APIs, where they become searchable, chartable, and exportable like native signals. DevOps/SRE read the results in Logging and Monitoring.

Exporting logs to Splunk​

To send logs to Splunk, route them out of Cloud Logging with a sink to a Pub/Sub topic, then use the Pub/Sub to Splunk Dataflow template to stream them to Splunk's HTTP Event Collector (HEC) over HTTP(S). Any message that reaches the Pub/Sub topic can be forwarded to Splunk Enterprise or Splunk Cloud.

A second Pub/Sub to Pub/Sub Dataflow pipeline runs in parallel to replay failed messages: delivery failures land in an unprocessed topic, and Ops/SRE can trigger a re-send once the cause is fixed.

Google CloudCloudLoggingLog sink topic andsubscriptionPub/SubPub/Sub to SplunkDataflow jobDataflowOptional user-definedfunction (UDF) to transform,enrich, filter or redact eventsReplay failed messagesPub/Sub to Pub/SubDataflow jobDataflowUnprocessed topicand subscriptionPub/SubSplunk Enterpriseor Splunk Cloudwith HTTP EventCollector (HEC)UsersOps/SRELog sinkHTTP(S)TriggerInspect
Cloud Logging routes logs through a sink to a Pub/Sub topic; the Pub/Sub to Splunk Dataflow job streams them over HTTP(S) to Splunk’s HTTP Event Collector. Failed messages land in an unprocessed topic and a second Dataflow job replays them - triggered and inspected by Ops/SRE.
NumbersSplunk export pipeline
  • 1 primary pipeline - Pub/Sub → Splunk Dataflow job, delivering over HTTP(S) to HEC.
  • 1 secondary pipeline - Pub/Sub → Pub/Sub Dataflow job, for replaying failed messages.
  • 1 optional UDF - a user-defined function to transform, enrich, filter, or redact events before delivery.
0%0 of 147 pages studied