Diagnostics
When something is slow, erroring, or expensive to run, these tools tell you why. The exam mostly tests picking the right one from a one-line symptom.
App is misbehaving - which tool?
Application performance
Two tools answer the "why is it slow / heavy?" question, and they split cleanly: Trace follows time across services, Profiler follows CPU and memory inside the code.
Cloud Trace
A trace follows one request as it propagates through your services; each hop is a span. Reading the waterfall, the widest span is where the time goes - that is the whole point of tracing. Trace also auto-analyzes all your traces to generate latency reports that surface performance degradations over time, in near real-time.
Traces come from three sources: App Engine (automatic), global external Application Load Balancers, and any application instrumented with the Cloud Trace SDKs / API (OpenTelemetry). No instrumentation on a custom service = no spans for it.
Cloud Profiler
Cloud Profiler continuously samples a running application and merges the results into a flame graph - stacked frames whose width is the share of CPU (or memory heap) they consume. The widest frame is the hot function to optimize. Because sampling is statistical and extremely low-impact, it runs safely across every production instance rather than a single dev run - which is why its results actually reflect production.
- Languages: Java, Go, Node.js, Python.
- Runs anywhere: applications on Google Cloud, other clouds, or on-premises.
- How: statistical sampling + extremely low-impact instrumentation across all production instances - a complete picture without slowing the app down.
- Why not dev profiling: dev-environment results rarely map to production, and classic production profilers either slow execution or only inspect a subset of the codebase.
Both are performance tools, easy to swap. Trace = where does time go across the call path. Profiler = where do CPU/memory go inside the code. "Requests slow" → Trace; "instance CPU pegged" → Profiler.
Errors
Error Reporting
Error Reporting counts, analyzes, and aggregates the crashes thrown by your running services. A crash in most modern languages is an exception that is not caught and is handled by the runtime rather than the code itself. Instead of scrolling raw logs, you get a centralized interface that de-dupes identical stack traces into error groups you can sort and filter, plus real-time notifications the moment a new error appears.
- Platforms (generally available): App Engine (standard and flexible), Apps Script, Compute Engine, Cloud Run, Cloud Run functions, GKE, and Amazon EC2.
- Languages the stack-trace parser handles: Go, Java, .NET, Node.js, PHP, Python, Ruby.
- Two outputs: a centralized dashboard (sort + filter) and real-time notifications on new errors.
Error Reporting parses exceptions from Amazon EC2, not just Google Cloud services - handy for a question that stresses a hybrid or multi-cloud fleet.
Data & platform health
The last two tools sit beside the application-performance trio: one scoped to your database queries, one to the health of Google's own services under you.
Query Insights
Query Insights moves the diagnosis into the database itself, for Cloud SQL and
AlloyDB. It charts database load over time and splits it by wait type - CPU,
CPU-wait, I/O, and lock - so you see why the database is busy, not just that it is. A
top-contributors view then ranks the queries, users, and client IPs driving that load,
and drills into a single normalized query (literals replaced with ?) down to its
sampled query plan. No third-party tooling required.
- Scope: Cloud SQL (MySQL, PostgreSQL, SQL Server) and AlloyDB.
- Load model: load = query execution time ÷ wall-clock time, aggregated per minute.
- Breaks load down by: query, SQL tag, wait type, user, client IP, and database.
- Normalized queries: literals become
?so the same shape aggregates into one row. - No extra cost for the feature itself.
Personalized Service Health
Personalized Service Health is your project-scoped window into Google Cloud's own reliability. Where the public Service Health dashboard lists every global incident, Personalized Service Health applies a relevance filter - matching an incident's impacted products and locations against what you actually run - so you only see disruptions that touch your resources. Each event carries its state, start/end times, impacted products and locations, and running updates, and it reaches you through four surfaces: the console dashboard, the Service Health API, Cloud Logging, and alerts wired through Cloud Monitoring.
- Four surfaces: console dashboard, Service Health API, Cloud Logging entries, and alerting via Cloud Monitoring.
- Relevance: filters incidents by the products and locations your project uses.
- Event fields: state, start/end time, impacted products, impacted locations, and updates.
- Also surfaces in Cloud Hub alongside your application views.
The public Google Cloud Service Health page shows global incidents. Personalized Service Health filters to incidents relevant to your projects and products - the answer when the question stresses "affecting our workloads."