Lisk Core Configuration

If you are using the Docker distribution, Lisk Core is configured slightly different. Go to the Docker Administration page, to find out more about the docker-specific configuration of Lisk Core.

Command Line Options

There are plenty of options available that you can use to override configuration on runtime while starting Lisk Core.

How to overwrite config options from the Command Line:

  • Pass options as ENV variables

  • Pass options as flags

LISK_NETWORK=[network] LISK_CONFIG_FILE=[config-path] LISK_ADDRESS=[address] LISK_WS_PORT=[port] pm2 start lisk
The flag options are deprecated. We recommend passing the options as ENV variables.
node dist/index.js -p [port] -a [address] -c [config-path] -n [network]

You can pass devnet (default), alphanet, betanet, testnet or mainnet for the [network] option.

All ENV variables restricted with operating system constraint of ENV variable maximum length.

Comma-separated lists will replace the original config values. E.g. If you specify LISK_PEERS, original peers.list specific to the network will be replaced completely.

Each of these options can be appended on the command line.

Command line Option ENV Variable Description

--network
-n

LISK_NETWORK

Which configurations set to use, associated to lisk networks. Any of this option can be used devnet, alphanet, betanet, testnet and mainnet. Default value is devnet.

--config
-c

LISK_CONFIG_FILE

Path the custom configuration file, which will override values of config/default/config.json.

--port
-p

LISK_WS_PORT

TCP port for P2P layer

--http-port
-h

LISK_HTTP_PORT

TCP port for HTTP API

--address
-a

LISK_ADDRESS

Listening host name or ip

--log
-l

LISK_FILE_LOG_LEVEL

Log level for file output

LISK_CONSOLE_LOG_LEVEL

Log level for console output

LISK_CACHE_ENABLED

Enable or disable cache. Must be set to true/false

--database
-d

LISK_DB_NAME

PostgreSQL database name to connect to

LISK_DB_HOST

PostgreSQL database host name

LISK_DB_PORT

PostgreSQL database port

LISK_DB_USER

PostgreSQL database username to connect to

LISK_DB_PASSWORD

PostgreSQL database password to connect to

--redis
-r

LISK_REDIS_HOST

Redis host name

LISK_REDIS_PORT

Redis port

LISK_REDIS_DB_NAME

Redis database name to connect to

LISK_REDIS_DB_PASSWORD

Redis database password to connect to

--peers
-p

LISK_PEERS

Comma separated list of peers to connect to in the format 192.168.99.100:5000,172.169.99.77:5000

LISK_API_PUBLIC

Enable or disable public access of http API. Must be set to true/false

LISK_API_WHITELIST

Comma separated list of IPs to enable API access. Format 192.168.99.100,172.169.99.77

LISK_FORGING_DELEGATES

Comma separated list of delegates to load in the format publicKey|encryptedPassphrase,publicKey2|encryptedPassphrase2

LISK_FORGING_WHITELIST

Comma separated list of IPs to enable access to forging endpoints. Format 192.168.99.100,172.169.99.77

--rebuild
-b

Rebuilds certain database tables on basis of the local blockchain data. Must be followed by an integer, that specifies the last delegate round that should be part of the rebuild. If 0 is specified, all rounds are rebuilt.

LISK_CHILD_PROCESS_MODULES

Comma separated list of modules, that shall be loaded in a separate process. To enable inter process communication, set ipc.enabled to true inside the config.json file.

Network-specific config files

The root folder for all configurations is config/. The default network is devnet. If you want to connect to another network, specify the network when starting Lisk Core, as described in Source Administration. You can find network specific configurations under config/<network>/config.json, where <network> can be any of these values:

  • devnet

  • alphanet

  • betanet

  • testnet

  • mainnet

Don’t override any value in files mentioned above if you need custom configuration. The changes will be overwritten everytime you upgrade Lisk Core. To use a custom configuration use environment variables or create your own .json file and pass it as command line option.

