Cribl Stream configurations are deployed after the bundle containing them is saved and committed. Deploying here means propagating updated configurations to Worker Nodes.

The typical workflow for deploying Cribl Stream configurations is the following:

1. Configure.
2. Save.
3. Commit (and optionally push).
4. Deploy.

You deploy new configurations at the Worker Group level: Locate the desired Worker Group and select Deploy. Worker Nodes that belong to the group will start pulling updated configurations on their next check-in with the Leader Node.

Can’t Log In to the Worker Node as Admin User? ​

When a Worker Node pulls its first configuration, the admin password will be randomized, unless specifically changed. This means that users won’t be able to log in on the Worker Node with default credentials. For details, see Set Worker/Edge Node Passwords.

Configuration and Lookup File Locations ​

When deployed via the Leader Node, lookup files are distributed to Worker Nodes as part of a configuration deployment.

If you want your lookup files to be part of the Cribl Stream configuration version control process, we recommended deploying using the Leader Node. Alternatively, you can update your lookup file on the individual Worker Nodes, which can be useful for larger lookup files (greater than 10 MB, for example), for lookup files maintained using some other mechanism, or for lookup files that are updated frequently.

For other options, see About Lookups.

Some configuration changes will require restarts, while many others require only reloads. See Configurations and Restart for details.

Restarts and reloads of each Worker Process are handled automatically by the Worker Node. Note that individual Worker Nodes might temporarily disappear from the Leader’s Workers tab while restarting.

Worker Process Rolling Restart ​

How a Worker Node restarts its Worker Processes depends on whether the restart involves the API Process.

Restarts That Don’t Involve the API Process ​

These restarts roll out gradually to minimize disruption and keep as much processing capability online as possible:

• By default, processes restart in batches of 20% of the running total, with at least one process per batch. To change this fraction, use the workerProcessConfigUpdateConcurrency advanced setting under Worker Processes. Consult Cribl Support before adjusting it.
• Every Worker Process in a batch must come up and report as started before the next batch begins.
• The rolling restart continues until all processes have restarted.
• If a Worker Process fails to restart, Cribl Stream rolls back the configuration.

Restarts That Involve the API Process ​

These restarts are not rolling. All Worker Processes stop before the API Process can restart. Once the API Process restarts, it starts up all Worker Processes.