Skip to main content

Google Cloud Monitoring

Google Cloud Monitoring (GCM) provides visibility into the performance, uptime, and overall health of cloud-powered applications. It collects metrics, events, and metadata from Google Cloud, hosted uptime probes, and application instrumentation.

Authentication

Google Cloud Monitoring authentication requires the user’s credentials to be entered in Nobl9. Users can retrieve their authentication credentials from the Google Cloud Platform (GCP) in the form of a Service account key file. For details on how to get your Service account key file, refer to the Getting Started with Authentication | Google Cloud Documentation.

For a Direct connection to GCM, the contents of the downloaded Service account key file must be uploaded into the Nobl9 UI. This enables direct integration with the GCM APIs to retrieve the data, leveraging the SaaS-to-SaaS infrastructure in Nobl9.

For an Agent connection, you need to copy and paste your credentials from your credentials.json file and pass those when invoking the Agent. Nobl9 Agent can use Workload Identity in GCP (Google Cloud Platform) in GKE (Google Kubernetes Engine). For more information, refer to the Deploying the Google Cloud Monitoring Agent section.

Adding Google Cloud Monitoring as a Data Source in the UI

To add Google Cloud Monitoring as a data source in Nobl9 using the Agent or Direct connection method, follow these steps:

  1. Navigate to Integrations > Sources.

  2. Click the plus button button.

  3. Click the Google Cloud Monitoring icon.

  4. Choose Direct or Agent, then configure the source as described below.

Google Cloud Monitoring Direct

Direct Configuration in the UI

A Direct connection to Google Cloud Monitoring requires users to enter their credentials which Nobl9 stores safely. To set up this type of connection:

  1. Upload your Service Account Key File to authenticate with GCP (mandatory). Retrieve your authentication credentials from the Google Cloud Platform. The file must be in JSON format. For more information, refer to the Getting Started with Authentication | Google Cloud Documentation or the Authentication section above.

  2. Select a Project (mandatory).
    Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, a default value appears.

  3. Enter a Display name (optional).
    You can enter a friendly name with spaces in this field.

  4. Enter a Name (mandatory).
    The name is mandatory and can only contain lowercase, alphanumeric characters and dashes (for example, my-project-name). This field is populated automatically when you enter a display name, but you can edit the result.

  5. Enter a Description (optional).
    Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it.

  6. Click the Add Data Source button.

Google Cloud Monitoring Agent

Agent Configuration in the UI

Follow the instructions below to set up an Agent connection. Refer to the previous section for the descriptions of the fields.

  1. Select a Project (mandatory).

  2. Enter a Display name (optional).

  3. Enter a Name (mandatory).

  4. Enter a Description (optional).

  5. Click the Add Data Source button.

Deploying the Google Cloud Monitoring Agent

When you add the data source, Nobl9 automatically generates a Kubernetes configuration and a Docker command line for you to use to deploy the Agent. Both of these are available in the web UI, under the Agent Configuration section. Be sure to swap in your credentials.

warning

Nobl9 Agent can use Workload Identity in GCP (Google Cloud Platform) in GKE (Google Kubernetes Engine). As such, the N9_GCP_CREDENTIALS_PATH environment variable has been changed to GOOGLE_APPLICATION_CREDENTIALS. For more information, refer to the Getting started with authentication | Google Cloud Documentation.

note

If you want to use Workload Identity in Kubernetes Cluster in Google Cloud Platform, comment out or delete the GOOGLE_APPLICATION_CREDENTIALS environment variable in the code block below and follow the instructions described in the Use Workload Identity | Google Cloud Documentation.

If you use Kubernetes, you can apply the supplied YAML config file to a Kubernetes cluster to deploy the Agent. Remember to swap in your credentials, for example, copy and paste your credentials from the ServiceAccount Key credentials.json file. It will look something like this:

# DISCLAIMER: This deployment description contains only the fields necessary for the purpose of this demo.
# It is not a ready-to-apply k8s deployment description, and the client_id and client_secret are only exemplary values.