Custom config file

To use a custom config, create a .json-file which is following the structure described in the Config Structure section.

You only need to include the values you want to update, for all other options, the predefined values will be used, like described in Config load order section.

Binary and Commander distributions both provide a config.json, which can be customized as desired.

For Source distributions, the config file needs to be created seperately and needs to be passed like described below.

  • Binary

  • Commander

  • Source

The binary script provides a custom config.json which is stored in the root folder of your Lisk Core installation by default.

So e.g. you have installed Lisk Core for Mainnet under ~/lisk-main, the config is stored directly in ~/lisk-main/config.json

The config.json will be used automatically when reloading your node with:

bash lisk.sh reload

Lisk Commander provides a custom config.json which is stored in the root folder of your Lisk Core instance by default.

So e.g. you have installed Lisk Core for Mainnet under ~/.lisk/instances/lisk-mainnet, the config is stored directly in ~/.lisk/instances/lisk-main/config.json

The config.json will be used automatically when reloading your node with:

pm2 stop lisk (1)
LISK_CONFIG_FILE=<CONFIG_PATH> pm2 start lisk (2)
1 Stop Lisk Core in case it is running.
2 Replace <CONFIG_PATH> with the path to your custom config file.

Config load order

Configurations will be loaded in the following order, each one will override the previous one:

  1. Default configuration values of modules and components of the Lisk Framework

  2. Network specific configuration file

  3. A custom configuration file (if specified by the user)

  4. Command line configurations, specified as command-line flags or ENV variables.

For development purposes, use devnet as the network option. Other networks are specific to public Lisk networks.

The config.json file and a description of each configurable parameter.

Structure

