Cloud Trace, Error Reporting and Profiler

GCP Basics · Operations – Cloud Monitoring, Alerting, Cloud Logging and Audit Logs · Lesson 5 of 5

Cloud Trace shows where request time goes across services, Error Reporting groups crashes and exceptions from logs, and Cloud Profiler shows which code burns CPU and memory in production.

Metrics tell you that something is slow or failing. These three tools tell you where and why.

flowchart LR
  REQ["Slow checkout request"] --> TR["Cloud Trace<br/>spans across services"]
  TR --> SP["Slow span: payment-api → Cloud SQL 1.8 s"]
  ERR["Exception stack traces in logs"] --> ER["Error Reporting<br/>grouped, counted, new vs resolved"]
  APP["Running service"] --> PR["Cloud Profiler<br/>CPU and heap flame graphs"]
  PR --> HOT["Hot function: json serialisation 35% CPU"]
  %% step REQ: Users report that checkout sometimes takes 3 seconds.
  %% step TR: Cloud Trace shows one trace per request, made of spans for each service and call.
  %% step SP: The trace reveals that the payment API spends 1.8 s waiting on a database query.
  %% step ERR: Apps write exceptions to logs; Error Reporting parses stack traces automatically.
  %% step ER: Errors are grouped by cause, counted, and you can be notified when a new error type appears.
  %% step APP: The Profiler agent samples the running code with very low overhead.
  %% step PR: Flame graphs show which functions use the most CPU time or memory.
  %% step HOT: You fix the hot function and lower cost and latency for every request.

Cloud Trace

Distributed tracing: a trace per request, made of spans (service calls, database queries).
Instrument with OpenTelemetry; Cloud Run, App Engine and load balancers add some spans automatically.
Use it to find the slowest dependency, N+1 queries and latency outliers (p95/p99).
Traces can be linked from logs (trace field), so you can jump from an error log to the full request.

Error Reporting

Reads stack traces from Cloud Logging (Cloud Run, GKE, Compute Engine with the Ops Agent, App Engine) or from the API.
Groups identical errors, shows first/last seen, count and affected versions.
Mark errors as acknowledged or resolved; get notified when a new error group appears or a resolved one comes back.

Cloud Profiler

Continuous CPU, heap, wall-time and contention profiling for Go, Java, Node.js and Python.
Overhead is designed to be low enough for production.
Compare versions to see if a release made code slower.

Other operations tools worth knowing

Tool	Use
Query Insights	Slow queries and their plans for Cloud SQL and AlloyDB
Personalized Service Health	Google Cloud incidents that affect your projects
Active Assist / Recommender	Idle resources, rightsizing, IAM recommendations
Gemini Cloud Assist	Natural-language investigation of logs, metrics and config issues
VPC Flow Logs, Firewall Rules Logging	Network troubleshooting

Putting it together

A typical investigation: alert fires on latency → open the dashboard → find a slow trace → see the Cloud SQL span → check Query Insights for the query → read related error logs → fix and confirm with Profiler and the SLO chart.

gcloud services enable cloudtrace.googleapis.com cloudprofiler.googleapis.com clouderrorreporting.googleapis.com
gcloud logging read 'resource.type="cloud_run_revision" AND trace:"projects/dl-shop-prod/traces/4bf92f3577b34da6"' --limit=50

Command	Meaning
`gcloud beta error-reporting events list --service=web`	Error events for a service
`gcloud sql instances patch shop-db --insights-config-query-insights-enabled`	Turn on Query Insights

Traps: traces need propagation of the trace context header between services, or spans appear as separate traces; Error Reporting only sees errors that are logged with a stack trace; profiling every service at once without a question wastes effort.