![\"Update](\"https://perses.dev/assets/images/blog/v055/lock-mode-update.png\")
Welcome to the v0.55.0 release!
\nThis release first comes with a large number of security fixes, several of them critical, so we strongly recommend\nupgrading as soon as possible.
\nOn the dashboard side, you can now repeat a single panel, define annotations per panel, drag and drop panels between\ngroups and lock the plugin versions used by a dashboard. Prometheus exemplars are supported, the search has been\nrewritten on the backend, and two new plugins are available: Canvas and JSON.
\nAs usual, this blog post doesn't cover every change. For the complete list, check the\nchangelog.
\n\nThis release fixes a significant number of security vulnerabilities, several of them critical. Most of them can be\nexploited without authentication when Perses runs with its default configuration (security.enable_auth: false).\nWe strongly recommend upgrading as soon as possible.
Some of these fixes are breaking changes, check the upgrade guide\nbefore upgrading and or the section Breaking changes below for more details.
\nWe also published a security considerations page\n(#4512) describing how to deploy Perses safely.
\nWhen authentication was enabled without setting security.encryption_key (or security.encryption_key_file), Perses\nfell back to a key hardcoded in its public source code. This key is also used to sign the JWTs, so anyone could forge a\nvalid token for any user, including an admin.
Perses now refuses to start when authentication is enabled and no encryption key is provided.
\nThe datasource proxy (HTTP and SQL) connected to whatever destination the datasource defined. Combined with the\n\"unsaved\" proxy endpoints, Perses could be used to read any service reachable from the server: loopback, cloud metadata\nendpoints, the Kubernetes API, etc.
\nThe destination of the proxy is now verified when a datasource is saved and before each request, including on every\nresolved IP address. Loopback, link-local, the cloud metadata endpoints and the Kubernetes API are denied by default.\nPrivate networks remain allowed. The restrictions can be adjusted in the new datasource.proxy configuration section:
datasource:\n proxy:\n allowed_networks: [\"127.0.0.0/8\", \"::1/128\"]Secrets can reference files (passwordFile, credentialsFile, clientSecretFile, caFile, certFile, keyFile).\nThese files could be anywhere on the server, so a user able to create a secret could exfiltrate any file readable by\nPerses through the datasource proxy.
File references are now rejected by default. They are only allowed in the directories listed in the new\nsecurity.secret_file_allowed_directories configuration.
The HTTP datasource proxy forwarded the Cookie and Authorization headers of the caller to the datasource. Anyone\ncontrolling a datasource could steal the Perses session of its users (including the refresh token) and take over their\naccount.
The Cookie header of the caller is no longer forwarded, and neither is the Authorization header when the native\nauthorization is enabled. To authenticate against a datasource, use a secret or the oauthPassthrough option.
The responses of the datasource proxy are served from the Perses origin, almost unchanged. A malicious datasource could\nserve HTML and JavaScript running with the session of any user opening a link to it, set cookies on the Perses domain,\nor redirect users anywhere.
\nThe proxy responses are now sandboxed with a strict Content-Security-Policy, and the headers that apply to the Perses\norigin (Set-Cookie, CORS headers, absolute redirections, etc.) are removed. As a consequence, the UI of a datasource\n(e.g. the Prometheus UI) can no longer be browsed through the proxy.
Several vulnerabilities have been fixed in the SQL proxy:
\nSELECT, WITH, SHOW, etc.) and are executed in a read-only transaction. MySQL multiStatements, as\nwell as SELECT ... INTO OUTFILE / DUMPFILE, are rejected.allowAllFiles driver option could be enabled from the datasource params, letting the database server read any\nfile of the Perses server. This option, as well as allowCleartextPasswords and allowOldPasswords, is now always\ndisabled.A user allowed to edit a dashboard, but not to read secrets, could embed a datasource referencing any secret of the\nproject and make the proxy send it to a server they control. Perses now checks that the user can read the secret used\nby a datasource embedded in a dashboard.
\nWith the file system database, deleting the project .. (DELETE /api/v1/projects/..) deleted the entire database.\nThe name of the resource in the URL was never validated. Every parameter of the URL is now validated before being used.
The fix released in v0.54.0 for CVE-2026-63445\ncould be bypassed with a project named .. (e.g. GET /api/v1/variables?project=..), returning the whole database. The\nanonymous endpoint POST /api/validate/dashboards was also using the metadata.project of the dashboard without any\nvalidation.
The project name is now validated for every HTTP method and in the body of the requests, and the file system database\nitself rejects any key that would escape its directory.
\nNote that these issues (as well as the previous one) don't affect the SQL database.
\n\n@perses-dev/coreAs announced in v0.54.0, @perses-dev/core is no longer published\n(#4325). Its code has been dispatched in @perses-dev/spec,\n@perses-dev/client, @perses-dev/plugin-system and @perses-dev/components. It is also no longer shared with the\nplugins at runtime (perses/shared#246), so plugins still importing it must\nbe migrated.
The frontend toolchain has been modernized across all the repositories:
\nIf you embed Perses in your own application, you now have to register the Perses packages shared with the plugins\nbefore rendering your app (perses/shared#268):
\nimport * as PersesClient from '@perses-dev/client';\nimport * as PersesComponents from '@perses-dev/components';\nimport * as PersesDashboards from '@perses-dev/dashboards';\nimport * as PersesExplore from '@perses-dev/explore';\nimport * as PersesPluginSystem from '@perses-dev/plugin-system';\nimport { registerHostSharedModules } from '@perses-dev/plugin-system';\nimport * as PersesSpec from '@perses-dev/spec';\n\nregisterHostSharedModules({\n '@perses-dev/spec': PersesSpec,\n '@perses-dev/client': PersesClient,\n '@perses-dev/components': PersesComponents,\n '@perses-dev/plugin-system': PersesPluginSystem,\n '@perses-dev/explore': PersesExplore,\n '@perses-dev/dashboards': PersesDashboards,\n});Since v0.54.0, the dashboard and datasource specifications live in perses/spec. The\ndeprecated copies remaining in Perses have been removed (#4326): the Go\npackages pkg/model/api/v1/{common,dashboard,datasource,plugin,variable} and their CUE equivalents. If you still import\nthem, switch to the ones provided by github.com/perses/spec (e.g. github.com/perses/spec/go/dashboard).
datasource.Selector is now a union typeA datasource selector can now reference a variable, which is serialized as a plain string (e.g. \"$myDatasource\")\n(#4545). As a result, datasource.Selector no longer has the Kind and\nName fields, but a Static or a Variable selector. Use the new constructors instead of a struct literal\n(#4557):
// Before\nsel := &datasource.Selector{Kind: \"PrometheusDatasource\", Name: \"myPrometheus\"}\n\n// After\nstatic := datasource.NewStaticSelector(\"PrometheusDatasource\", \"myPrometheus\")\nvariable, err := datasource.NewVariableSelector(\"myDatasource\")\n// Or let the SDK detect a variable reference (\"$foo\" or \"${foo}\")\nauto, err := datasource.NewSelector(\"PrometheusDatasource\", name)The official plugins have been updated (perses/plugins#857): their\nSelector helper now detects variable references, and a new VariableSelector helper is available. If you maintain\nyour own datasource plugin with a Selector helper, update it the same way.
Likewise, the deprecated CUE package cue/common/proxy has been removed from perses/shared\n(perses/shared#327). Use github.com/perses/spec/cue/datasource/proxy/http\nand github.com/perses/spec/cue/datasource/proxy/sql instead.
If you develop plugins or embed Perses, these changes in the @perses-dev/* packages may require an update:
useDeepMemo and useMemoized are removed, use React useMemo instead. The spec of a Resource and the cell\nvalues of TableColumnConfig are now unknown instead of any (perses/shared#310).useId is no longer exported from @perses-dev/components, use React useId() instead\n(perses/shared#348).z.ZodType<T, T> instead of z.ZodType<T> or the deprecated z.ZodSchema<T>\n(perses/shared#282, perses/spec#95).PanelEditorValues type and its schema are removed from @perses-dev/spec, use the ones from\n@perses-dev/plugin-system (perses/spec#59).annotationState store field and the\nsetAnnotationState action are removed, and usePanelAnnotationsWithData no longer returns hidden annotations.Some of the security fixes require a configuration change on your side:
\nsecurity.encryption_key (or security.encryption_key_file) must be\nset, otherwise Perses won't start. If you were relying on the default key, the secrets previously stored can no longer\nbe decrypted and must be re-created, and users will have to log in again.localhost), allow them through datasource.proxy.allowed_networks or datasource.proxy.allowed_hosts. URLs\ncontaining credentials (https://user:password@host) are also refused: use a secret instead.security.secret_file_allowed_directories..., nor start or end with .\n(perses/spec#102). Rename the resources using such a name.Authorization header of the caller is no longer forwarded to the datasource when the native\nauthorization is enabled, and the UI of a datasource can no longer be browsed through the proxy.See the upgrade guide for more details.
\nThis release comes with several performance improvements on the backend. The numbers below come from the benchmarks\nshared in the corresponding pull requests.
\nUntil now, the proxy created a new HTTP transport for every proxied request, so no TCP or TLS connection was ever\nreused. Perses now keeps one transport per saved datasource\n(#4521), which is particularly visible with HTTPS datasources:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Case | Before | After | Gain |
|---|---|---|---|
| HTTP, sequential | 153 µs/op | 70 µs/op | ~2.2x |
| HTTP, parallel (10 CPUs) | 60 µs/op | 22 µs/op | ~2.8x |
| HTTPS, sequential | 1.69 ms/op | 72 µs/op | ~23x |
| HTTPS, parallel (10 CPUs) | 295 µs/op | 23 µs/op | ~13x |
It also uses ~4x less memory per request. On a real network, each request additionally saves the round trips of the\nTCP and TLS handshakes. The connection limits can be tuned with the new datasource.proxy.http configuration:
datasource:\n proxy:\n http:\n max_conns_per_host: 0 # 0 = no limit\n max_idle_conns: 100\n max_idle_conns_per_host: 10The permission cache of the native authorization is rebuilt at startup, periodically, on every RBAC change and on the\nfirst login of every OAuth/OIDC user. Its build now runs in linear time\n(#4540). With 10,000 users and 1,000 projects:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Benchmark | Before | After | Delta |
|---|---|---|---|
| Cache refresh | 2.81 s | 21 ms | −99.25% |
| 25 simultaneous first OAuth logins | 12.68 s | 149 ms | −98.82% |
The cache is now also an immutable snapshot read without any lock\n(#4537). It fixes a deadlock that could hang every authorization check\nuntil a restart, and makes permission checks under concurrent load ~7x faster (from ~145 ns to ~20 ns per check).
\nPlugin archives are now extracted in parallel (#4507), and the ones\nalready extracted are skipped (#4534). With the default plugins (32\narchives, ~9,000 files), the extraction step goes from ~1–2 s to ~1 ms when the archives are already extracted, and\nthe whole plugin initialization from ~1.35 s to ~0.3 s.
\nSkipping the archives benefits binary installations and deployments where the plugin folder is kept between restarts\n(e.g. mounted on a volume). With the official container image and its default setup, every new container still extracts\nall archives, but in parallel.
\nContent-hashed JS and CSS bundles (#4475), as well as fonts and images\nfrom the app and the plugins (#4533), are now served as immutable assets.\nBrowsers no longer download or revalidate them on every page load.
\nDashboards don't pin the version of the plugins they use, so a plugin upgrade can change how a panel looks. The new lock\nmode (perses/shared#243) pins every plugin of a dashboard to the latest\ninstalled version. When a newer version is available, a button lets you update the plugins, with a preview of the\nchange based on the first panel using it. If a pinned version is no longer installed, an error is displayed.
\nThe panel type selector also shows the plugin version when several versions are installed.
\nThe feature is disabled by default (#4370):
\nfrontend:\n enable_lock_mode: true
The grid layout library has been replaced by Snapgrid (perses/shared#296),\nso panels can now be dragged from one panel group to another. Drag and drop in lists (e.g. item actions) is also only\ntriggered from the drag handle, so you can select text again (perses/shared#335).
\n![\"Drag](\"https://perses.dev/assets/images/blog/v055/drag-and-drop.gif\")
Until now, only a panel group could be repeated over the values of a variable. A single panel can now be repeated as\nwell (perses/spec#32,\nperses/shared#149). In the Layout tab of the panel editor, choose the\nvariable, the alignment (horizontal or vertical) and the maximum number of panels per row or column:
layouts:\n - kind: Grid\n spec:\n items:\n - x: 0\n y: 0\n width: 12\n height: 6\n content:\n $ref: '#/spec/panels/cpu'\n repeatVariable:\n value: instance\n alignment: horizontal\n maxPer: 4Only the selected values are used, and a group repeat takes precedence over a panel repeat. Repeated panels are also\nsupported by the Grafana migration (#4328).
\n\nv0.54.0 introduced annotations at the dashboard level. They can now be defined on a panel as well\n(perses/spec#61, perses/shared#206,\n#4356). The panel displays the dashboard annotations plus its own ones.
\nA new Annotations tab is available in the panel editor for the plugins supporting it. For now, only the\nTimeSeriesChart does (perses/plugins#754). Panel annotations are\nvalidated by the backend like the dashboard ones (#4299), and the Go SDK\ncan now build both of them (#4448).
![\"Panel](\"https://perses.dev/assets/images/blog/v055/panel-annotations.png\")
The Prometheus datasource can now fetch exemplars\n(perses/plugins#799). It is disabled by default and must be enabled per\ndatasource:
\nkind: GlobalDatasource\nmetadata:\n name: prometheus\nspec:\n plugin:\n kind: PrometheusDatasource\n spec:\n exemplars:\n enable: true\n proxy:\n kind: HTTPProxy\n spec:\n url: https://prometheus.example.comExemplars are then fetched with range queries and displayed by the TimeSeriesChart as diamonds on top of their series\n(perses/plugins#800). Hovering one shows its labels (e.g. the trace ID),\nvalue and timestamp, and clicking it pins the tooltip (perses/shared#278).
![\"Exemplars](\"https://perses.dev/assets/images/blog/v055/exemplars.png\")
The search is now done by the backend, through the new endpoint /api/v1/search/dashboards\n(#4355). Dashboards are indexed in memory and matched with a fuzzy search.\nWith a SQL database, every Perses instance periodically checks for changes to keep its index in sync. By default, the\nname and the display name are indexed, but you can index any attribute, like the panel names:
search:\n index_keys:\n dashboard:\n - metadata.name\n - spec.display.name\n - spec.panels.@dig:display.nameThe project view also uses this endpoint to list the dashboards, without loading their full definition\n(#4366), and its search bar now matches tags too\n(#4446).
\nFinally, the important dashboards of the home page can be organized in groups, and an entire project can be marked as\nimportant (#4506). The previous flat list is still supported but\ndeprecated.
\nfrontend:\n important_dashboards:\n - title: Perses demos\n dashboards:\n - project: perses\n - project: testing\n - title: Quick links\n description: Highlighted dashboards\n dashboards:\n - project: perses\n dashboard: nodeexporter![\"Grouped](\"https://perses.dev/assets/images/blog/v055/important-dashboards.png\")
Roles from OAuth/OIDC claims (#4172): roles can be assigned from the\nclaims of the identity provider token, without creating any RoleBinding. Without project, the role is a GlobalRole.
security:\n authentication:\n providers:\n oidc:\n - slug_id: keycloak\n # ...\n claims:\n - claim_name: roles\n mappings:\n - claim_value: admin\n role_name: admin\n - claim_value: ops\n role_name: editor\n project: platformOAuth pass-through (#4404): with oauthPassThrough: true in its\nHTTPProxy, a datasource is queried with the OAuth/OIDC token of the current user. The token is refreshed when needed.
Kubernetes impersonation (#4339): with the Kubernetes authorization,\nthe Impersonate-User header is honored if the caller is allowed to impersonate this user.
Pre-hashed passwords (#4423): users can be provisioned with a bcrypt\nhash (spec.nativeProvider.passwordHash) instead of a cleartext password.
OIDC login property (#4468): like the OAuth provider, the OIDC\nprovider supports custom_login_property to choose the user info field used as login (e.g. preferred_username).
The HTTP proxy used by the datasources received a lot of attention in this release: it is safer, faster and more\nconfigurable.
\nSome datasources don't play well with certain headers sent by the browser or added by Perses (e.g. X-Forwarded-For).\nThe HTTPProxy spec now supports two optional header policies\n(#4428):
allowHeaders: only the listed headers are forwarded to the datasource.dropHeaders: the listed headers are removed, and the others are forwarded.kind: Datasource\nmetadata:\n name: prometheus\n project: my-project\nspec:\n default: true\n plugin:\n kind: PrometheusDatasource\n spec:\n proxy:\n kind: HTTPProxy\n spec:\n url: https://prometheus.example.com\n dropHeaders:\n - X-Forwarded-For\n - User-AgentHeader names are case-insensitive and only one of the two lists can be set. The filtering is applied after the headers\ndefined in the datasource, but before the secret authentication, so there is no need to allow Authorization when the\ndatasource uses a secret.
The HTTPProxy spec also accepts a new optional timeout field, available in the datasource editor as well\n(#4525). To avoid letting users hold goroutines and sockets against\nunreachable hosts for too long, the timeout of a datasource is bounded by the server configuration:
datasource:\n proxy:\n http:\n default_timeout: 30s # used when the datasource doesn't define a timeout\n max_timeout: 1m # highest timeout a datasource can defineA datasource defining a timeout greater than max_timeout is rejected when it is saved, and its timeout is clamped when\nit is used.
As described in the Security section, the proxy has been hardened in many ways:
\ndatasource.proxy. The allowed schemes can be\nrestricted with datasource.proxy.http.allowed_schemes;Cookie header of the caller is never forwarded, and neither is the Authorization header when the native\nauthorization is enabled. An Authorization header defined in the headers of a datasource is ignored: use a secret\ninstead;Content-Security-Policy, and the headers applying to the Perses origin are\nremoved.Some of these changes may require a configuration update, check the Security changes section and\nthe proxy documentation for more details.
\nFinally, the proxy now keeps one HTTP transport per datasource and reuses its connections, making HTTPS requests up to\n~23x faster. See Datasource proxy reuses its connections for the numbers\nand the new connection limits.
\nThe auto-refresh options of the dashboards can now be configured (#4432),\nor the auto-refresh can be disabled entirely (#4338). In that case, the\ninterval picker is hidden and the refreshInterval of the dashboards, as well as the ?refresh= URL parameter, are\nignored.
Similarly, administrators can define the default timezone, theme and number of rows per page, used when a user hasn't\nchosen their own (#4268).
\nfrontend:\n auto_refresh:\n disable: false\n options: [\"0s\", \"30s\", \"1m\", \"5m\"]\n default_user_preferences:\n timezone: UTC\n theme: dark\n rows_per_page: 50--- (#4332).provisioning:\n enable_watch: true\n folders:\n - /etc/perses/provisioningpercli dac watch rebuilds your Dashboard-as-Code files on every change, including the dashboards\ndepending on a modified library file (#3903). Combined with the\nprovisioning watch mode, it gives you a live reload of your dashboards.percli dac preview supports the --create-project flag, like percli apply\n(#4413).Perses now exposes the CUE schemas of the dashboards and of the installed plugins\n(#4505). It is particularly useful for tools generating dashboards, like\nthe Perses MCP server:
\nGET /api/v1/schemas/dashboards: the complete dashboard schema, including the plugin schemas.GET /api/v1/schemas/plugins: the schemas of all plugins.GET /api/v1/schemas/plugins/<plugin_name>: the schema of a single plugin, with the optional version and\nregistry query parameters.The datasource editor has a new Test Connection button to check the datasource is reachable before saving it\n(#4396, perses/shared#99).\nIt is available for Prometheus (perses/plugins#620), OpenSearch\n(perses/plugins#797) and AlertManager\n(perses/plugins#798).
The Kubernetes datasource discovery can also mark a discovered datasource as the default one, based on its labels or\nannotations (#4368):
\ndatasource:\n global:\n discovery:\n - name: prometheus\n kubernetes_sd:\n # ...\n default:\n enable: true\n labels:\n app.kubernetes.io/name: prometheusThe Canvas panel (perses/plugins#729) is a free-form diagram editor to\nbuild weathermap-like visualizations. Place nodes, connect them with edges and add background shapes or images. Nodes\nand edges can be bound to a query: their color then follows thresholds and the edge thickness can scale with the value.
\n![\"Canvas](\"https://perses.dev/assets/images/blog/v055/canvas.png\")
The new JSON datasource and query (perses/plugins#770) can query any HTTP\nendpoint returning JSON, with GET or POST, query parameters and variables. The response can be transformed with a\nJSONata expression, and the result displayed in a Table panel.
![\"JSON](\"https://perses.dev/assets/images/blog/v055/json-query.png\")
Auto\nkeeps the current color by series name, the categorical palettes give more distinct colors.PivotByLabel transform turns series into a time × label matrix (perses/shared#288)./render endpoint\n(perses/plugins#763). The minimum step can be configured on the\ndatasource (perses/plugins#810), and the profile types and labels\nproposed are restricted to the selected service (perses/plugins#820,\nperses/plugins#835).| TimeSeriesChart color palette | StatChart grid layout |
|---|---|
![\"TimeSeriesChart](\"https://perses.dev/assets/images/blog/v055/palette.png\") | ![\"StatChart](\"https://perses.dev/assets/images/blog/v055/statchart-layout.png\") |
Duplicate a dashboard into another project (#4536), including from\na project where you only have read access.
\n![\"Duplicate](\"https://perses.dev/assets/images/blog/v055/duplicate-dashboard.png\")
Open in a new tab: the project and admin tabs, as well as the ephemeral dashboards, are now real links\n(#4252).
\nPage title: the browser tab title now reflects the current page (#4489).
\nCollapsed panel groups show the number of panels they contain (perses/shared#309).
\nCustom unit label: a panel can display its own unit label (e.g. trx/s) while keeping the formatting of a\nstandard unit (perses/shared#297).
Grafana migration: the default time range, the refresh interval and the timezone of the Grafana dashboard are kept\n(#4555). Table thresholds are migrated to cell settings\n(perses/plugins#808), and datasource variables for Jaeger and\nOpenSearch are supported (perses/plugins#769).
\nCompressed requests: the API accepts request bodies compressed with gzip (Content-Encoding: gzip)\n(#4381).
Custom fetch: apps embedding Perses can override the fetch used by the client and the datasources through a\nfetch provider, e.g. to add custom headers (perses/shared#214,\nperses/shared#316, perses/plugins#854).
Welcome in the v0.54.0 release !
\nFirst of all this release includes several security fixes that patches some breach in the permission system included in\nPerses, so we strongly recommend to upgrade to this version as soon as possible.
\nThen, you will be happy to know that this release includes new plugins: Jaeger, GreptimeDB, Splunk, LogExplorer,\nAlertManager and OpenSearch.
\nAs adding more plugins is increasing the size of the container image, likely we will remove some of them in future\nrelease. It does not mean we will remove the support for these plugins, it is just we won't include them into the\ndefault image. You will have to add them manually. The drop will occur once we are able to provide a good way to add\nplugins to an existing installation without having to rebuild the image. In the meantime, if you don't want to use these\nplugins, you can choose to enable or disable them by configuration.
\nWe are also happy to announce it includes the long awaited sub-folder system to better organize your dashboards and\nimprove the accessibility by adding keyboard shortcuts.
\nThis release is also the last release for the package @perses-dev/core that is now deprecated. For that we are\nintroducing two new packages @perses-dev/spec and @perses-dev/client.
@perses-dev/spec contains the dashboard and datasource specifications.@perses-dev/client contains the client to interact with the Perses API.The code from @perses-dev/core has been dispatched in these these two packages and in others (like\n@perses-dev/plugin-system and @perses-dev/components) to better separate the concerns and make it easier to\nmaintain.
Finally, thank you to all the contributors who made this release possible, you are more and more, and we are really\nhappy to see the community growing and contributing to make Perses better and better!
\nAs usual, this blog post does not cover all the changes and improvements included in this release. We are only talking\nabout the changes that should interest you the most. If you want to have a complete list of all the changes, please\nrefer to the changelog
\n\nOn top of the various features and improvements, we have fixed several security issues in this release that compromised\nthe permission system of the Perses application. We strongly recommend to upgrade to this version as soon as possible.
\nIn previous versions, it was possible to list resources (dashboards, datasources, etc.) that you don't have access to by\nusing the query parameter project in the API.
For example, if you have access to the project project-a but not to project-b, you could list all dashboards in\nproject-b by calling the API endpoint /api/v1/dashboards?project=project-b. This would return a list of dashboards\nin project-b even if you don't have access to that project.
Now, if you try to list resources that you don't have access to, you will get a 403 Forbidden error.
\nIn previous versions, it was possible to use the project query parameter to access files outside the Perses\ninstallation directory. This could be exploited by an attacker to read sensitive files on the server.
It was also possible to use this query parameter to get access to other resources contained in the database by using a\nproject name that contains a path traversal sequence (e.g. ../secrets).
For example /api/v1/dashboards?project=../projects returns the list of the project while it must not return anything.
Now, if you try to use a project name that contains a path traversal sequence, you will get a 400 Bad Request error.
\nNote that this attack is not possible if you are using an SQL database instead of the default fileSystem database.
\nIn previous versions, it was possible to contact datasources protected by secrets that you don't necessary have access\nto by using the datasource proxy.
\nThis was because the datasource proxy did not check if you have access to the secret used to connect to the datasource\nwhile testing the connection to the same datasource.
\nNow, if you are creating a datasource or testing a connection to a datasource, the datasource proxy will check if you\nhave access to the secret used to connect to the datasource. If you don't have access to the secret, you will get a 403\nForbidden error.
\nWe have created a new repository called perses/spec that contains the Dashboard and\nDatasource specifications in different languages (Go, TypeScript, Cuelang).
\nThe goal of this repository is to provide a single source of truth for the specifications and make it easier for\ndevelopers to work with them in different programming languages, independently of the Perses project.
\nThe specifications are now used in the Perses app, the Go and CUE SDKs, and the CLI. This means that if you use the SDKs\nand/or the CLI, you will need to update your code to use the new specifications and upgrade the CLI to v0.54.0.
\n@perses-dev/core deprecationAs part of the introduction of the Perses specification, we are deprecating the package @perses-dev/core. We have\ncreated a final version of this package that is compatible with the new specifications and will be available in the npm\nregistry. However, we recommend migrating your code to use the new specifications instead of using this package.
Also, if you are using the @perses-dev/core package in your code, you may be using more than just the specifications.\nIn this case, you will also need to update your imports to use the new @perses-dev/client package.
Please read the migration guide for more details about how to migrate\nyour code to use the new specifications and the new package.
\nAs we are adding more and more plugins to Perses, we have introduced a new configuration option to enable or disable\nplugins. This gives users more fine-grained control over which plugins are available in their Perses instance and\nreduces noise and issues caused by unused plugins.
\nFor example, with the following configuration:
\nplugin:\n disabled:\n - \"pyroscope\"\n - \"victoriaLogs\"\n - \"clickHouse\"\n - \"tempo\"Prometheus will be the only datasource enabled in the default Perses installation.
\nAnother way to achieve the same result is to explicitly enable only the plugins you want to use:
\nplugin:\n enabled:\n - \"prometheus\"In this example, only the Prometheus plugin will be enabled and all other plugins will be disabled.
\nNote that, a consequence of this configuration is that every panels, variables and queries are also disabled.
\nThis also means that if you add a new plugin in the future, it will be disabled by default, and you will need to\nexplicitly enable it in the configuration.
\nPerses now supports annotations, which add information such as events to panels.
\nPanels must support annotations; for now, only the TimeSeries Chart panel does. In addition, only annotations based on\nPrometheus PromQL are supported. However, thanks to the Perses plugin architecture, support for annotations can easily\nbe added to any datasource (as source of data) or panel (for the display).
\n![\"TimeSeries](\"https://perses.dev/assets/images/blog/v054/annotation-editor.png\")
\n![\"TimeSeries](\"https://perses.dev/assets/images/blog/v054/annotations.png\")
Perses v0.54.0 introduces built-in keyboard shortcuts to help you navigate and operate dashboards faster without having\nto using a mouse. Press ? anywhere in the UI to open the shortcuts help modal, which lists all available shortcuts\ngrouped by category.
Some highlights:
\n? — Open the keyboard shortcuts help modalCtrl/⌘ + K — Open the search dialogG + H — Go to the Home pageCtrl/⌘ + S — Save the current dashboardD + M — Toggle between edit and view modeE — Edit the focused panel (in edit mode)V — Toggle fullscreen on the focused panel![\"Keyboard](\"https://perses.dev/assets/images/blog/v054/keyboard-shortcuts.gif\")
Keyboard shortcuts are enabled by default. To disable them, set the following in your Perses configuration:
\nfrontend:\n enable_keyboard_shortcuts: falsePerses now supports folders — a way to organise dashboards within a project using a tree structure. A folder's\nspec.items can contain both dashboard references and nested subfolders, allowing you to mirror how your teams\nstructure their observability content.
![\"Sub-folder](\"https://perses.dev/assets/images/blog/v054/subfolder-tree-view.png\")
The project's dashboard list displays dashboards in a tree view, where you can browse, create, edit, and delete folders\nand subfolders. The same operations are available through the API and CLI (percli apply, percli get folder, etc.).
For example, the demos folder visible in the screenshot above is defined as:
{\n \"kind\": \"Folder\",\n \"metadata\": {\n \"name\": \"demos\",\n \"project\": \"perses\"\n },\n \"spec\": {\n \"items\": [\n {\n \"kind\": \"Dashboard\",\n \"name\": \"demo\"\n },\n {\n \"kind\": \"Dashboard\",\n \"name\": \"benchmark\"\n },\n {\n \"kind\": \"Folder\",\n \"name\": \"infrastructure\",\n \"items\": [\n {\n \"kind\": \"Dashboard\",\n \"name\": \"nodeexporter\"\n }\n ]\n }\n ]\n }\n}This version of Perses now ships a bundled OpenSearch datasource along with a LogQuery plugin. Users can now query and\nview their logs directly in a Perses dashboard, right next to the other panels with metrics and traces.
\nConnecting to an existing OpenSearch cluster is easy, using either a proxy or a direct connection. The recommended setup\nroutes requests through the Perses backend proxy: the browser talks to Perses and Perses talks to OpenSearch, so any\ncredentials stay server-side and you don't need to enable CORS on your cluster. A direct connection is also available\nfor local experimentation.
\n![\"OpenSearch](\"https://perses.dev/assets/images/blog/v054/opensearch-datasource.png\")
Logs are queried\nwith PPL (Piped Processing Language). You add a\nLogs Table panel, pick the OpenSearch Log Query query type, point it at an index pattern, and write a PPL\nquery — for example, showing the most recent ERROR lines from a service.
![\"OpenSearch](\"https://perses.dev/assets/images/blog/v054/recent-logs.png\")
Results are rendered as log entries, with every other column in the row kept as a label so you can filter and display\nfields like service.name, severityText, or traceId. You can drop several log panels on a single dashboard. For\ninstance, a broad \"Recent Logs\" view alongside a filtered \"Error Logs\" one.
![\"OpenSearch](\"https://perses.dev/assets/images/blog/v054/log-dashboard.png\")
A couple of things happen automatically to make this feel native. Queries are bound to the dashboard's current time\nrange. The plugin injects a timestamp filter for you, so the logs follow the time picker (you can turn this off per\nquery). And because OpenSearch indices are schema-flexible, the plugin auto-detects the timestamp and message fields\nfrom common names, with per-query overrides when your index uses different ones. Since traceId is just another field,\nyou can even setup an OpenSearch logs panel next to a Tempo or Jaeger trace panel on the same dashboard and pivot from a\ntrace straight to the logs it produced.
This release adds support for Jaeger. With this integration, you can run trace queries against Jaeger from Perses dashboards or explorer.
\n![\"Jaeger](\"https://perses.dev/assets/images/blog/v054/jaeger.png\")
This release adds support for GreptimeDB as a datasource in Perses.
\n\n\nGreptimeDB is an open-source observability database built for Observability 2.0 — treating metrics, logs, and traces\nas one unified data model (wide events) instead of three separate pillars.
\n
With this integration, you can run log, trace, and time series queries against GreptimeDB directly from Perses\ndashboards.
\nThe images below show a dashboard example and the corresponding query editors.
\n![\"GreptimeDB](\"https://perses.dev/assets/images/blog/v054/greptimedb_dashboard.png\")
| GreptimeDB Log Query | GreptimeDB Time Series Query |
|---|---|
![\"GreptimeDB](\"https://perses.dev/assets/images/blog/v054/greptimedb_logquery.png\") | ![\"GreptimeDB](\"https://perses.dev/assets/images/blog/v054/greptimedb_tsquery.png\") |
Perses now supports Splunk as a datasource, bringing Splunk's search capabilities directly into your Perses dashboards.
\nThe Splunk plugin lets you connect to Splunk Enterprise or Splunk Cloud and query data using SPL (Splunk Processing\nLanguage) — the same query language you already use in Splunk. Once connected, you can visualize results as time series\ncharts or explore raw log data, all within the Perses UI.
\n| TimeSeries | Logs |
|---|---|
![\"Splunk](\"https://perses.dev/assets/images/blog/v054/Splunk-Time-Series.jpg\") | ![\"Splunk](\"https://perses.dev/assets/images/blog/v054/Splunk-Log-Query.jpg\") |
Perses now supports Alertmanager as a datasource. This\nallows you to visualize and manage alerts and silences directly from a Perses dashboard.
\n| Alerts | Silences |
|---|---|
![\"Alerts](\"https://perses.dev/assets/images/blog/v054/alerts-table.png\") | ![\"Silences](\"https://perses.dev/assets/images/blog/v054/silences-table.png\") |
Perses has been extended with a generic Log Explorer. This allows you to visualize and explore logs from any datasource\nthat supports logs, such as Loki, VictoriaMetrics, ClickHouse, GreptimeDB, etc.
\n![\"Log](\"https://perses.dev/assets/images/blog/v054/logexplorer.png\")
This is a really great addition to Perses, as it will avoid the need to implement an explorer for each datasources\nsupporting logs.
\nWe are thinking about doing the same for traces in the future, but we are still evaluating the best approach to do so.
", "date_published": "2026-07-29T00:00:00Z", "tags": [ "Release notes" ] }, { "id": "https://perses.dev/blog/2026/01/31/release-v0530/", "url": "https://perses.dev/blog/2026/01/31/release-v0530/", "title": "Release v0.53.0", "summary": "Welcome to Perses v0.53.0! In this release, on top of many improvements and bug fixes, we have introduced several changes that break the compatibility with previous versions.", "content_html": "\nWelcome to Perses v0.53.0! In this release, on top of many improvements and bug fixes, we have introduced several\nchanges that break the compatibility with previous versions.
\nThese changes have been thinking carefully to improve the overall user experience and maintainability of Perses. We hope\neven if it will make the upgrade process a bit more complex, you will stay with us and enjoy the benefits of these\nimprovements.
\nWhile you can read this blog post to have details about the changes and how to upgrade, we are also providing a\nmigration guide that is more condensed and focused on the steps\nrequired to upgrade from previous versions to v0.53.0.
\nOn a different topic, we are happy to being able to list Logz.io as a new officially company using\nPerses in production. Welcome to the Perses community!
\nIf you are a company using Perses or contributing to it and want to be listed as an adopter, please follow\nthe guideline. It is always great to see more and more companies trusting Perses for their\nmonitoring needs. And it will help us to grow the community and make Perses even better.
\nAs usual, this blog post does not cover all the changes and improvements included in this release. We are only talking\nabout the changes that should interest you the most. If you want to have a complete list of all the changes, please\nrefer to the changelog
\n\nTo enhance the management of plugins specially when dealing with upgrading a plugin version that may introduce breaking\nchanges, we introduced a new field in the plugin specification called metadata. It includes a version field that\nallows to specify the version of the plugin and the registry field that indicates the source registry of the plugin.
Now a plugin specification looks like this:
\nkind: TimeSeriesChart\nmetadata:\n version: v0.1.0\n registry: perses.dev\nspec:\n# ... rest of the plugin specNote that the version is following the semantic versioning format (semver) and this is enforced during the loading of\nthe plugin.
\nThis change is important as it will allow in the future to manage multiple versions of the same plugin and facilitate\nthe migration from one version to another. We are planning to introduce automatic migration tools in future releases to\nhelp users upgrade their plugins seamlessly. Excepting if a plugin is introducing breaking changes that cannot be\nautomatically handled, the upgrade process will be handled by the Perses backend using cuelang script contained in the\nplugin package.
\nFor end users using the Perses application, this change is transparent and does not require any action.
\nHowever, for plugin developers, you will need to update the CLI to the last version. This is required as the API\nhandling the load of the plugins in development has changed. Therefore, previous versions of the CLI won't be able to\nsend the data to the server to load plugin in development. The error returned by the server will be 405 (Method Not\nAllowed). (see https://github.com/perses/perses/issues/3789)
\nIf you want to see the changes and more details regarding how it is implemented, they are available in this\nPR: https://github.com/perses/perses/pull/3711
\nWe are introducing a breaking change in the TLS configuration to have a consistent syntax to define TLS settings across\nall data-sources specifications and across all backend sub configurations.
\nThe previous version was mixing two syntaxes to set TLS across the various possible configuration that could lead to\nconfusion (camelCase and snake_case).\nThis breaking change is impacting only the SQL database configuration.
\nIn the SQL configuration, if the tls_config is used, then you should change your config like that:
\nca_file -> caFile\ncert_file -> certFile\nkey_file -> keyFile\nserver_name -> serverName\ninsecure_skip_verify -> insecureSkipVerify\nmin_version -> minVersion\nmax_version -> maxVersionIn order to simplify the build of the docker image, we have changed the default user used in the container from nobody\nto nonroot. As a based image we are using now gcr.io/distroless/static-debian12:non-root instead of\nggcr.io/distroless/static-debian12:latest, which gives us a non-root user by default.
This change can impact users that is using as a database the file system inside the container, specially when running\nthe container with docker (not within Kubernetes). In that case, you should ensure that the nonroot user has the right\npermissions to read and write into the database folder. If this is not the case, when upgrading the image, you will face\npermission errors when Perses is trying to load the data coming from the file system.
A new OIDC logout endpoint has been added to the API, allowing users to log out both from Perses and from their OIDC\nprovider, respecting\nthe OpenID Connect RP-Initiated Logout 1.0\nspecification.\nThis is mainly used by the frontend to ensure a proper provider-side logout when a user signs out.
\nThe feature is currently in beta and disabled by default. It has been successfully tested with Azure AD\nand Keycloak, so feel free to try it out.
We also introduced several improvements to the generic OIDC/OAuth2 provider system:
\napiPrefix configuration is now correctly applied during login redirections.state parameter is now more secure, enabling compatibility with providers such as Authelia.If you are developing plugin specially query plugin or embedding MultiQueryEditor in your app, these changes will impact\nyou,\nand you need to follow these guidelines.
\nMultiQueryEditor component has a new mandatory method: onQueryRun. It will be called when the user click on the\nbutton \"Run Query\". It's useful if you want to execute a query only when this button is clicked and not on every\nonChange (previous Perses behavior). Now the onChange method is always called when something change in the editor.\nOn the Perses app, queries are only executed when the user click on the \"Run Query\" button, however changes are still\nsaved\nif user save the dashboard without clicking on \"Run Query\". But embedded use-cases might want to execute queries on\nevery change,\nso this new behavior allows both use-cases.
In parallel, the caching of queries has been greatly improved to avoid memory leaks on dashboard refresh. More info can\nbe found in related PR: #3518\nAnd queries errors are now displayed at the query level (before it was only displayed at the panel level, could be hard\nto know which queries are causing issues).
\nAbout the breaking change, your code should change from this:
\nexport function FooExplorer(): ReactElement {\n const {\n data: {queries = []},\n setData,\n } = useExplorerManagerContext<FooExplorerQueryParams>();\n\n return (\n <Stack gap={2} sx={{width: '100%'}}>\n <MultiQueryEditor\n queryTypes={['ProfileQuery']}\n queries={queries}\n onChange={(newQueries) => setData({queries: queryDefinitions})}\n />\n <FooPanel queries={queries}/>\n </Stack>\n );\n}to this:
\nexport function FooExplorer(): ReactElement {\n const {\n data: {queries = []},\n setData,\n } = useExplorerManagerContext<FooExplorerQueryParams>();\n\n const [queryDefinitions, setQueryDefinitions] = useState<QueryDefinition[]>(queries);\n\n return (\n <Stack gap={2} sx={{width: '100%'}}>\n <MultiQueryEditor\n queryTypes={['ProfileQuery']}\n queries={queryDefinitions}\n onChange={(newQueries) => setQueryDefinitions(newQueries)}\n onQueryRun={() => setData({queries: queryDefinitions})}\n />\n <FooPanel queries={queries}/>\n </Stack>\n );\n}We realized variable migration script could be simplified & better follow CUE's good practices by replacing condition\nblocks by constraints defined on the variable object. However to enable this we had to introduce a breaking change*:\nwhere previously such schema was describing the remapping of a Grafana variable object named #var, it is now called\n#grafanaVar. Thus, if you had defined a schema looking like this:
package migrate\n\nimport \"strings\"\n\n#var: _ \n\nif #var.type == \"custom\" || #var.type == \"interval\" {\n kind: \"MyVariable\"\n spec: {\n values: strings.Split(#var.query, \",\")\n }\n}..the minimum change you need to do is this renaming:
\npackage migrate\n\nimport \"strings\"\n\n#grafanaVar: _ \n\nif #grafanaVar.type == \"custom\" || #grafanaVar.type == \"interval\" {\n kind: \"MyVariable\"\n spec: {\n values: strings.Split(#grafanaVar.query, \",\")\n }\n}Then it is recommended to refactor to something like this:
\npackage migrate\n\nimport \"strings\"\n\n#grafanaVar: {\n type: \"custom\" | \"interval\"\n query: string\n ...\n}\n\nkind: \"MyVariable\"\nspec: {\n values: strings.Split(#grafanaVar.query, \",\")\n}*We believe the trade‑off was worth introducing this breaking change, as we expect very few (if any) people to have\nwritten such variable migration schemas outside of the Perses organization. However, if you are impacted, please reach\nout to us! Learning more about our community helps us make better future decisions by having a clearer understanding of\npotential impacts.
\nThis new version is introducing internationalization (i18n) support in the frontend, allowing to easily add new\nlanguages and provide a better experience for non-English speaking users. The i18n implementation is based on the widely\nused react-i18next library, which provides a powerful and flexible solution for managing translations in React\napplications.
For the moment, the il8n is really limited as it only contains a few translations for few languages. The main goal of\nthis change is mainly to get the i18n support in place and have a framework to easily add new translations in the\nfuture.
\nThis release introduces Kubernetes authentication and authorization providers, enables authorization decisions for users\nbased on Kubernetes RBAC checks against Perses CRDs. This change marks a forward step in Perses Kubernetes integration\nstory, allowing Perses CRDs to not just create resources but be used in conjunction with Kubernetes Roles and\nRoleBindings to provide access checks for users within Perses itself. Due to the variety of authentication providers\nfor Kubernetes, the implementation is designed to be provider agnostic. When enabled, Perses expects requests to contain\nan Authorization header in the form of Authorization: Bearer XXXX. The token is used to authenticate against the\nKubernetes API Server and check if the user has permission to requested namespaces and resources.
The concept of authorization providers has been added with this change, marking the\n.security.authorization.guest_permissions and .security.authorization.check_latest_update_interval fields as\ndeprecated, moving them to the \"native\" authorization provider. These fields will be removed in a future release.
security:\n authorization:\n provider:\n native:\n enable: true\n check_latest_update_interval: 5m\n guest_permissions:\n # ...The frontend and percli have been updated to support these new providers. An /api/v1/user/whoami endpoint has been\ncreated to return user information for a logged in user. The percli has had --kube and --kubeconfig-file flags added\nwhich use the bearer token present in a kubeconfig file to authenticate with the Perses backend.
percli login --kube --kubeconfig-file=\"./kubeconfig\" http://localhost:8080\nsuccessfully logged in http://localhost:8080The Kubernetes authentication and authorization providers must be enabled together. When enabled, the Perses backend\nwill use its pod's service account to authenticate and authorize users. The service account should be given\nTokenReview and SubjectAccessReview create and Namespace list permissions. The authenticator and authorizer\nprovider configurations are exposed as configuration options:
security:\n enable_auth: true\n authorization:\n provider:\n kubernetes:\n enable: true\n qps: 500\n burst: 1000\n authorizer_allow_ttl: 5m\n authorizer_deny_ttl: 30s\n authenticator_ttl: 2m\n authentication:\n providers:\n kubernetes:\n enable: trueplugin test-schemas has been improved to test that the actual migrated schemas are valid against the expected\nschemas.plugin start is now able to discover the port used by rspack to serve the plugin in development mode, so you don't\nneed to provide it anymore.\nlint: when you were using local plugin to validate the dashboards, it was mandatory to have the plugins extracted in\na folder. Now you can also provide the plugins as an archive like it is the case for the Perses server. The command\nwill extract the plugins before starting validating any data.// TODO list of improvements, ideally give major changes and improvements for each plugin.
\nIn the previous version of the GO-SDK, a query plugin was defined by using the Query builder. The issue with this\napproach is that it was not possible to provide the high level query type as it was hardcoded in the query builder.
\nThis was not a problem for the Perses app as we only have one query type until recently. It changed with the\nintroduction of the new query types: \"ProfileQuery\", \"LogQuery\" and \"TraceQuery\". To support this new use-case, we had\nto introduce a breaking change in the way to define a query plugin.
\nNow, instead of using the Query builder, you need to fill a struct query.Option that contains the query plugin and the\nhigh level query type.
If we take the Prometheus plugin as an example, the implementation will change from this:
\npackage query\n\nimport (\n\t\"github.com/perses/perses/go-sdk/query\"\n)\n\nfunc PromQL(expr string, options ...Option) query.Option {\n\treturn func(builder *query.Builder) error {\n\t\tplugin, err := create(expr, options...)\n\t\tif err != nil {\n\t\t\treturn err\n\t\t}\n\n\t\tbuilder.Spec.Plugin.Kind = PluginKind\n\t\tbuilder.Spec.Plugin.Spec = plugin\n\t\treturn nil\n\t}\n}\nto this:
\npackage query\n\nimport (\n\t\"github.com/perses/perses/go-sdk/query\"\n\t\"github.com/perses/perses/pkg/model/api/v1/common\"\n\t\"github.com/perses/perses/pkg/model/api/v1/plugin\"\n)\n\nfunc PromQL(expr string, options ...Option) query.Option {\n\tplg, err := create(expr, options...)\n\treturn query.Option{\n\t\tKind: plugin.KindTimeSeriesQuery,\n\t\tPlugin: common.Plugin{\n\t\t\tKind: PluginKind,\n\t\t\tSpec: plg,\n\t\t},\n\t\tError: err,\n\t}\n}\nCelsius (°C) and Fahrenheit (°F) temperature units are now available for panel plugins that support unit configuration.
\nOn top of that, this release is also introducing two new data-sources: VictoriaLogs and ClickHouse provided directly by\nthe community.
\n// TODO: write more about these two data-sources, highlight their features, and who did it.
\nNote that since these two data-sources are provided by the community, they are not officially supported by the Perses\nteam.\nAnd as such, soon we will come with a governance model to manage community plugins. In later release, these plugins\nmight be removed in the main images, depending on the governance adopted. You will still be able to use them by\ninstalling the datasources in your Perses instance.
", "date_published": "2026-01-31T00:00:00Z", "tags": [ "Release notes" ] }, { "id": "https://perses.dev/blog/2025/09/15/release-v0520/", "url": "https://perses.dev/blog/2025/09/15/release-v0520/", "title": "Release v0.52.0", "summary": "The release of Perses v0.52.0 introduces significant new features and improvements.", "content_html": "\nThe release of Perses v0.52.0 introduces significant new features and improvements.
\nThis update expands Perses' observability capabilities by introducing support for logging and continuous profiling,\nalong with new plugins for Pyroscope, Flame Chart, Loki, and log visualization.
\nAdditional enhancements include a heatmap panel for Prometheus histograms, a quick query viewer, panel group variable repeat,\nusability improvements, and upgraded CLI commands to streamline plugin development and schema testing.
\n\nThis release provides the support of Continuous Profiling through two plugins:
\nContinuous Profiling is a new observability signal, complementing the traditional logs, metrics, and traces. This\ninnovative approach provides a way of continuously measuring applications' resource consumption with code-level\ngranularity and low overhead. This signal generates excitement in the community for its ability to provide in-depth\nvisibility into production performance of applications.
\nThe flame graph panel offers a simple and intuitive way to represent performance data, providing a hierarchical view\nthat let you zoom in on any stack for a detailed analysis. It helps to understand resource allocations (CPU,\nMemory, ...) and bottlenecks within an application.
\n![\"Flame](\"https://perses.dev/assets/images/blog/v052/flame-graph-panel.png\")
This panel displays the profile in a table format. It allows you to sort stacks, for example in descending order, to see\nwhich function consume the most resources. A search bar is also present for filtering the table and highlighting stacks\nin the flame graph.
\n![\"Table](\"https://perses.dev/assets/images/blog/v052/table-view-panel.png\")
When retrieving profiles from the Pyroscope server, they include timeline data showing how the total amount of resources\nconsumed evolves over time, depending on the selected profile type. This panel allows you to visualize this data in\norder to identify spikes in resource consumption (CPU, memory, etc.) and focus on them by zooming into the corresponding\ntime range.
\n![\"Series](\"https://perses.dev/assets/images/blog/v052/series-chart-panel.png\")
This release introduces two new plugins enabling log visualization and exploration in Perses:
\n![\"LogTable](\"https://perses.dev/assets/images/blog/v052/logtable-panel.jpg\")
These new plugins have been developed by the Perses community.\nA big thank you to @abelyakin !!
\nAs spoiled on the previous release note, the heatmap panel has been added on Perses!\nIt is now possible to visualize Prometheus native histograms in a heatmap format. This panel is particularly useful for\nvisualizing latency distributions over time.
\n![\"Heatmap](\"https://perses.dev/assets/images/blog/v052/heatmap-dark.png\")
\n![\"Heatmap](\"https://perses.dev/assets/images/blog/v052/heatmap-light.png\")
This panel still need to be improved, so stay tuned for future updates! Or even better, contribute to it! List of\nimprovements to be done can be found in the GitHub issue #2978
\nPanels introduces a new feature called Quick Query Viewer using which users can quickly check the executed queries\nwithout being in edit mode.\nThe feature has added a new, default icon button into the panel header. When clicked a modal is opened in which you can\nsee relevant query specs.
![\"Quick](\"https://perses.dev/assets/images/blog/v052/quick_query_viewer.png\")
Panel group now support variable repeat. This allows you to create a panel group and have it repeated for each value of\na variable.
\nYou can define the repeat variable in the panel group settings dialog.\nIt will be also applied to preview in panel group.\nWhen editing a panel inside a panel group with repeat, changes will be applied to all panels group repeated.
\n![\"Panel](\"https://perses.dev/assets/images/blog/v052/panel-group-job.png\")
\n![\"Panel](\"https://perses.dev/assets/images/blog/v052/markdown-panel-job.png\")
We are introducing user profiles in Perses!
\nFor the moment, the user profile page only contains the list of the permissions associated to the account used.\nBut it is the first step towards a more complete user profile page, which will include more functionalities in the\nfuture.
\n![\"User](\"https://perses.dev/assets/images/blog/v052/user-profile.png\")
When editing a dashboard, if you try to leave the page with unsaved changes, a prompt will appear to warn you about\npotential lost changes.\nThere are 2 different prompts depending on how you try to leave the page:
\n![\"Discard](\"https://perses.dev/assets/images/blog/v052/discard-changes-prompt.png\")
\n![\"Discard](\"https://perses.dev/assets/images/blog/v052/discard-browser-prompt.png\")
Explorer can now show more information about your resources, thanks to collapsable tab menu!
\n![\"Explorer](\"https://perses.dev/assets/images/blog/v052/explorer-not-collapsed.png\")
\n![\"Explorer](\"https://perses.dev/assets/images/blog/v052/explorer-collapsed.png\")
Few other improvements have been made to the explorer, such as:
\nThe Tempo plugin now allows you to search for traces by attributes directly in the query editor, without writing a\nTraceQL query manually.
\n![\"Attribute](\"https://perses.dev/assets/images/blog/v052/tempo-filter-bar.png\")
You can now view span links in a new Links tab when clicking on a span which has links configured. This makes it\neasier to explore related spans and understand trace relationships.
\n![\"Span](\"https://perses.dev/assets/images/blog/v052/tracingganttchart-span-links.png\")
The TracingGanttChart panel now includes a download action in the panel header. With one click, you can export the\nentire trace in OTLP/JSON format for offline analysis or sharing.
\nThe TracingGanttChart, TraceTable, and ScatterChart panels now support configuring links in the panel spec. You can\nconfigure the link to a specific trace (e.g. relevant for the trace table) or create dynamic links from resource and\nspan attributes (in the TracingGanttChart panel).
\npercli plugin test-schemaThis new command provides a way to test the Cuelang schema and the migration schema. Here how it works:
\nFirst, all tests files needs to be placed directly alongside the schema file to test, within a tests folder.\nThen you will have different way to test the schemas:
Tests validating the model:
\nTests verifying invalid possibility:
\nMigration Tests:
\nExample of file structure for a single plugin:
\nschemas/\n├── model.cue\n├── tests/\n│ ├── valid/\n│ │ ├── basic-config.json\n│ │ └── advanced-config.json\n│ └── invalid/\n│ ├── missing-required.json\n│ └── invalid-type.json\n└── migrate/\n├── migrate.cue\n└── tests/\n├── basic-migration/\n│ ├── input.json\n│ └── expected.json\n└── complex-migration/\n├── input.json\n└── expected.jsonMore complex example for a package embedding several plugins:
\nschemas/\n├── my-datasource/\n│ ├── model.cue\n│ ├── tests/\n│ │ ├── valid/\n│ │ │ ├── basic-config.json\n│ │ │ └── advanced-config.json\n│ │ └── invalid/\n│ │ ├── missing-required.json\n│ │ └── invalid-type.json\n│ └── migrate/\n│ ├── migrate.cue\n│ └── tests/\n│ ├── basic-migration/\n│ │ ├── input.json\n│ │ └── expected.json\n│ └── complex-migration/\n│ ├── input.json\n│ └── expected.json\n└── my-query/\n├── model.cue\n├── tests/\n│ ├── valid/\n│ └── invalid/\n└── migrate/\n├── migrate.cue\n└── tests/`,percli plugin startThis command has been improved to provide a better experience when starting a plugin locally.
\nNote: all improvement described below will only work with a remote server of version >= 0.52.0 as it also included new\nendpoints to make the features work.
\nWith this new version, the command is now able to detect any changes on the Cuelang schema.\nWhen a change is detected, the command will trigger the remote server to reload the schema internally.\nThis improvement is particularly useful during the development of a plugin, as it allows to see the changes of the\nschema immediately without having to manually restart the server and the plugin watching process.
\nWhen stopping the command, it will now unregister any plugin it was watching. This is useful to avoid having to\nrestart the remote server to get back the list of registered plugins clean. It also solve an issue about being able\nto override a plugin with the development version of the same plugin.
\nWe're thrilled to introduce the Perses MCP Server, now available in public beta. This new tool empowers you to interact with your Perses instances using natural language, opening up a world of possibilities for monitoring and visualization.
\nWith the Perses MCP Server, users can use AI Agents to understand, query and interact with Perses APIs in a standardized and secure manner.
\nImagine being able to prompt your favorite AI Agent with questions like:
\nAs you can see, the possibilities are endless. The Perses MCP Server allows you to interact with Perses in ways that were previously not possible.
\n\nThis diagram visually represents how the Perses MCP Server acts as an intermediary between your AI Agent and the Perses Application.
\nYou might be wondering what makes this all possible. The magic behind the scenes is the Model Context Protocol (MCP), an open standard pioneered by Anthropic that is quickly gaining industry-wide adoption.
\nMCP’s purpose is to create a universal language for AI agents to interact with the \"outside world\" that is, any data or system beyond their initial training data. This protocol enables AI to securely access real-time information and perform tasks by connecting to external APIs. In short, MCP provides a paved road for Large Language Models (LLMs) to interact with external systems like databases, APIs, and filesystems.
\nMajor players like Google, Microsoft, and OpenAI have already committed to supporting MCP.
\nUsing the Perses MCP Server is simple and straightforward.
\nCheck out this short demo to see it in action:
\n\nReady to dive in? Here are the resources you'll need:
\nThis public beta is just the beginning. Currently, the server supports read-only operations, allowing you to query the Perses API. Our roadmap includes adding write capabilities, which will enable you to use AI agents to create and update Perses resources like dashboards, projects, and datasources.
\nWe are committed to an open development process and we welcome your feedback and contributions as we build these new features.
", "date_published": "2025-06-18T00:00:00Z", "tags": [ "Community" ] }, { "id": "https://perses.dev/blog/2025/06/10/composable-dashboards----lessons-from-building-perses-community-dashboards/", "url": "https://perses.dev/blog/2025/06/10/composable-dashboards----lessons-from-building-perses-community-dashboards/", "title": "Composable Dashboards - Lessons from building Perses Community Dashboards", "summary": "Every CNCF User/Developer/Contributor has, at some point, to endure the frustration of trying to salvage an outdated dashboard, or adapting upstream YAML, only to get to the point of wondering why it…", "content_html": "\nEvery CNCF User/Developer/Contributor has, at some point, to endure the frustration of trying to salvage an outdated dashboard, or adapting upstream YAML, only to get to the point of wondering why it doesn't work on their setup. This leads to a recurring pattern: everyone ends up rebuilding the same dashboards, over and over again, each slightly different.
\nThe Mixins Dashboards helped bring about a sense of relief, as users now could use dashboards and alerts packaged together with the code they are deployed with. In theory, this promised consistency and easier integration. In practical terms, as the concept of mixins relies on Jsonnet, and even though it’s a suitable language for configuration management, it leads to a few issues:
\nJsonnet has a steep learning curve. It’s not a conventional Turing-complete programming language, and often makes it hard for downstream users of mixins to be able to do any sort of customization on their dashboards;
\nMixin Jsonnet is completely detached from the actual application code. It was introduced as a way to maintain dashboarding config for code that you are deploying side by side, to ensure it never goes out of sync. However, many mixins are rarely updated, even when the code is - sometimes these are maintained out of the tree. And Jsonnet cannot use Go structs, so there is no automatic validation during code changes. Thus keeping mixins accurate and reliable demands a lot of effort.;
\nAdoption has also been uneven. A good example of this is kube-prometheus stack, built with Jsonnet, where many users bypass it entirely and only fetch the rendered YAML from that repository, then doing any sort of changes with tools like Kustomize instead. This undermines the original goal of reuse and standardization.
\nThe end result is, that despite the promise of reusable dashboards, the reality is there’s still not a widely used solution for automatic dashboards creation.
\n\nDuring KubeCon EU 2025 in London, two of Perses’ core maintainers, Nicolas Takashi and Antoine Thébaud, shared how Perses is changing the way engineers develop and manage dashboards as code. Their talk covered the power of the Open Dashboard Model, how to use strongly typed code with the Perses Go SDK, and why this approach fits naturally into CI/CD pipelines using modern GitOps practices. If you didn’t get a chance to watch it live, you can watch the full session here.
\nThey also mentioned the Community Dashboards Project, but didn’t have time to dive into it during the session. With that in mind is our belief that such an important topic deserves more space, and as so we bring this into live here.
\nWith the limitations of mixins in mind, the Perses community decided to take a different path. Since Perses is written in Go, with both its configuration and plugins defined using Go structs, it presents an opportunity to design dashboards in a more efficient and structured way. This approach takes full advantage of the Go structs imported from Perses, with its robust SDK that has the methods and constructs to build dashboards. This then ensures consistency with the core project, safe versioning, both for the dashboard data model and each individual panel plugins, and type-safe dashboard construction and customization.
\nIntroducing the community-dashboards repository. Maintained by community contributors, it offers the following dashboards in type-safe modular Go SDK based Dashboards as Code:
\n![\"Dashboard](\"https://perses.dev/assets/images/blog/community-dashboards/perses-dashboards-overview.png\")
The goal of the community-dashboards library isn't just to provide ready-to-use YAML dashboards (though you can use them as-is), but to empower users to import the project as a Go module in their downstream configuration, generate tailored subsets of dashboards, and customize or extend them to meet specific needs (similar to what mixins originally intended).
\nA core strength of the Perses Community Dashboards is its modular, reusable panel library. These panels—such as Go CPU Usage and Memory Consumption—serve as building blocks that can be composed into new dashboards. Instead of starting from scratch, users can leverage these community-maintained components to quickly build dashboards suited to their applications and workloads.
\nThis approach also lowers the barrier to achieving consistency across dashboards. By reusing the same patterns to build and display common metrics, dashboards remain aligned across teams and services. This makes it easier to compare environments, onboard new engineers, and scale observability practices—without reinventing the wheel.
\n![\"AM](\"https://perses.dev/assets/images/blog/community-dashboards/perses-dashboards-am.png\")
Here we have an example of how to define a panel of Time Series type below. More detailed info about the available option for Time Series Panels can be found here and PromQLBuilder.
\n// Define your panel\nfunc CPUUsage(datasourceName string, labelMatchers ...*labels.Matcher) panelgroup.Option {\n\treturn panelgroup.AddPanel(\"CPU Usage\",\n\t\tpanel.Description(\"Shows the CPU usage of the component.\"),\n\t\ttimeSeriesPanel.Chart(\n\t\t\ttimeSeriesPanel.WithYAxis(timeSeriesPanel.YAxis{\n\t\t\t\tFormat: &commonSdk.Format{\n\t\t\t\t\tUnit: string(commonSdk.DecimalUnit),\n\t\t\t\t},\n\t\t\t}),\n\t\t\ttimeSeriesPanel.WithLegend(timeSeriesPanel.Legend{\n\t\t\t\tPosition: timeSeriesPanel.BottomPosition,\n\t\t\t\tMode: timeSeriesPanel.TableMode,\n\t\t\t\tValues: []commonSdk.Calculation{commonSdk.LastCalculation},\n\t\t\t}),\n\t\t\ttimeSeriesPanel.WithVisual(timeSeriesPanel.Visual{\n\t\t\t\tDisplay: timeSeriesPanel.LineDisplay,\n\t\t\t\tConnectNulls: false,\n\t\t\t\tLineWidth: 0.25,\n\t\t\t\tAreaOpacity: 0.5,\n\t\t\t\tPalette: timeSeriesPanel.Palette{Mode: timeSeriesPanel.AutoMode},\n\t\t\t}),\n\t\t),\n\t\tpanel.AddQuery(\n\t\t\tquery.PromQL(\n\t\t\t\tpromql.SetLabelMatchersV2(\n\t\t\t\t\tpromqlbuilder.Rate(\n\t\t\t\t\t\tmatrix.New(\n\t\t\t\t\t\t\tvector.New(\n\t\t\t\t\t\t\t\tvector.WithMetricName(\"process_cpu_seconds_total\"),\n\t\t\t\t\t\t\t),\n\t\t\t\t\t\t\tmatrix.WithRangeAsVariable(\"$__rate_interval\"),\n\t\t\t\t\t\t),\n\t\t\t\t\t),\n\t\t\t\t\tlabelMatchers,\n\t\t\t\t).Pretty(0),\n\t\t\t\tdashboards.AddQueryDataSource(datasourceName),\n\t\t\t\tquery.SeriesNameFormat(\"{{pod}}\"),\n\t\t\t),\n\t\t),\n\t)\n}Next after you have your first panel, it’s time to add it to a dashboard - here’s how to add to a dashboard named Workload / Overview:
// Use the panel in a dashboard\nfunc withResources(datasource string, clusterLabelMatcher *labels.Matcher) dashboard.Option {\n\tlabelMatchersToUse := []*labels.Matcher{\n\t\tpromql.JobVarV2,\n\t}\n\tlabelMatchersToUse = append(labelMatchersToUse, clusterLabelMatcher)\n\n\treturn dashboard.AddPanelGroup(\"CPU Usage\",\n\t\tpanelgroup.PanelsPerLine(1),\n\t\tpanelgroup.PanelHeight(10),\n\t\tpanelsGostats.CPUUsage(datasource, labelMatchersToUse...),\n\t)\n}\n\n// Build the dashboard and add the time series panel withResources\nfunc BuildWorkloadOverview(project string, datasource string, clusterLabelName string) dashboards.DashboardResult {\n\tclusterLabelMatcher := dashboards.GetClusterLabelMatcherV2(clusterLabelName)\n\treturn dashboards.NewDashboardResult(\n\t\tdashboard.New(\"workload-overview\",\n\t\t\tdashboard.ProjectName(project),\n\t\t\tdashboard.Name(\"Workload / Overview\"),\n\t\t\tdashboard.AddVariable(\"job\",\n\t\t\t\tlistvariable.List(\n\t\t\t\t\tlabelvalues.PrometheusLabelValues(\"job\",\n\t\t\t\t\t\tlabelvalues.Matchers(\"workload_build_info{}\"),\n\t\t\t\t\t\tdashboards.AddVariableDatasource(datasource),\n\t\t\t\t\t),\n\t\t\t\t\tlistvariable.DisplayName(\"job\"),\n\t\t\t\t),\n\t\t\t),\n\t\t\twithResources(datasource, clusterLabelMatcher),\n\t\t),\n\t).Component(\"workload\")\n}For more on the SDK please check perses/go-sdk, and community-dashboards.
\nGoing back to the idea of copy-pasting raw YAML or JSON, although it might seem quicker, it leads to painful maintenance over time. The Go SDK offers a better path:
\nCombining the use of panel libraries and the SDK, you get a flexible and scalable way to manage dashboards, while saving time, reducing errors, and staying consistent across your observability stack. This allows a community of dashboards users to have their lives made easier with these features.
\nAlso considering the most commonly used dashboard across platforms and teams, like Kubernetes, Prometheus and exporters like Node Exporter, Blackbox Exporter, also projects like Thanos dashboards as it tends to be a power duo within the Prometheus ecosystem, we have from the get go some core dashboards that will help you in the long term in your observability journey.
\nWe’re committed to expanding support for more CNCF and other OSS projects while continuing to enhance the existing panel libraries. By adding more features and improving the quality of reusable panels, we enable users to gain deeper insights from their dashboards because the faster you can pinpoint an issue in your telemetry data, the better.
\nAlso, we aim to ensure proper documentation for all dashboards. Whether you're importing full dashboards or using panel libraries as building blocks, we want to make the process as seamless as possible. That means clear, well-commented code and guidance, so modularity is not only guaranteed but also easy to work with, without needing to dig through the entire codebase.
\nUltimately, this is a community effort, and we invite everyone to help grow this project. So if you have a dashboard you’ve rewritten more than once, or any mixin dashboard you use, but want to ensure it becomes modular, easily used and want to increase adoption of it. Whether it’s opening an issue or submitting a contribution, all help is moving forward so we can all, very soon, stop rebuilding the same dashboards.
\nLet’s stop duplicating efforts and start building shared observability standards!
", "date_published": "2025-06-10T00:00:00Z", "tags": [ "Community" ] }, { "id": "https://perses.dev/blog/2025/06/06/release-v0510/", "url": "https://perses.dev/blog/2025/06/06/release-v0510/", "title": "Release v0.51.0", "summary": "We are excited to announce the release of Perses v0.51.0!", "content_html": "\nWe are excited to announce the release of Perses v0.51.0!
\nThis release brings several new features, improvements, and bug fixes to enhance your experience with Perses.
\nIt is a significant step forward in the evolution of Perses, and we are thrilled to share it with you. We have\nbeen working hard to bring you a more powerful and flexible platform for your observability needs.
\nThis release includes a new plugin architecture, new panel, new variable, a new\nrepository perses/plugins\ncontaining all default plugins supported by Perses.
\nWe have also made significant improvements to the documentation, highlighting features that were implemented some time\nago but not well advertised, such as datasource discovery and ephemeral dashboards.
\n\nBig news from us at Perses! We've rolled out a brand-new plugin system, and it's all about making things more flexible\nand expandable.\nOur goal? To provide a more flexible and extensible way to scaffold, develop and distribute plugins in Perses so we can\nexpand the possibilities for sources of data, visualization and interactions within the platform.
\nLeveraging module federation plugins can now operate\nindependently of the main Perses code.\nOpening up a world of possibilities for developers to create and share plugins without being tied down to the core\ncodebase.\nPlugins can be grouped into Plugin Modules, which are essentially collections of related plugins that can be\ndeveloped and distributed together.\nUnderneath it all, the system has a backend that handles data validation and migrations using Cuelang schemas, and a\nfrontend that brings everything to life with React components.
\nTo make life easier for developers, we've built some handy plugin commands right into our command-line interface,\npercli.\nThe CLI will do all the heavy lifting from setting up your project, getting your development environment ready, to\nbuilding your plugins.\nThat way, you can kick back and focus on the exciting part: actually creating awesome plugin features!
The new plugin system is designed to be super user-friendly.\nYou can scaffold a plugin using the percli plugin generate command, which will set up the new plugin files for you.\nThis command can be used several times to create multiple plugins in the same plugin module.\nThen you can start developing your plugin using percli plugin start to run it in development mode and test it out in\nyour local Perses instance. Finally, compile it with percli plugin build to prepare it for distribution.
You can follow the documentation for details and examples to get\nstarted with creating your own plugins.
\nThanks to this new setup, our main Perses plugins have moved to their own dedicated home\nat perses/plugins. And speaking of plugins, the system supports a bunch of\ndifferent types:
\nYou just use percli to get started, test your creations, and then build them up to distribute as archive files or npm\npackages.\nAfter that, they're ready to be installed on a Perses server or even embedded directly into other React apps.
So, what kind of plugin are you dreaming of building first?
\nAll plugins that are available in the repository perses/plugins are installed by\ndefault in Perses.
\nYou can find the list of available plugins at runtime in the UI, in the Configuration page, under the Plugins\ntab.
\n![\"PluginsList\"](\"https://perses.dev/assets/images/blog/v051/plugins-list.png\")
You can also use the CLI command percli plugin list to get the list of available plugins.
percli plugin list\n\n NAME │ VERSION │ TYPE │ LOADED │ FROM DEV\n────────────────────┼─────────────┼──────────────┼────────┼──────────\n DatasourceVariable │ 0.1.2 │ Variable │ true │ false\n GaugeChart │ 0.7.1 │ Panel │ true │ false\n Markdown │ 0.7.1 │ Panel │ true │ false\n Prometheus │ 0.51.0-rc.1 │ PluginModule │ true │ false\n ScatterChart │ 0.6.1 │ Panel │ true │ false\n StaticListVariable │ 0.3.1 │ Variable │ true │ false\n Table │ 0.6.1 │ Panel │ true │ false\n HistogramChart │ 0.7.2 │ Panel │ true │ false\n PieChart │ 0.7.1 │ Panel │ true │ false\n TimeSeriesChart │ 0.8.0 │ Panel │ true │ false\n TimeSeriesTable │ 0.7.1 │ Panel │ true │ false\n TraceTable │ 0.6.1 │ Panel │ true │ false\n BarChart │ 0.7.1 │ Panel │ true │ false\n TracingGanttChart │ 0.6.1 │ Panel │ true │ false\n StatChart │ 0.7.1 │ Panel │ true │ false\n StatusHistoryChart │ 0.7.2 │ Panel │ true │ false\n Tempo │ 0.51.0-rc.1 │ PluginModule │ true │ falseThanks to the community contributions, we are introducing a new plugin: the Datasource Variable.\nThis plugin allows the possibility to use a datasource as a variable in your dashboard, specially in the queries of your\npanels.
\nThis is particularly useful when you have multiple datasources of the same type, such as multiple Prometheus instances,\nand you would like to switch between them without having to modify each panel query.\n![\"DatasourceVariable\"](\"https://perses.dev/assets/images/blog/v051/datasourceVariable.gif\")
Of course, this plugin is not limited to Prometheus; it can be used with any datasource.
\nNote: If you are familiar with Grafana this feature wont will feel particularly new to you.\nIt's a valuable addition to Perses, helping to bring feature parity and making it a strong alternative for those\nconsidering or exploring a\ntransition.
\nThis release introduces a new plugin: the Histogram Chart. This plugin allows you to visualize Prometheus Native\nHistograms, providing a clear and concise way to understand the distribution of your histogram buckets.
\n![\"Histogram](\"https://perses.dev/assets/images/blog/v051/histogram-panel.png\")
This panel is supporting thresholds, which allow you to colorize the chart based on specific values, making it easier to\nunderstand your data.
\n![\"Histogram](\"https://perses.dev/assets/images/blog/v051/histogram-thresholds.png\")
This chart is also used in TimeSeriesTable panel to display histogram details, allowing the Explore page to display\nhistograms.
\n![\"Explore](\"https://perses.dev/assets/images/blog/v051/histogram-explore.png\")
In next releases, we are planning to add exponential mode support, add support for Prometheus classic histograms and\nsummaries and thresholds on bucket counts.\nFeel free to give us ideas on how to improve this plugin, with issues or discussions on\nthe Perses GitHub repository.\nSpoiler: the heatmap panel is coming next release 🤫
\nAs previously mentioned, we have relocated the default plugins to a new repository. This includes not only the frontend\ncode, which has been transferred there, but also the corresponding Go SDK and CUE SDK for each plugin.
\nThis move is a breaking change for the Dashboard as Code feature as when upgraded to the last version, you will no\nlonger have the plugin code from perses/perses repository.
\nAll imports will have to be updated to point to the new repository. We created a module for each plugin so you can\nimport only the ones you need.
\nFor example, in Go SDK, in case you are using the plugin label-values from the Prometheus module, you will need to\ngo get the plugin first:
go get github.com/perses/plugins/prometheusThen, in your Go code, you will have to change the import path from:
\nimport labelValuesVar \"github.com/perses/perses/go-sdk/prometheus/variable/label-values\"to:
\nimport labelValuesVar \"github.com/perses/plugins/prometheus/sdk/go/variable/label-values\"As a complete example, this PR: https://github.com/perses/community-dashboards/pull/69 is demonstrating the required\nchanges you will have to do in your code when upgrading to the v0.51.0 of Perses.
\nIn the case of CUE SDK, we are also leveraging on the new dependency management introduced by CUE v0.12.0.\nWhere we previously had a custom-made schema retrieval achieved by percli dac setup, Perses is now fully aligned with\nthe new CUE modules.
To continue using the CUE SDK, you will need to update your CUE files to import the new modules, but also to upgrade\nthe\ncue version you are using to at least v0.12.0.
\nAs you may know, to validate your dashboard, we have implemented a set of rules.\nThese rules are executed when you save your dashboard during the unmarshalling step from JSON or YAML or during the\nvalidation of each plugin using Cuelang.
\nIn this release, we have added the ability to create custom lint rules. This allows you to enforce specific standards or\npractices within your organization.
\nThese custom rules should be defined in the configuration file of your Perses instance, typically located at\n/etc/perses/config.yaml. The rules are defined under the dashboard.custom_lint_rules section.
Here is an example of how to define custom lint rules for dashboards:
\ndashboard:\n custom_lint_rules:\n - name: \"Dashboard Naming Convention\"\n target: \"$.metadata.name\"\n assertion: \"value.matches('^[a-z]+(-[a-z]+)*$')\"\n message: \"Dashboard name must be all lowercase letters with hyphens only.\"\n disable: false\n\n - name: \"At Least One Panel Exists\"\n target: \"$.spec.panels\"\n assertion: \"value.size() > 0\"\n message: \"Dashboard must contain at least one panel.\"\n disable: falseWe are using the JSONPath syntax to target specific parts of the dashboard\nJSON structure, and the assertion is a CEL expression.
\nTo know more about the syntax of the rules, please refer to\nthe documentation
\nIn Perses, it is possible to create datasource and variables at three different levels: global, project, and dashboard.
\nUsually, for security and governance reasons, you may want to prevent people to create datasource and variables at\nvarious levels. For global and project levels, this is already possible using the RBAC system.
\nBut before this release, it was not possible to disable the creation of datasource and variables at the dashboard level.
\nIn this release, we are introducing the ability to disable the manipulation of datasources and variables at any level.\nFor that, you need to modify the configuration file of your Perses instance, and add the following section:
\ndatasource:\n global:\n disable: true\n project:\n disable: true\n disable_local: trueThis configuration is preventing the usage of datasources at any level and disable the associated HTTP route in the\nPerses proxy.
\nOf course, this config is silly because without datasources, you cannot use dashboards, but it is a good example of how\nto disable datasources.
\nThe same example applies for variables:
\nvariable:\n global:\n disable: true\n project:\n disable: true\n disable_local: trueOne year ago, we introduced the datasource discovery feature, which allows you to automatically discover remote\ndatasources from the Kubernetes API or from a generic HTTP endpoint.\nAnd so far we never got feedback about it until a couple of months ago when SAP started using\nit.
\nWe didn't have the opportunity to highlight this feature, so here is a quick overview of how it works.
\nDatasource discovery is useful when you have a large number of datasources, and you don't want to manually register\nthem in your application. Note that this feature can only be used when registering Global Datasources.
\nWe are supporting two types of discovery:
\nIf you want to learn more about this feature, please refer to\nthe documentation.
\nThanks to these little improvements, the datasource discovery feature is now more reliable and easier to use.
\nFresh off our talk at KubeCon EU 2025 in\nLondon - Limitless Possibilities, Consistent Design: Crafting Dashboards With Perses DAC,\ngiven by two perses maintainers, Nicolas Takashi and Antoine Thébaud, we are happy to introduce\nthe community-dashboards repository.
\nHere we provide support for commonly used Mixin Dashboards, like Prometheus, Kubernetes and Thanos, build on top of\nDashboard as Code capabilities provided by Perses. We’ll dive deeper into the community-dashboards in our upcoming\nblog post, but starting today, you can begin using them right away — whether by:
\nImporting them directly into your Perses instance;
\nUsing them as a starting point to build your own dashboards;
\nOr reusing individual panels in your own dashboards-as-code workflows.
\nWe're also welcoming the community to help us support and extent the community-dashboards. So if there are additional\ndashboards you’d like to see supported, feel free to reach out to the team - or even better, help us extend the\nsupported dashboards with feedback or improvements to the dashboards. Your input helps shape what comes next!
\nAnother cool contribution from the community is the support for OAuth2 authentication for datasources.
\nBefore this release, the only way to authenticate to a datasource was to use a token, basic authentication and/or TLS\nconfiguration (like client certificate).
\nBut in real world scenarios, you may want to use OAuth2 authentication to access your datasources and this is now\npossible!
\n![\"Datasource](\"https://perses.dev/assets/images/blog/v051/datasource-oauth2.png\")
![\"Dashboard](\"https://perses.dev/assets/images/blog/v051/dashboard-yaml.png\")
\nFinally, but not least, we are introducing the support for YAML and YAML K8s Custom Resource format when exporting a\ndashboard from the UI.
\nThe YAML CR format is directly compatible with the perses-operator and can be used in your GitOps workflow.
In future releases, we will also support the YAML format for all other resources, so you can export a panel or variable\nin a YAML format.
", "date_published": "2025-06-06T00:00:00Z", "tags": [ "Release notes" ] }, { "id": "https://perses.dev/blog/2025/01/15/release-v0500/", "url": "https://perses.dev/blog/2025/01/15/release-v0500/", "title": "Release v0.50.0", "summary": "We are excited to announce the release of Perses v0.50.0! This release brings significant improvements to the migration process from Grafana to Perses, including a major fix for a memory leak issue.…", "content_html": "\nWe are excited to announce the release of Perses v0.50.0! This release brings significant improvements to the migration\nprocess from Grafana to Perses, including a major fix for a memory leak issue. Additionally, it introduces a new Status\nHistory Panel and various enhancements to the Table Panel, UI, and CLI. Read on to learn more about the new features and\nimprovements in this release.
\nSee the complete release note for more details: v0.50.0
\n\nOne of the greatest contents of this release is the migration that has been drastically improved.
\nSince the beginning of the project, we have been willing to provide an easy way to migrate dashboards from Grafana to\nPerses. As a reminder, you can migrate a Grafana dashboard using the HTTP endpoint /api/migrate or the UI or the CLI\nthat consumes this endpoint.
The big issue with this feature was the memory leak that was hidden and not that easy to trigger.\n(See issue #2039)
\nThis was a big blocker for the migration and one of the main reasons why Amadeus was not able to migrate to Perses.\nAmadeus has a huge number of dashboards, and the memory leak was too important to be ignored.\nTo give you an idea, the memory leak was about 40GB after migrating 3000 dashboards. (~ 3MB per dashboard)
\n![\"Memory](\"https://perses.dev/assets/images/blog/v050/migration-memory-leak.png\")
As you may know, we are using Cuelang for the Perses plugin validation, and at first, we implemented a complete way to\nmigrate using Cuelang only.\nThe idea behind was to append every migration script (one for each panel, variable, queries) to the main one.\nThen the Grafana JSON was converted to a Cuelang value, and we were applying the migration script to this value.
\nWith the v0.50.0, we are changing deeply and only internally the way it's working. It doesn't change anything for the\nuser, but it's a huge improvement for the maintainability and the performance of the migration.
\nWe have entirely rewritten the migration process. It is now using a hybrid system partially written in Golang and the\nrest in Cuelang when the plugins are involved. Thanks to this new system, the Cuelang files written to migrate the\npanels, the variables, and the queries can be validated and tested before the migration is applied.
\nThanks to this change, we are happy to announce the memory leak has been fixed and the migration is now working\nperfectly. We performed the same mass migration, and it succeeded without causing OOMKill, as it requires much less\nmemory than before. The graph below shows we didn't exceed 3GB of memory during the migration.
\n![\"no](\"https://perses.dev/assets/images/blog/v050/migration-without-memory-leak.png\")
Finally, we’ve also addressed numerous updates to the migration process itself, incorporating fixes and enhancements to\nbetter cover use cases raised by the community - thank you for your contributions!
\nThanks to Alexander Belyakin from the community, Perses is supporting a new Panel: the\nStatus History Panel.
\nThe Status History panel provides a visual representation of the status of various metrics over time.\nIt allows users to track changes in the status of different metrics, making it easier to identify patterns, trends, and\nanomalies.\nThis panel is particularly useful for monitoring the health and performance of systems, as it can display status changes\nin a clear and concise manner.\nThe panel can be customized to show different statuses, such as up, down, warning, or any other user-defined states, and\nit supports various visualization options to enhance the readability of the data.
\nAnd of course, this panel is fully compatible with the migration process.
\n![\"Status](\"https://perses.dev/assets/images/blog/v050/status-history-panel.png\")
We have finally added the redirection to the initial URL after you are authenticated. This was definitely a missing\nfeature annoying for the users.
\nThis release also introduces various improvements to the Table Panel, such as debounced text fields in the editor,\ndefault column sorting, custom column ordering, default column width setting, and cell focus on hover.
\n![\"Table](\"https://perses.dev/assets/images/blog/v050/reorder-columns.gif\")
First, we have fixed the login command not working if you were using the CLI to log in to different Perses servers.
\nThen, based on the community feedback, we also have improved the DAC (Dashboard as Code) sub-command.\nWe hope the experience with our DAC framework will be better.
\nWe are also introducing new commands for plugin development.\nThat's something that comes along with the new plugin architecture we are working on since last year.\nThese commands cannot be used currently as we are still working on the plugin architecture.
\nBut stay tuned as we are really close to finishing this intense work! V0.51.0 is going to be incredible with a lot\nof changes!
", "date_published": "2025-01-15T00:00:00Z", "tags": [ "Release notes" ] } ] }