{
    "app": { (1)
        "genesisConfig": { (2)
            "BLOCK_TIME": 10, (3)
            "EPOCH_TIME": "2016-05-24T17:00:00.000Z", (4)
            "MAX_TRANSACTIONS_PER_BLOCK": 25, (5)
            "REWARDS": { (6)
                "DISTANCE": 1000, (7)
                "MILESTONES": [ (8)
                    "500000000", (9)
                    "400000000", (10)
                    "300000000", (11)
                    "200000000", (12)
                    "100000000" (13)
                ],
                "OFFSET": 1451520 (14)
            }
        },
        "ipc": {
            "enabled": true (15)
        }
    },
    "components": { (16)
        "logger": { (17)
            "fileLogLevel": "debug", (18)
            "logFileName": "logs/devnet/lisk.log", (19)
            "consoleLogLevel": "info" (20)
        },
        "storage": { (21)
            "database": "lisk_dev", (22)
            "host": "localhost", (23)
            "port": 5432, (24)
            "user": "lisk", (25)
            "password": "password", (26)
            "min": 10, (27)
            "max": 95, (28)
            "poolIdleTimeout": 30000, (29)
            "reapIntervalMillis": 1000, (30)
            "logEvents": ["error"], (31)
            "logFileName": "logs/lisk_db.log" (32)
        },
        "cache": { (33)
            "db": 0, (34)
            "enabled": true, (35)
            "host": "127.0.0.1", (36)
            "port": 6380 (37)
        }
    },
    "modules": { (38)
        "http_api": { (39)
            "httpPort": 4000, (40)
            "address": "0.0.0.0", (41)
            "enabled": true, (42)
            "trustProxy": false, (43)
            "access": { (44)
                "public": false, (45)
                "whiteList": ["127.0.0.1"] (46)
            },
            "ssl": { (47)
                "enabled": false, (48)
                "options": {
                    "port": 443, (49)
                    "address": "0.0.0.0", (50)
                    "key": "./ssl/lisk.key", (51)
                    "cert": "./ssl/lisk.crt" (52)
                }
            },
            "options": {
                "limits": { (53)
                    "max": 0, (54)
                    "delayMs": 0, (55)
                    "delayAfter": 0, (56)
                    "windowMs": 60000, (57)
                    "headersTimeout": 5000, (58)
                    "serverSetTimeout": 20000 (59)
                },
                "cors": { (60)
                    "origin": "*", (61)
                    "methods": ["GET", "POST", "PUT"] (62)
                }
            },
            "forging": {
                "access": { (63)
                    "whiteList": ["127.0.0.1"] (64)
                }
            }
        },
        "chain": { (65)
            "broadcasts": { (66)
                "active": true, (67)
                "broadcastInterval": 5000, (68)
                "parallelLimit": 20, (69)
                "releaseLimit": 25, (70)
                "relayLimit": 3 (71)
            },
            "transactions": {
                "maxTransactionsPerQueue": 1000 (72)
            },
            "forging": { (73)
                "force": false, (74)
                "delegates": [ (75)
                    {
                    "encryptedPassphrase": "iterations=1&salt=476d4299531718af8c88156aab0bb7d6&cipherText=663dde611776d87029ec188dc616d96d813ecabcef62ed0ad05ffe30528f5462c8d499db943ba2ded55c3b7c506815d8db1c2d4c35121e1d27e740dc41f6c405ce8ab8e3120b23f546d8b35823a30639&iv=1a83940b72adc57ec060a648&tag=b5b1e6c6e225c428a4473735bc8f1fc9&version=1",
                    "publicKey": "9d3058175acab969f41ad9b86f7a2926c74258670fe56b37c429c01fca9f2f0f"
                    }
                ],
                "defaultPassword": "elephant tree paris dragon chair galaxy" (76)
            },
            "syncing": {
                "active": true (77)
            },
            "loading": {
                "loadPerIteration": 5000, (78)
                "rebuildUpToRound": null (79)
            },
            "exceptions": { (80)
                "blockRewards": [],
                "senderPublicKey": [],
                "signatures": [],
                "signSignature": [],
                "multisignatures": [],
                "votes": [],
                "inertTransactions": [],
                "rounds": {},
                "precedent": { "disableDappTransfer": 0 },
                "ignoreDelegateListCacheForRounds": [],
                "blockVersions": {},
                "roundVotes": [],
                "recipientLeadingZero": {},
                "recipientExceedingUint64": {},
                "duplicatedSignatures": {},
                "transactionWithNullByte": []
            }
        },
        "network": { (81)
            "wsPort": 5000, (82)
            "address": "0.0.0.0", (83)
            "seedPeers": [ (84)
                {
                    "ip": "1.2.3.4", (85)
                    "wsPort": 4000 (86)
                }
            ],
            "blacklistedPeers": [ (87)
                {"ip": "9.8.7.6"} (88)
            ],
            "fixedPeers": [ (89)
                {"ip": "11.22.33.44"} (90)
            ],
            "whitelistedPeers": [ (91)
                {"ip": "66.77.88.99"} (92)
            ],
            "discoveryInterval": 30000, (93)
            "maxInboundConnections": 20, (94)
            "maxOutboundConnections": 20, (95)
            "peerBanTime": 86400, (96)
            "populatorInterval": 10000, (97)
            "emitPeerLimit": 25, (98)
            "peerDiscoveryResponseLength": 1000, (99)
            "maxPeerDiscoveryResponseLength": 1000, (100)
            "maxPeerInfoSize": 20480, (101)
            "wsMaxPayload": 3048576, (102)
            "ackTimeout": 20000, (103)
            "connectTimeout": 5000, (104)
            "wsEngine": "ws" (105)
        }
    }
}
1 Contains general application configurations.
2 Slot time interval in seconds.
3 Slot time interval in seconds.
4 Timestamp indicating the initial network start (Date.toISOString()).
5 Maximum number of transactions allowed per block.
6 Options about block rewards.
7 Distance between each milestone.
8 Initial 5, and decreasing until 1.
9 Initial Reward
10 Milestone 1
11 Milestone 2
12 Milestone 3
13 Milestone 4
14 Start rewards at block (n).
15 If true, allows modules to communicate over IPCs (inter-process-channels).
16 Contains configurations related to components.
17 Contains options for the logger component.
18 Minimum loglevel, that should be logged in the log file. Available values: trace, debug, log, info(default), warn, error, fatal, none.
19 define name and path of the log file. Default: logs/lisk.log
20 Minimum loglevel, that should be logged in the console, when starting the node. Available values: trace, debug, log, info, warn, error, fatal, none(default).
21 Contains options for the storage component.
22 The name of the database to use.
23 The host address of the database.
24 The port of the database.
25 Name of the database user.
26 Password of the datbase user.
27 Specifies the minimum amount of database handles.
28 Specifies the maximum amount of database handles.
29 This parameter sets how long to hold connection handles open
30 Closes & removes clients which have been idle > 1 second
31 Specify the minimal log level for database logs.
32 Relative path of the database log file.
33 Contains options for the cache component.
34 Set the number of databases for Redis to use. Min: 0 (default), Max: 15
35 If true, enables cache. Default: false
36 Redis host IP. Default: 127.0.0.1
37 Redis host port. Default: 6380
38 Contains configurations related to modules.
39 Contains options for the API module.
40 HTTP port, the node listens on.
41 Address of the API of the node.
42 Controls the API’s availability. If disabled, no API access is possible.
43 For nodes that sit behind a proxy. If true, client IP addresses are understood as the left-most entry in the X-Forwarded-* header.
44 Contains API access options.
45 If true, the API endpoints of the node are available to public.
46 This parameter allows connections to the API by IP. Defaults to only allow local host.
47 Options for enabling SSL with Lisk Core (alternative to enabling SSL through a Webserver).
48 Enables SSL for HTTP requests - Default is false.
49 Port to host the Lisk Wallet on, default is 443 but is recommended to use a port above 1024 with iptables.
50 Interface to listen on for the Lisk Wallet.
51 Required private key to decrypt and verify the SSL Certificate.
52 SSL certificate to use with the Lisk Wallet.
53 Limits for API connections.
54 Maximum of API conncections.
55 Minimum delay between API calls in ms.
56 Minimum delay after an API call in ms.
57 Minimum delay between API calls from the same window.
58 Indicating the minimum amount of time an idle connection has to be kept opened (in seconds).
59 Time to wait for response from server before timing out.
60 Options for cross-origin resource sharing.
61 Defines the domains, that the resource can be accessed by in a cross-site manner. Defaults to all domains.
62 Defines the allowed methods for CORS.
63 Define who can access the forging related API anedpoints of the node.
64 This parameter allows connections to the Forging API by IP. Defaults to allow only local connections.
65 Contains options for the chain module.
66 Options for broadcasting events to the network.
67 If true, enables broadcasts.
68 Specifies how often the node will broadcast transaction bundles.
69 Specifies how many parallel threads will be used to broadcast transactions.
70 How many transactions can be included in a single bundle.
71 Specifies how many times a transaction broadcast from the node will be relayed.
72 Sets the maximum size of each transaction queue. Default: 1000
73 Contains forging options for delegates.
74 Forces forging to be on, only used on local development networks.
75 List of delegates, who are allowed to forge on this node. To successfully enable forging for a delegate, the publickey and the encrypted passphrase need to be deposited here as JSON object.
76 Default password for dummy delegates, only used on local development networks.
77 If true, enables syncing (fallback for broadcasts).
78 How many blocks to load from a peer or the database during verification.
79 Integer. If this value is defined, the node will start and rebuild up to the defined round (set to 0 to rebuild until current round). Otherwise, the application continues normal execution.
80 Define network specific exceptions. More details about exceptions: https://github.com/LiskHQ/lisk-core/blob/v2.1.0/EXCEPTIONS.md
81 Contains network options for the node.
82 Websocket port of the node.
83 The host IP which the P2P server should listen on for inbound connections. This value is passed directly to the underlying Node.js server.listen function documented here: https://nodejs.org/api/net.html#net_server_listen_port_host_backlog_callback
84 A list of peers to use as seeds when starting the node for the first time. Should be an array of objects in the form: [{ip: '123.123.123.123', wsPort: 7000}, {ip: '111.111.111.111', wsPort: 8000}]
85 IP or address of the Seed Peer.
86 Port of the Seed Peer.
87 A list of peers to blacklist. Should be an array of objects in the form: [{ip: '123.123.123.123'}, {ip: '111.111.111.111'}]
88 IP or address of the blacklisted peer.
89 A list of peers to stay constantly connected to. Should be an array of objects in the form: [{ip: '123.123.123.123'}, {ip: '111.111.111.111'}]
90 IP or address of the blacklisted peer.
91 A list of peers which should never be banned. Should be an array of objects in the form: [{ip: '123.123.123.123'}, {ip: '111.111.111.111'}]
92 IP or address of the blacklisted peer.
93 Time interval(ms), in that the nodes performs peer discovery.
94 The maximum number of inbound peers/connections which the node should have. Should be an integer. Peers which initiate the connection to the node will be added to the node’s inbound list.
95 The maximum number of outbound peers/connections which the node should have. Should be an integer. The node will keep trying to connect to new peers until it reaches maxOutboundConnections.
96 The number of milliseconds to ban a peer for if its reputation score falls bellow 0.
97 How frequently (in milliseconds) to check and repopulate the outbound list (since peers can drop out over time).
98 When broadcasting a message such as a block or transaction to peers, this number determines how many peers to send it to at a time.
99 This number indicates the number of peer info which the node will send back to a peer when that peer requests the node’s peer list.
100 This number indicates the maximum number of peer info which we are prepared to receive from a single peer to populate our peer directory with during discovery.
101 The maximum size in bytes (integer) of a single peer info object. A peer info object has a flexible schema and can contain custom properties/data about the node.
102 The maximum size in bytes (integer) of any kind of message from a peer. If the peer tries to send a message greater than this value, they will be immediately disconnected.
103 When a node tries to make an RPC against a peer (and expects a response), this value determines the maximum amount of time (in milliseconds) that the node will wait to receive a response from the peer. If the peer does not respond in time, then the RPC will fail with an error.
104 When a node tries to connect to a peer, this value determines the maximum amount of time (in milliseconds) that the node will wait to complete the handshake with the peer. If the peer does not complete the handshake in time, then the connection will be closed.
105 Represents the low-level WebSocket engine which the node should use (for advanced users). Possible values are "ws" (default, recommended) and "uws" (more performant, but not compatible with all systems).

