The name Stackdriver still appears in older tutorials, configuration references, and search results, but Google’s current suite is called Google Cloud Observability. Its services help operators collect and interpret signals about application health, infrastructure behavior, and requests crossing several systems. Google Cloud Operations was a previous branding stage rather than a separate replacement product. Understanding the naming history prevents teams from assuming a current Logging or Monitoring feature has disappeared because its old Stackdriver label is no longer prominent.<\/p>\n
Observability is not simply collecting as many logs as possible. It is the ability to ask what users are experiencing, which components contributed to a problem, what changed, and which action could restore acceptable service. Google’s current products include Cloud Logging, Cloud Monitoring, Cloud Trace, and Error Reporting, with associated profiling, application monitoring, and telemetry collection capabilities. They work best when signals reflect a specific workload and incident process, not when a dashboard is assembled before anyone knows what questions it must answer.<\/p>\n
Historically, Stackdriver combined monitoring and logging for cloud environments; Google later used the Cloud Operations naming before adopting Google Cloud Observability for its present integrated experience. The underlying functions have changed alongside the branding, but a production team should distinguish a historical console screenshot from a current supported API or agent. Old application guides may refer to Stackdriver Logging or Stackdriver Monitoring while their corresponding present services are Cloud Logging and Cloud Monitoring.<\/p>\n
The current product encompasses telemetry for Google Cloud infrastructure and applications, and supports selected external or hybrid workloads through appropriate collectors and integrations. It is not an unconditional promise that every third-party service is automatically observed. Collection depends on the service, available instrumentation, permissions, configuration, and billing choices. A cloud team should maintain a service inventory describing where its metrics, logs, and traces originate and which required signals have not yet been instrumented.<\/p>\n
A good starting point is a simple customer workflow, such as submitting an order. Identify where the request enters, which service checks identity, where data is stored, and which external dependency is called. The Google Cloud architecture dependency model<\/a> makes this path easier to draw. Monitoring should follow the actual chain and user outcome rather than counting unrelated resource metrics in isolation.<\/p>\n Cloud Monitoring gathers metric data and supports dashboards, alerts, and analysis of applications and Google Cloud services. Basic platform metrics may be collected without special application code, but business-level indicators often require custom instrumentation. CPU, memory, and request count can describe infrastructure load yet fail to show whether customers are receiving correct answers or completing transactions. Choose service-level indicators that represent successful activity, latency, error rate, or data freshness as appropriate to the workload.<\/p>\n An alert should have an owner and an intended response. Record which metric is evaluated, the threshold, observation period, missing-data behavior, and escalation path. An instantaneous spike may not deserve the same reaction as sustained transaction failures. Test alerts with bounded synthetic conditions and confirm notifications reach responders. Otherwise a team can have hundreds of well-designed charts and still learn about outages from customers.<\/p>\n Monitoring is most useful when it enables comparison over time. After a release, compare customer-visible performance, error rates, saturation, and cost-related measures to the agreed baseline. A dashboard can help identify a correlation between a deployment and degraded service, but correlation does not prove a cause. Operators should use the change record and other telemetry to test their explanation before carrying out a disruptive remediation.<\/p>\n Cloud Logging stores, searches, and analyzes log records from supported Google Cloud services and instrumented applications. A structured log makes incident analysis easier when it includes meaningful severity, service identity, correlation identifiers, and safe contextual fields. Logging a full customer record or authentication secret can create another security incident, so teams should define which information may enter telemetry and how it is protected. Sensitive-data restrictions are as important as log availability.<\/p>\n Cloud Logging supports log views, routing, and retention controls, and logs-based metrics can help drive Cloud Monitoring analysis. A team should decide which log categories belong in operational troubleshooting, security investigations, and compliance workflows. Different groups may need different access scopes and retention periods. Unlimited storage is neither a prudent cost plan nor a universal legal requirement. The Google Cloud operating-control practices<\/a> provide related guidance on ownership, IAM, security, and the lifecycle of production evidence.<\/p>\n During an investigation, reconstruct an event timeline using timestamps and reliable identifiers instead of reading one suspicious line without context. A new policy installation might be close to the first error, but the application could also be failing because a database quota or external API changed. Log queries should help differentiate these explanations. If a needed event was never emitted or its retention expired, document that gap and improve collection for future incidents.<\/p>\n Cloud Trace records spans that describe parts of a request as it moves through instrumented services. It can reveal that an otherwise fast frontend spent most of a response waiting for an internal API or database call. A trace is most useful when identifiers, service labels, and sampling decisions are consistent across components. Without suitable instrumentation, the request path may be incomplete and investigators must avoid interpreting a partial trace as the complete history of the transaction.<\/p>\n Error Reporting groups application errors found through supported error events or log data, helping responders identify new or recurring failures. A spike in exception count may represent a genuine application problem, a change in logging, or a known harmless condition. Review the grouping, affected version, user impact, and deployment history before assigning urgency. An error group is evidence to investigate, not a diagnosis by itself.<\/p>\n Cloud Profiler provides another perspective by showing CPU and memory behavior for supported applications. Profile information can help explain a cost or latency problem that ordinary resource metrics do not resolve. Profiling and tracing should be used in accordance with application data policies and resource limits. Together, logs, metrics, traces, errors, and profiling can narrow a question, but none substitutes for understanding what the customer was trying to accomplish.<\/p>\n Google now recommends vendor-neutral instrumentation frameworks such as OpenTelemetry for many applications. This can provide consistent metrics, logs, and traces across services while reducing dependence on a product-specific client library. The appropriate path depends on runtime support, existing deployment tooling, and where telemetry should be exported. Plan trace context propagation and structured logging together so a responder can move from an alert to the relevant request and underlying application events.<\/p>\n For Compute Engine VMs, the Ops Agent is the preferred supported agent for collecting logs and metrics. Google announced that the legacy standalone Monitoring and Logging agents reached end of support on September 28, 2026; they are not the recommended choice for a new installation. Existing legacy agents may continue sending telemetry, but receiving data does not mean the agents receive maintenance or support for newer operating systems. Organizations should plan a tested move to supported alternatives rather than wait for an incident.<\/p>\n Containerized workloads require their own labels, request identifiers, and collection considerations. An application can create a flood of logs that is difficult to search or unnecessarily expensive if severity and context are inconsistent. The Kubernetes logging and workload evidence<\/a> is relevant when a service spans pods and deployments. Test how telemetry behaves through a restart, rollout, or missing downstream dependency to verify the collected events still support diagnosis.<\/p>\n A practical observability plan starts from a critical user journey and names three or four questions: is the user outcome succeeding, is it fast enough, which dependency is failing, and what changed recently? Use service-level indicators, dashboards, and alerting policies that answer those questions. A system can meet a low-level availability threshold and still violate its business requirement because responses are stale or incorrect. Operational measurement should capture that difference.<\/p>\nUse Cloud Monitoring to define healthy service behavior<\/h2>\n
Use Cloud Logging for evidence and controlled retention<\/h2>\n
Trace distributed requests and understand grouped errors<\/h2>\n
Instrument applications and agents using supported methods<\/h2>\n
Design service indicators, alerts, and incident workflows together<\/h2>\n