Google Cloud Monitoring Essentials

Welcome to the next step in your GCP developer journey! So far, you have learned how to keep your applications secure by managing credentials and protecting your APIs. Now, we will focus on another critical aspect: monitoring your applications.

Monitoring is essential for both security and reliability. It helps you answer questions like:

• Is my application working as expected?
• Are there any unusual patterns or errors?
• How is my application performing over time?

Google Cloud Monitoring (formerly Stackdriver) is a service that helps you collect, view, and analyze data from your applications. In this lesson, you will learn how to send your own custom data (called metrics) to Cloud Monitoring using OpenTelemetry, an industry-standard observability framework. You'll also learn how to create dashboards to visualize this information. By the end, you will be able to track important numbers from your application and see them in real time.

Before we dive in, let's quickly remind ourselves about Google Cloud client libraries. In previous lessons, you used GCP client libraries to interact with services like Secret Manager and Cloud Functions. These are the official Google Cloud SDKs for Python, and they allow you to connect to GCP services directly from your code.

For monitoring specifically, you can use the official google-cloud-monitoring library:

from google.cloud import monitoring_v3

# Create a client for Google Cloud Monitoring
client = monitoring_v3.MetricServiceClient()

However, in this lesson, we'll use OpenTelemetry to send metrics. OpenTelemetry is a vendor-neutral standard for observability that works with many cloud platforms, including GCP. It provides a cleaner API and makes your code more portable.

OpenTelemetry is an open-source framework that provides a standardized way to collect metrics, logs, and traces from your applications. Instead of using vendor-specific APIs, you write code once using OpenTelemetry, and it can send data to various backends, including Google Cloud Monitoring.

Benefits of using OpenTelemetry:

• Vendor-neutral: Your code isn't locked to a specific cloud provider
• Cleaner API: Simpler, more intuitive code
• Industry standard: Widely adopted across the industry

Let's visualize how the pieces fit together:

┌─────────────────────┐
│  Python Application │
│   (Your Code)       │
└──────────┬──────────┘
           │
           │ OpenTelemetry API
           │ meter.create_histogram()
           ↓
┌─────────────────────┐
│   OpenTelemetry     │
│   SDK + Exporter    │
└──────────┬──────────┘
           │
           │ Exports to
           ↓
┌─────────────────────┐
│ Google Cloud        │
│ Monitoring          │
│ (Stores Metrics)    │
└──────────┬──────────┘
           │
           │ Visualizes
           ↓
┌─────────────────────┐
│  Cloud Monitoring   │
│  Dashboard          │
└─────────────────────┘

This diagram shows the complete flow:

1. Your Python application uses the OpenTelemetry API to create and record metrics
2. The OpenTelemetry SDK processes these metrics and exports them
3. Cloud Monitoring receives and stores the metrics
4. A dashboard displays the metrics visually for monitoring

Note: In this practice environment, we use the OTLP (OpenTelemetry Protocol) exporter which sends metrics to a local collector. This collector then forwards metrics to Cloud Monitoring. In production GCP environments, you can use either OTLP or the direct Cloud Monitoring exporter. Both approaches are industry-standard and widely used.

Now let's implement this flow step by step.

Before we can emit metrics, we need to set up OpenTelemetry to work with Google Cloud Monitoring.

First, import the libraries you will use:

import time
import random
from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.resources import Resource

• opentelemetry.metrics provides the core metrics API
• MeterProvider manages the creation of meters (which create metrics)
• PeriodicExportingMetricReader sends metrics to Cloud Monitoring at regular intervals
• OTLPMetricExporter exports metrics using the OpenTelemetry Protocol
• Resource helps identify what is emitting the metrics

Next, configure OpenTelemetry to send metrics to Cloud Monitoring:

# Create a resource to identify your service
resource = Resource.create({"service.name": "OrdersAPI"})

# Create the OTLP exporter (for local development)
exporter = OTLPMetricExporter(endpoint="http://localhost:4317", insecure=True)

# Create a metric reader that exports every 10 seconds
reader = PeriodicExportingMetricReader(exporter, export_interval_millis=10000)

# Create and set the meter provider
provider = MeterProvider(resource=resource, metric_readers=[reader])
metrics.set_meter_provider(provider)

# Get a meter for creating instruments
meter = metrics.get_meter("app.monitoring")

Let's break down what's happening:

• Resource identifies your service with the label "service.name": "OrdersAPI"
• OTLPMetricExporter configures the OTLP endpoint to send metrics to (in this environment, a local collector that forwards to GCP)
• PeriodicExportingMetricReader automatically exports metrics every 10 seconds
• MeterProvider combines everything and manages the metrics lifecycle
• meter is used to create specific metric instruments

A metric is just a number that tells you something about your application. OpenTelemetry provides different types of metric instruments. For tracking order values, we'll use a Histogram, which is perfect for recording measurements like amounts, durations, or sizes.

Let's create a histogram to track order values:

# Create a histogram for order values
order_value_histogram = meter.create_histogram(
    name="order_value",
    description="Value of customer orders",
    unit="USD"
)

This creates a histogram instrument named "order_value" that will track the distribution of order values in USD.

Now let's record some order values. With OpenTelemetry, recording a value is very simple:

# Record metric values
for i in range(5):
    value = random.uniform(10, 200)
    order_value_histogram.record(value)
    print(f"Recorded metric: OrderValue = {value:.2f}")
    time.sleep(0.5)

