On This Page

Home / Cribl as Code/ Code Examples/Configure Resources

Configure Resources

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 a Syslog Source, an S3 Destination, a Pipeline, and a Route 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 resources.

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

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

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

Configure Resources with the Python SDK

This example demonstrates how to use the Python SDK for the control plane to create the following resources in Cribl Stream:

  • A Worker Group to manage the configuration.
  • A Syslog Source to receive data on port 9021.
  • An S3 Destination to store processed data.
  • A Pipeline that filters events and keeps only data in the eventSource and eventID fields.
  • A Route that connects the Source, Pipeline, and Destination.

This example also deploys the resource configurations to a Worker Group to make them active.

Python SDK (Cribl.Cloud)Python SDK (On-Prem Deployment)

Configure Resources with the Cribl API

The example requests in this section demonstrate how to use the Cribl API to create the following resources in Cribl Stream:

  • A Syslog Source to receive data on port 9021.
  • An S3 Destination to store processed data.
  • A Pipeline that filters events and keeps only data in the eventSource and eventID fields.
  • A Route that connects the Source, Pipeline, and Destination.

The example also deploys the resource configurations to a Worker Group to make them active.

The examples use the Worker Group created in Configure Worker Groups to manage the resource configuration.

Create a Source

This example creates a Syslog Source to receive data on port 9021.

API (Cribl.Cloud and Hybrid)API (On-Prem)

Create a Destination

This example creates an S3 Destination to store processed data. Replace placeholder values like your-aws-api-key before you run the example.

API (Cribl.Cloud and Hybrid)API (On-Prem)

Create a Pipeline

This example creates a Pipeline that filters events and keeps only data in the eventSource and eventID fields.

API (Cribl.Cloud and Hybrid)API (On-Prem)

Create a Route

This example creates a Route that connects the Syslog Source, Pipeline, and S3 Destination and adds it to the end of the default Routing table. The Routing table already includes a default Route, so this request changes the default Route’s setting for final to false so that it won’t block the new Route.

The PATCH /routes/default endpoint requires a complete representation of the Routing table and its existing Routes in the request body. This endpoint does not support partial updates. Cribl removes any omitted fields when updating the Routing table. Use GET /routes/default to retrieve the existing Routing table to use in the body of the PATCH request.

API (Cribl.Cloud and Hybrid)API (On-Prem)

Commit and Deploy the Resource Configurations

This example demonstrates how to commit and deploy the resource configurations to your Worker Group, then commit to the Leader to keep it in sync with the Worker Group.

Committing and deploying the Worker Group configuration requires three requests: commit to the Worker Group, deploy to the Worker Group, and commit the the Leader to keep it in sync.

First, commit the pending resource configurations to the Worker Group:

API (Cribl.Cloud and Hybrid)API (On-Prem)

Next, 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/Hybrid)API (On-Prem)

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

API (Cribl.Cloud/Hybrid)API (On-Prem)