NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #782 by repository stars
Last release 16 days ago
22 Sep 2026
Ships fairly regularly
a new release about every 3 weeks
Nearly every release is documented
notes for 56 of 59 stable releases
Nothing withdrawn
no release was ever pulled
11 years old
334 releases · first in 2015
Nothing published for this version
Nothing published for this version
The v1.4.0 release has many new features, here is a list of some of the highlights:
The v1.4.0 release has many new features, here is a list of some of the highlights:
See the complete list of bug fixes and features below.
One column per quarter.
### Bugfixes - #1703: Fix issues where log API checked the wrong header for the desired content type.
### Features - #1622: Add support for AWS EC2 autoscaling services. - #1566: Add BarrierNode to emit BarrierMessage periodically ### Bugfixes - #1250:
tasks no longer need to specify their TaskType (Batch, Stream).
dbrp expressions were added to tickscript.
Topic-Handler file format was modified to include the TopicID and HandlerID in the file.
Load service was added; the service can load tasks/handlers from a directory..yml file extensions in define-topic-handlerNothing published for this version
Nothing published for this version
Nothing published for this version
### Bugfixes - #1520: Expose pprof without authentication if enabled
### Bugfixes - #1512: Use details field from alert node in PagerDuty.
Nothing published for this version
### Bugfixes - #1415: Proxy from environment for HTTP request to slack - #1414: Fix derivative node preserving fields from previous point in stream ta
The v1.3.0 release has two major features.
The v1.3.0 release has two major features.
Here is a quick example of how to configure Kapacitor to scrape discovered targets. First configure a discoverer, here we use the file-discovery discoverer. Next configure a scraper to use that discoverer.
NOTE: The scraping and discovering features are released under technical preview, meaning that the configuration or API around the feature may change in a future release.
# Configure file discoverer
[[file-discovery]]
enabled = true
id = "discover_files"
refresh-interval = "10s"
##### This will look for prometheus json files
##### File format is here https://prometheus.io/docs/operating/configuration/#%3Cfile_sd_config%3E
files = ["/tmp/prom/*.json"]
# Configure scraper
[[scraper]]
enabled = true
name = "node_exporter"
discoverer-id = "discover_files"
discoverer-service = "file-discovery"
db = "prometheus"
rp = "autogen"
type = "prometheus"
scheme = "http"
metrics-path = "/metrics"
scrape-interval = "2s"
scrape-timeout = "10s"
Add the above snippet to your kapacitor.conf file.
Create the below snippet as the file /tmp/prom/localhost.json:
[{
"targets": ["localhost:9100"]
}]
Start the Prometheus node_exporter locally.
Now startup Kapacitor and it will discover the localhost:9100 node_exporter target and begin scrapping it for metrics.
For more details on the scraping and discovery systems see the full documentation here.
The second major feature with this release, are changes to the alert topic system. The previous release introduce this new system as a technical preview, with this release the alerting service has been simplified. Alert handlers now only ever have a single action and belong to a single topic.
The handler definition has been simplified as a result. Here are some example alert handlers using the new structure:
id: my_handler
kind: pagerDuty
options:
serviceKey: XXX
id: aggregate_by_1m
kind: aggregate
options:
interval: 1m
topic: aggregated
id: publish_to_system
kind: publish
options:
topics: [ system ]
To define a handler now you must specify which topic the handler belongs to. For example to define the above aggregate handler on the system topic use this command:
kapacitor define-handler system aggregate_by_1m.yaml
For more details on the alerting system see the full documentation here.
# Bugfixes - #1379: Copy batch points slice before modification, fixes potential panics and data corruption. - #1394: Use the Prometheus metric name a
### Bugfixes - #1369: Fix panic with concurrent writes to same points in state tracking nodes. - #1387: static-discovery configuration simplified - #1
### Bugfixes - #1370: Fix missing working_cardinality stats on stateDuration and stateCount nodes.
### Features - #1299: Allowing sensu handler to be specified - #1284: Add type signatures to Kapacitor functions. - #1203: Add isPresent operator for
isPresent operator for verifying whether a value is present (part of #1284).### Features - #117: Add headers to alert POST requests. ### Bugfixes - #1294: Fix bug where batch queries would be missing all fields after the first
### Features - #1322: TLS configuration in Slack service for Mattermost compatibility - #1330: Generic HTTP Post node - #1159: Go version 1.7.4 -> 1.7
query_errors to errors in batch node.
Renamed eval_errors to errors in eval node.working_cardinality stat to each node type that tracks the number of groups per node.parseMode value.Series is always series, and the old key Err is now always error instead of for only some of the outputs.### Bugfixes - #1323: Fix issue where credentials to InfluxDB could not be updated dynamically.
Nothing published for this version
>NOTE: The new alerting features are being released under technical preview. This means breaking changes may be made in later releases until the featu…
A new system for working with alerts has been introduced. This alerting system allows you to configure topics for alert events and then configure handlers for various topics. This way alert generation is decoupled from alert handling.
Existing TICKscripts will continue to work without modification.
To use this new alerting system remove any explicit alert handlers from your TICKscript and specify a topic. Then configure the handlers for the topic.
stream
|from()
.measurement('cpu')
.groupBy('host')
|alert()
// Specify the topic for the alert
.topic('cpu')
.info(lambda: "value" > 60)
.warn(lambda: "value" > 70)
.crit(lambda: "value" > 80)
// No handlers are configured in the script, they are instead defined on the topic via the API.
The API exposes endpoints to query the state of each alert and endpoints for configuring alert handlers. See the API docs for more details. The kapacitor CLI has been updated with commands for defining alert handlers.
This release introduces a new feature where you can window based off the number of points instead of their time. For example:
stream
|from()
.measurement('my-measurement')
// Emit window for every 10 points with 100 points per window.
|window()
.periodCount(100)
.everyCount(10)
|mean('value')
|alert()
.crit(lambda: "mean" > 100)
.slack()
.channel('#alerts')
With this change alert nodes will have an anonymous topic created for them. This topic is managed like all other topics preserving state etc. across restarts. As a result existing alert nodes will now remember the state of alerts after restarts and disiabling/enabling a task.
NOTE: The new alerting features are being released under technical preview. This means breaking changes may be made in later releases until the feature is considered complete. See the API docs on technical preview for specifics of how this effects the API.
Nothing published for this version
Nothing published for this version
Nothing published for this version
No changes to Kapacitor, only upgrading to go 1.7.4 for security patches.
No changes to Kapacitor, only upgrading to go 1.7.4 for security patches.
New K8sAutoscale node that allows you to auotmatically scale Kubernetes deployments driven by any metrics Kapacitor consumes. For example, to scale a
New K8sAutoscale node that allows you to auotmatically scale Kubernetes deployments driven by any metrics Kapacitor consumes.
For example, to scale a deployment myapp based off requests per second:
// The target requests per second per host
var target = 100.0
stream
|from()
.measurement('requests')
.where(lambda: "deployment" == 'myapp')
// Compute the moving average of the last 5 minutes
|movingAverage('requests', 5*60)
.as('mean_requests_per_second')
|k8sAutoscale()
.resourceName('app')
.kind('deployments')
.min(4)
.max(100)
// Compute the desired number of replicas based on target.
.replicas(lambda: int(ceil("mean_requests_per_second" / target)))
New API endpoints have been added to be able to configure InfluxDB clusters and alert handlers dynamically without needing to restart the Kapacitor daemon. Along with the ability to dynamically configure a service, API endpoints have been added to test the configurable services. See the API docs for more details.
NOTE: The
connect_errorsstat from the query node was removed since the client changed, all errors are now counted in thequery_errorsstat.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
### Release Notes ### Features ### Bugfixes - #951: Fix bug where errors to save cluster/server ID files were ignored. - #954: Create data_dir on star
### Release Notes ### Features - #873: Add TCP alert handler - #869: Add ability to set alert message as a field - #854: Add .create property to Influ
.create property to InfluxDBOut node, which when set will create the database
and retention policy on task start.### Release Notes Final release of v1.0.0.
Final release of v1.0.0.
### Release Notes ### Features ### Bugfixes - #842: Fix side-effecting modification in batch WhereNode.
### Release Notes ### Features - #827: Bring Kapacitor up to parity with available InfluxQL functions in 1.0 ### Bugfixes - #763: Fix NaNs begin retur
Kapacitor now supports alert reset expressions. This way when an alert enters a state, it can only be lowered in severity if its reset expression eval
Kapacitor now supports alert reset expressions. This way when an alert enters a state, it can only be lowered in severity if its reset expression evaluates to true.
Example:
stream
|from()
.measurement('cpu')
.where(lambda: "host" == 'serverA')
.groupBy('host')
|alert()
.info(lambda: "value" > 60)
.infoReset(lambda: "value" < 50)
.warn(lambda: "value" > 70)
.warnReset(lambda: "value" < 60)
.crit(lambda: "value" > 80)
.critReset(lambda: "value" < 70)
For example given the following values:
61 73 64 85 62 56 47
The corresponding alert states are:
INFO WARNING WARNING CRITICAL INFO INFO OK
Kapacitor now supports grouping by fields. First convert a field into a tag using the EvalNode. Then group by the new tag.
Kapacitor now supports grouping by fields. First convert a field into a tag using the EvalNode. Then group by the new tag.
Example:
stream
|from()
.measurement('alerts')
// Convert field 'level' to tag.
|eval(lambda: string("level"))
.as('level')
.tags('level')
// Group by new tag 'level'.
|groupBy('alert', 'level')
|...
Note the field level is now removed from the point since .keep was not used.
See the docs for more details on how .tags works.
In companion with being able to create new tags, you can now delete tags or fields.
Example:
stream
|from()
.measurement('alerts')
|delete()
// Remove the field `extra` and tag `uuid` from all points.
.field('extra')
.tag('uuid')
|...
if("value" > 6, 1, 2).fill operation on a JoinNode.
Fill with batches and fill when using the on property were broken.
Also changes the DefaultNode set defaults for nil fields.### Release Notes ### Features - #662: Add -skipVerify flag to kapacitor CLI tool to skip SSL verification. - #680: Add Telegram Alerting option, than
-skipVerify flag to kapacitor CLI tool to skip SSL verification.### Release Notes ### Features - #636: Change HTTP logs to be in Common Log format. - #652: Add optional replay ID to the task API so that you can get
kapacitord config to not search default location for configuration files but rather require the -config option.
Since the kapacitord run command behaves this way they should be consistent.
Fix issue with kapacitord config > kapacitor.conf when the output file was a default location for the config.autogen in InfluxDB.
This changes Kapacitor to use autogen for the default retention policy for the stats.
You may need to update your task DBRPs to use autogen instead of default.Nothing published for this version
The ability to create and use template tasks has been added. you can define a template for a task and reuse that template across multiple tasks.
The ability to create and use template tasks has been added. you can define a template for a task and reuse that template across multiple tasks.
A simple example:
// Which measurement to consume
var measurement string
// Optional where filter
var where_filter = lambda: TRUE
// Optional list of group by dimensions
var groups = [*]
// Which field to process
var field string
// Warning criteria, has access to 'mean' field
var warn lambda
// Critical criteria, has access to 'mean' field
var crit lambda
// How much data to window
var window = 5m
// The slack channel for alerts
var slack_channel = '#alerts'
stream
|from()
.measurement(measurement)
.where(where_filter)
.groupBy(groups)
|window()
.period(window)
.every(window)
|mean(field)
|alert()
.warn(warn)
.crit(crit)
.slack()
.channel(slack_channel)
Then you can define the template like so:
kapacitor define-template generic_mean_alert -tick path/to/above/script.tick -type stream
Next define a task that uses the template:
kapacitor define cpu_alert -template generic_mean_alert -vars cpu_vars.json -dbrp telegraf.default
Where cpu_vars.json would like like this:
{
"measurement": {"type" : "string", "value" : "cpu" },
"where_filter": {"type": "lambda", "value": "\"cpu\" == 'cpu-total'"},
"groups": {"type": "list", "value": [{"type":"string", "value":"host"},{"type":"string", "value":"dc"}]},
"field": {"type" : "string", "value" : "usage_idle" },
"warn": {"type" : "lambda", "value" : " \"mean\" < 30.0" },
"crit": {"type" : "lambda", "value" : " \"mean\" < 10.0" },
"window": {"type" : "duration", "value" : "1m" },
"slack_channel": {"type" : "string", "value" : "#alerts_testing" }
}
With this release you can now replay data directly against a task from InfluxDB without having to first create a recording.
Replay the queries defined in the batch task cpu_alert for the past 10 hours.
kapacitor replay-live batch -task cpu_alert -past 10h
Or for a stream task with use a query directly:
kapacitor replay-live query -task cpu_alert -query 'SELECT usage_idle FROM telegraf."default".cpu WHERE time > now() - 10h'
Now InfluxDB and Kapacitor support HTTP/S based subscriptions. This means that Kapacitor need only listen on a single port for the HTTP service, greatly simplifying configuration and setup.
In order to start using HTTP subscriptions change the subscription-protocol option for your configured InfluxDB clusters.
For example:
[[influxdb]]
enabled = true
urls = ["http://localhost:8086",]
subscription-protocol = "http"
# or to use https
#subscription-protocol = "https"
On startup Kapacitor will detect the change and recreate the subscriptions in InfluxDB to use the HTTP protocol.
NOTE: While HTTP itself is a TCP transport such that packet loss shouldn't be an issue, if Kapacitor starts to slow down for whatever reason, InfluxDB will drop the subscription writes to Kapacitor. In order to know if subscription writes are being dropped you should monitor the measurement
_internal.monitor.subscriberfor the fieldwriteFailures.
This release contains an new Holt Winters InfluxQL function.
With this forecasting method one can now define an alert based off forecasted future values.
For example, the following TICKscript will take the last 30 days of disk usage stats and using holt-winters forecast the next 7 days. If the forecasted value crosses a threshold an alert is triggered.
The result is now Kapacitor will alert you 7 days in advance of a disk filling up. This assumes a slow growth but by changing the vars in the script you could check for shorter growth intervals.
// The interval on which to aggregate the disk usage
var growth_interval = 1d
// The number of `growth_interval`s to forecast into the future
var forecast_count = 7
// The amount of historical data to use for the fit
var history = 30d
// The critical threshold on used_percent
var threshold = 90.0
batch
|query('''
SELECT max(used_percent) as used_percent
FROM "telegraf"."default"."disk"
''')
.period(history)
.every(growth_interval)
.align()
.groupBy(time(growth_interval), *)
|holtWinters('used_percent', forecast_count, 0, growth_interval)
.as('used_percent')
|max('used_percent')
.as('used_percent')
|alert()
// Trigger alert if the forecasted disk usage is greater than threshold
.crit(lambda: "used_percent" > threshold)
Nothing published for this version
>Breaking changes may require special upgrade steps from versions <= 0.12, please read the 0.13.0 release notes
Breaking changes may require special upgrade steps from versions <= 0.12, please read the 0.13.0 release notes
Along with the API changes of 0.13.0, validation logic was added to task IDs, but this was not well documented. This minor release remedies that.
All IDs (tasks, recordings, replays) must match this regex ^[-\._\p{L}0-9]+$, which is essentially numbers, unicode letters, '-', '.' and '_'.
If you have existing tasks which do not match this pattern they should continue to function normally.
>Breaking changes may require special upgrade steps please read below.
Breaking changes may require special upgrade steps please read below.
Changes to how and where task data is store have been made. In order to safely upgrade to version 0.13 you need to follow these steps:
Upgrade InfluxDB to version 0.13 first.
Update all TICKscripts to use the new | and @ operators. Once Kapacitor no longer issues any DEPRECATION warnings you are ready to begin the upgrade.
The upgrade will work without this step but tasks using the old syntax cannot be enabled, until modified to use the new syntax.
Upgrade the Kapacitor binary/package.
Configure new database location. By default the location /var/lib/kapacitor/kapacitor.db is chosen for package installs or ./kapacitor.db for manual installs.
Do not remove the configuration for the location of the old task.db database file since it is still needed to do the migration.
[storage]
boltdb = "/var/lib/kapacitor/kapacitor.db"
Restart Kapacitor. At this point Kapacitor will migrate all existing data to the new database file. If any errors occur Kapacitor will log them and fail to startup. This way if Kapacitor starts up you can be sure the migration was a success and can continue normal operation. The old database is opened in read only mode so that existing data cannot be corrupted. Its recommended to start Kapacitor in debug logging mode for the migration so you can follow the details of the migration process.
At this point you may remove the configuration for the old task dir and restart Kapacitor to ensure everything is working.
Kapacitor will attempt the migration on every startup while the old configuration and db file exist, but will skip any data that was already migrated.
With this release the API has been updated to what we believe will be the stable version for a 1.0 release. Small changes may still be made but the significant work to create a RESTful HTTP API is complete. Many breaking changes introduced, see the client/API.md doc for details on how the API works now.
Along with the API changes, breaking changes where also made to the kapacitor CLI command.
Here is a break down of the CLI changes:
name used before to define a task is now its ID.
As such instead of using -name and -id to refer to tasks and recordings,
the flags have been changed to -task and -recording accordingly.fast clock mode.-no-wait option to start but not wait for the recording/replay to complete.-replay-id/-recording-id to specify the ID of the replay or recording.
If not set then a random ID will be chosen like the previous behavior.UDF can now be managed externally to Kapacitor via Unix sockets. A process or container can be launched independent of Kapacitor exposing a socket. On startup Kapacitor will connect to the socket and begin communication.
Example UDF config for a socket based UDF.
[udf]
[udf.functions]
[udf.functions.myCustomUDF]
socket = "/path/to/socket"
timeout = "10s"
Alert data can now be consumed directly from within TICKscripts.
For example, let's say we want to store all data that triggered an alert in InfluxDB with a tag level containing the level string value (i.e CRITICAL).
...
|alert()
.warn(...)
.crit(...)
.levelTag('level')
// and/or use a field
//.levelField('level')
// Also tag the data with the alert ID
.idTag('id')
// and/or use a field
//.idField('id')
|influxDBOut()
.database('alerts')
...
|groupBy and |where methods..all() property that specifies that all points in a batch must match the criteria in order to trigger an alert.elapsed function to compute the time difference between subsequent points.skip-format query parameter to the GET /task endpoint so that returned TICKscript content is left unmodified from the user input..durationField('duration').event property configurable.lambda: "bool_value" && (count() > 100) if "bool_value" is false, we won't evaluate "count".(1+2-3*4/5) was evaluated as (1+(2-(3*(4/5))))
which is not the typical/expected behavior. Now using left-associative parsing the statement is evaluated as ((1+2)-((3*4)/5)).rawData attribute and set default severity to indeterminate..as() for JoinNode.Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
New TICKscript syntax that uses a different operators for chaining methods vs property methods vs UDF methods.
New TICKscript syntax that uses a different operators for chaining methods vs property methods vs UDF methods.
| operator.. operator.@ operator.For example below the from, mean, and alert methods create new nodes,
the detectAnomalies method calls a UDF,
and the other methods modify the nodes as property methods.
stream
|from()
.measurement('cpu')
.where(lambda: "cpu" == 'cpu-total')
|mean('usage_idle')
.as('value')
@detectAnomalies()
.field('mean')
|alert()
.crit(lambda: "anomaly_score" > 10)
.log('/tmp/cpu.log')
With this change a new binary is provided with Kapacitor tickfmt which will
format a TICKscript file according to a common standard.
tickfmt binary..mapReduce functions..align() property to BatchNode so you can align query start and stop times..quiet() option to EvalNode so errors can be suppressed if expected.Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
This change now hides the mapReduce aspect and handles it internally. Using .mapReduce is officially deprecated in this release and will be remove in…
Kapacitor is now using the functions from the new query engine in InfluxDB core.
Along with this change is a change in the TICKscript API so that using the InfluxQL functions is easier.
Simply call the desired method directly no need to call .mapReduce explicitly.
This change now hides the mapReduce aspect and handles it internally.
Using .mapReduce is officially deprecated in this release and will be remove in the next major release.
We feel that this change improves the readability of TICKscripts and exposes less implementation details
to the end user.
Updating your exising TICKscripts is simple.
If previously you had code like this:
stream.from()...
.window()...
.mapReduce(influxql.count('value'))
then update it to look like this:
stream.from()...
.window()...
.count('value')
a simple regex could fix all your existing scripts.
Kapacitor now exposes more internal metrics for determining the performance of a given task.
The internal statistics includes a new measurement named node that contains any stats a node provides, tagged by the task, node, task type and kind of node (i.e. window vs union).
All nodes provide an averaged execution time for the node.
These stats are also available in the DOT output of the Kapacitor show command.
Significant performance improvements have also been added. In some cases Kapacitor throughput has improved by 4X.
Kapacitor can now connect to different InfluxDB clusters.
Multiple InfluxDB config sections can be defined and one will be marked as default.
To upgrade convert an influxdb config.
From this:
[influxdb]
enabled = true
...
to this:
[[influxdb]]
enabled = true
default = true
name = "localhost"
...
Various improvements to joining features have been implemented. With #144 you can now join streams with differing group by dimensions.
If you previously configured Email, Slack or HipChat globally now you must also set the state-changes-only option to true as well if you want to preserve the original behavior.
For example:
[slack]
enable = true
global = true
state-changes-only = true
.stats and has been replaced by emitted.stream.from().count().event property has been removed from the Alerta node and is now set as the value of the alert ID..from on the stream object before filtering it, so as to not create confusing to understand TICKscripts.url but rather a host option since the communication is raw TCP rather HTTP.Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →