NXLog Legacy Documentation

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, and 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.

Log in to your Google Cloud account and switch to the project you want to configure.
From the navigation menu, click IAM & Admin > Service Accounts.
Click CREATE SERVICE ACCOUNT.
Enter a service account name and description and click CREATE AND CONTINUE.
Select the Owner role from the Role drop-down and click DONE.
Click on the newly created account on the Service accounts page to open its configuration page.
Click the KEYS tab, expand the ADD KEY drop-down and select Create new key.
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.

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

Severity	Alternative values
`DEFAULT`	`NONE`, `UNKNOWN`
`DEBUG`	-
`INFO`	`LOW`
`NOTICE`	`NOTE`
`WARNING`	`WARN`, `MEDIUM`
`ERROR`	`ERR`, `HIGH`
`CRITICAL`	`CRIT`, `VERY-HIGH`
`ALERT`	-
`EMERGENCY`	`EMERG`, `EMEGENT`, `PANIC`

DEFAULT

NONE, UNKNOWN

DEBUG

INFO

LOW

NOTICE

NOTE

WARNING

WARN, MEDIUM

ERROR

ERR, HIGH

CRITICAL

CRIT, VERY-HIGH

ALERT

EMERGENCY

EMERG, EMEGENT, PANIC

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.

Configuration

Log data sent to the destination with this module must be UTF-8 encoded, otherwise, the target will refuse and drop the events.

If the source does not guarantee that events are UTF-8 encoded, use the xm_charconv extension module to convert the log data to UTF-8:

Set the AutodetectCharsets directive in your xm_charconv module block with as many character set names as required to automatically detect all possible source log data encodings. For example:
```
<Extension converter>
    Module                xm_charconv
    AutodetectCharsets    utf-8, utf-16, utf-32, iso8859-2, iso8859-7, iso-8859-1, euc-jp
</Extension>
```
Add the convert_fields procedure call to each input module that routes events to this output module:
```
Exec    convert_fields("auto", "utf-8");
```

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

Required directives

The following directives are required for the module to start.

CredentialsFile

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.

LogName

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.

Resources

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.

<Resources>
    type        gce_instance
    <labels>
        zone    us-cental
    </labels>
</Resources>

HTTP(S) directives

The following directives are for configuring HTTP(S) connection settings.

Connections

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.

OutputRequestSize

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

AddHeader

This optional directive can be specified multiple times to add custom headers to each HTTP request.

Compression

This optional directive can be used to enable HTTP compression for outgoing HTTP messages. The possible values are none, gzip, and deflate. By default, compression is disabled. Please note that some HTTP servers may not accept compressed HTTP requests. If a server doesn’t support a specific compression method, it may return 415 Unsupported Media Type errors in response to compressed requests.

HTTPBasicAuthUser

HTTP basic authorization username. You must also set the HTTPBasicAuthPassword directive to use HTTP authorization.

HTTPBasicAuthPassword

HTTP basic authorization password. You must also set the HTTPBasicAuthUser directive to use HTTP authorization.

HTTPSAllowExpired

This boolean directive specifies whether the connection should be allowed with an expired certificate. If set to TRUE, the remote host will be able to connect with an expired certificate. The default is FALSE: the certificate must not be expired. This directive is only valid if HTTPSRequireCert is set to TRUE.

HTTPSAllowUntrusted

This boolean directive specifies that the connection should be allowed without certificate verification. If set to TRUE, the connection will be allowed even if the remote host presents an unknown or self-signed certificate. The default value is FALSE: the remote host must present a trusted certificate.

HTTPSCADir

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 host. 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 host’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.

HTTPSCAFile

This specifies the path of the certificate authority (CA) certificate that will be used to verify the certificate presented by the remote host. A remote host’s self-signed certificate (which is not signed by a CA) can be trusted by specifying the remote host certificate itself. In the case of certificates signed by an intermediate CA, the certificate specified must contain the complete certificate chain (certificate bundle).

HTTPSCertFile

This specifies the path of the certificate file that will be presented to the remote host during the HTTPS handshake.

HTTPSCertKeyFile

This specifies the path of the private key file that was used to generate the certificate specified by the HTTPSCertFile directive. This is used for the HTTPS handshake.

Proxy

This optional directive is used to specify the protocol, IP address (or hostname) and port number of the HTTP or SOCKS proxy server to be used. The format is protocol://hostname:port.

Reconnect

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.

Optional directives

Labels

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

<Labels>
    zone    us-central1-a
</Labels>

Examples

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
    </Labels>
    <Resources> (3)
        type    gce_instance
    </Resources>
</Output>

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.