VERSION 1.91.4
Features
Added include_fields
parameter to Deduplicate Logs processor.
The latest product updates from Bindplane
RSS feedAdded include_fields
parameter to Deduplicate Logs processor.
Resolves an issue where Bindplane would fail to sync with GitHub for new agent releases. This would disrupt installing an agent.
Users experiencing this issue should upgrade to this version to resolve the issue.
Resolves an issue where Bindplane would intermittently
render sensitive values as (sensitive)
under special
conditions.
Users experiencing this issue should upgrade to this version to ensure sensitive values are rendered correctly.
cumulative_normalization
option in Google Managed Prometheus destinationquery
, selector
, offset
, and limit
to get configuration
commandsend_raw
parameter to Netflow sourcesort
flag for get agents
command40
HTTPS
instead of gRPC
TLS
, however, the API used was the legacy Chronicle gRPC API.This patch release resolves a regression where Bindplane fails to startup if the Postgres database
was setup without GRANT CREATE ON DATABASE
permissions. This permission is not required if Bindplane
is configured to use the public
schema.
If you are upgrading from Bindplane v1.89.5 or older, it is recommended that you skip v1.90.1 in favor of v1.90.2. If you upgraded to v1.90.1 and encountered startup errors, upgrade to v1.90.2.
It is recommended that users review the Postgres Configuration for the latest Postgres setup requirements.
đźš§ Postgres permission requirements have changed.
Execute the following on your Postgres database before performing the upgrade to v1.90.1.
8888
Bindplane ships with Prometheus v3 as of release v1.90.1. Prometheus is used for storing agent throughput and health metrics. You can learn more about Bindplane's use of Prometheus here.
Stand-alone installations of Bindplane will receive Prometheus v3 when upgrading to Bindplane v1.90.1+. If you are operating Bindplane in High Availability you will need to upgrade your Prometheus instance yourself. See the Prometheus Installation documentation for details.
Bindplane does not require Prometheus v3 to function. You can upgrade Bindplane before upgrading Prometheus. It is recommended to upgrade Prometheus to ensure you are receiving the latest build for bug and security fixes.
Fixed an issue where Bindplane Collector v1.74.1 telemetry host and port was incorrectly configured.
Users with Kubernetes agents using the Kubernetes Prometheus source should upgrade to this version of Bindplane in order to resolve an issue where the Prometheus receiver fails to scrape the collector's telemetry endpoint.
Users who have modified Bindplane server's advanced.agent.telemetryPort
should upgrade to this
release as well.
Fixed an issue where the AWS S3 Event Source could not be configured.
agent upgrade
command required the --version
flagPlease install Bindplane v1.88.2 to avoid a stability issue introduced in v1.88.1. The v1.88.2 release includes a fix for the issue.
/status
StatefulSet
deployment optionStatefulSet
deployment optionget
commands --export
flag will now omit metadata.id
when exporting resourcesmatch_once
parameter caused rollout failureschronicle_log_type
was already setMigrating from Bolt Store to Postgres is supported with system
authentication.
Beta features are subject to change and can contain bugs. Please use beta features with caution against non critical workloads.
Bindplane v1.85.0 introduces the new configuration topology with advanced routing capabilities.
Previously, users required the Filter by Condition processor for handling routing between sources and destinations. Now, users can connect sources and destinations explicitly, and avoid duplicating data across multiple destinations.
Existing configurations can be upgraded to to the new v2 topology by using the advanced "Upgrade to v2 beta" option.
It is recommended to duplicate your configuration before proceeding, and test the new functionality against the duplicate configuration.
Once upgraded, you will need to configure routing from source to destination.
This example shows the routing connector being used to route Prometheus source to Google Managed Prometheus, Kubelet to Google Cloud, and both sources to a Prometheus destination.
New commands admin vacuum-analyze
to assist in managing your Postgres
database. When directed by support, performing a manual Postgres Vacuum can help with performance issues.
Generally a manual vacuum is not required.
The commands require system
auth.
ts
, datatime
, and timestamp
are detectedBindplane Collector v1.63.0 or newer is not compatible with BindPlane OP server v1.59.1 or older. If you are using BindPlane OP v1.59.1 or older, it is recommended to upgrade to v1.79.0.
It is safe to upgrade from v1.59.1 to v1.79.0. However, if you are on v1.59.0 or older, it is recommended to first upgrade to v1.59.1 and then to v1.79.0.
Licenses have always been required when operating BindPlane OP. If a license was not configured, the web interface would prompt for one. As of v1.79.0, new installations of BindPlane OP will require a license key in the configuration file. If you are installing BindPlane OP with the installation script or the Helm chart, no further steps are required.
If you are installing BindPlane OP Linux packages without using the install script, you must run the
init
command or modify /etc/bindplane/config.yaml
to configure a license before starting the service.
suppress_rendering_info
option for Windows Event Log SourceThe following processors have been deprecated and replaced by a version 2 implementation.
Deprecated resources are available to users who are already using them within a configuration. It is recommended that you replace your existing processors with the new v2 implementation.
max_log_size
option to TCP and Syslog sourcesregion
option to Google SecOps destinationCouchbase source need to take care when upgrading their Bindplane Collector. This is due to changes to the OpenTelemetry Transformation Language (OTTL) which impact the Couchbase source.
BindPlane v1.76.0 is required for Bindplane Collector v1.63.0 or newer. Users with BindPlane agent version v1.60.0 or older must upgrade to v1.61.0 or v1.62.0 before upgrading to v1.63.0.
If you are not using the Couchbase source, you can ignore Agent Version Support upgrade notes.
When using TLS, BindPlane defaults to a minimum TLS version of 1.3
. Users can opt into TLS 1.2
for supporting client devices that do not support TLS 1.3.
To configured TLS 1.2, update network.tlsMinVersion
string value to "1.2"
.
ephemeral: true
file_prefix
optioninit
command/v1/agent-versions/:version/install-command
API endpoint.Users can opt into multi factor authentication (MFA) by navigating to their project's "Users" tab and selecting the MFA toggle next to their username.
Once the user is enrolled in MFA, MFA will be required for all of the users projects.
Kafka Event Bus for BindPlane High Availability is deprecated, use the built in distributed eventbus. It is simpler to use and does not require additional infrastructure.
Kafka sources and destinations are unrelated and fully supported.
zstd
compression to the Sumo Logic destinationWhen an agent is connected for the first time, its OpAMP labels will be used as the initial set of labels. Future agent label changes will be stored on the BindPlane server only, they will not be sent to the agent.
This allows BindPlane to be the single source of truth for agent labels and it prevents an agent reconfiguration due to label changes.
--selector
and --query
flags for label agents
commandinit license
command, for updating a Linux server's licenseYou can now label agents based on criteria passed to the --selector
or --query
flags.
A new command is available for updating BindPlane's license. Similar to the init server
command,
the BindPlane license can be updated by executing the init license
command on the BindPlane host.
The command must be executed on the BindPlane Linux host to update the configuration
file at /etc/bindplane/config.yaml
.
_sourceCategory
and sumo.datasource
attributes when sending Windows Events to Sumo Logic.The new extract metric processor allows multiple metrics to be created in a single processor instance. Improvements on the previous processor include specifying the metric type, using an OTTL autocomplete field for the metric field parameter, and a variety of default units that can be selected from while still allowing custom units to be specified.
/agents/labels
endpointIf you are not using BindPlane with high availability, no action is required.
BindPlane High Availability users should upgrade their Prometheus Linux Package. The latest version of the package will contain the new recording rules that enable Configurable Measurement Interval. After upgrading, no further action is required.
If you are managing Prometheus manually, you will need to re-review the documentation. Make sure to update your recording rules.
The new recording rules look like this.
Agents send configuration throughput metrics to BindPlane every 10 seconds. This interval is now configurable, supporting 10s, 1m, and 15m. It is recommended to use 1m or 15m intervals when managing large numbers of agents. At scale, 10s intervals can be responsible for high overhead.
The interval can be set by modifying a configuration's advanced settings. Select the gear icon on and choose "Advanced Configuration Options".
See the Upgrade Notes for important details regarding configurable measurement intervals.
BindPlane can expose APM metrics using a built-in Prometheus exporter. Metrics are disabled by default and can be enabled by updating your configuration file.
The CLI supports shell completion for bash
, zsh
, fish
and powershell
. After upgrading your
CLI, use the bindplane completion -h
command for more information.
bindplane init auth
for updating the BindPlane server's authentication configurationWhen operating BindPlane OP on Linux, you can migrate to LDAP by executing the following command on the Linux server.
The command will prompt for your ldap server information, and migrate your BindPlane accounts to the new authentication mechanism.
After upgrading to BindPlane v1.62.0, review your configurations for pending rollouts. Update any configurations that contain processors with conditions built using the condition builder. Previous versions of BindPlane will have required the user to handle regex escaping on their own. v1.62.0 handles the escaping for you, however, existing conditions will need to be updated to take this into account.
metadata.name
Enterprise users operating BindPlane in High Availability can now use the NATS Event Bus. The NATS Event Bus eliminates the need for an external event bus such as Google Pub/Sub or Apache Kafka.
Agents managed by BindPlane expose metrics on TCP port 8888
by default. The port is now configurable
using a global setting. Modifying the port will affect all agents.
The BindPlane configuration file's advanced
section can be updated to include the agent.telemetryPort
option.
Modifying advanced options should be considered an advanced operation, and is not recommended unless guided by BindPlane support.
A new configuration section agents
allow users to configure OpAMP authentication. Currently, secretKey
is the only supported authentication type. It supports one or more headers. In this example, the BindPlane
control plane will check for X-Bindplane-Authorization
first and then Authorization
if the first header
is not present.
Modifying the agent authentication options should be considered an advanced operation, and is not recommended unless guided by BindPlane support.
configuration=<configuration name>
will be added automatically when creating a configuration using the API.8888
will now bind to localhost
on Linux, Windows, and macOS.Starting in 1.59 each deployment of BindPlane OP will have a new top-level Organization made up of all the previous existing Accounts on the deployment. Accounts will now be referred to as Projects, which still contain all of the Agents and Resources associated with the account.
Some things to note:
With Progressive Rollouts you can now deploy your configuration changes incrementally, one stage at a time. Tag specific agents as belonging to dev, stage, and prod environments and then BindPlane will pause the rollout after it completes each stage.
The stages themselves are entirely configurable, so you can create the exact rollout that works best for your environment.
Updated telemetry displayed in the Edit Processors (Live Preview) dialog to show more detail.
v1.55.0 adds a new source for rehydrating data stored in an AWS S3 bucket. Read the source documentation here.
Filter By Condition is a new processor introduced in v1.55.0. It can be used to include or exclude telemetry based on a condition that is evaluated against the telemetry data. Read the processor documentation here.
nop
destinationv1.54.0 introduces processor recommendations. BindPlane will recommend processors when viewing Live Preview.
The initial release recommendation feature set includes the following recommendations:
New CLI command for rotating secret keys. Run bindplane secret --help
for details.
Downgrades from 1.52.0 to previous versions of BindPlane are not supported if you make use of the new OTTL condition builder feature. BindPlane 1.52.0 introduces a new parameter type that will not render
The new condition builder allows the user to easily create OTTL.
We added new functionality that allows users to assign custom labels to agents. Agent labels can be managed either individually or in bulk. To manage labels individually, users can click on the labels in the details of the agent. To manage labels in bulk, users can select multiple agents from the agents table and click the new “Manage Labels” button that will appear. In addition to this, labels are now displayed in the agents table. If labels are truncated in this view, users can use the hover interaction to display all labels.
đźš§ BindPlane v1.46.0 contains breaking changes.
As of 1.46.0, Prometheus is required to store agent throughput measurements. Throughput measurement support has been removed from Bolt Store and PostgreSQL.
Single-instance users do not need to take action. BindPlane will spawn a Prometheus sub-process automatically.
High-availability users will need to make sure Prometheus is configured in their environment. Documentation for configuring Prometheus in a BindPlane HA architecture can be found here.
Helm users should upgrade to chart version 1.2.0. Consult the chart release notes before upgrading. Once upgraded to Chart version 1.2.0, it is safe to upgrade to Chart version 1.2.1, which contains BindPlane v1.46.0.
Fixes an issue where changing the system account username would cause the user to lose access to their account.
It is recommended that all users upgrade from 1.43.0 to 1.43.1.
This release includes a change that will break future downgrade compatibility for users with a single account boltstore installation of BindPlane. Before upgrading, those users should create a backup of their storage file, which can be used in the event of a downgrade.*
To downgrade, those users should follow these steps:
Changes made after upgrading will not be persisted when performing this downgrade.
* If, instead, BindPlane is configured with either multi-account or postgres, this release is backward compatible and no action is needed to downgrade safely. BindPlane is multi-account if accounts.enable
is true
in its configuration:
Agent measurement values will be inconsistent in some situations. Upgrading to v1.41.0 solves this issue.
If you are using BindPlane's built in Prometheus service, no action is required. If you are unsure, generally this means your BindPlane server is managing it's own Prometheus service behind the scenes. You can skip this procedure.
If you are using a self managed Prometheus instance for your measurements backend, you must update your Prometheus recording
rule at /etc/prometheus/rules.yml
.
Once updated, restart the service.
mtime
option./var/lib/bindplane/scripts/create-support-bundle.sh
after upgradinginit server
improvements
admin
server command
fixes/agents
api endpoint.