API Access Control

Controlling access to a node plays a vital role in security. The following configurable flags are available to control the access to your node:

{
  "modules": {
    "http_api": { (1)
      "enabled": true, (2)
      "access": { (3)
        "public": false, (4)
        "whiteList": ["127.0.0.1"], (5)
      },
    }
  }
}
1 Contains options for the API module.
2 Controls the API’s availability. If disabled, no API access is possible.
3 Contains API access options.
4 If true, the API endpoints of the node are available to public.
5 This parameter allows connections to the API by IP. Defaults to only allow local host.

The recommended setup is to configure a whitelist for only trusted IP addresses, such as your home connection. Use IPV4 addresses only as the whitelist does not support IPV6.

To set up a public wallet, simply leave the modules.http_api.access.whitelist array empty.

For best security, disable all access setting modules.http_api.enabled to false.

This last configuration may prevent monitoring scripts from functioning.

Forging

To enable your node to forge, you need first to insert some encrypted data into the config file under the chain.forging.delegates array. To encrypt your passphrase, we offer and recommend one of the following alternatives:

We explain further the first alternative. First, make sure you have installed Lisk Commander in a secure environment. Upon completion, please follow the commands below to generate the encrypted passphrase:

$ lisk
lisk passphrase:encrypt --output-public-key
Please enter your secret passphrase: *****
Please re-enter your secret passphrase: *****
Please enter your password: ***
Please re-enter your password: ***
{
        "encryptedPassphrase": "iterations=1000000&cipherText=30a3c8&iv=b0d7322bf24e0dfe08462f4f&salt=aa7e26c9f4317b61b4f45b5c6909f941&tag=a2e0eadaf1f11a10b342965bc3bafc68&version=1",
        "publicKey": "a4465fd76c16fcc458448076372abf1912cc5b150663a64dffefe550f96feadd"
}
  1. In the first step, type in your passphrase and then type in the password you want to use for encryption.

  2. Afterward, you will get an encryptedPassphrase key-value pair.

  3. Create the JSON object and add it to your config.json under chain.forging.delegates:

{
  "modules": {
    "chain": { (1)
      "forging": { (2)
        "force": false, (3)
        "delegates": [ (4)
            {
                "encryptedPassphrase": "iterations=1&salt=476d4299531718af8c88156aab0bb7d6&cipherText=663dde611776d87029ec188dc616d96d813ecabcef62ed0ad05ffe30528f5462c8d499db943ba2ded55c3b7c506815d8db1c2d4c35121e1d27e740dc41f6c405ce8ab8e3120b23f546d8b35823a30639&iv=1a83940b72adc57ec060a648&tag=b5b1e6c6e225c428a4473735bc8f1fc9&version=1",
                "publicKey": "9d3058175acab969f41ad9b86f7a2926c74258670fe56b37c429c01fca9f2f0f"
            }
        ],
      },
    },
    "http_api": { (5)
      "forging": {
        "access": {
          "whiteList": ["127.0.0.1", "REPLACE_ME"], (6)
        },
      },
    }
  }
}
1 Contains options for the chain module.
2 Contains forging options for delegates.
3 Forces forging to be on, - only used on local development networks.
4 List of delegates, who are allowed to forge on this node. To successfully enable forging for a delegate, the publickey and the encrypted passphrase need to be deposited here as JSON object.
5 Contains options for the API module.
6 Replace with the IP you will use to access your node
  1. Reload your Lisk Core process to make the changes in the config effective, e.g. for Binary install, run: bash lisk.sh reload

