Cribl puts your IT and Security data at the center of your data management strategy and provides a one-stop shop for analyzing, collecting, processing, and routing it all at any scale. Try the Cribl suite of products and start building your data engine today!
Learn more ›Evolving demands placed on IT and Security teams are driving a new architecture for how observability data is captured, curated, and queried. This new architecture provides flexibility and control while managing the costs of increasing data volumes.
Read white paper ›Cribl Stream is a vendor-agnostic observability pipeline that gives you the flexibility to collect, reduce, enrich, normalize, and route data from any source to any destination within your existing data infrastructure.
Learn more ›Cribl Edge provides an intelligent, highly scalable edge-based data collection system for logs, metrics, and application data.
Learn more ›Cribl Search turns the traditional search process on its head, allowing users to search data in place without having to collect/store first.
Learn more ›Cribl Lake is a turnkey data lake solution that takes just minutes to get up and running — no data expertise needed. Leverage open formats, unified security with rich access controls, and centralize access to all IT and security data.
Learn more ›The Cribl.Cloud platform gets you up and running fast without the hassle of running infrastructure.
Learn more ›Cribl.Cloud Solution Brief
The fastest and easiest way to realize the value of an observability ecosystem.
Read Solution Brief ›AppScope gives operators the visibility they need into application behavior, metrics and events with no configuration and no agent required.
Learn more ›Explore Cribl’s Solutions by Use Cases:
Explore Cribl’s Solutions by Integrations:
Explore Cribl’s Solutions by Industry:
Watch On-Demand
3 ways to fast-track your data lake strategy without being a data expert
Watch On-Demand ›Try Your Own Cribl Sandbox
Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Get inspired by how our customers are innovating IT, security and observability. They inspire us daily!
Read Customer Stories ›Sally Beauty Holdings
Sally Beauty Swaps LogStash and Syslog-ng with Cribl.Cloud for a Resilient Security and Observability Pipeline
Read Case Study ›Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Transform data management with Cribl, the Data Engine for IT and Security
Learn More ›Cribl Corporate Overview
Cribl makes open observability a reality, giving you the freedom and flexibility to make choices instead of compromises.
Get the Guide ›Stay up to date on all things Cribl and observability.
Visit the Newsroom ›Cribl’s leadership team has built and launched category-defining products for some of the most innovative companies in the technology sector, and is supported by the world’s most elite investors.
Meet our Leaders ›Join the Cribl herd! The smartest, funniest, most passionate goats you’ll ever meet.
Learn More ›Whether you’re just getting started or scaling up, the Cribl for Startups program gives you the tools and resources your company needs to be successful at every stage.
Learn More ›Want to learn more about Cribl from our sales experts? Send us your contact information and we’ll be in touch.
Talk to an Expert ›At the beginning of November, we announced the availability of a Helm chart to install and run a LogStream worker group on Kubernetes. That was the first of a few things you’re going to see from Cribl with regard to Kubernetes. The next one is the availability of a Helm chart to install and configure a Cribl LogStream master instance on a Kubernetes cluster, and I’m happy to announce that that is available now in our helm-charts
repository.
The logstream-master
helm chart is a simple way to install and do basic configuration on a Cribl LogStream master instance. It allows you to, with a single command line, spin up a master node, install a license key, configure one or more worker group configurations, and set the instances’ admin password and master authentication key. If you wanna just skip to the Helm chart, take a look at the Helm Chart repo.
Unlike the logsteam-workergroup helm chart, this chart has a requirement for maintaining state. In the 2.3 release of LogStream, there are four directories where state is maintained:
We looked at two different mechanisms for maintaining the state information – 1) use an external git repository to “rehydrate” the instance upon creation, or 2) use persistent storage that can be mounted on the master pod as part of its lifecycle. For the helm chart, we chose the persistent storage approach for simplicity. Also, this way the helm chart does not require a LogStream Enterprise license (remote git access is an Enterprise feature).
Due to this requirement for persistent storage, you’ll need to set up a (preferably default) storage class. The implementation details will be different for each Kubernetes cluster, but in our case, we’re using AWS’s EKS service, the EBS CSI driver, and a default storage class called ebs-sc
. Make sure to understand the limitations and challenges for the storage driver you use. (For example, with EKS and EBS as the storage class, it’s very important that your cluster is “AZ aware”, or you’ll run into problems with nodes not being able to mount the storage volumes.)
While LogStream is typically configured in the UI, the logstream-master
helm chart provides a few options to “preconfigure” the instance. These can all be configured either by creating a values
file and giving helm install
the -f <filename>
option, or via the --set
argument. The overridable values for “preconfiguration” are:
Value | Use |
---|---|
config.adminPassword
|
The password you want set for the LogStream admin user. |
config.token
|
The auth key to set up for worker access. Setting this value will configure the instance as a “master” node. |
config.license
|
The license for your LogStream instance. If you do not set this, it will default to the “free” license. |
config.groups
|
The group names to configure for the master instance. This will create a mapping for each group, which looks for the tag <groupname> , and will create the basic structure of each group’s configuration. |
The combination of both the logstream-workergroup and logstream-master helm charts gives us a very simple and quick way to deploy a distributed LogStream environment. Let’s say that we want to create a complete distributed environment with one worker group (named all-logs
), and we want to use a generated UUID as our authentication key,
We also like using namespaces to achieve a modicum of isolation, so let’s start out by creating a logstream
namespace, via the kubectl
command:
kubectl create namespace logstream
And, we’ll use the uuid
command to generate an auth key:
helm-charts% uuid
e448c60a-2d24-11eb-a601-c78b7f337b04
Now, we’ll use the helm
command to install the master instance:
helm install ls-master cribl/logstream-master --set config.token="e448c60a-2d24-11eb-a601-c78b7f337b04" --set config.groups=\{all-logs\} --set config.license="<license key>"
Now, if you look at the output from kubectl get all -n logstream
, you’ll see something like this:
helm-charts% kubectl get all -n logstream
NAME |
READY |
STATUS |
RESTARTS |
AGE |
||
pod/ls-master-57744fcf45-qmrkn |
1/1 |
Running |
0 |
113s |
NAME |
TYPE |
CLUSTER-IP |
EXTERNAL-IP |
PORT(S) |
AGE |
||
service/ls-master |
LoadBalancer |
172.20.137.83 |
a15<...>.us-west-2.elb.amazonaws.com |
9000:32233/TCP |
113s |
||
service/ls-master-internal |
LoadBalancer |
172.20.95.84 |
a9c<...>.us-west-2.elb.amazonaws.com |
9000:30564/TCP |
4200:32002/TCP |
113s |
NAME |
READY |
UP-TO-DATE |
AVAILABLE |
AGE |
||
deployment.apps/ls-master |
1/1 |
1 |
1 |
114s |
NAME |
DESIRED |
CURRENT |
READY |
AGE |
replicaset.apps/ls-master-57744fcf45 |
1 |
1 |
1 |
114s |
You may notice that there are two services defined:
ls-master
ls-master-internal
Those services are named after the helm chart “release” that was specified in the helm install command. Since we used ls-master
, the primary service is the ls-master
service. This service is intended for end-user access to the LogStream instance, and exposes the 9000 TCP port. The other service is ls-master-internal
, which exposes the 9000 AND the 4200 TCP ports, and is intended as the endpoint for worker groups to connect to.
Now, to create our worker group, we simple run the helm install
command for the logstream-workergroup
chart, with a couple arguments:
Value | Use |
---|---|
--set config.host="ls-master-internal" |
Tells the logstream-workergroup instance to connect to the ls-master-internal service. |
--set config.tag="all-logs" |
Sets the tag and workergroup name to all-logs (which was the group we specified creating in the logstream-master install above). |
--set config.token="e448c60a-2d24-11eb-a601-c78b7f337b04" |
Sets the authentication token to use the uuid we generated before the master install. |
So, if we run:
helm install ls-wg-all-logs cribl/logstream-workergroup --set config.token="e448c60a-2d24-11eb-a601-c78b7f337b04" --set config.tag="all-logs" --set config.host=”\"ls-master-internal" -n logstream
…this sets up the worker group and connects it to the master. Looking at the output of kubectl get all -n logstream
again, you should see something like this:
helm-charts kubectl get all -n logstream
NAME | READY |
STATUS |
RESTARTS |
AGE |
pod/ls-master-57744fcf45-qmrkn | 1/1 |
Running |
0 |
5m43s |
pod/ls-wg-all-logs-logstream-workergroup-668cb65d75-9tndm | 1/1 |
Running |
0 |
21s |
NAME | TYPE |
CLUSTER-IP |
EXTERNAL-IP |
PORT(S) |
AGE |
service/ls-master | LoadBalancer |
172.20.137.83 |
a15<...>.us-west-2.elb.amazonaws.com |
9000:32233/TCP |
5m44s |
service/ls-master-internal | LoadBalancer |
172.20.95.84 |
a9c<...>.us-west-2.elb.amazonaws.com |
9000:30564/TCP,4200:32002/TCP |
5m44s |
service/ls-wg-all-logs-logstream-workergroup | LoadBalancer |
172.20.111.33 |
ac4<...>.us-west-2.elb.amazonaws.com |
10001:30082/TCP, 9997:30381/TCP, 10080:31380/TCP, 10081:32596/TCP, 5140:32025/TCP, 8125:32546/TCP, 9200:30030/TCP |
22s |
NAME | READY |
UP-TO-DATE |
AVAILABLE |
AGE |
deployment.apps/ls-master | 1/1 |
1 |
1 |
5m44s |
deployment.apps/ls-wg-all-logs-logstream-workergroup | 1/1 |
1 |
1 |
22s |
NAME | DESIRED |
CURRENT |
READY |
AGE |
replicaset.apps/ls-master-57744fcf45 | 1 |
1 |
1 |
5m44s |
replicaset.apps/ls-wg-all-logs-logstream-workergroup-668cb65d75 | 1 |
1 |
1 |
22s |
NAME | REFERENCE |
TARGETS |
MINPODS |
MAXPODS |
REPLICAS |
AGE |
horizontalpodautoscaler.autoscaling/ls-wg-all-logs-logstream-workergroup-all-logs | Deployment/ls-wg-all-logs-logstream-workergroup-all-logs |
/50% |
2 |
10 |
0 |
22s |
You’ll notice that we have a new service ls-wg-all-logs-logstream-workergroup
– this is the load balancer that you’ll need to point all your sources to. After just a few commands, you now have a working distributed deployment of Cribl LogStream!
As I mentioned when I announced the logstream-workergroup chart, this is not “fire and forget” – we’re learning as we go, and would love feedback at each step (via the #kubernetes channel in our Slack community). Please try the charts, and let us know how we can make them better and easier to use.
Experience a full version of Cribl Stream and Cribl Edge in the cloud with pre-made sources and destinations.
Classic choice. Sadly, our website is designed for all modern supported browsers like Edge, Chrome, Firefox, and Safari
Got one of those handy?