NXLog Legacy Documentation

Microsoft Azure Log Ingestion (om_azuremonitor)

This module forwards logs to Azure services that support the Azure Monitor Logs Ingestion API. Event data is sent in batches, reducing the latency caused by the HTTP responses, thus improving Microsoft Azure’s server performance.

Configuring a Microsoft Azure AD application

You must first create a Microsoft Azure AD application to use any Microsoft API. You will need the following details to configure the om_azuremonitor module:

An Application (client) ID
The Directory (tenant) ID
A client secret or a certificate and private key pair.

See Add credentials on Microsoft Docs for more information.

Register an Azure application

First, follow the instructions to Register an application on Microsoft Learn. Once you have created the new application, take note of the Application (client) ID and the Directory (tenant) ID from the application Overview page.

Generate an X.509 certificate

To use certificate-based authentication to authenticate with Microsoft’s APIs, you need an X.509 certificate and the private key used to generate the certificate. The following instructions guide you through creating the private key pair using OpenSSL.

Save the following script in a file named gencertkey.sh

#!/bin/sh

openssl req -new -nodes -newkey rsa:2048 -x509 -days 730 -keyout certkey.pem -out cert.pem
#openssl pkcs12 -export -out cert.pfx -inkey certkey.pem -in cert.pem
openssl x509 -outform der -in cert.pem -out cert.der
cat cert.der |openssl dgst -binary -sha1 | openssl base64 >cert.base64thumb
THUMBPRINT=`cat cert.base64thumb`
echo "ThumbPrint:$THUMBPRINT"

UUID=`uuidgen`
CERT=`cat cert.pem | grep -v "\-\-\-\-"| tr -d '\n'`

cat <<EOF
"keyCredentials": [
     {
        "customKeyIdentifier":"$THUMBPRINT",
        "keyId":"$UUID",
        "type":"AsymmetricX509Cert",
        "usage":"Verify",
        "value":"$CERT"
     }
],
EOF

The script depends on the openssl toolkit and the uuidgen program. Install the corresponding packages if necessary.

On Debian-based platforms:
```
# apt install openssl uuid-runtime
```
On Centos/Red Hat platforms:
```
# yum install openssl util-linux
```

Execute gencertkey.sh on the computer where NXLog is installed to generate the certificate.

$ ./gencertkey.sh

The output:

Generating a RSA private key
............+++++
................................................+++++
writing new private key to 'certkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
ThumbPrint:0nFt3fB0JP7zuSmHaRQtmsFNYqo=
"keyCredentials": [
{
    "customKeyIdentifier":"0nFt3fB0JP7zuSmHaRQtmsFNYqo=",
    "keyId":"629ab88d-1059-454b-b258-4ca05b46dee4",
    "type":"AsymmetricX509Cert",
    "usage":"Verify",
    "value":"MIIDXTCCAkWgAwIBAgIJAP+XrnwhAxjOMA0GCSqGSIb3DQEBCwUAMEUxCzAJB..."
}
],
--------
+
Take note of the `ThumbPrint` and `KeyCredentials` values.

Go to the Microsoft Azure AD application registration page, select Manifest on the left, and click Download.

Edit the downloaded manifest file and replace the KeyCredentials value with the value from the previous step.

"keyCredentials": [
{
    "customKeyIdentifier":"0nFt3fB0JP7zuSmHaRQtmsFNYqo=",
    "keyId":"629ab88d-1059-454b-b258-4ca05b46dee4",
    "type":"AsymmetricX509Cert",
    "usage":"Verify",
    "value":"MIIDXTCCAkWgAwIBAgIJAP+XrnwhAxjOMA0GCSqGSIb3DQEBCwUAMEUxCzAJB..."
}
],

Save the changes and upload the manifest to Microsoft Azure.

Output log format

om_azuremonitor forwards log records over HTTP(S) as JSON payload. The JSON format depends on the value of the $raw_event field. The module checks if the value of $raw_event is valid JSON and applies the following rules:

If it is valid JSON, the value is forwarded as is.
If it is not valid JSON, the log record is converted to JSON in the following format:
```
{
  "raw_event": "<json_escaped_raw_event>"
}
```

