In the last 12 months, there’s been significant progress in the OpenTelemetry project -- arriving in the form of contributions, stability, and adoption. Being such, it felt a good time to refresh this post, providing project newcomers a short guide to get up and running quickly. In this post, I'll step through.

The BindPlane Agent is a flexible tool that can be run as an agent, an aggregator, or both. As an agent the collector will be running on the same host it's collecting telemetry from, while an aggregator will collect telemetry from other agents and forward the data on to their final destination. Here are a few of the reasons you might want to consider inserting Aggregators into your pipelines: Today we will examine these reasons, and some possible architectures for implementing aggregators.

BindPlane OP and the BindPlane Agent offer a unified solution for Google customers to ship telemetry from various environments to Google Cloud Operations. This 4-part video series will guide you through setting up and using BindPlane OP effectively.

Logs serve as an invaluable resource for monitoring system health, debugging issues, and maintaining security. But as our applications grow more complex, the volume of logs they generate is increasing exponentially. While logs are crucial, not all log data is equally valuable. With the surge in volume, costs associated with storing and analyzing logs are skyrocketing, impacting both performance and cost. The need for effective log management is more urgent than ever.

In today's data-driven world, ensuring the stability and efficiency of software applications is not just a need but a requirement. Enter observability. But as with any evolving technology, there's always room for growth. That growth, as it stands today, is the convergence of artificial intelligence (AI) with observability pipelines. In this blog, we'll explore the idea behind this merge and its potential.

We’ve all been surprised by our cloud monitoring bill at one time or another. If you are a BindPlane OP customer ingesting Host Metrics into Google Cloud Monitoring, you may be wondering which metrics are impacting your bill the most. You may have metrics enabled that aren’t crucial to your business, driving unnecessary costs. How do we verify that and remediate?

If you’re a systems engineer, SRE, or just someone with a love for tech buzzwords, you’ve likely heard about “data lakes”. Before we dive deep into this concept, let’s debunk the illusion: there aren’t any floaties or actual lakes involved! Instead, imagine a vast reservoir where you store loads and loads of raw data in its natural format. Now, pair this with the idea of observability and telemetry pipelines, and we have ourselves an engaging topic.

Often it can be a challenge to collect data into a monitoring environment that does not natively support that data source. Bindplane can help solve this problem. As the Bindplane Agent is based on OpenTelemetry (and is also as freeform as possible), one can bring in data from disparate sources that are not easily supported by the Splunk Universal Forwarder.

Much of the log data we handle doesn’t offer substantial insight and can be conveniently removed from your logs, helping us reduce costs. What may seem like a small adjustment, like deleting an attribute, can have significant implications when scaled up. A typical case involves fields in your logs presenting empty values or housing data considered irrelevant. Below we’ll take a look at a few examples of what this looks like and how you can take action in BindPlane OP.

As the foundation of your observability stack, BindPlane OP provides great visibility into your telemetry data, all the way from collection to its final destination. With the introduction of Live Preview in BPOP Enterprise, and a brand new processor workflow, we’ve now made this even better.