On This Page

Home / Cribl as Code/ Code Examples/Configure Worker Groups

Configure Worker Groups

Preview Feature

The Cribl SDKs are Preview features that are still being developed. We do not recommend using them in a production environment, because the features might not be fully tested or optimized for performance, and related documentation could be incomplete.

Please continue to submit feedback through normal Cribl support channels, but assistance might be limited while the features remain in Preview.

These code examples demonstrate how to use the Cribl Python SDK for the control plane or the Cribl API to configure, scale, and replicate Worker Groups in Cribl Stream.

About the Code Examples

The code examples use Bearer token authentication. Read the authentication documentation for the API or SDKs to learn how to configure authentication. The Permissions granted to your Bearer token must include creating and managing Worker Groups.

Replace the variables in the examples with the corresponding information for your Cribl deployment.

For customer-managed deployments, to use https in the URLs, you must configure Transport Layer Security (TLS).

The configurations in the examples do not include all available body parameters. For a complete list of body parameters for each endpoint, refer to the documentation in the API Reference.

Configure Worker Groups with the Python SDK

The examples in this section demonstrate how to create, scale, replicate, and deploy Worker Groups using the Cribl Python SDK for the control plane.

The examples for creating and scaling a Worker Group on Cribl.Cloud include the estimatedIngestRate property, which allows you to configure Worker Groups for optimal performance. For each supported estimatedIngestRate value, the following table maps the corresponding throughput and number of Worker Processes:

estimatedIngestRateThroughputWorker Processes
102412 MB/s6
204824 MB/s9
307236 MB/s14
409648 MB/s21
512060 MB/s30
716884 MB/s45
10240120 MB/s62
13312156 MB/s93
15360180 MB/s186

1. Create a Worker Group

This example creates a new Worker Group in Cribl Stream.

In the Cribl.Cloud example, the estimatedIngestRate is set to 2048, which is equivalent to a maximum of 24 MB/s with nine Worker Processes. In the customer-managed deployment example, the new Worker Group is created with eight Workers.

Python SDK (Cribl.Cloud)Python SDK (Customer-Managed Deployment)

2. Scale and Provision the Worker Group

The Cribl.Cloud example scales the Worker Group to an estimatedIngestRate of 4096, which is equivalent to a maximum of 48 MB/s with 21 Worker Processes. The example also sets provisioned to true to activate Cribl.Cloud resources.

The Cribl SDKs do not support scaling Worker Groups in customer-managed deployments.

The groups.update method requires a complete representation of the Worker Group that you want to update in the request body. This method does not support partial updates. Cribl removes any omitted fields when updating the Worker Group to scale and provision it.

Python SDK (Cribl.Cloud)

3. Replicate a Worker Group

This example uses the following operations to programmatically create a replica Worker Group in Cribl Stream based on an existing Worker Group configuration:

  1. Retrieve a list of all Worker Groups in Cribl Stream.
  2. Select the first Worker Group in the list as the source Worker Group to replicate.
  3. Retrieve the complete configuration of the source Worker Group.
  4. Create a new Worker Group that uses the same configuration as the source Worker Group. The replica Worker Group has a unique ID and a name and description that identify it as a replica.

To run this example, you must have at least one existing Worker Group in Cribl Stream.

Python SDK (Cribl.Cloud)Python SDK (Customer-Managed Deployment)

4. Confirm the Worker Group Configuration

Use this example to retrieve a list of all Worker Groups in Cribl Stream so that you can review and confirm their configurations.

Python SDK (Cribl.Cloud)Python SDK (Customer-Managed Deployment)

5. Commit and Deploy the Worker Group

This example demonstrates how to commit and deploy the Worker Group configuration, then commit to the Leader to keep it in sync with the Worker Group. You can commit and deploy immediately after a single create or update request or after multiple requests.

Committing and deploying the Worker Group configuration requires three requests, which the Python SDK example chains together:

  1. Commit pending changes to the Worker Group. This request commits only the configuration changes for Worker Groups by specifying the file local/cribl/groups.yml.
  2. Deploy the committed changes to the Worker Group. This request includes the version body parameter, which uses the value of commit from the response body for the commit request.
  3. Commit the changes to the Leader to keep the Leader in sync with the Worker Group.
