Skip to main content

Google Cloud Monitoring

Reading time: 0 minute(s) (0 words)

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.

Google Cloud Monitoring parameters and supported features in Nobl9
General support:
Release channel: Stable, Beta
Connection method: Agent, Direct
Replay and SLI Analyzer: Supported
Event logs: Supported
Query checker: Not supported
Query parameters retrieval: Supported
Timestamp cache persistence: Supported
Query parameters:
Query interval: 1 min
Query delay: 2 min
Jitter: 15 sec
Timeout: 50 sec
Agent details and minimum required versions for supported features:
Environment variable: GCM_QUERY_DELAY
Plugin name: n9gcm
Replay and SLI Analyzer: 0.79.0-beta
Maximum historical data retrieval period: 30 days
Query parameters retrieval: 0.73.2
Timestamp cache persistence: 0.65.0
Additional notes:
Support for PromQL queries (beta) in Nobl9 agent version 0.83.0-beta or higher
Support for Google Cloud Monitoring metrics
Learn more Opens in a new tab

Authentication​

Google Cloud Monitoring authorization requires user credentials. You can retrieve these credentials from the Google Cloud Platform (GCP) in the form of a Service account key file.

Learn more about authentication in Google Cloud.

Provide your Service account key when connecting GCM using the direct method. This ensures direct integration with the GCM APIs to retrieve the data, leveraging the SaaS-to-SaaS infrastructure in Nobl9.

  • On the Nobl9 Web, drag&drop the required file into the Service Account Key File field.
  • When you use sloctl, pass your credentials as the value for the gcm.serviceAccountKey field.
note

Your user account must have access to one of the following OAuth scopes:

Adding Google Cloud Monitoring as a data source​

To ensure data transmission between Nobl9 and Google Cloud Monitoring, it may be necessary to list Nobl9 IP addresses as trusted.

💻ip allowlist
IP addresses to include in your allowlist for secure access:

If you're using app.nobl9.com instance:
  • 18.159.114.21
  • 18.158.132.186
  • 3.64.154.26
If you're using us1.nobl9.com instance:
  • 34.121.54.120
  • 34.123.193.191
  • 34.134.71.10
  • 35.192.105.150
  • 35.225.248.37
  • 35.226.78.175
  • 104.198.44.161

You can add the Google Cloud Monitoring data source using the direct or agent connection methods.

Direct connection method​

A direct connection to Google Cloud Monitoring requires users to enter their credentials which Nobl9 stores safely.

Nobl9 Web​

To set up this type of connection:

  1. Navigate to Integrations > Sources.
  2. Click .
  3. Click the required Source button.
  4. Choose Direct.
  1. Select one of the following Release Channels:
    • The stable channel is fully tested by the Nobl9 team. It represents the final product; however, this channel does not contain all the new features of a beta release. Use it to avoid crashes and other limitations.
    • The beta channel is under active development. Here, you can check out new features and improvements without the risk of affecting any viable SLOs. Remember that features in this channel can change.

  2. 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.

  1. Select a Project.
    Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses the default project.
  2. Enter a Display Name.
    You can enter a user-friendly name with spaces in this field.
  3. Enter a Name.
    The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example, my-project-1). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result.
  4. Enter a Description.
    Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it.
  5. Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
    • The default value in Google Cloud Monitoring integration for Query delay is 2 minutes.
    info
    Changing the Query delay may affect your SLI data. For more details, check the Query delay documentation.
  6. Enter a Maximum Period for Historical Data Retrieval.
    • This value defines how far back in the past your data will be retrieved when replaying your SLO based on this data source.
    • The maximum period value depends on the data source.
      Find the maximum value for your data source.
    • A greater period can extend the loading time when creating an SLO.
      • The value must be a positive integer.
  7. Enter a Default Period for Historical Data Retrieval.
    • It is used by SLOs connected to this data source.
    • The value must be a positive integer or 0.
    • By default, this value is set to 0. When you set it to >0, you will create SLOs with Replay.
  8. Click Add Data Source.

sloctl​

The YAML for setting up a direct connection to Google Cloud Monitoring looks like this:

Sample YAML definition for the direct connection
apiVersion: n9/v1alpha
kind: Direct
metadata:
  name: google-cloud-monitoring-data-source
  displayName: Google Cloud Monitoring direct connection
  project: default
