Lisk Core Configuration

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

Command Line Options

Please note, there are numerous options available that can be deployed to override the configuration on the runtime whilst starting the Lisk Core.

To overwrite config options from the Command Line, execute the following commands below:

  • 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. Therefore it is recommend to pass 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 are restricted with a operating system constraint of ENV variable maximum length.

Comma-separated lists will replace the original config values. For example, If LISK_PEERS is specified, the original peers.list specific to the network will be replaced completely.

Each of these options listed below can be appended in the command line:

Command line Option ENV Variable Description

--network
-n

LISK_NETWORK

Any of these options can be used devnet, alphanet, betanet, testnet and mainnet. The default value is devnet.

--config
-c

LISK_CONFIG_FILE

Pass the custom configuration file, which will override values of the following: 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 following 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 the 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. To connect to another network, specify the network when starting the Lisk Core, as described in Source Administration. The network specific configurations can be found under config/<network>/config.json, whereby <network> can be any of these values listed below:

  • devnet

  • alphanet

  • betanet

  • testnet

  • mainnet

Do not override any value in the files mentioned above, as the changes will be overwritten everytime the Lisk Core is upgraded. If a custom configuration is required, use the environment variables or alternatively create your own .json file and pass it as command line option.

Custom config file

To use a custom config, firstly create a .json-file. Further information can be found in the Config Structure section.

Only the values required to be updated are needed, as for all other options the pre-defined values will be used as described in the 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 as 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.

For example, Lisk Core for Mainnet is installed under ~/lisk-main, and the config is stored directly in ~/lisk-main/config.json

The config.json will be used automatically when reloading the node with the following command:

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.

For example, Lisk Core for Mainnet is installed under ~/.lisk/instances/lisk-mainnet, and the config is stored directly in ~/.lisk/instances/lisk-main/config.json

The config.json will be used automatically when reloading the node with the following command:

pm2 stop lisk (1)
LISK_CONFIG_FILE=<CONFIG_PATH> pm2 start lisk (2)
1 Stop Lisk Core in the case whereby 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 listed below. Each configuration 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

A breakdown of the code structure can be seen below:

{
    "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 The HTTP port that 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 connections.
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 Defines who can access the forging related API end points 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 a 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. The listen function is documented in the following link: 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. This 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. This should be an array of objects in the following 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. This should be an array of objects in the following 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. This should be an array of objects in the following form: [{ip: '123.123.123.123'}, {ip: '111.111.111.111'}]
92 IP or address of the blacklisted peer.
93 Time interval in milliseconds,(ms) whereby the nodes performs peer discovery.
94 The maximum number of inbound peers/connections which the node should have. This 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. This should be an integer. The node will keep trying to connect to new peers until it reaches the maximum number of outbound connections.
96 The number of milliseconds to ban a peer for, in the case whereby its reputation score falls below 0.
97 How frequently, (in milliseconds) the outbound list is checked and repopulated, (as peers can drop out over a period of time).
98 When broadcasting a message such as a block or transaction to peers, this number determines how many peers it will be sent to.
99 This number indicates the amount of peer information which the node will send back to a peer, when that peer requests the node’s peer list.
100 This number indicates the maximum amount of peer information which can be received from a single peer, to populate the peer directory with during discovery.
101 The maximum size in bytes, (integer), of a single peer information object. A peer information object has a flexible schema, and can contain custom properties/data about the node.
102 The maximum size in bytes, (integer) of any type of message from a peer. If the peer tries to send a message greater than this value, it 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 (This value offers greater performance, however it is 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 optimal 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, firstly it is required to insert some encrypted data into the config file under the chain.forging.delegates array. To encrypt your passphrase, it is recommended to use one of the following alternatives listed below:

The first alternative with the Lisk Commander is described in detail below. Please ensure the Lisk Commander is installed in a secure environment. Upon completion, please follow these commands 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. Type in your passphrase followed by the password required for encryption.

  2. This will result in the creation of an encryptedPassphrase key-value pair.

  3. Create the JSON object and add it to your config.json under chain.forging.delegates as can be seen below:

{
  "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'. This is only used on local development networks.
4 The list of delegates who are allowed to forge on this node. To successfully enable forging for a delegate, the public key and the encrypted passphrase need to be deposited here as a JSON object.
5 Contains options for the API module.
6 Replace with the IP which will be used to access your node
  1. Reload your Lisk Core process to make the changes in the config effective. For example, for Binary install, run the following command: bash lisk.sh reload

Check Forging

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

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

The result should appear as shown below in the following code snippet:

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

Enable/Disable Forging

Remember that after restarting your Lisk node, it is necessary to re-enable forging again.

The endpoint to perform this action is idempotent.

This means that the results are identical, regardless of how many times the query is executed.

If your Lisk Node is running on a local machine, it is possible to enable forging through the API client, without any further interruption.

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

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 as shown below:

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
      }'
  • publicKey is the key for the delegate which is required to be enabled/disabled.

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

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

  • The HTTP Port can be different based on your configuration, therefore it is recommended to check the httpPort in your config.json

SSL

It is recommended to use a webserver such as NGINX or Apache to set up the SSL for the Lisk Core. If that opportunity is not available then it is also possible to configure the Lisk Core to handle SSL connections as described below:

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

The following code snippet listed below displays the essential parameters required 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 it is required to block web access to the node.
4 Replace path_to_key with the actual path to the key file.
5 Replace path_to_cert with the actual path to the certificate file.
If the SSL Port configured above in http_api.ssl.options.port is a privileged port, (below 1024), then either the node must be allowed to use the specified port with setcap, or the configuration must be changed in order to to use a port outside of that range.

Setcap: This is only required to grant Lisk access to port 443.

 sudo setcap cap_net_bind_service=+ep bin/node

To verify your node has been configured correctly, open the web client using this url: https://MY_IP_OR_HOST. A secure SSL connection should now be visible.

Logging

For monitoring or debugging your node, Lisk Core tracks all activities that occur within the node by creating applicable log messages.

These log messages are grouped in different log levels. Hence, this makes it easy to define the level of the log details.

Bunyan is used for the logging library, as this 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. This requires the operator to investigate the problem.

Error(50)

Fatal for a particular request, however the node continues servicing other requests. This also requires the operator to investigate the problem, although it does not necessarily require immediate attention.

Warn(40)

A warning indication that should be investigated 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 else very detailed application logging.

Logging destinations

There are two possible output sources for the 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 from where the Lisk Core process is started. It is useful for quick debugging or verifying that Lisk Core starts correctly. Default log level for the console log stream is none.

An example command displaying the console log stream can be seen below:

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 regarding the Bunyan CLI tool, please refer to 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 can be used 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 log rotation is not initiated, then the log files may grow very large over time, (depending on the specified file log level), and hence will eventually exceed the server’s disk space limits.

For example, Ubuntu systems  provide a service called logrotate specifically for this purpose. Please ensure Logrotate is installed on your system as shown below:

logrotate --version

Now go to the logrotate config directory and create a new logrotate file for Lisk Core as shown below:

cd /etc/logrotate.d
touch lisk

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

Example values can be seen below:

/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 Keeps the last 5 most recent logs.
3 Removes logs that are older than 14 days.
4 Compresses old log files.
5 Compresses the data after it has been moved.
6 If no log file is present, then it is ignored.
7 Does not rotate empty log files.

After customizing and saving the config to fit your requirements, it is recommended to test it by doing a dry run using the following command listed below:

sudo logrotate /etc/logrotate.conf --debug