Skip to main content

Configure - Log

The logging context in the configuration file specifies the location of the Aerospike log as well as the logging level desired.

Use the configuration file to determine which levels of log events you want reported into the log file. Greater verbosity delivers additional details, however it also increases the size of log files and takes more time to read. The default log level is INFO which provides a generally-acceptable balance between detail and usability. You can set the log file location and the logging level using the configuration file. Review the possible contexts at: Server Log Reference.

The following example of a logging context instructs the node to log to /var/log/aerospike/aerospike.log, at info level.

Below is an example of a logging context:

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

By default, logs in systemd based systems are configured to go to the console:

logging {
console { # systemd based
context any info
}
}

Refer to systemd for details.

note

Create the log directory before configuring logs. If the log directory does not exist, the server will not start. Aerospike does not create this directory automatically.

Refer to systemd for more details.

note

Make sure the directory exists. If the log directory does not exist, Aerospike does NOT create this directory automatically and the server will not start.

Every message that the server produces includes a context, which names the part of the code that generated the message, and a severity level, which describes how acute the message is.

The severity log levels:

SeverityDescription
criticalCritical error messages
warningWarning messages
infoInformational messages
debugDebugging information
detailVerbose debugging information

Static configuration of server logs

  • In the logging stanza, define the limit of eight sinks.
  • You can change the logging level for all context or only for a specific context.
  • Different Aerospike components can have different logging levels.
  • Contexts indicate which component a log message was emitted from.

For the full list of contexts, run the following command:

$ asinfo -v "log/" -l
misc:INFO
alloc:INFO
arenax:INFO
hardware:INFO
msg:INFO
os:INFO
rbuffer:INFO
socket:INFO
tls:INFO
vault:INFO
vmapx:INFO
xmem:INFO
aggr:INFO
appeal:INFO
as:INFO
audit:INFO
batch:INFO
bin:INFO
config:INFO
clustering: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-port:INFO
job:INFO
migrate:INFO
mon:INFO
namespace:INFO
nsup:INFO
particle:INFO
partition:INFO
paxos:INFO
proto:INFO
proxy:INFO
proxy-divert:INFO
query:INFO
record:INFO
roster:INFO
rw:INFO
rw-client:INFO
scan: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

Dynamic configuration of server logs

Aerospike log settings are dynamic, which means they can be set without a node or cluster restart using asinfo. You can configure the logs dynamically using the log-set. The linked sink must exist in aerospike.conf beforehand or the server will return the following message: There is a paramater that can be used to report on data transactions for a set or namespace. The parameter to use to address the error message is report-data-op. Due to the volume of log information generated using this setting, use it with a separate sink.

Example: Log-set, bad log Id

root@40286da04365:/var/log# asinfo -v 'log-set:id=4;security=info'
error-bad-id

Example: Logs all context at info level, and the migrate context at debug level.

Static configuration of logs

Dynamic configuration of logs

Refer to Working with the Log File.

Changing the sink (destination) of a context.

The destination (sink) must already exist to dynamically change where the context gets logged. Refer to How to configure a separate log sink.

Static configuration of log

Dynamic configuration of logs

Refer to Working with Log File.

Changing the sink (destination) of a context.

The destination (sink) must already exist to dynamically change where the context gets logged. Refer to How to configure a separate log sink.

The example below logs all context at info level, and in addition, the "migrate" context at "debug" level.

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

You can find out all available context using asinfo, via the log command.

Use asinfo to change the logging level on the node dynamically.

Example: Changing a log level for all components other than XDR:

asinfo -v "log-set:id=0;<Component1>=<LogLevel>" 

Example: Changing UDF logging to detail:

asinfo -h 127.0.0.1 -p 3000 -v "log-set:id=0;udf=detail"
requested value log-set:id=0;udf=detail
value is ok

Example: Switching back the logging level to the default info:

asinfo -h 127.0.0.1 -p 3000 -v "log-set:id=0;udf=info"
requested value log-set:id=0;udf=info
value is ok

Refer to Log-set, Changing logging levels and Working with Log File.

Configuring a separate log sink/destination

The destination (sink) must already exist to dynamically change where the context gets logged. For auditing purposes, you may want to log security information in a separate log file.

Step 1: Add the security audit lines into the security stanza to turn on security reporting:

It is also possible to change the logging level dynamically on the node by using asinfo. Refer to log-set.

security {
enable-security true
log {
report-authentication true
report-user-admin true
report-sys-admin true
report-violation true
}

}
  • report-authentication=true: reports successful authentication report authentication
  • report-user-admin=true: reports user administration tasks that have succeeded
  • report-sys-admin true: reports successful systems administration tasks
  • report-violation true: reports failed logins to the system report violation

Step 2: Add an extra log into the logging stanza:

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

file /var/log/audit.log {
context any critical
context security info
}
}

The default context setting for a log sink is any critical, meaning only critical issues are logged.

Step 3: Restart the Aerospike server to apply the new configuration changes:

root@40286da04365:/var/log# service aerospike restart
* Restarting aerospike aerospike
* Stopping aerospike aerospike [ OK ]
* Starting aerospike aerospike [ OK ]
root@40286da04365:/var/log#

Step 4: Access the cluster and observe the extra reporting:

root@40286da04365:/var/log# aql
Seed: 127.0.0.1
User: None
Config File: /etc/aerospike/astools.conf /root/.aerospike/astools.conf
2020-03-23 18:01:28 WARN Failed to connect to seed 127.0.0.1 3000. AEROSPIKE_NOT_AUTHENTICATED not authenticated, 127.0.0.1:3000
Error 80: Failed to connect
root@40286da04365:/var/log# tail -f aero_security.log
Mar 23 2020 18:05:48 GMT: INFO (security): (security.c:5973) not authenticated | client: 127.0.0.1:44726 | authenticated user: <none> | action: info request | detail: <none>
Mar 23 2020 18:05:49 GMT: INFO (security): (security.c:5973) not authenticated | client: 127.0.0.1:44728 | authenticated user: <none> | action: info request | detail: <none>
^C
root@40286da04365:/var/log#

Find an existing log location

To find the logs location on a running instance, check the config file or run:

~$ asinfo -v logs
requested value logs
value is 0:/var/log/aerospike/aerospike.log

Log Rotate

Refer to logrotate.