apiVersion: v1
kind: Secret
metadata:
name: nobl9-agent-nobl9-dev-gcm-gcm
namespace: default
type: Opaque
stringData:
client_id: #client_id
client_secret: #client_secret
data:
credentials.json: |-
# <CREDENTIALS>
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nobl9-agent-nobl9-dogfood-default-gcm-test
namespace: default
spec:
replicas: 1
selector:
matchLabels:
nobl9-agent-name: gcm-test
nobl9-agent-project: default
template:
metadata:
labels:
nobl9-agent-name: gcm-test
nobl9-agent-project: default
spec:
containers:
- name: agent-container
image: nobl9/agent:0.48.0
resources:
requests:
memory: "350Mi"
cpu: "0.1"
env:
- name: N9_CLIENT_ID
valueFrom:
secretKeyRef:
key: client_id
name: nobl9-agent-nobl9-dogfood-default-gcm-test
- name: N9_CLIENT_SECRET
valueFrom:
secretKeyRef:
key: client_secret
name: nobl9-agent-nobl9-dogfood-default-gcm-test
- name: N9_AUTH_SERVER
value: "n9_auth_server_credentials"
- name: N9_OKTA_ORG_URL
value: "https://accounts.nobl9.com"
- name: GOOGLE_APPLICATION_CREDENTIALS
value: "/var/gcp/credentials.json"
# N9_ALLOWED_URLS is an optional safety parameter that limits the URLs that an Agent is able to query
# for metrics. URLs defined in the Nobl9 app are prefix-compared against the N9_ALLOWED_URLS list of
# comma separated URLs.
# - name: N9_ALLOWED_URLS
# value: "http://172.16.0.2/api/v1/query,http://172.16.0.3"
volumeMounts:
- name: gcp-credentials
mountPath: "/var/gcp"
readOnly: true
volumes:
- name: gcp-credentials
secret:
secretName: nobl9-agent-nobl9-dogfood-default-gcm-test

Creating SLOs with Google Cloud Monitoring

Creating SLO in the UI

Follow the instructions below to create your SLOs with Google Cloud Monitoring in the Nobl9 UI:

  1. Navigate to Service Level Objectives.

  2. Click the plus button button.

  3. In step 1 of the SLO wizard, select the Service the SLO will be associated with.

  4. In step 2, select Google Cloud Monitoring as the Data Source for your SLO.

  5. Enter a Project ID.

  6. Specify the Metric. You can choose either a Threshold Metric, where a single time series is evaluated against a threshold or a Ratio Metric, which allows you to enter two time series to compare (for example, a count of good requests and total requests).

  7. Use the Monitoring Query Language (MQL) to enter a Query or a Good Query and Total Query for the metric you selected. For more details on MQL, refer to the Monitoring Query Language reference | Google Cloud Documentation.

    • Each query must return only one metric and one time series.

    • The recommended period for the align_delta function is 1 minute.

    • The group_by aggregator must point to the exact dataset you want to be observed.

      • Since Nobl9 can only process a single dataset and there is no aggregation on the Nobl9 side, make sure the default group_by aggregator points to a single entity. You can always view the resulting groups below the charts in the Metrics explorer view, in the Google Cloud Platform UI.
    • The following is an example query:

      "fetch consumed_api
      | metric 'serviceruntime.googleapis.com/api/request_latencies'
      | filter (resource.service == 'bigquery.googleapis.com')
      | align delta(1m)
      | every 1m
      | group_by [resource.service],
      [value_request_latencies_mean: mean(value.request_latencies)]"
  8. In step 3 of the SLO wizard, define a Time Window for the SLO.

  9. In step 4, specify the Error Budget Calculation Method and your Objective(s).

  10. In step 5, add a Name, Description, and other details about your SLO. You can also select Alert Policies and Labels on this screen.

  11. When you’re done, click Create SLO.

SLOs using Google Cloud Monitoring - YAML samples

Here’s an example of Google Cloud Monitoring using rawMetric (Threshold Metric):

apiVersion: n9/v1alpha
kind: SLO
metadata:
name: bigquery-googleapis-latency-mean-threshold
project: gcm
spec:
service: gcm-service
indicator:
metricSource:
name: gcm
project: gcm
rawMetric:
gcm:
projectId: bdwtest-256112
query: "fetch consumed_api
| metric 'serviceruntime.googleapis.com/api/request_latencies'
| filter (resource.service == 'bigquery.googleapis.com')
| align delta(1m)
| every 1m
| group_by [resource.service],
[value_request_latencies_mean: mean(value.request_latencies)]"
timeWindows:
- unit: Day
count: 1
calendar:
startTime: 2022-01-21 12:30:00 # date with time in 24h format
timeZone: America/New_York # name as in IANA Time Zone Database
budgetingMethod: Occurrences
objectives:
- displayName: Healthy
value: 40
op: lte
target: 0.99
- displayName: Slower
value: 41
op: gte
target: 0.98
- displayName: Critical
value: 100
op: gte
target: 0.95

Querying the Google Cloud Monitoring Server

Nobl9 queries the Google Cloud Monitoring server using the projects.timeSeries.query API every 60 seconds. The number of data points returned is dependent on the amount of data Google Cloud Monitoring can return.

Google Cloud Monitoring API Rate Limits

To verify the limits to API usage, go to the Quotas dashboard in the GCM UI. For an API, click the All Quotas button to see your quota.

Getting Started with Authentication | Google Cloud Documentation

Creating and Managing Projects | Google Cloud Documentation

Monitoring Query Language reference | Google Cloud Documentation

projects.timeSeries.query | Google Cloud Documentation