[FEATURE] Add LogExplorer plugin

[rickardsjp]

Description

This PR adds a Log Explorer for the growing number of log query datasources. The LogExplorer consists of a MultiQueryEditor for building log queries, an automatically-generated volume histogram showing log volume over time, and a LogsTable displaying the log entries. The histogram requires the log data source plugins to implement an optional createVolumeQuery interface method. This is currently implemented for Loki and VictoriaLogs, but not yet for ClickHouse.

Changes to other plugins

VictoriaLogs

• Added optional createVolumeQuery method to its LogQueryPlugin interface
• Implemented with dynamic interval selection (targets ~40 histogram bars across time range)
• Generates | stats by (_time:<interval>, _stream) count() as volume queries
• Filters __name__ metadata label from time series results for cleaner histogram legends

Loki

• Added optional createVolumeQuery method to its LogQueryPlugin interface
• Implemented with dynamic interval selection
• Generates sum by (level, detected_level) (count_over_time(...)) queries

ClickHouse

• Added optional createVolumeQuery method to its LogQueryPlugin interface
• Stub implementation returns null (requires SQL query parsing for proper implementation)

Testing this PR:

Because this PR changes multiple plugins at once, you will need to build the plugins using percli and copy them to the plugin_archive directory of your perses server. I believe the standard plugin development server can only run one plugin at once. If you clone the victorialogs repo, you can start a sample instance with make docker-vl-single-up. For Loki, you can use Grafana's instructions to set up a Loki datasource locally using docker compose. Remember to set the X-Scope-OrgID header to tenant1 in the Loki datasource in Perses.

Screenshots

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.

[rickardsjp]

The go lint check seems erroneous:

level=error msg="Running error: context loading failed: no go files to analyze: running `go mod tidy` may solve the problem"
time="2026-02-19T22:09:47Z" level=error msg="issue with golangci for the plugin logexplorer" error="exit status 5"

If a purely frontend plugin like this one has no Go SDK, it shouldn't fail. If the maintainers agree, I can also open a PR to skip the linting if no go files exist?

[shahrokni]

The go lint check seems erroneous:

level=error msg="Running error: context loading failed: no go files to analyze: running `go mod tidy` may solve the problem"
time="2026-02-19T22:09:47Z" level=error msg="issue with golangci for the plugin logexplorer" error="exit status 5"

If a purely frontend plugin like this one has no Go SDK, it shouldn't fail. If the maintainers agree, I can also open a PR to skip the linting if no go files exist?

@Nexucis
Remember that I had the same issue with e2e dir yesterday?
I can open a PR to create an exclusion list when iterating over workspaces.

-- UPDATE

@rickardsjp
OK, I got the approval for an exclusion script. I will let you know when it is merged, then you can rebase main and the issue will disappear

[rickardsjp]

OK, I got the approval for an exclusion script. I will let you know when it is merged, then you can rebase main and the issue will disappear

What about #578? Then we don't need to maintain a list.

[Nexucis]

so, re-reading the issue raised and the proposition from each party I would say there is two different issues here @shahrokni.

The first one is: with the inclusion of the e2e tests package in the npm workspaces, we have now packages which are not plugins and that needs to be excluded from various scripts that are only running for the plugins.

Then you also have the issue we have here when we are checking golang code per plugins. This was fine because we never had a plugins with frontend only features (so here explorer). In the past, the explorer was included with the datasource, so we never go the issue until now.

On that matter, I think the fix proposed by @rickardsjp makes sense as indeed we don't want to support an exact list on what should be excluded for the go check.

But @rickardsjp we still want to have this check if there is a schema. So instead of verifying if you have go files, I think you should more check if you have the schema folder. If you have schema folder, then we want to have the go-sdk folder. So if the go files are not present, we want the script to fail.

Does it make sense for you @rickardsjp ?

[rickardsjp]

Makes sense. I've adapted #578 to check for schemas instead.