Part 2 of #2197
Zabbix has two ways of processing and returning proxies depending on the
zabbix version being used:
1. Before 7.0.0 it uses `host`
2. After 7.0.0 it uses `name`
when we made the call to the backend, we accounted for this
[difference](592380851c/src/datasource/zabbix/connectors/zabbix_api/zabbixAPIConnector.ts (L940C5-L944C6)).
However, in the frontend, we always populated the dropdown using
`proxy.host` regardless of the version customers were using.
So for customers that had proxies in their zabbix set up AND were using
a zabbix version `>-7.0.0`, the query editor would crash because we
ended up with a list of undefined options.
This PR changes it so that when `host` is not present, it uses `name` or
otherwise defaults to `''` to ensure that we never have and array of
options with undefined values.
While we are rendering Problems table for each cell we use a different
renderer. For `Age` field we didn't pass the data properly and it caused
errors. The problem is we were trying to render the whole moment object
instead of just the datatime.
Part of: https://github.com/grafana/grafana-zabbix/issues/2197
This PR will fix the issue. This happens when user wants to add a new
panel with `Age` field or try to edit a problems panel `Age` field
enabled.
Kudos to @yesoreyeram
## Summary
Implements configurable query execution timeout controls to prevent
poorly optimized or excessive queries from consuming excessive server
resources, causing performance degradation, or crashing the Zabbix
server.
Fixes: https://github.com/grafana/oss-big-tent-squad/issues/127
## Problem
Previously, the plugin only had an HTTP connection timeout (`timeout`)
that controlled individual API request timeouts. However, a complete
query execution could involve multiple API calls and run indefinitely if
not properly controlled, potentially causing resource exhaustion.
## Solution
Added a new `queryTimeout` setting that enforces a maximum execution
time for entire database queries initiated by the plugin. Queries
exceeding this limit are automatically terminated with proper error
handling and logging.
## Testing
1. Configure a datasource with `queryTimeout` set to a low value (e.g.,
5 seconds)
2. Execute a query that would normally take longer than the timeout
3. Verify that:
- Query is terminated after the timeout period
- Error message indicates timeout occurred
- Logs contain timeout warning with query details
- Other queries in the same request continue to execute
## Notes
- `queryTimeout` is separate from `timeout` (HTTP connection timeout)
- `queryTimeout` applies to the entire query execution, which may
involve multiple API calls
- Default value of 60 seconds ensures reasonable protection while
allowing normal queries to complete
- Timeout errors are logged with query refId, queryType, timeout
duration, and datasourceId for troubleshooting
## Summary
When we switched to use `Combobox` we were no longer able to add custom
values for our dropdowns, and this prevented users from using regexp
values for `group`, `host`, `proxy` etc. This PR adds
`createCustomValue` flag so that any custom value can be entered into
the dropdowns.
## Detailed summary
- Make use of `Combobox`'s `createCustomValues` so that wherever
necessary, users are able to enter regex values.
<img width="720" height="221" alt="Screenshot 2026-01-05 at 7 15 23 AM"
src="https://github.com/user-attachments/assets/841716eb-cd86-49d1-b13c-a0e37e8a37b9"
/>
## Why
For users to be able to use regexp, and any custom value in our
dropdowns.
## How to test
For all query types where dropdowns are used and user configurable (i.e.
group, host, proxy, application) start typing a value that does not
already exist in the dropdown. You should see an option to `Use custom
value`
Fixes
[comment](https://github.com/grafana/grafana-zabbix/pull/2141#issuecomment-3698818476),
thanks for the testing and call out @christos-diamantis
## Sumary
When dealing with multiple hosts, it can be hard for customers filter
through and figure out which host to query metric data from. This PR
aims to make this easier by adding support for host tags so that there
is another layer of filtering / grouping applied for hosts.
## Detailed explanation
- Adds new UI components to allow adding one or more host tag filter,
and a switch to choose between `AND/OR` and `OR` operators when using
more than one filter following Zabbix's UI:
https://github.com/user-attachments/assets/c971f5eb-7e93-4238-bd6b-902cc657c014https://github.com/user-attachments/assets/5f8996de-684e-4ffa-b98e-8e205c4fc1df
- Modifies the existing `getHosts` function to make a call to the
backend with a few additional parameters to `extend` (essentially
extract) the host tags for a given selected group. No backend changes
were required for this.
## Why
To make it easier for customers to query metric data when dealing with
multiple hosts.
## How to test
- Go to explore or a dashboard and create a Zabbix query where the query
type is `Metrics`
- The easiest way to test is by selecting `/.*/` for Groups, checking
the returned `Hosts` they should all be there
- Add a host tag filter and change the keys and operators as well as
switching from `AND/OR` to `OR` you should see how the values returned
for `Host` changes
## Future work
Adding variable support for host tags once this is completed.
Fixes:
https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3609900134&issue=grafana%7Coss-big-tent-squad%7C126
and https://github.com/grafana/grafana-zabbix/issues/927
---------
Co-authored-by: ismail simsek <ismailsimsek09@gmail.com>
## Summary
With the new logic to merge backend and frontend query responses, some
of the frontend query responses were being lost due to early
termination.
Merging frontend and backend responses was not properly waiting for all
promises to resolve before returning this "merged" result
## Detailed explanation
In `mergeQueries` although `Promise.all` was triggered, we returned
immediately without waiting for the promises to actually resolve, now
instead of passing down promises:
- use `switchMap` so that the upstream backend response observable can
be used as an inner Observable value to be concatenated with the rest of
the responses
- Why not use `map`? To prevent out of sync results, we need to wait for
the promises to resolve **before** we pass it down to the `mergeQueries`
function, `map` does not allow that.
- use `from` and trigger `Promise.all` **before** calling `mergeQueries`
so that all promise results can be resolved and converted to observables
by the time they get passed into the function
- modify `mergeQueries` to accept `DataResponse` for arguments, clone
the existing data and return the merged result.
<img width="1700" height="398" alt="Screenshot 2025-12-29 at 1 06 05 PM"
src="https://github.com/user-attachments/assets/c07c59b1-43b8-47f9-adc6-67583b125856"
/>
## Why
To fix how frontend and backend queries are merged so that no response
gets lost in the process
## How to test
1. Create a new dashboard or go to Explore
2. For query type select `Problems` or anything that is not `Metrics`
3. Execute the query, and you should be able to see a response.
## Summary
Adds a non-intrusive warning banner in the query editor that alerts
users when the selected time range exceeds 1 year (365 days). This helps
users understand that their query may return a large amount of data and
could take longer to execute, without blocking or interrupting their
workflow.
Part of https://github.com/grafana/oss-big-tent-squad/issues/127
## Changes
- Added `TIME_RANGE_WARNING_THRESHOLD_DAYS` constant (365 days) in
`src/datasource/constants.ts`
- Created new `TimeRangeWarning` component in
`src/datasource/components/TimeRangeWarning.tsx`
- Integrated the warning component into the main `QueryEditor` component
## How it works
- When the dashboard time range is >= 365 days, a warning banner appears
at the top of the query editor
- The warning displays the formatted duration (e.g., "1 year and 30
days")
- The warning is purely informational - queries still execute normally
- Uses Grafana theme colors for consistent styling in both light and
dark modes
## Screenshot
The warning appears as a subtle banner with a warning icon:
<img width="705" height="374" alt="grafik"
src="https://github.com/user-attachments/assets/eb0ace4b-524a-488e-8f88-b7e9523660b0"
/>
## Why
Queries spanning years of data can return millions of data points and
potentially overload the Zabbix server. This proactive warning helps
users make informed decisions about their query scope without adding
friction to the normal query flow.
## Summary
Adds a non-intrusive warning banner in the query editor that alerts
users when their query matches a large number of items (>= 500). This
helps users understand that their query may return a large amount of
data and suggests using more specific filters.
Part of https://github.com/grafana/oss-big-tent-squad/issues/127
## Changes
- Added `ITEM_COUNT_WARNING_THRESHOLD` constant (500 items) in
`src/datasource/constants.ts`
- Created new `ItemCountWarning` component in
`src/datasource/components/ItemCountWarning.tsx`
- Updated `MetricsQueryEditor` to track and report the count of items
matching the current filter
- Integrated the warning component into the main `QueryEditor` component
## How it works
- When items are loaded for the dropdown in the Metrics query editor,
the component counts how many items match the current item filter
- If using a regex filter like `/.*/`, it applies the regex to count
matching items
- If the count is >= 500, a warning banner appears at the top of the
query editor
- The warning is purely informational - queries still execute normally
- The warning only appears for the "Metrics" query type
## Screenshot
The warning appears as a subtle banner with a warning icon:
> I set the limit as 5 just to show the warning
<img width="901" height="298" alt="grafik"
src="https://github.com/user-attachments/assets/a9be8563-1b90-4581-ad15-4e7035b4166e"
/>
## Why
Queries that match thousands of items via wildcard filters (e.g.,
`/.*/`) can return massive amounts of data and potentially overload the
Zabbix server. This proactive warning helps users make informed
decisions about their query scope without adding friction to the normal
query flow.
## Summary
Throughout Zabbix we did not have a uniform UI - some drop-down were
using `Select` others `Combobox` others a custom one that we created.
Some had placeholders and others did not. This PR aims to standardize
our Zabbix UI across our query, variable and config editors
## Detailed summary
- Migrate from `Select` to `Combobox` -> `Select` component is
deprecated
- Migrate from `HorizontalGroup` to `Stack` -> `HorizontalGroup` is also
deprecated
- Remove use of "custom" dropdown `MetricPickerMenu` in favor of
`Combobox` ensuring uniformity across our drop-down and removing
maintenance overhead for us down the line
- Standardize placeholders across all inputs
<img width="630" height="243" alt="Screenshot 2025-12-17 at 1 13 45 PM"
src="https://github.com/user-attachments/assets/9382057e-b443-4474-a9c8-850086d7f3d4"
/>
<img width="691" height="256" alt="Screenshot 2025-12-17 at 1 14 05 PM"
src="https://github.com/user-attachments/assets/a05ff2af-8603-4752-8d12-337dc381c0fd"
/>
## Why
To have a clean and standard UI and remove use of UI deprecated
packages.
## How to test
- Query Editor:
- By creating a new query in a dashboard or Explore and interacting with
all the different query types and drop-downs
- All drop-downs should be searchable and have placeholders
- Config Editor:
- By going to a datasource and ensuring that the dropdown for Datasource
(when DB connection is enabled) and Auth type are responsive and working
as expected)
Fixes:
https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3740545830&issue=grafana%7Coss-big-tent-squad%7C139
This PR migrates the use of `DatasourceApi` to `DatasourceWithBackend`,
with this a couple additional improvements were made:
1. Migrate to use `interpolateVariablesInQuery` everywhere instead of
the custom `replaceTemplateVariables` we were using
2. Moves util functions out of `datasource.ts` and into the existing
`utils.ts`
<img width="1261" height="406" alt="Screenshot 2025-11-20 at 11 37
56 AM"
src="https://github.com/user-attachments/assets/9e396cf2-eab0-49d1-958c-963a2e896eba"
/>
Now we can see the `query` calls being made to the backend:
<img width="367" height="102" alt="Screenshot 2025-11-20 at 11 38 18 AM"
src="https://github.com/user-attachments/assets/a5a9a337-7f19-4f7c-9d04-9d30c0216fb2"
/>
Tested:
- By running queries from Explore and Dashboards (with and without
variables)
- By interacting with all the different Editors to make sure `ComboBox`
was working as expected
Next:
Once this is merged, we will next be able to slowly move away from using
the `ZabbixConnector` to make backend datasource calls.
Fixes:
[#131](https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=139450234&issue=grafana%7Coss-big-tent-squad%7C131)
Updating react-table to v8.
- Migrating the existing table to v8
- Preserving the visuals and logic
What's done?
- Cell components are moved under `Cells` folder
- Old styles for react-table-6 is removed.
- Old types are removed
- All logic was preserved
- Some cell components are removed for simplicity
Fixes: https://github.com/grafana/oss-big-tent-squad/issues/125
This PR moves the health check to backend only leaving in the frontend
the functionality to test the dbconnector datasource.
Leaving the `dbconnector.testDataSource` should be fine since the
datasource types we allow for db connection with Zabbix already are
backend datasources, and so their health requests would go through the
backend.
Verified:
Clicking test and seeing a `health` request go out.
IMPORTANT: While testing this in the UI, I found a bug with the config
editor - whenever a change is made in the UI and tested, the changes
don't take effect (i.e. disabling trends, keeps `trends` set to `true`,
enabling db connection keep `dbConnectionEnabled` set to `false` and so
on.). Created a separate
[issue](https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3627315751&issue=grafana%7Coss-big-tent-squad%7C132)
to fix this
Fixes https://github.com/grafana/oss-big-tent-squad/issues/124
Fixes https://github.com/grafana/grafana-zabbix/issues/2004
Zabbix 5.0.x supported filtering `Problems` feature with `applications`.
When this got removed, we removed the filter dropdown from the UI, but
failed to check whether applications were supported before sending out
the request with the parameters.
This was causing dashboards that had been created with zabbix version
`5.0.x` to fail when querying with newer versions of our plugin with
error: `Invalid params. Invalid parameter "/": unexpected parameter
"applicationids".`
These changes now ensure that we also check whether applications filter
should be supported before sending the backend request to fetch
problems.
How to test:
- use the attached JSON file. This was created using zabbix50 and
applying an `applicationids` filter for `Problems` query type OR
- run the `zabbix50` test environment:
```
cd devenv/zabbix50
docker-compose up -d
```
- create a dashboard that queries for `Problems` and filters with
applications then export the dashboard JSON
- stop the `zabbix50` test environment and start the `zabbix74` test
environment
```
docker-compose stop
cd ../zabbix74
docker-compose up -d
```
- import the dashboard you created above, it should load and work as
expected.
Bottom panel was created using zabbix50 and it used the application
filter. Both panels now load as expected:
<img width="2558" height="1018" alt="Screenshot 2025-10-21 at 2 28
25 PM"
src="https://github.com/user-attachments/assets/9613d59b-3f88-420c-9897-f8d988b3d2f0"
/>
Fixes https://github.com/grafana/grafana-zabbix/issues/1852
This PR resolves the below issues:
#2022#1465
Specifically, when executing a script on the problems panel, we do check
if the script scope is event or host.
Based on the script scope, the Zabbix API call is constructed
differently.
---------
Co-authored-by: Zoltán Bedi <zoltan.bedi@gmail.com>
