influxdata / influxdata/kapacitor

[Feature Request] Create new UDF type only for Alert Filtering

Open
#1,537 3 comments 2 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
2.4k
Forks
479
Avg merge
4d 16h
Merged PRs (30d)
4

Description

I would like to add an advanced alert filter, based on some properties not stored on the influxDB.

Now we can inject tags with an UDF in this way. and evaluate the external_tag in the AlertNode

````javascript
stream
|from()
.database(db)
.retentionPolicy(rp)
.measurement(measurement)
.groupBy(groupBy)
.where(whereFilter)
@injectTagsFromSQLDB().
.db('jdbc:mysql://localhost:3306/YourDBName')
.key('host')
|eval(lambda: "usage_user" )
.as('value')
|alert()
.crit(lambda: "value" > crit AND externa_tag == "true" )
.email('oncall@example.com')
````
In this way I will do as many SQL querys as points will be processed , but what we need indeed is not that. We need filter just before alert will be sent , and UDF as a property for the Alert node , something like this .

````javascript
stream
|from()
.database(db)
.retentionPolicy(rp)
.measurement(measurement)
.groupBy(groupBy)
.where(whereFilter)
|eval(lambda: "usage_user" )
.as('value')
|alert()
.crit(lambda: "value" > crit )
.@AlertFilterFromSQLDB()
.db('jdbc:mysql://localhost:3306/YourDBName')
.key('host')
.email('oncall@example.com')
````
In this second way my "UDF" should filter only when all other conditions will be true. The number of SQL evaluations will be reduced drastically and the alert performance will be improved.

Thank you for this great tool !

Contributor guide

Open the contributing guide

Research direction

Start by tracing the AlertNode and alert() implementation, then inspect how UDFs are represented and evaluated. Define the alert-only filter semantics so it runs after other alert conditions but before sending, and add coverage for the filtering behavior and reduced external-query evaluation.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, mysql
Domain
observability
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.