Fixup on a misleading error being returned due to a missing return statement in the code. Was returning the error "conversion succeeded but no frames" even though there was an error.
sql_expression_query_length_limit
Set the maximum length of a SQL query that can be used in a SQL expression. Default is 10000 characters. A setting of 0 means no limit.
* Capture error_type label on metrics/traces
* Make error messages more helpful to user
* Use errutil, categorized errors, and tie them to error_type (category in code)
* Misc trace fixes
* Add metric to track SQL input conversion
* capture errors on metrics
* rename seconds to sql_command_duration_milliseconds to match unit that has been captured, and update buckets
* rename sql_command_errors_total to sql_command_count
Adds settings for SQL expressions:
sql_expression_cell_output_limit
Set the maximum number of cells that can be returned from a SQL expression. Default is 100000.
sql_expression_timeout
The duration a SQL expression will run before being cancelled. The default is 10s.
Initial support for alerting with SQL expressions
- When `format` is set to `alerting`, SQL expressions output in a format suitable for alerting evaluation.
- Outstanding TODOs:
- Deduplicate output rows
- Add more tests
- Fix broken alerting UI rendering (likely due to shape change to undocumented full-long format)
- Basic usage:
- SQL must return one numeric column and one or more string columns.
- Each row may become an alert.
- The alert fires if the numeric value is non-zero.
- String columns are treated as labels.
---------
Co-authored-by: Konrad Lalik <konradlalik@gmail.com>
Co-authored-by: Tom Ratcliffe <tom.ratcliffe@grafana.com>
Co-authored-by: Sam Jewell <sam.jewell@grafana.com>
* expr: Add row limit to SQL expressions
Adds a configurable row limit to SQL expressions to prevent memory issues with large
result sets. The limit is configured via the `sql_expression_row_limit` setting in
the `[expressions]` section of grafana.ini, with a default of 100,000 rows.
The limit is enforced by checking the total number of rows across all input tables
before executing the SQL query. If the total exceeds the limit, the query fails
with an error message indicating the limit was exceeded.
* revert addition of newline
* Switch to table-driven tests
* Remove single-frame test-cases.
We only need to test for the multi frame case. Single frame is a subset
of the multi-frame case
* Add helper function
Simplify the way tests are set up and written
* Support convention, that limit: 0 is no limit
* Set the row-limit in one place only
* Update default limit to 20k rows
As per some discussion here:
https://raintank-corp.slack.com/archives/C071A5XCFST/p1741611647001369?thread_ts=1740047619.804869&cid=C071A5XCFST
* Test row-limit is applied from config
Make sure we protect this from regressions
This is perhaps a brittle test, somewhat coupled to the code here. But
it's good enough to prevent regressions at least.
* Add public documentation for the limit
* Limit total number of cells instead of rows
* Use named-return for totalRows
As @kylebrandt requested during review of #101700
* Leave DF cells as zero values during limits tests
When testing the cell limit we don't interact with the cell values at
all, so we leave them at their zero values both to speed up tests, and
to simplify and clarify that their values aren't used.
* Set SQLCmd limit at object creation - don't mutate
* Test that SQL node receives limit when built
And that it receives it from the Grafana config
* Improve TODO message for new Expression Parser
* Fix failing test by always creating config on the Service
* Under feature flag `sqlExpressions` and is experimental
* Excluded from arm32
* Will not work with the Query Service yet
* Does not have limits in place yet
* Does not working with alerting yet
* Currently requires "prepare time series" Transform for time series viz
---------
Co-authored-by: Sam Jewell <sam.jewell@grafana.com>
Kyle Brandt
Sarah Zinger
Todd Treece
Sam Jewell
Ryan McKinley
Scott Lepper
Yuri Tseretyan