spec:
  description: Example Google Cloud Monitoring direct connection method
  releaseChannel: beta
  gcm:
    serviceAccountKey: |-
      {
       # copy and paste your credentials from the credentials.json file
      }
  historicalDataRetrieval:
    maxDuration:
      value: 30
      unit: Day
    defaultDuration:
      value: 15
      unit: Day
  queryDelay:
    value: 3
    unit: Minute
FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies the unit for the query delay. Possible values: Second | Minute.
• Check query delay documentation for default unit of query delay for each source.
queryDelay.value
mandatory
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default unit of query delay for each source.
logCollectionEnabled
optional
booleanOptional. Defaults to false. Set to true if you'd like your direct to collect event logs. Contact us to activate it.
releaseChannel
mandatory
enumSpecifies the release channel. Accepted values: beta | stable.
Source-specific fields
gcm.serviceAccountKey
mandatory
stringCopy and paste your credentials from the `credentials.json` file. See authentication for more details.
Replay-related fields
historicalDataRetrieval
optional
n/aOptional structure related to configuration related to Replay.
❗ Use only with supported sources.
• If omitted, Nobl9 uses the default values of value: 0 and unit: Day for maxDuration and defaultDuration.
maxDuration.value
optional
numericSpecifies the maximum duration for historical data retrieval. Must be integer ≥ 0. See Replay documentation for values of max duration per data source.
maxDuration.unit
optional
enumSpecifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day.
defaultDuration.value
optional
numericSpecifies the default duration for historical data retrieval. Must be integer ≥ 0 and ≤ maxDuration.
defaultDuration.unit
optional
enumSpecifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day.

Agent connection method​

Nobl9 Web​

Follow the instructions below to set up an agent connection.

  1. Navigate to Integrations > Sources.
  2. Click .
  3. Click the required Source button.
  4. Choose Agent.
  1. Select one of the following Release Channels:
    • The stable channel is fully tested by the Nobl9 team. It represents the final product; however, this channel does not contain all the new features of a beta release. Use it to avoid crashes and other limitations.
    • The beta channel is under active development. Here, you can check out new features and improvements without the risk of affecting any viable SLOs. Remember that features in this channel can change.
  1. Select a Project.
    Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses the default project.
  2. Enter a Display Name.
    You can enter a user-friendly name with spaces in this field.
  3. Enter a Name.
    The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example, my-project-1). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result.
  4. Enter a Description.
    Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it.
  5. Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
    • The default value in Google Cloud Monitoring integration for Query delay is 2 minutes.
    info
    Changing the Query delay may affect your SLI data. For more details, check the Query delay documentation.
  6. Enter a Maximum Period for Historical Data Retrieval.
    • This value defines how far back in the past your data will be retrieved when replaying your SLO based on this data source.
    • The maximum period value depends on the data source.
      Find the maximum value for your data source.
    • A greater period can extend the loading time when creating an SLO.
      • The value must be a positive integer.
  7. Enter a Default Period for Historical Data Retrieval.
    • It is used by SLOs connected to this data source.
    • The value must be a positive integer or 0.
    • By default, this value is set to 0. When you set it to >0, you will create SLOs with Replay.
  8. Click Add Data Source.

sloctl​

The YAML for setting up an agent connection to Google Cloud Monitoring looks like this:

Sample YAML definition for the agent connection
apiVersion: n9/v1alpha
kind: Agent
metadata:
  name: google-cloud-monitoring-data-source
  displayName: Google Cloud Monitoring agent connection
  project: default
spec:
  description: Example Google Cloud Monitoring agent connection method
  releaseChannel: beta
  gcm: {}
  historicalDataRetrieval:
    maxDuration:
      value: 30
      unit: Day
    defaultDuration:
      value: 15
      unit: Day
  queryDelay:
    value: 3
    unit: Minute
FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies the unit for the query delay. Possible values: Second | Minute.
• Check query delay documentation for default unit of query delay for each source.
queryDelay.value
mandatory
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default unit of query delay for each source.
releaseChannel
mandatory
enumSpecifies the release channel. Accepted values: beta | stable.
warning

You can deploy only one agent in one YAML file by using the sloctl apply command.

Agent deployment​

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.

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:

Sample Kubernetes configuration for agent deployment
# 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-gcm-data-source
  namespace: my-namespace
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-gcm-data-source
  namespace: my-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      nobl9-agent-name: gcm-data-source
      nobl9-agent-project: my-project
  template:
    metadata:
      labels:
        nobl9-agent-name: gcm-data-source
        nobl9-agent-project: my-project
    spec:
      containers:
        - name: agent-container
          image: nobl9/agent:0.82.2
          resources:
            requests:
              memory: "350Mi"
              cpu: "0.1"
          env:
            - name: N9_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  key: client_id
                  name: nobl9-agent-nobl9-gcm-data-source
            - name: N9_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  key: client_secret
                  name: nobl9-agent-nobl9-gcm-data-source
            # The N9_METRICS_PORT is a variable specifying the port to which the /metrics and /health endpoints are exposed.
            # The 9090 is the default value and can be changed.
            # If you don’t want the metrics to be exposed, comment out or delete the N9_METRICS_PORT variable.
            - name: N9_METRICS_PORT
              value: "9090"
            # To use Workload Identity in Kubernetes Cluster in Google Cloud Platform,
            # comment out or delete the GOOGLE_APPLICATION_CREDENTIALS environment variable
            # and follow the instructions described here https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
            - 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-gcm-data-source

Creating SLOs with Google Cloud Monitoring​

Nobl9 Web​

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

  1. Navigate to Service Level Objectives.

  2. Click .

  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).

    1. Choose the Data Count Method for your ratio metric:
      • Non-incremental: counts incoming metric values one-by-one. So the resulting SLO graph is pike-shaped.
      • Incremental: counts the incoming metric values incrementally, adding every next value to previous values. It results in a constantly increasing SLO graph.

  7. Specify Query or a Good Query and Total Query for the metric you selected.

    • Each query must return only one metric and one time series.
    • Since Nobl9 asks for data every 1 minute, we recommend setting the period for the align delta function to 1 minute, i.e. align delta(1m).
      As a result, Nobl9 receives the difference in a given minute and records it as an SLI.
    • Nobl9 processes a single dataset at a time and doesn't aggregate GCM metrics.
      Make sure your group_by aggregator points to the single dataset—exactly that one you want to observe.
      You can find the available groups on your Google Cloud Observability Monitoring dashboard > Metrics explorer.
Monitoring Query Language

MQL is no longer recommended by Google as a query language for Cloud Monitoring. Following this, MQL is deprecated in Nobl9 as well. PromQL is a recommended replacement.

PromQL in GCM is supported by Nobl9 agent version is 0.83.0-beta or higher.

You can refer to the PromQL Cheat Sheet if needed.

PromQL query examples

Threshold query:
"sum(rate(serviceruntime_googleapis_com:api_request_latencies_sum{monitored_resource=\"consumed_api\",service=\"bigquery.googleapis.com\"}[1m]))/sum(rate(serviceruntime_googleapis_com:api_request_latencies_count{monitored_resource=\"consumed_api\",service=\"bigquery.googleapis.com\"}[1m]))"

Ratio query:
Good counter "sum(rate(serviceruntime_googleapis_com:api_request_count{monitored_resource=\"consumed_api\",response_code=\"200\",service=\"monitoring.googleapis.com\"}[1m]))"
Total counter "sum(rate(serviceruntime_googleapis_com:api_request_count{monitored_resource=\"consumed_api\",service=\"monitoring.googleapis.com\"}[1m]))"

SLI values for good and total
When choosing the query for the ratio SLI (countMetrics), keep in mind that the values ​​resulting from that query for both good and total:
  • Must be positive.
  • While we recommend using integers, fractions are also acceptable.
    • If using fractions, we recommend them to be larger than 1e-4 = 0.0001.
  • Shouldn't be larger than 1e+20.
  1. In step 3 of the SLO wizard, define a Time Window for the SLO.

  • Rolling time windows are better for tracking the recent user experience of a service.

  • Calendar-aligned windows are best suited for SLOs that are intended to map to business metrics measured on a calendar-aligned basis, such as every calendar month or every quarter.

  1. In step 4, specify the Error Budget Calculation Method and your Objective(s).
  • Occurrences method counts good attempts against the count of total attempts.
  • Time Slicesmethod measures how many good minutes were achieved (when a system operates within defined boundaries) during a time window.
  • You can define up to 12 objectives for an SLO.