Additional metadata, including the NXLog-specific fields EventReceivedTime, SourceModuleName, and SourceModuleType, will not be included in the output unless these values have been written to the $raw_event field. The processing required to achieve this depends on the format of the input data, but generally it means you need to:

Parse the log record according to the data format.
- If the input data is already in JSON format, use parse_json() to parse $raw_event into fields.
- If the input is unstructured plain text data, copy the value of $raw_event to a custom field.
Create and populate any additional custom fields.
Use to_json() to convert the fields to JSON format and update the value of $raw_event.

See the Examples section for NXLog configuration examples of the above.

Logs Ingestion API requirements

To send data to a custom table, you must create a data collection endpoint (DCE) and a data collection rule (DCR) in Microsoft Azure. Instructions are available in the Microsoft tutorial Send data to Azure Monitor Logs with Logs ingestion API (Azure portal).

The following requirements are essential to note when planning your data structure:

The JSON object must match the structure expected by your DCR. If you forward logs that do not match the expected format, the server will silently discard them.
If the data doesn’t match the structure of the target table, your DCR must include a transformation to convert JSON fields to table columns accordingly.
Azure Monitor Logs tables must have a TimeGenerated column containing the timestamp of the event. You can either set this field from your NXLog configuration, e.g., by renaming the EventReceivedTime field, or add a transformation to your DCR to rename it.
Table columns in Azure Monitor Logs are case-sensitive. Therefore, the field names in the JSON object must match the columns exactly when sending logs via the Logs Ingestion API.

TimeGenerated field

Azure Monitor Logs requires the TimeGenerated field for built-in tables. The server will discard the record without generating an error if it’s not present.

om_azuremonitor automatically adds a $TimeGenerated field to the record based on the following rules to avoid data loss:

If $TimeGenerated is present, is in YYYY-MM-DDThh:mm:ssZ format, and is no more than 48 hours behind or 24 hours ahead of the current time, the field will not be changed.

If $TimeGenerated is not available, the module creates it with the value of:

$EventTime, if this field is present, is in YYYY-MM-DDThh:mm:ssZ format and is no more than 48 hours behind or 24 hours ahead of the current time.
Else, $EventReceivedTime if it is present, in YYYY-MM-DDThh:mm:ssZ format, and is no more than 48 hours behind or 24 hours ahead of the current time.
If neither field is present, it will use the current time in YYYY-MM-DDThh:mm:ssZ format.

Configuration

The om_azuremonitor module accepts the following directives in addition to the common module directives. The ClientId, ClientSecret, DcrImmutableId, StreamName (or its alias TableName), TenantId, and URL directives are required.

Required directives

The following directives are required for the module to start.

CertKeyFile

Specifies the path of the private key file that was used to generate the certificate specified by the CertThumbprint directive. This directive is mutually exclusive with the ClientSecret directive.

CertPattern

This optional directive, supported only on Windows, defines a pattern for identifying a corresponding certificate and its thumbprint within the native Windows Certificate Storage. The pattern must follow PCRE2 rules and use the format "SUBJECT=, CN=, DN=, SAN=" where DN is "CN=, O=, OU=, L=, ST=, C=". The certificate must be imported in PFX format into the Local Computer\Personal certificate store for NXLog to locate it. During configuration, this directive is resolved into the corresponding CertThumbprint value. The first found thumbprint will be chosen if multiple certificates match the pattern. We recommend ensuring that the used certificate storage is well-maintained for optimal performance. This feature is not dynamic; the agent must be restarted if the certificate changes. This directive is mutually exclusive with the CertThumbprint directive.

Configuration examples:

CertPattern    $hostname + 'Cert'

CertPattern    DN=CN=Client\.example\.com;.*?SAN=DNS:Client\.example\.com

A normal log output example would look like as follows:

matching pattern [DN=CN=Client\.example\.com;.*?SAN=DNS:Client\.example\.com] to certificate [SUBJECT=US, ClientState, ClientCity, ClientCompany, ClientUnit, Client.example.com, CN=Client.example.com; DN=CN=Client.example.com, O=ClientCompany, OU=ClientUnit, L=ClientCity, ST=ClientState, C=US; SAN=DNS:Client.example.com; DNS:www.Client.example.com; IP:127.0.0.3; ]

CertThumbprint

Specifies the thumbprint of the certificate that will be presented to the remote server during Azure Certificate Authentication. This value corresponds to the hexadecimal fingerprint string generated by gencertkey.sh when Generating the X.509 certificate. This directive is mutually exclusive with the ClientSecret directive.

When the global directive UseCNGCertificates is set to FALSE the private key associated with the certificate must be exportable.

If you generate the certificate request using Windows Certificate Manager, enable the Make private key exportable option from the certificate properties.
If you import the certificate with the Windows Certificate Import Wizard, make sure that the Mark this key as exportable option is enabled.
If you migrate the certificate and associated private key from one Windows machine to another, select Yes, export the private key when exporting from the source machine.

ClientId

This mandatory directive specifies the Microsoft Azure App Application (client) ID.

ClientSecret

Specifies the Microsoft Azure App client secret. This directive is mutually exclusive with the CertThumbprint and CertKeyFile directives.

DcrImmutableId

Specifies the ID of the Data Collection Rule (DCR) to use for Azure Monitor to ingest the logs.

StreamName

The name of the Azure Monitor stream that will receive the logs. You must prefix custom stream names with Custom-.

TableName

Alias for StreamName. You must prefix custom table names with Custom-.

This parameter will be deprecated in future releases. Consider switching to the StreamName parameter instead.

TenantId

This mandatory directive specifies the Microsoft Azure App Directory (tenant) ID.

URL

Specifies the Data Collection Endpoint (DCE) URI. The module works in a failover configuration if additional URL directives are specified on new lines. If the first URL is unreachable, the module automatically fails over to the next one. If the last URL is unreachable, the module fails over to the first URL.

HTTP(S) directives

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

AuthURL

This directive specifies the URL for authenticating with the API. The default value is https://login.microsoftonline.com.

Connections

Number of allowed parallel HTTP connections. More connections mean bigger throughput. The default is 1.

OutputRequestSize

Maximum size of the request in bytes. The default is 1 MB.

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.

Examples

Example 1. Sending data to Azure custom tables

To send data to a custom table, you must create a data collection endpoint (DCE) and a data collection rule (DCR) in Microsoft Azure. Instructions are available in the Microsoft Learn tutorial Send data to Azure Monitor Logs by using a REST API. Once you have your DCE and DCR set up, configure an om_azuremonitor instance as follows.

It might take up to 30 minutes for the assigning permissions to the DCR to take affect

nxlog.conf

<Output azure_monitor>
    Module           om_azuremonitor
    ClientId         <CLIENT_ID>
    TenantId         <TENANT_ID>
    ClientSecret     <CLIENT_SECRET>

    URL              <DATA_COLLECTION_ENDPOINT>
    DcrImmutableId   <DCR_IMMUTABLE_ID>
    StreamName        Custom-<CUSTOM_STREAM_NAME>
</Output>

Example 2. Sending data to Azure built-in tables

To send data to a built-in table, you must create a data collection endpoint (DCE) and a data collection rule (DCR) in Microsoft Azure using one of the following templates:

The template automatically creates a data collection rule (DCR) to redirect logs from Custom-MyTableRawData to the desired table. Currently, it is not possible to insert records directly into built-in tables.

See Create a data collection endpoint on Microsoft Learn for more information.

Once you have your DCE and DCR set up, configure an om_azuremonitor instance as follows. The destination table name corresponds to the table created by the template.

nxlog.conf

<Output azure_monitor>
    Module           om_azuremonitor
    ClientId         <CLIENT_ID>
    TenantId         <TENANT_ID>
    ClientSecret     <CLIENT_SECRET>

    URL              <DATA_COLLECTION_ENDPOINT>
    DcrImmutableId   <DCR_IMMUTABLE_ID> # The ID of the DCR created by the template
    StreamName        Custom-MyStreamRawData
</Output>