# Give the exporter time to send the final batch
time.sleep(10)

Example output:

Recorded metric: OrderValue = 153.27
Recorded metric: OrderValue = 45.12
Recorded metric: OrderValue = 189.03
Recorded metric: OrderValue = 77.56
Recorded metric: OrderValue = 120.44

Notice how much simpler this is compared to manually creating time series! OpenTelemetry handles:

• Timestamps automatically
• Batching multiple measurements
• Exporting at regular intervals
• Resource attribution

The final time.sleep(10) ensures the last batch of metrics is exported before the program ends (since we export every 10 seconds).

A dashboard in Cloud Monitoring is a visual display of your metrics. It helps you see trends and spot problems quickly. For this task, you would use the official Google Cloud Monitoring library in a production environment.

In production GCP, you would create a dashboard to visualize the metrics you're sending through OpenTelemetry. Here's how that would look:

from google.cloud.monitoring_dashboard import v1

def create_dashboard(project_id):
    """Create Cloud Monitoring dashboard to visualize metrics"""
    dashboard_client = v1.DashboardsServiceClient()
    project_name = f"projects/{project_id}"
    
    dashboard = v1.Dashboard(
        display_name="App-Overview",
        grid_layout=v1.GridLayout(
            widgets=[
                v1.Widget(
                    title="Order Value Distribution",
                    xy_chart=v1.XyChart(
                        data_sets=[
                            v1.XyChart.DataSet(
                                time_series_query=v1.TimeSeriesQuery(
                                    time_series_filter=v1.TimeSeriesFilter(
                                        filter='metric.type="workload.googleapis.com/order_value" AND resource.labels.service_name="OrdersAPI"',
                                        aggregation=v1.Aggregation(
                                            alignment_period={"seconds": 300},
                                            per_series_aligner=v1.Aggregation.Aligner.ALIGN_MEAN,
                                        ),
                                    )
                                )
                            )
                        ]
                    )
                )
            ]
        )
    )
    
    dashboard_client.create_dashboard(
        parent=project_name,
        dashboard=dashboard
    )
    print("Dashboard 'App-Overview' created successfully!")

Here's what's happening:

• We define a Widget that tells Cloud Monitoring what to display
• The widget shows the average value of the order_value metric
• When using the OTLP exporter (as in this lesson), metrics use the prefix workload.googleapis.com/
• When using the direct Cloud Monitoring exporter, metrics use the prefix custom.googleapis.com/
• The filter selects metrics from the OrdersAPI service using the resource label we set earlier
• The aggregation computes the average over 5-minute windows (300 seconds)
• The dashboard is named "App-Overview"

Important Note on Resource Types and Labels: The filter syntax shown above (resource.labels.service_name) is simplified for illustration. In a real GCP environment, you'll need to adjust the filter based on your actual resource type and available labels. For example:

• If running on Cloud Run: resource.type="cloud_run_revision" with labels like resource.labels.service_name
• If running on GCE: resource.type="gce_instance" with labels like resource.labels.instance_id
• If running on GKE: resource.type="k8s_container" with labels like resource.labels.namespace_name

You can discover the correct resource type and available labels by viewing your metrics in the Cloud Console's Metrics Explorer, which shows the exact filter syntax for your environment.

Note: This dashboard creation code is shown for educational purposes. In this practice environment, you'll focus on emitting metrics. The dashboards can be created through the Cloud Console or using the above code in a production GCP environment.

Here's the complete code that brings everything together:

import time
import random
from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.resources import Resource

# Create a resource to identify your service
resource = Resource.create({"service.name": "OrdersAPI"})

# Create the OTLP exporter (for local development)
exporter = OTLPMetricExporter(endpoint="http://localhost:4317", insecure=True)

# Create a metric reader that exports every 10 seconds
reader = PeriodicExportingMetricReader(exporter, export_interval_millis=10000)

# Create and set the meter provider
provider = MeterProvider(resource=resource, metric_readers=[reader])
metrics.set_meter_provider(provider)

# Get a meter for creating instruments
meter = metrics.get_meter("app.monitoring")

# Create a histogram for order values
order_value_histogram = meter.create_histogram(
    name="order_value",
    description="Value of customer orders",
    unit="USD"
)

# Record metric values
for i in range(5):
    value = random.uniform(10, 200)
    order_value_histogram.record(value)
    print(f"Recorded metric: OrderValue = {value:.2f}")
    time.sleep(0.5)

# Give the exporter time to send the final batch
time.sleep(10)

This code will emit 5 order value metrics and export them to Cloud Monitoring through the OTLP collector.

In this lesson, you learned how to:

• Use OpenTelemetry, an industry-standard observability framework, to emit custom metrics from your application
• Configure OpenTelemetry to export metrics using OTLP (OpenTelemetry Protocol)
• Create metric instruments (histograms) to track application data
• Understand how dashboards can be created in Cloud Monitoring to visualize your metrics in real time

These skills help you keep an eye on your application's health and performance, which is important for both security and reliability. Using OpenTelemetry makes your monitoring code cleaner and more portable across different cloud platforms.

Next, you will get hands-on practice by emitting your own metrics with OpenTelemetry in the CodeSignal environment. Remember, the required libraries are already installed, so you can focus on writing and running your code.

Great job making it this far! You are now ready to monitor your own GCP applications using modern, industry-standard tools.