See the use case example and the SLO calculations guide for more information on the error budget calculation methods.

  1. In step 5, add the Display name, Name, and other settings for your SLO:
  • Create a composite SLO
  • Set notification on data, if this option is available for your data source.
    When activated, Nobl9 notifies you if your SLO hasn't received data or received incomplete data for more than 15 minutes.
  • Add alert policies, labels, and links, if required.
    You can add up to 20 links per SLO.
  1. Click Create SLO.

sloctl​

Monitoring Query Language

MQL is no longer recommended by Google as a query language for Cloud Monitoring. Following this, MQL is deprecated in Nobl9 as well. PromQL is a recommended replacement.

PromQL in GCM is supported by Nobl9 agent version is 0.83.0-beta or higher.

You can refer to the PromQL Cheat Sheet if needed.

Monitoring Query Language is deprecated. We recommend using PromQL to write queries for Google Cloud Monitoring.

Here’s an example of Google Cloud Monitoring rawMetric (threshold metric) SLO:

Sample GCM rawMetric SLO YAML definition with the MQL query (deprecated)
# Metric type: threshold
# Budgeting method: Occurrences
# Time window type: Calendar
- apiVersion: n9/v1alpha
  kind: SLO
  metadata:
    name: api-server-slo
    # Optional
    #displayName: API Server SLO
    project: default
    # Optional
    #labels:
    #  area:
    #  - latency
    #  - slow-check
    #  team:
    #  - green
    #  - sales
    # Optional
    #annotations:
    #  area: latency
    #  team: sales
  spec:
    # Optional
    #description: Example Google Cloud Monitoring SLO
    indicator:
      metricSource:
        name: google-cloud-monitoring
        project: default
        kind: Agent
    budgetingMethod: Occurrences
    objectives:
      - displayName: Good response (200)
        value: 200.0
        name: ok
        target: 0.95
        rawMetric:
          query:
            gcm:
              query: |-
                fetch api-server
                | metric 'serviceruntime.googleapis.com/api/request_latencies'
                | filter (resource.service == 'monitoring.googleapis.com')
                | align delta(1m)
                | every 1m
                | group_by [resource.service],
                    [value_request_latencies_mean: mean(value.request_latencies)]
              projectId: my-project-id
        op: lte
        primary: true
    service: api-server
    timeWindows:
      - unit: Month
        count: 1
        isRolling: false
        calendar:
          startTime: 2022-12-01 00:00:00
          timeZone: UTC
    # Optional
    #alertPolicies:
    #- fast-burn-5x-for-last-10m
    # Optional
    #attachments:
    #- url: https://docs.nobl9.com
    #  displayName: Nobl9 Documentation
    # Optional
    #anomalyConfig:
    #  noData:
    #    alertMethods:
    #    - name: slack-notification
    #      project: default

Expected query output​

Nobl9 accepts single time series only. Therefore, at each point in the time series, the GCM query must return a single value.
When your query includes multiple tables, for example, using ident, make sure it returns a single value.
You can test your query result with the projects.timeSeries.query method

Sample expected query output returning a single value
{
  "timeSeriesDescriptor": {
    "pointDescriptors": [
      {
        "key": "good_total_ratio",
        "valueType": "DOUBLE",
        "metricKind": "GAUGE",
        "unit": "1"
      }
    ]
  },
  "timeSeriesData": [
    {
      "pointData": [
        {
          "values": [
            {
              "doubleValue": 0.9877300613496932
            }
          ],
          "timeInterval": {
            "startTime": "2024-06-06T08:00:03.532075Z",
            "endTime": "2024-06-06T08:00:03.532075Z"
          }
        }
      ]
    }
  ]
}

Querying the Google Cloud Monitoring server​

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.

For a more in-depth look, consult additional resources:
Getting started with authenticationGoogle Cloud docsCreating and managing projectsGoogle Cloud docsMonitoring Query Language referenceGoogle Cloud docsprojects.timeSeries.queryGoogle Cloud docsAgent metricsAgentCreating SLOs via TerraformTerraformCreating agents via TerraformTerraform
Last updated on
On this page