Check Forging

Use the following curl command to verify the forging status of your delegate:

curl \
  http://127.0.0.1:7000/api/node/status/forging \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json'

The result should be something like this:

{
  "meta": {},
  "data": [
    {
      "forging": true,
      "publicKey": "9bc945f92141d5e11e97274c275d127dc7656dda5c8fcbf1df7d44827a732664"
    }
  ],
  "links": {}
}

Enable/Disable Forging

Remember that after restarting your Lisk node, you need to re-enable forging again.

The endpoint to perform this action is idempotent.

That means, the result is the same, no matter how many times you execute the query.

If you are running your Lisk Node from a local machine, you can enable forging through the API client, without further interruption.

Use the following curl command to enable the forging for your delegate:

curl -X PUT \
  http://127.0.0.1:7000/api/node/status/forging \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
          "publicKey": "YYYYYYYYY",
          "password": "XXX",
          "forging": true
      }'

Use the following curl command to disable the forging for your delegate:

curl -X PUT \
  http://127.0.0.1:7000/api/node/status/forging \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
          "publicKey": "YYYYYYYYY",
          "password": "XXX",
          "forging": false
      }'
  • Where publicKey is the key for the delegate you want to enable/disable

  • password is the password used to encrypt your passphrase in config.json

  • forging is the boolean value to enable or disable the forging

  • HTTP Port can be different based on your configuration, so check httpPort in your config.json

SSL

We recommend to use a webserver like NGINX or Apache to set up SSL for Lisk Core. If you don’t have that opportunity, it’s possible to configure Lisk Core to handle SSL connections like described below.

