daemon mode processes data in the background, without any live output. This mode is used in scenarios where you need to continuously bridge blockchain data with other persistence mechanisms or to trigger an automated process in response to a particular event pattern.
Start Daemon Mode
To start Oura in daemon mode, use the following command:
--config: path of a custom toml configuration file to use. If not specified, configuration will be loaded from
--cursor: a custom point in the chain to use as starting point. Expects format:
slot,hex-hash. If not specified, it will look for the cursor section available via toml configuration or fallback to the intersect options of the source stage.
Example of starting daemon mode with default config file:
# config will be loaded from /etc/oura/daemon.toml oura daemon
Example of starting daemon mode with a custom config file at
oura daemon --config my_config.toml
Example of starting daemon mode specifying a particular cursor:
oura daemon --cursor 56134714,2d2a5503c16671ac7d5296f8e6bfeee050b2c2900a7d8c97b36c434667eb99d9
The configuration file needs to specify the source, filters and sink to use in a particular pipeline. The following toml represent the typical skeleton of an Oura config file:
[source] type = "X" # the type of source to use # custom config fields for this source type foo = "abc" bar = "xyz" [[filters]] type = "Y" # the type of filter to use # custom config fields for this filter type foo = "123" bar = "789" [sink] # the type of sink to use type = "Z" # custom config fields for this sink type foo = "123" bar = "789" # optional cursor settings, remove seaction to disable feature [cursor] type = "File" path = "/var/oura/cursor"
This section specifies the origin of the data. The special
type field must always be present and containing a value matching any of the available built-in sources. The rest of the fields in the section will depend on the selected
type. See the sources section for a list of available options and their corresponding config values.
This section specifies a collection of filters that are applied in sequence to each event. The special
type field must always be present and containing a value matching any of the available built-in filters. Notice that this section of the config is an array, allowing multiple filter sections per config file. See the filters section for a list of available options and their corresponding config values.
This section specifies the destination of the data. The special
type field must always be present and containing a value matching any of the available built-in sinks. The rest of the fields in the section will depend on the selected
type. See the sinks section for a list of available options.
This section specifies how to configure the cursor feature. A cursor is a reference of the current position of the pipeline. If the pipeline needs to restart for whatever reason, and a cursor is available, the pipeline will start reading from that point in the chain. Removing the section from the config will disable the cursor feature.
Here's an example configuration file that uses a Node-to-Node source and output the events into a Kafka sink:
[source] type = "N2N" address = ["Tcp", "relays-new.cardano-mainnet.iohk.io:3001"] magic = "mainnet" [[filters]] type = "Fingerprint" [[filters]] type = "Selection" predicate = "variant_in" argument = ["Block", "Transaction"] [sink] type = "Kafka" brokers = ["127.0.0.1:53147"] topic = "testnet"