NXLog Docs

Google Cloud Logging (om_googlelogging)

Google Cloud Logging is a managed service that stores and analyzes log data from applications hosted on Google Cloud and Amazon Web Services.

The Google Cloud Logging API enables you to write logs to Cloud Logging. This module uses the REST version of the API to send events in batches, reducing HTTP response latency, thus improving data throughput.

To examine the supported platforms, see the list of installer packages in the Available Modules chapter.

Configuring a Google Cloud service account

om_googlelogging requires a Google Cloud service account and a corresponding private key file in JSON format to connect to the Cloud Logging API. Follow these instructions to create a new service account and download its private key file for an existing project.

  1. Log in to your Google Cloud account and switch to the project you want to configure.

  2. From the navigation menu, click on IAM & Admin > Service Accounts.

    IAM & Admin menu

  4. Enter a service account name and description and click CREATE AND CONTINUE.

    Create service account
  5. Select the Owner role from the Role drop-down and click DONE.

    Service account role
  6. Click on the newly created account on the Service accounts page to open its configuration page.

  7. Click the KEYS tab, expand the ADD KEY drop-down and select Create new key.

    Create new service key
  8. Select JSON for the key type and click CREATE to download the private key. Save the private key file to a location accessible by NXLog. This file is required for the NXLog configuration.

    New service key type

Output log format

om_googlelogging forwards the value of the $raw_event field to Google Cloud Logging as JSON payload if it is a valid JSON object. Otherwise, it sends it as text payload. If a $Severity field is present, it will use its value to assign a LogSeverity to the record. If not, it will set the severity to DEFAULT. The table below lists the possible severity values. All values are case-insensitive.

Severity Alternative values



















Alternative values will be translated to the severity value on the left.

Individual JSON log records have the following structure:

    "jsonPayload": { }, // Value of $raw_event
    "severity": "<severity>",
    "timestamp": "<EventReceivedTime>"

Records will have the following structure if the value of $raw_event is not a valid JSON object:

    "textPayload": " ", // Value of $raw_event
    "severity": "<severity>",
    "timestamp": "<EventReceivedTime>"

The complete request body has the following structure:

    "logName": "<LogName>",
    "labels": {
        "<key>": "<value>"
    "resource": {
        "type": "<type>"
    "entries" : [
            "textPayload": "<raw_event>",
            "severity": "<Severity>",
            "timestamp": "<EventReceivedTime>"

See Method: entries.write in the Google Cloud Logging API reference for more information.


The om_googlelogging module accepts the following directives in addition to the common module directives. The CredentialsFile, LogName, and Resources directives are required.


This mandatory directive specifies the path to the private key file of the service account required for authenticating with the Cloud Logging API. See Configuring a Google Cloud service account for more information.


This mandatory directive specifies the name of the log source on Google Cloud. It accepts a string in the format project/<YOURPROJECTNAME>/logs/<LOG_ID>, where <YOURPROJECTNAME> is the name of your Google Cloud project and <LOG_ID> is the log source name. See Logging query language in the Google Cloud documentation for more information.


This mandatory group directive specifies the Google Cloud resource that produced the log entry. See resources list to get all available values. For example, specify the monitored resource that owns the database to collect its error logs.

    type        gce_instance
        zone    us-cental


This directive specifies a path to a directory containing certificate authority (CA) certificates. These certificates will be used to verify the certificate presented by the remote server. The certificate files must be named using the OpenSSL hashed format, i.e. the hash of the certificate followed by .0, .1 etc. To find the hash of a certificate using OpenSSL:

$ openssl x509 -hash -noout -in ca.crt

For example, if the certificate hash is e2f14e4a, then the certificate filename should be e2f14e4a.0. If there is another certificate with the same hash then it should be named e2f14e4a.1 and so on.

A remote server’s self-signed certificate (which is not signed by a CA) can also be trusted by including a copy of the certificate in this directory.

The default operating system root certificate store will be used if this directive is not specified. Unix-like operating systems commonly store root certificates in /etc/ssl/certs. Windows operating systems use the Windows Certificate Store, while macOS uses the Keychain Access Application as the default certificate store. See NXLog TLS/SSL configuration in the User Guide for more information on using this directive.


Number of allowed parallel HTTP connections. More connections mean bigger throughput, but you need to be sure to not hit the Google Cloud Logging API quotas. The default is 1.


Maximum size of the request in bytes. The default is 65 KB.


A list of key-value pairs for providing event metadata. The labels can be user-defined or system-defined.

User-defined labels are optional key-value pairs that you can use to enrich logs. System-defined labels are defined by Google Cloud Platform (GCP) services for platform logs and are in the format <SERVICE_NAMESPACE>/<ATTRIBUTE_NAME>—for example, compute.googleapis.com/resourceName.

Cloud Logging truncates label keys that exceed 512 B and label values that exceed 64 KB and replaces the truncated text with an ellipsis (…​).

    zone    us-central1-a

This optional directive sets the reconnect interval in seconds. If it is set, the module attempts to reconnect in every defined second. If it is not set, the reconnect interval will start at 1 second and doubles on every attempt. If the duration of the successful connection is greater than the current reconnect interval, then the reconnect interval will be reset to 1 sec.


Example 1. Forwarding logs to Google Cloud Logging

This configuration uses the om_googlelogging output module to forward logs from the project myproject to Google Cloud Logging.

<Output google_logging>
    Module             om_googlelogging
    CredentialsFile    /path/to/credentials.json (1)
    LogName            projects/myproject-343509/logs/test
    <Labels> (2)
        zone    us-central
    <Resources> (3)
        type    gce_instance
1 Credentials file for authenticating with the Cloud Logging API. See Configuring a Google Cloud service account for more information.
2 List of labels defined as key-value pairs to attach to the event.
3 List of resources to attach to the event.