Database ( latest 8.1.0 )

/Manage/Logging/Log management

Log management

This page describes how to create and manage log streams that route Aerospike log messages to supported log sinks.

Log management system components

Aerospike’s log management system consists of logged events, log streams, log sinks and one or more log files or audit logs. Here’s how they work together:

The system generates a logged event.
Events are aggregated into a log stream, which is the live, in-memory sequence of logs.
Aerospike routes events from the stream to one or more log sinks.
- A log file stored on disk is one type of log sink.
- An audit log is a specialized log file that receives only security- or compliance-related events. Audit events can be logged to any type of log sink (file, console, syslog). For details about creating audit logs, see Audit trail.

Supported log sinks

Aerospike supports a maximum of eight log sinks per node. The location for any of the logs can be customized in the logging section of aerospike.conf.

The supported log sinks are:

File sink: default path is /etc/aerospike/aerospike.conf
Syslog sink: forwards to your syslog daemon for aggregation/monitoring (SIEM-friendly).
Console sink: helpful if running Aerospike in Docker/Kubernetes where stdout is aggregated.

Log events

Emitted logs provide a broad view of a system’s operational status by recording events like errors, warnings, startup messages, and resource utilization. These logs are a vital tool for IT professionals to diagnose and resolve technical issues.

Key characteristics of system logs:

Purpose: To monitor system health, performance, and to aid in troubleshooting technical problems.
Focus: System events and application operations, such as system crashes, service starts/stops, disk space warnings, and performance bottlenecks.
Level of detail: Varies widely, but generally focuses on the technical aspects of the event rather than user identity.
Retention: System logs often have shorter retention periods, as they are primarily used for real-time or recent analysis and troubleshooting.

Basic log sink components

File name and location: The default Aerospike log file is/var/log/aerospike/aerospike.log.
Context: Specifies the server module where the log messages originated, such as tls, drv_ssd, or fabric. See Logging contexts for a comprehensive list of available contexts.
Severity level: Aerospike uses five severity levels that determine how much information is logged. See Severity levels for a description of each severity level.
See Log lines for detailed descriptions of each component of a log line.

Defining log sinks

Aerospike log sinks are defined in the logging section of the Aerospike configuration file, /etc/aerospike/aerospike.conf. Log sinks are a static subsection of the logging section. After a log sink is defined, restart the affected node to activate the changed.

logging {

    file /var/log/aerospike/aerospike.log { # Defines a log sink that outputs to a file
        context any info                    # `context any` applies the severity level to messages from all modules
                                            # `info` sets the minimum severity level to INFO
    }
}

Create a file log sink

The following example configures two log sinks, a file log sink for Aerospike, and a console log sink.

The default location for the default log file is ‘/var/log/aerospike/aerospike.log’. If you configure a different location, the new directory must already exist.

Edit /etc/aerospike/aerospike.conf and add the following configuration section.

logging {
        file /var/log/aerospike/aerospike.log {
             context any info
        }

        console {
             context any info
        }
}

Save your changes and restart ‘asd’.
When asd restarts, Aerospike creates the log sinks based on the logging section.
Verify the enumerated list of log sinks with the following command.
Terminal window
```
  asinfo -v "logs" -l
```

Create a log sink for debugging

You can direct a debugging log stream to a separate file. The following example configures a separate log file, tls_debug.log, only for debug-level messages from the tls context, a standard file log sink, and a console log sink:

logging {
        file /var/log/aerospike/tls_debug.log {
            context any critical
            context tls debug
        }

        file /var/log/aerospike/aerospike.log {
            context any info
        }

        console {
            context any info
        }
}

The following example configures rsyslog to send locally written audit information to syslog, with the following line added to /etc/rsyslog.conf:

 local0.    /var/log/aerospike_security_audit.log

Restart rsyslogd to activate any changes.

Change the severity level dynamically

Use asinfo to temporarily change the logging level of a context to help debug a problem. The following example shows the syntax:

asinfo -v "log-set:id=SINK-ID;CONTEXT=LOG-LEVEL"

Use asinfo to get your SINK-IDs. The SINK-ID is the log identifier.
Terminal window
```
asinfo -v "logs" -l
```
The example output shows two sinks. Sink 0 is the log file on disk, sink 1 is stderr.
```
0:/var/log/aerospike/aerospike.log
1:stderr
```
Use CONTEXT=LOG-LEVEL to specify the context to change and the severity level to set. For example, the following command sets the logging level to debug on the tls context:
Terminal window
```
asinfo -v "log-set:id=0;tls=debug"
```
Expected output:
```
asinfo --host 127.0.0.1:3100 -v "log-set:id=0;tls=debug"
ok
```
When you are finished debugging, change it back:
Terminal window
```
asinfo -v "log-set:id=0;tls=info"
```

All other contexts remain at their configured logging levels.

Severity level details

The severity level controls how much information is logged. Every severity level includes all higher levels. For production systems, consider the amount of logging information you need and set the severity level appropriately.

Severity	Description	Notes
`critical`	Indicates that at least one system component is inoperable, causing a fatal error	Least verbose.
`warning`	Might indicate that an operation will fail in the future.	Includes `critical` messages.
`info`	The default severity level, containing high-level, operational messages that log the system’s normal operation.	Includes `critical` and `warning` messages.
`debug`	For low-level, diagnostic messages.	Includes `info`, `warning`, and `critical` messages.
`detail`	Includes routine messages about normal operations, like keys of records being read and written.	Most verbose.

Logging contexts

A log context defines the server module where a log message originated. Following is the default configuration for logging:

logging {
    console {
        context any info
    }
}

console is the log sink that streams log messages to stderr.
context any captures the log messages of all Aerospike logging contexts.

Click the dropdown arrow to see a full list of logging contexts, or print the list with asinfo -v "log/" -l.

Aerospike logging contexts

misc:INFO
alloc:INFO
arenax:INFO
hardware:INFO
msg:INFO
os:INFO
secrets:INFO
socket:INFO
tls:INFO
vault:INFO
vmapx:INFO
xmem:INFO
aggr:INFO
appeal:INFO
as:INFO
audit:INFO
batch:INFO
batch-sub:INFO
bin:INFO
config:INFO
clustering:INFO
deprecation:INFO
drv-mem:INFO
drv_pmem:INFO
drv_ssd:INFO
exchange:INFO
exp:INFO
fabric:INFO
flat:INFO
geo:INFO
hb:INFO
health:INFO
hlc:INFO
index:INFO
info:INFO
info-command:INFO
key-busy:INFO
migrate:INFO
mrt-audit:INFO
mrt-monitor:INFO
namespace:INFO
nsup:INFO
particle:INFO
partition:INFO
proto:INFO
proxy:INFO
proxy-divert:INFO
query:INFO
record:INFO
roster:INFO
rw:INFO
rw-client:INFO
security:INFO
service:INFO
service-list:INFO
sindex:INFO
skew:INFO
smd:INFO
storage:INFO
truncate:INFO
tsvc:INFO
udf:INFO
xdr:INFO
xdr-client:INFO

See Configure access control for details about how to enable authentication and assign roles and permissions.
See Audit trail for details about configuring Aerospike EE to log security events to an audit log.
See the Database log reference for examples of log messages by context.