This step requires a signed certificate (from a CA, such as Let’s Encrypt) or a self-signed certificate. You will need both the private and public keys in a location that is accessible to Lisk.

The next snippet highlights the essential parameters to enable SSL security on your node’s connections:

SSL Configuration

{
  "modules": {
      "http_api": {
          "ssl": {
              "enabled": false,           (1)
              "options": {
                  "port": 443,            (2)
                  "address": "0.0.0.0",   (3)
                  "key": "path_to_key",   (4)
                  "cert": "path_to_cert"  (5)
              }
          }
      }
  }
}
1 Change FROM false TO true
2 Default SSL Port
3 Change only if you wish to block web access to the node
4 Replace FROM path_to_key TO actual path to key file
5 Replace FROM path_to_cert TO actual path to certificate file
If the SSL Port configured above in http_api.ssl.options.port is a privileged port (below 1024), you must either allow the node to use the specified port with setcap or change the configuration to use a port outside of that range.

Setcap: Only required to grant Lisk access to port 443

 sudo setcap cap_net_bind_service=+ep bin/node

To verify all you have properly configured your node, open the web client using https://MY_IP_OR_HOST. You should now see a secure SSL connection.

Logging

For monitoring or debugging your node, Lisk Core tracks all activity that happens in the node by creating log messages for them.

These log messages are grouped in different log levels, which makes it easy to define the level of detail for the logs.

We use Bunyan as logging library. Bunyan allows simple and fast JSON logging for Node.js services.

Log Levels

Log Level Description

None

No events are logged.

Fatal(60)

The node is going to stop or become unusable now. An operator should definitely look into this soon.

Error(50)

Fatal for a particular request, but the node continues servicing other requests. An operator should look at this soon(ish).

Warn(40)

A note on something that should probably be looked at by an operator eventually.

Info(30)

Detail on a regular operation.

Debug(20)

Anything else, i.e. too verbose to be included in ``info'' level.

Trace(10)

Logging from external libraries used by your node or very detailed application logging.

Logging destinations

There are two possible output sources for logs: The file log stream and the console log stream. Each output source can be configured independently inside of config.json under the options for the logger component.

Console log stream

The console log level displays the logs directly to the console where the Lisk Core process is started from. It is useful for quick debugging or verifying that Lisk Core starts correctly. Default log level for the console log stream is none.

Example: Display the console log stream:

node dist/index.js | npx bunyan  (1)
1 Pretty-prints console logs with log level equal or higher to the console log level.

For more information about the Bunyan CLI tool, please check out the official Bunyan Documentation.

File log stream

All logs that have equal or higher log levels than the in config.json specified file log level are saved in a .log-file for further analysis. By default, the generated log files are saved inside of the logs folder of Lisk Core. Default log level for the file log stream is info.

The file log stream is perfect to monitor the node via logs.

Logrotation

It is recommended to set up some form of log rotation for the log files of Lisk Core. If no log rotation is set up, the log files may grow very big over time (depending on the specified file log level), and will eventually exceed the servers’ disk space limits.

Ubuntu systems, e.g. provide a service called logrotate for this purpose. Please ensure Logrotate is installed on your system:

logrotate --version

Next, go to the logrotate config directory and create a new logrotate file for Lisk Core:

cd /etc/logrotate.d
touch lisk

Inside this file, define the parameters for the log rotation.

Example values:

/path/to/lisk/logs/mainnet/*.log {
        daily                   (1)
        rotate 5                (2)
        maxage 14               (3)
        compress                (4)
        delaycompress           (5)
        missingok               (6)
        notifempty              (7)
}
1 daily rotation
2 keep the 5 most recent logs
3 remove logs that are older than 14 days
4 compress old log files
5 compress the data after it has been moved
6 if no log file is present, ignore
7 do not rotate empty log files

After customizing the config to fit your needs and saving it, you can test it by doing a dry run:

sudo logrotate /etc/logrotate.conf --debug