Python SDK (Cribl.Cloud)Python SDK (Customer-Managed Deployment)

Configure Worker Groups with the Cribl API

The examples in this section demonstrate how to create, scale, replicate, and deploy Worker Groups using the Cribl API.

The examples for creating and scaling a Worker Group on Cribl.Cloud include the estimatedIngestRate property, which allows you to configure Worker Groups for optimal performance. For each supported estimatedIngestRate value, the following table maps the corresponding throughput and number of Worker Processes:

estimatedIngestRateThroughputWorker Processes
102412 MB/s6
204824 MB/s9
307236 MB/s14
409648 MB/s21
512060 MB/s30
716884 MB/s45
10240120 MB/s62
13312156 MB/s93
15360180 MB/s186

1. Create a Worker Group

This example creates a new Worker Group in Cribl Stream.

In the Cribl.Cloud example, the estimatedIngestRate is set to 2048, which is equivalent to a maximum of 24 MB/s with nine Worker Processes. In the customer-managed deployment example, the new Worker Group is created with eight Workers.

API (Cribl.Cloud)API (Customer-Managed)

2. Scale and Provision the Worker Group

The Cribl.Cloud example scales the Worker Group to an estimatedIngestRate of 4096, which is equivalent to a maximum of 48 MB/s with 21 Worker Processes. The example also sets provisioned to true to activate Cribl.Cloud resources.

The customer-managed deployment example scales the Worker Group to 11 Workers.

The PATCH /products/{product}/groups/{id} endpoint requires a complete representation of the Worker Group that you want to update in the request body. This endpoint does not support partial updates. Cribl removes any omitted fields when updating the Worker Group to scale it.

API (Cribl.Cloud)API (Customer-Managed)

3. Replicate the Worker Group

Using the API to create a replica Worker Group in Cribl Stream based on an existing Worker Group configuration requires the following requests:

  1. Retrieve a list of all Worker Groups to identify the source Worker Group that you want to replicate.
  2. Retrieve the complete configuration of the source Worker Group.
  3. Create a new Worker Group that uses the same configuration as the source Worker Group.

To use these examples, you must have at least one existing Worker Group in Cribl Stream.

First, retrieve a list of all Worker Groups in Cribl Stream to identify the source Worker Group that you want to replicate. The response to this request includes the id for each Worker Group. You need the id of the source Worker Group to retrieve its configuration in the next request.

If you already know the id of the Worker Group that you want to replicate, you can skip this and proceed with the next request.

API (Cribl.Cloud)API (Customer-Managed)

Next, retrieve the complete configuration of the source Worker Group using its id. In this example, the id is my-worker-group.

API (Cribl.Cloud)API (Customer-Managed)

Finally, copy the configuration for the source Worker Group from the response to the previous request to use as the basis for the replica Worker Group. Update the id and name to use unique values and add a description that identifies the Worker Group as a replica. Remove any read-only attributes like lookupDeployments, workerCount, and configVersion.

API (Cribl.Cloud)API (Customer-Managed)

4. Confirm the Worker Group Configuration

Use this example to retrieve a list of all Worker Groups in Cribl Stream so that you can review and confirm their configurations.

API (Cribl.Cloud)API (Customer-Managed)

5. Commit and Deploy the Worker Group

This example demonstrates how to commit and deploy the Worker Group configuration, then commit to the Leader to keep it in sync with the Worker Group. You can commit and deploy immediately after a single create or update request or after multiple requests.

First, commit pending changes to the Worker Group. This request commits only the configuration changes for Worker Groups by specifying the file local/cribl/groups.yml.

API (Cribl.Cloud)API (Customer-Managed)

Second, deploy the committed changes to the Worker Group. This request includes the version body parameter, which uses the value of commit from the response body for the commit request.

API (Cribl.Cloud)API (Customer-Managed)

Finally, commit the changes to the Leader to keep the Leader in sync with the Worker Group.

API (Cribl.Cloud)API (Customer-Managed)