* remove support for bus from scheduler
* rename event to FolderTitleUpdated and fire only if title has changed
* add method to increase version of all rules that belong to a folder
* update ngalert service to subscribe to folder title change event call data store and update scheduler
* add tests
* Replace subquery with threshold calculation
* Use offset/limit to account for orgs with large gaps in IDs
* Collapse into one statement
* Drop dead constants
* Revert to 2 query approach
* Drop unused consts again
* public dashboards: check to see if dashboard state is different from persisted on save
Co-authored-by: Ezequiel Victorero <ezequiel.victorero@grafana.com>
* prevent recursion blowup in redux, attempt to reintroduce import e2e test
* try importing json like this instead?
* need the panel validation
* Update text so it finds Panel data instead of Dataframe JSON
* skip test for now
* Add new pill-shaped Indicator component
* Use indicator for clipboard button success
* show just check icon during success state
* expose Indicator
* move animation and positioning into Indicator component
* update stories
* update stories
* Annotations: replaced dashboardId with dashboardUID when fetching annotations
* Annotations: Replaced dashboardID with dashboardUID when adding and updating annotations
* Annotations: Used dashboardUID for PanelChrome related methods
* Annotations: Used dashboarduid in annolistpanel
* Annotations: Used dashboardUID in graph plugin
* used boolean in canEditDashboard
* consolidate project, metric, and service
* CloudMonitor: make AlignmentPeriodLabel a tooltip
alignmentPeriodLabel now returns a string instead of component. This is
because as a <label> it would cause wrapping issues when the screen size
would change. It also isn't essential information _unless_ the user is
using a template variable for the Alignment period.
* refactor: remove any hard-coded widths for auto
* chore: use newly moved experimental comps in UI
* Previews: datasource permissions
* lint
* simplify - force non-null `ds_uids`
* add `canBeDisabled` to search service
* add `IncludeThumbnailsWithEmptyDsUids`
* remove force refresh migration
* refactor main preview service
* add safeguard
* revert ticker interval
* update testdata
* fix test
* add mock search service
* add datasources lookup test
* update migration
* extract ds lookup to its own package to avoid cyclic imports
* lint
* fix dashbaord extract, use the real datasource lookup in tests. IS IT BULLETPROOF YET?!
* fix dashbaord extract, use the real datasource lookup in tests. IS IT BULLETPROOF YET?!
* remove stale log
* consistent casing
* pass context to `createServiceAccount`
* filter out the special grafana ds
* RBAC: Update the docs homepage to mention that RBAC is only enterprise
* Don't mention that there is anything to enable for provisioning RBAC
* Add GE notices to child RBAC pages
* Extend the RBAC availibility note to Cloud Advanced
Co-authored-by: Garrett Guillotte <garrett.guillotte@grafana.com>
* Toggle on the mixed mode option
* Ensure switching to mixed gives existing query prev datasource
* WIP - Populate datasource when switching between mixed and not
* WIP - handle change from mixed
* Remove preimport filter, refine filter to work for queries
* WIP debugging datasource transition
* Ensure creating a new query gets target data source if switching with no matches between
* Add mixed datasource to rich history display
* Cleanup console logs, add relevant comments
* Add feature toggle for mixed datasource
* Fix Wrapper tests
* Fix tests!
* Fix test types and add feature tracking
* Remove unnecessary default, remove explore/mixed workarounds for D2E
* Move display text logic to mixed datasource file
* Add in the default query parameters to a generated empty query
* Condense some code
* Apply suggestions from code review
Co-authored-by: Giordano Ricci <me@giordanoricci.com>
Co-authored-by: Giordano Ricci <me@giordanoricci.com>
* Auth: check of auth_token in url and resolve user if present
* check if auth_token is passed in url
* Auth: Pass auth_token for request if present in path
* no need to decode token in index
* temp
* use loadURLToken and set authorization header
* cache token in memory and strip it from url
* Use loadURLToken
* Keep token in url
* strip sensitive query strings from url used by context logger
* adapt login by url to jwt token
* add jwt iframe devenv
* add jwt iframe devenv instructions
* add access note
* add test for cleaning request
* ensure jwt token is not carried into handlers
* do not reshuffle queries, might be important
* add correct db dump location
* prefer set token instead of cached token
Co-authored-by: Ieva <ieva.vasiljeva@grafana.com>
Co-authored-by: Karl Persson <kalle.persson@grafana.com>
Co-authored-by: Ieva <ieva.vasiljeva@grafana.com>
* add Examplars: false in collapsed view
* assign defaut value - false to switch
* add 3 tests for 3 possible cases
Co-authored-by: Taewoo Kim <taewookim@Taewoos-MacBook-Pro.local>
* add validation for plugin manifest
* no more semver checking
* undo go.mod changes
* undo go.mod changes
* only validate v2 fields where necessary
* remove manifest version field check
* Fix comment lines
* Introduce graphite variable editor
* Render results differently based on queryType
* Add comments and fallback values
* Unit tests for different type of graphite queries
* Use metrics/expand endpoint to retrieve metric names
* update GetAlertRulesForSchedulingQuery to have result AlertRule
* update fetcher utils and registry to support AlertRule
* alertRuleInfo to use alert rule instead of version
* update updateCh hanlder of ruleRoutine to just clean up the state. The updated rule will be provided at the next evaluation
* update evalCh handler of ruleRoutine to use rule from the message and clear state as well as update extra labels
* remove unused function in ruleRoutine
* remove unused model SchedulableAlertRule
* store rule version in ruleRoutine instead of rule
* do not call the sender if nothing to send
* Progress
* Example usage in application
* Add FocusScope
* REmove unused type
* simplify it by removing trigger property
* Use new Menu.Item way to access component
* refactor: convert .elapsed-time
* refactor: elapsedTime styling not required
* refactor: logs-rows styling not defined, remove classname
* refactor: logs-meta-item__labels styling not defined, remove classname
* refactor: transfer .label-slider styling to its own element
* refactor: clean up .slider styling
* refactor: muted styling not defined, remove classname
* refactor: transfer .space-between styling to its own element + clean up
* refactor: remove icon
* First pass at using datasource UID when appropriate
* Fix tests
* be more lenient with lookup to accomodate different URLs
* Make test setup get mock work like real datasource get
* Fix the typing issue and remaining tests
* Fix PR feedback
* add special handling on the plugin gathering side to check whether secrets manager plugins are enabled or not
* show disabled badge in front end if the plugin is not enabled
* Only show error in disabled badge hover if one is present (otherwise it shows "undefined")
* refactor to make use of fields already available in the DTO
* fix typo
* if there is no error returned for the plugin, just show 'disabled'
* fix typo
* Update public/app/features/plugins/admin/components/Badges/PluginDisabledBadge.tsx
Co-authored-by: Levente Balogh <balogh.levente.hu@gmail.com>
* Update frontendsettings.go
add clarifying comment
* fix unit test
* rework task to use new frontend property combined with plugin type to determine if the plugin should be disabled
* Update helpers.test.ts
revert test change
* fix unit test
* show custom uninstall message if the plugin is a secrets manager
* bogus commit to trigger precommit
* undo commit
* run precommit manually
* add some consts
* refactor a bit to pull plugin error management up a level
* re-add code squashed in merge
* fix compile issues
* add code to set plugin error fatal flag after secret migration
* refactor to move plugin startup out of Should Check func
* re-add important check
* make plugin startup errors fatal the first time we set a secret on the plugin
* rename func to make intent clearler
* remove unnecessary duplicate code from plugin mig
* fix compile error
* fix more compile errors
* add some extra logging to secrets migration
* have remote_plugin secret service managed plugin error fatal flag directly
* add blank file for eventual unit tests
* fix linting issues
* changes from PR review
* quick bit of cleanup
* add comment explaining design decision
* move more common test helpers to file
* slightly update to first time Get secret call
* add unit tests
* remove override func from provider
* fix linting issues
* add test cleanup step
* add some comments about refactoring to hacky test function
Co-authored-by: Levente Balogh <balogh.levente.hu@gmail.com>
* Add support for IP line filter
* Add support for IP label filter
* Updates for Explain mode
* Update test
* Remove invalid options in LabelFilterIpMatches
* feat: show data-sources under the data-connections page
* refactor: add a constant for data-sources routes
* refactor: add a context that holds the currently active data-sources routes
* refactor: use the data-sources routes constant wherever possible
* refactor: use the data-sources routes context wherever possible
* feat(data-connections): add edit and new pages
* feat(data-connections): set the the custom routes via the context provider
* fix(data-connections): set the active tab properly
We needed to update the routes to match with the ones on the backend ("data-sources" vs "datasources"),
and we also needed to check if it is the default tab, in which case we would like to highlight the Datasources tab.
* tests: fix tests for Data Connections page
* fix: address rebase issues
* tests: find button based on role and text
Co-authored-by: Jack Westbrook <jack.westbrook@gmail.com>
* fix: add missing closing ) paren in tests
* refactor: use implicit return types for components
* tests: change role from "button" to "link"
* refactor: stop using unnecessary wrapper components
Co-authored-by: Jack Westbrook <jack.westbrook@gmail.com>
* Loki: Add hint for level-like label
* Add test to addToQuery
* Add tests
* Update tests
* Update copy
* Get log position in metrics query and add test
* Update
* Update dependency moment to v2.29.4 [SECURITY]
* chore(moment): make sure nested moment deps resolve to moment@2.29.4
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jack Westbrook <jack.westbrook@gmail.com>
* Service account: Ensure that you can revert only service accounts which you can access
* Remove prettier messup with docs
* Remove prettier messup with docs
* Prettier run
* rename file
* add promstats for authinfostore every 4h
* add mixed cased users
* cherry pick and cleanup
* fix: query login,email instead of count()
* FIX: mysql missing alias to subquery
* fix: query working on mysql, sqllite3, and pg
* Service accounts: Add a confirm modal for migration actions
* Handle the error case when migrating fails, reload page afterwards so that the tab disappears
The query inspector was experiencing some error pop-ups due
to errors encountered on metrics datasources configured with multiple
tenants.
e.g., team-a|team-b
This fix suppresses those errors so as to not mislead the user.
* Allow the webhook notifier to support a custom Authorization header
Instead of doing something clever of re-using the existing username/password fields of Basic Authentication - I opted for two diffent fields to match the upstream Alertmanager configuration (that in turn is based of the HTTP Basic authentication).
It'll fail if you have values for both HTTP Basic Authentication and Authorization.
* Alerting: use static channel configuration to determinate secure fields
* move to channels package
* introduce channel_config package to fix cyclic import
* add missing changes
* compare type to type
* adjusts heading and makes intro active voice
* Update docs/sources/administration/service-accounts/_index.md
Co-authored-by: Ursula Kallio <ursula.kallio@grafana.com>
Co-authored-by: Ursula Kallio <ursula.kallio@grafana.com>
* First stab at new page layouts behind feature toggle
* Simplifying PageHeader
* Progress on a new model that can more easily support new and old page layouts
* Progress
* rename folder
* Progress
* Minor change
* fixes
* Fixing tests
* Make breadcrumbs work
* Add tests for old Page component
* Adding tests for new Page component and behavior
* fixing page header test
* Fixed test
* Moving user profile routes to navId
* PageLayouts: Updates dashboards routes with navId
* added missing navId
* AppChrome outside route
* Renaming folder
* Minor fix
* Updated
* Fixing StoragePage
* Updated
* Updating translation ids
* Updated snapshot
* update nav translation ids (yes this is confusing)
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
Co-authored-by: joshhunt <josh@trtr.co>
* OAuth: Add extract role support to github
OAuth: correct github errors
Oauth: add github tests
Oauth: Allow mapping via group memberships
Oauth: Add markdown instructions to the new mappers
fix lint
* Apply suggestions from code review
Co-authored-by: Gabriel MABILLE <gamab@users.noreply.github.com>
Co-authored-by: Vardan Torosyan <vardants@gmail.com>
* Apply suggestions from code review
Co-authored-by: Gabriel MABILLE <gamab@users.noreply.github.com>
Co-authored-by: Vardan Torosyan <vardants@gmail.com>
* CloudMonitoring: add tests around experimental UI
I also reworked the annotation query editor UI a little bit to bring it
inline with how AzureMonitor's query editor looks.
Closes#44431
* Fix get legacy alert response
* Swagger: Fix get folder by UID response
* Fix conflicting swagger model Alert
Reanme legacy alerting swagger model to LegacyAlert to differentiate it
from the prometheus Alert
* Bump grafana-plugin-sdk-go
* Fix get folder response
* Use go-swagger command for merging the specifications and remove merge_specs script
* Move user not found err to user service
* User ErrCaseInsensitive from user pkg
* User ErrUserAlreadyExists from user pkg
* User ErrLastGrafanaAdmin from user pkg
* Remove errors from model
* User Experience: apply the same pattern feedback for all copy to clipboard buttons
* add copy icon to all ClipboardButton use cases
* Change primary color for copy to clipboard in create token
* Add success button variant
* Remove copy confirmation from TableCellInspectModal because it's in the base component now
* Design tweaks to copy confirmation
- Only change the icon to tick to avoid the button changing size
- Change button to success green
- Only show copy confirmation state for 2 seconds
* revert TabelCellInspectModal text button back
* revert accidental change to ShareLink
Co-authored-by: joshhunt <josh@trtr.co>
* allow setting team managed permissions for service accounts
* Revert "allow setting team managed permissions for service accounts"
This reverts commit 7598626397.
* fix org user removal for OSS
* remove comment
* refactor: move utility functions out of the redux actions
* refactor: move password handlers to the feature root
* refactor: move API related functions to an api.ts
* refactor: move components under a /components folder
* refactor: move page containers under a /pages folder and extract components
* refactor: update mocks to be easier to reuse
* refactor: move tests into a state/tests/ subfolder
* refactor: expose 'initialState' for plugins
* refactor: move generic types to the root folder of the feature
* refactor: import path fixe
* refactor: update import paths for app routes
* chore: update betterer
* refactor: fix type errors due to changed mock functions
* chore: fix mocking context_srv in tests
* refactor: udpate imports to be more concise
* fix: update failing test because of mocks
* refactor: use the new `navId` prop where we can
* fix: use UID instead ID in datasource edit links
* fix:clean up Redux state when unmounting the edit page
* refactor: use `uid` instead of `id`
* refactor: always fetch the plugin details when editing a datasource
The deleted lines could provide performance benefits, although they also make the
implementation more prone to errors. (Mostly because we are storing the information
about the currently loaded plugin in a single field, and it was not validating if it
is for the latest one).
We are planning to introduce some kind of caching, but first we would like to clean up
the underlying state a bit (plugins & datasources.
* fix: add missing dispatch() wrapper for update datasource callback
* refactor: prefer using absolute import paths
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* fix: ESLINT import order issue
* refactor: put test files next to their files
* refactor: use implicit return types for components
* fix: remove caching from datasource fetching
I have introduced a cache to only fetch data-sources once, however as we
are missing a good logic for updating the instances in the Redux store
when they change (create, update, delete), this approach is not keeping the UI in sync.
Due to this reason I have removed the caching for now, and will reintroduce it once we have a
more robust client-side state logic.
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* FolderPage: Progress on folder page navigation
* Dashboard to adapt breadcrumbs when opening dashboard from file storage
* add warning when topnav is not enabled
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* Created PluginSecretMigrationService to be able to migrate from the secrets table from the database to the secret plugin. Added migration which takes all the secrets at the sql store and stores it in the plugin. Then deletes all the secrets from the sql
* Added secretsKVStoreSQL.GetAll() method to return all the secrets at the sql table
* Renaming kvstore_test.go as sql_test.go, adding GetAll test case. Fixing decryption of keys
This commit fixes push notifications for Slack which used to show "This content cannot be displayed". The text field is shown in both the message and the push notification.
* ScenePanelRepeater: Fixes refreshes temporarily by setting key to guid
* Fixing issue with old state being returned by useState when the scene object instance changed (with same react key)
* Storage: add special users for system branding access
* Storage: explicit global org id
* Storage: initialize org storages with global org id
* Storage: add comments
* Storage: simplify - use orgId: 1 for systembranding
* Remove user from preferences, stars, orguser, team member
* Fix lint
* Add Delete user from org and dashboard acl
* Delete user from user auth
* Add DeleteUser to quota
* Add test files and adjust user auth store
* Rename package in wire for user auth
* Import Quota Service interface in other services
* do the same in tests
* fix lint tests
* Fix tests
* Add some tests
* Rename InsertUser and DeleteUser to InsertOrgUser and DeleteOrgUser
* Rename DeleteUser to DeleteByUser in quota
* changing a method name in few additional places
* Fix in other places
* Fix lint
* Fix tests
* Chore: Split Delete User method
* Add fakes for userauth
* Add mock for access control Delete User permossion, use interface
* Use interface for ream guardian
* Add simple fake for dashboard acl
* Add go routines, clean up, use interfaces
* fix lint
* Update pkg/services/user/userimpl/user_test.go
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Update pkg/services/user/userimpl/user_test.go
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Update pkg/services/user/userimpl/user_test.go
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Add wrapper for not service account error
* fix indentation
* Use fmt for error wrapper
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* move fake FakeExternalAlertmanager to sender package
* move tests from scheduler to router
* update alerts router to have all fields private
* update scheduler tests to use sender mock
* Chore: Add new go test commands for unit, integration tests to makefile
* Add test-go-unit and test-go-integration targets as dependencies of the test-go target
* Add makefile target for mysql & postgres backends
* Set GRAFANA_TEST_DB variable for the xargs postgres command
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Set GRAFANA_TEST_DB variable for the xargs mysql command
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Use postgres_tests as source
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Set postgres_tests as source
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Clean test cache before postgres and mysql integration test makefile commands
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Documentation: Updated links to landing pages for the respective notifiers in alerting
Updated links for listed notifiers to correctly redirect to their landing pages
* Ran prettier
This changes the API codegen template (controller-api.mustache) to simplify some names. When this package was created, most APIs "forked" to either a Grafana backend implementation or a "Lotex" remote implementation. As we have added APIs it's no longer the case. Provisioning, configuration, and testing APIs do not fork, and we are likely to add additional APIs that don't fork.
This change replaces {{classname}}ForkingService with {{classname}} for interface names, and names the concrete implementation {{classname}}Handler. It changes the implied implementation of a route handler from fork{{nickname}} to handle{{nickname}}. So PrometheusApiForkingService becomes PrometheusApi, ForkedPrometheusApi becomes PrometheusApiHandler and forkRouteGetGrafanaAlertStatuses becomes handleRouteGetGrafanaAlertStatuses
It also renames some files - APIs that do no forking go from forked_{{name}}.go to {{name}}.go and APIs that still fork go from forked_{{name}}.go to forking_{{name}}.go to capture the idea that those files a "doing forking" rather than "are a fork of something."
Signed-off-by: Joe Blubaugh <joe.blubaugh@grafana.com>
* Encryption: Move secrets migrations into secrets.Migrator
* Encryption: Refactor secrets.Service initialization
* Encryption: Add support to run secrets migrations even when EE is disabled
* Encryption: Expose secrets migrations through HTTP API
* Update docs
* Fix docs links
* Some adjustments to makes errors explicit through HTTP response
* Dashboard: Add guidance about reloaded needed for shared cursor/tooltip
* Dashboard: Added todo note for author of (#46581) impl
* Dashboard: prettier errors fixed for new text
* Fix: sql plugins feature
* SQLDS: Use builtin annotation editor
Plus strict rule fixes
* MSSQL: Migrate query editor to React
* Make code editor work
* Make SQLOptions and SQLQuery in SQLDatasource and in Editor generic
* MSSQL: Fix ts issues
* Fix SQLDatasource refID
* Remove comment
* Revert "Make SQLOptions and SQLQuery in SQLDatasource and in Editor generic"
This reverts commit 1d15b4061a.
* Fix ts issues without generic
* TS
* Encryption: Move secrets migrations into secrets.Migrator
* Encryption: Refactor secrets.Service initialization
* Encryption: Add support to run secrets migrations even when EE is disabled
* Init EE providers on-demand (only when needed)
* Add multiple tests + some adjustments
* Apply feedback
* handler for update message in rule evaluation routine ignores the message if its version greater or equal.
* replace messages to update the channel if it is not empty
* Remove user from preferences, stars, orguser, team member
* Fix lint
* Add Delete user from org and dashboard acl
* Delete user from user auth
* Add DeleteUser to quota
* Add test files and adjust user auth store
* Rename package in wire for user auth
* Import Quota Service interface in other services
* do the same in tests
* fix lint tests
* Fix tests
* Add some tests
* Rename InsertUser and DeleteUser to InsertOrgUser and DeleteOrgUser
* Rename DeleteUser to DeleteByUser in quota
* changing a method name in few additional places
* Fix in other places
* Fix lint
* Fix tests
* Rename DeleteOrgUser to DeleteUserFromAll
* Update pkg/services/org/orgimpl/org_test.go
Co-authored-by: Emil Tullstedt <emil.tullstedt@grafana.com>
* Update pkg/services/preference/prefimpl/inmemory_test.go
Co-authored-by: Emil Tullstedt <emil.tullstedt@grafana.com>
* Rename Acl to ACL
* Fix wire after merge with main
* Move test to uni test
Co-authored-by: Emil Tullstedt <emil.tullstedt@grafana.com>
* move sanitize test to its own test file
* add a test for renderTextPanelMarkdown to always sanitize
* setup TextPanel tests
* add tests to always sanitize Text Panel contents and always convert correctly to html/markdown
* add tests for cache getOrCreate
* update ProcessEvalResults to accept extra lables
* extract to getRuleExtraLabels
* move populating of constant rule labels to extra labels
* Scenes: Support new top nav
* Page: Make Page component support new and old dashboard page layouts
* Pass scrollbar props
* Fixing flex layout for dashboard
* Updated title handling and test
* Initial work on new toolbar button
* Minor step
* Small progress
* Minor progress
* Minor fix
* removed console.log
* Removing stuff we don't need yet
* add the migration
* Update pkg/services/sqlstore/migrations/accesscontrol/dashboard_permissions.go
Co-authored-by: Eric Leijonmarck <eric.leijonmarck@gmail.com>
Co-authored-by: Eric Leijonmarck <eric.leijonmarck@gmail.com>
When there is a single frame with no fields (e.g. splunk datasource) SSE errors when trying to figure out the data type. This frame needs to exist since this is where the executedQueryString metadata exists.
This adds a new return type to SSE to represent no data, so the original frame with its metadata can still be maintained.
* feat: make azure experimental the default
* feat: combine metrics query editor rows
fix: linter errors
* chore: remove test loop for DimensionFields test
without setting function map from alertmanager we receive error:
method=PUT path=/api/v1/provisioning/templates/slack.message status=400
level=error msg="invalid object specification: invalid template: template: :1: function \"toUpper\" not defined"
So for validation we should use the same settings as alertmanager do
for templates internally.
This commit fixes a bug where the state did not change from Alerting to Error if the evaluation result returned an error, or from Error to Alerting if evaluations stopped returning errors.
* update decrypt secrets function signature and add secrets error handling
* remove a couple instances of unnecessary logging since errors are properly handled now
* add unit test
* fix linting issues
* SQLstore: Fix fetching and deleting an inexistent playlist
xorm's session.Get() does not return an error if the raw does not exist.
It returns a boolean instead.
The playlist `sqlstore.GetPlaylist()` used to check only the error and in case
of inexistent UID didn't return an error.
Fixes public dashboards bug. When panel targets have no datasource, the datasource on the panel can be a json object or a string and will get added to the targets for pubdash.
* AlertRule to return condition
* update ConditionEval to not return an error because it's always nil
* make getExprRequest private
* refactor executeCondition to just converter and move execution to the ConditionEval as this makes code more readable.
* log error if results have errors
* change signature of evaluate function to not return an error
* Implement disableSecretsCompatibility flag
* Allow secret deletion right after migration
* Use dialect.Quote for secure_json_data on secret deletion
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Set secure_json_data to NULL instead of empty json
* Run toggles_gen_test and use generated flag variable
* Add ID to delete data source secrets command on function call
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Remove extra query to get datasource on secret deletion
* Fix linting issues with CHANGELOG.md
* Use empty json string when deleting secure json data
* Implement secret migration as a background process
* Refactor secret migration as a background service
* Refactor migration to be inside secret store
* Re-add secret deletion function removed on merge
* Try using transaction to fix db lock during tests
* Disable migration for pipeline debugging
* Try adding sleep to fix database lock
* Remove unecessary time sleep from migration
* Fix merge issue, replace models with datasources
* Try event listener approach
* Fix merge issue, replace models with datasources
* Fix linting issues with unchecked error
* Remove unecessary trainling new line
* Increase wait interval on background secret migration
* Rename secret store migration folder for consistency
* Convert background migration to blocking
* Fix number of arguments on server tests
* Check error value of secret migration provider
* Fix linting issue with method varaible
* Revert unintended change on background services
* Move secret migration service provider to wire.go
* Remove unecessary else from datasource service
* Move transaction inside loop on secret migration
* Remove unecessary GetServices function
* Remove unecessary interface after method removal
* Rename Run to Migrate on secret migration interface
* Rename secret migrations service variable on server
* Use MustBool on datasource secret migration
* Revert changes to GetDataSources
* Implement GetAllDataSources function
* Remove DeleteDataSourceSecrets function
* Move datasource secret migration to datasource service
* Remove unecessary properties from datasource secret migration
* Make DecryptLegacySecrets a private method
* Remove context canceled check on secret migrator
* Log error when fail to unmarshal datasource secret
* Add necessary fields to update command on migration
* Handle high availability on secret migration
* Use kvstore for datasource secret migration status
* Add error check for migration status set on kvstore
* Remove NewSecretMigrationService from server tests
* Use const for strings on datasource secrets migration
* Test all cases for datasources secret migrations
Co-authored-by: Sofia Papagiannaki <1632407+papagian@users.noreply.github.com>
* Introduce AlertsRouter in the sender package, and move all fields and methods related to notifications out of the scheduler to this router.
* Introduce a new interface AlertsSender in the schedule package and replace calls of anonymous function `notify` inside the ruleRoutine to calling methods of that interface.
* Rename interface Scheduler in api package to ExternalAlertmanagerProvider, and replace scheduler with AlertRouter as struct that implements the interface.
/api/admin/pause-all-alerts only takes effect for legacy alerts. This
change returns a 403 if it's called when legacy alerting is disabled.
Fixes#51729
* Define query param and regenerate
* Add query struct for contact points
* Filter contact points by name in query
* Document that name filter is optional
* Alerting: Add config disabled_labels to disable reserved labels
[unified_alerting.reserved_labels]
disabled_labels
* Replace IsGrafanaFolderDisabled with more generic IsReservedLabelDisabled
* Simplify SchedulerCfg by including UnifiedAlertingSettings
* Alerting: Update default route groupBy to [grafana_folder, alertname]
Default group by for new routes and migrations is now [grafana_folder, alertname]
* Define route and run codegen
* Wire up HTTP layer
* Update API layer and test fakes
* Implement reset of policy tree
* Implement service layer test and authorization bindings
* API layer testing
* Be more specific when injecting settings
* init
* support template variables
* support variables without curly braces
* add todo for `__all` case
* fix `$__all` case for non-multivalue
* extract some functions
* fix flakinesss
* support `$__all` and `default` template variables
* add todo
* compilation fix
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* Add NumberInput to core slider
* Change opacity interpretation
To be consistent with other layers, and CSS, opacity of 0 is fully
transparent and an opacity of 1 is fully opaque.
* Add state management for slider.
* Ensure number input step matches slider
* Style input width based on expected digits
* Improve styling for number input validation error
* Org: use constants for status codes
* ServiceAccounts: Avoid creating new orgs for service accounts
* Document createUserBehavior
* Update pkg/services/sqlstore/org_users_test.go
* add doc string to flag
* refactor(Data Sources): rename file to follow naming convention
* refactor: use react-redux hooks for interacting with the store
* tests: update data-sources list related test files
* refactor: extract datasource list page contents
* refactor: pass dataSources to the DataSourcesList as a prop
* refactor: use proper typing for navIndex mocks
* Add doc-validator tool to CI
Signed-off-by: Jack Baldry <jack.baldry@grafana.com>
* Use simpler apostrophe to make title match h1
Signed-off-by: Jack Baldry <jack.baldry@grafana.com>
* Ensure doc-validator CI always passes until all errors are resolved
Signed-off-by: Jack Baldry <jack.baldry@grafana.com>
* Playing around
* This is getting interesting
* Updates
* Updated
* Observable experiments
* This is tricky
* VizPanel panel renderer
* New model progress
* Maybe this could be something
* Updated
* Rename
* updates
* Updated
* Query runners? not sure
* Updated
* updates
* flex box layout starting to work
* Testing
* Tested an action
* Parent context sort of working
* Progress
* Progress
* Updated
* Starting to work
* Things are working
* Scene list, nested scene demo
* Progress on repeats
* Moving things
* Pretty big progress
* More things working
* Great progress
* Progress
* Name changing
* Minor tweaks
* Simplified sizing
* Move toggleDirection to SceneFlexLayout
* add feature flag (#50990)
* removed new useObservable hook
* Rename folder and feature toggle to scenes
* Caching scenes so you can go back to another scene without having to re-query data
* Fix issue with subs on re-mount
* Fixing test
* Added SceneCanvasText to play around with layout elements with size based on content
* Scene: Edit mode and component edit wrapper that handles selection (#51078)
* First step for scene variables
* Started playing around with a scene edit mode
* Better way to set component
* Progress on edit mode
* Update
* Progress on edit mode
* Progress on editor
* Progress on editor
* Updates
* More working
* Progress
* Minor update
* removed unnessary file
* Moving things around
* Updated
* Making time range separate from time picker
* minor rename of methods
* The most basic variable start
* Minor renames
* Fixed interpolate issue if not found at closest level
* An embryo of event model and url sync handling
* Update url sync types
* Removed unnessary any type arg
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
Co-authored-by: Dominik Prokop <dominik.prokop@grafana.com>
This PR moves public dashboards into its own self contained service including API, Service, Database, and Models. Routes are mounted on the Grafana HTTPServer by the API service at injection time with wire.go. The main route that loads the frontend for public dashboards is still handled by the API package.
Co-authored-by: Jesse Weaver <jesse.weaver@grafana.com>
Co-authored-by: Owen Smallwood <owen.smallwood@grafana.com>
* passes id and uid to PublicDashboardDatasource
* betterer results
* If for a public dashboard, return the PublicDashboardDataSource first or else getDatasourceSrv.get() will fail bc of no authed user.
Added some unit tests for resolving the uid from the many possible datasource types.
* updates betterer
* Exports DashboardService. Adds method to DashboardService to build anonymous user for use with public dashboards where there is no authed user. Adds method on dashboard_queries to get all dashboard uids from a dashboard.
* refactors to get unique datasource uids
* Adds tests for getting all unique datasource uids off a dashboard
* adds test for building anonymous user with read and query actions that are scoped to each datasource uid in the dashboard
* updates casing of DashboardService
* updates test case to have additional panel with a different datasource
* gives default interval to public dashboard data source
* add custom title in wecom channel
* add wecom test case and setting config in ui
* Update pkg/services/ngalert/notifier/channels/wecom_test.go
Co-authored-by: Matthew Jacobson <JacobsonMT@gmail.com>
* change version in comment
* Update pkg/services/ngalert/notifier/available_channels.go
Co-authored-by: Matthew Jacobson <JacobsonMT@gmail.com>
* format
Co-authored-by: Matthew Jacobson <JacobsonMT@gmail.com>
* First stab at new page layouts behind feature toggle
* Simplifying PageHeader
* Progress on a new model that can more easily support new and old page layouts
* Progress
* rename folder
* Progress
* Minor change
* fixes
* Fixing tests
* Make breadcrumbs work
* Add tests for old Page component
* Adding tests for new Page component and behavior
* fixing page header test
* Fixed test
* AppChrome outside route
* Renaming folder
* Minor fix
* Updated
* Fixing StoragePage
* Fix for banners
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
* Ensure resource name is appended to URI
* Add storage account check to ensure default subresource is appended
* Update storage dashboard
* Bump storage version
* Remove ADX StreamingIngestRequestRate panel as the metric is unavailable
* Refactor condition for storage namespaces
* Add more tests for URI builder
* Do not migrate resource URI if resource name or metric definition uses template variables
* Revert change to metricNamespace
* Revert "Serviceaccounts: #48995
Do not display service accounts assigned to team (#48995)"
This reverts commit cbf71fbd7f.
* fix: test to not include more actions than necessary
* adding service accounts to teams - backend and frontend changes
* also support SA addition through the old team membership endpoints
* fix tests
* tests
* serviceaccounts permission tests
* serviceaccounts permission service tests run
* added back test that was removed by accident
* lint
* refactor: add testoptionsTeams
* fix a bug
* service account picker change
* explicitly set SA managed permissions to false for dash and folders
* lint
* allow team creator to list service accounts
Co-authored-by: IevaVasiljeva <ieva.vasiljeva@grafana.com>
* Add SpanBarSettings
* Add SpanBarSettings to Jaeger
* Add SpanBarSettings to Zipkin
* Updated title
* Add dropdown to select identifer and make duration a default option
* Show duration by default
* Add option to hide
* Move identifers into constants
* Add process
* Update text
* Update placeholders
* Text/meta data updates
* Added tests
* Added docs
* Update find
* Merge tag and prcoess options
* Update docs
* Updated tests
* Update betterer results and trace view to match
* Updated docs
* Alerting: validate that the receiver exist when updating routing tree
* rename interface
* add missing file
* change constructor
* fix e2e tests
* only import package once
* add unit test for bug
* wording
* close response body
* Update pkg/services/ngalert/api/tooling/definitions/alertmanager_validation.go
* refactor to remove database roundtrip
* Copy delete user permission to access control service
* Update pkg/services/accesscontrol/database/database_test.go
Co-authored-by: Gabriel MABILLE <gamab@users.noreply.github.com>
Co-authored-by: Gabriel MABILLE <gamab@users.noreply.github.com>
* Import the mdx documentation file to PluginSignatureBadge.story.tsx and add to its export defaul
* Create the mdx file of PluginSignatureBadge with its information
* Fix signed PluginSignatureBadge status
* Modify text according to reviewer suggestions
* betterer
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
* MegaMenu: Add mega menu to new top nav design
* Copy NavBar in order to make changes more cleanly
* Adding tests
* whoops, forgot to resolve conflicts...
* Review fixes
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
* Convert QueryOperationRow test to RTL
* Convert QueryOperationRow test to RTL
* Convert QueryOperationRow test to RTL
* Convert QueryOperationRow test to RTL
* Update QueryOperationRow.test.tsx
* update betterer
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
* Added mdx file for secret input
* Chore: Improve SecretInput story
* review related changes in docs
Co-authored-by: Ashley Harrison <ashley.harrison@grafana.com>
* rewrite eslint test to not care about position of errors
* changing file contents shouldn't require a betterer.results update
* fix up eslint test
* fix the undocumented stories test
* ignore .test.ts files as well
* UsageStats: fixed elasticsearch version number
- The version numbering was changed from plain numbers to a semver-ish approach
* added missing version assertion
* adapted tests
* WIP: Enable annotations display and annotations editor in State timeline panel
* Note support for annotations in module file
* Lint fix
* Post review
Co-authored-by: Kyle Cunningham <kyle@codeincarnate.com>
- **Access control:** Show dashboard settings to users who can edit dashboard. [#52535](https://github.com/grafana/grafana/pull/52535), [@grafanabot](https://github.com/grafanabot)
- **Alerting:** Allow the webhook notifier to support a custom Authorization header. [#52515](https://github.com/grafana/grafana/pull/52515), [@gotjosh](https://github.com/gotjosh)
- **Chore:** Upgrade to Go version 1.17.12. [#52523](https://github.com/grafana/grafana/pull/52523), [@sakjur](https://github.com/sakjur)
- **Prometheus:** Don't show errors from unsuccessful API checks like rules or exemplar checks. [#52193](https://github.com/grafana/grafana/pull/52193), [@darrenjaneczek](https://github.com/darrenjaneczek)
### Bug fixes
- **Access control:** Allow organisation admins to add existing users to org (#51668). [#52553](https://github.com/grafana/grafana/pull/52553), [@vtorosyan](https://github.com/vtorosyan)
- **Apps:** Fixes navigation between different app plugin pages. [#52571](https://github.com/grafana/grafana/pull/52571), [@torkelo](https://github.com/torkelo)
- **Cloudwatch:** Upgrade grafana-aws-sdk to fix auth issue with secret keys. [#52420](https://github.com/grafana/grafana/pull/52420), [@sarahzinger](https://github.com/sarahzinger)
- **Grafana/toolkit:** Fix incorrect image and font generation for plugin builds. [#52661](https://github.com/grafana/grafana/pull/52661), [@academo](https://github.com/academo)
- **Loki:** Fix `show context` not working in some occasions. [#52458](https://github.com/grafana/grafana/pull/52458), [@svennergr](https://github.com/svennergr)
- **RBAC:** Fix permissions on dashboards and folders created by anonymous users. [#52615](https://github.com/grafana/grafana/pull/52615), [@gamab](https://github.com/gamab)
<!-- 9.0.5 END -->
<!-- 9.0.4 START -->
# 9.0.4 (2022-07-20)
### Features and enhancements
- **Browse/Search:** Make browser back work properly when visiting Browse or search. [#52271](https://github.com/grafana/grafana/pull/52271), [@torkelo](https://github.com/torkelo)
- **Loki:** Improve handling of empty responses. [#52397](https://github.com/grafana/grafana/pull/52397), [@gabor](https://github.com/gabor)
- **Plugins:** Always validate root URL if specified in signature manfiest. [#52332](https://github.com/grafana/grafana/pull/52332), [@wbrowne](https://github.com/wbrowne)
- **Preferences:** Get home dashboard from teams. [#52225](https://github.com/grafana/grafana/pull/52225), [@sakjur](https://github.com/sakjur)
- **SQLStore:** Support Upserting multiple rows. [#52228](https://github.com/grafana/grafana/pull/52228), [@joeblubaugh](https://github.com/joeblubaugh)
- **Traces:** Add more template variables in Tempo & Zipkin. [#52306](https://github.com/grafana/grafana/pull/52306), [@joey-grafana](https://github.com/joey-grafana)
- **Alerting:** Preserve new-lines from custom email templates in rendered email. [#52253](https://github.com/grafana/grafana/pull/52253), [@alexweav](https://github.com/alexweav)
- **Insights:** Fix dashboard and data source insights pages. (Enterprise)
- **Log:** Fix text logging for unsupported types. [#51306](https://github.com/grafana/grafana/pull/51306), [@papagian](https://github.com/papagian)
- **Loki:** Fix incorrect TopK value type in query builder. [#52226](https://github.com/grafana/grafana/pull/52226), [@ivanahuckova](https://github.com/ivanahuckova)
- **Access control:** Allow organisation admins to add existing users to org. [#51668](https://github.com/grafana/grafana/pull/51668), [@IevaVasiljeva](https://github.com/IevaVasiljeva)
- **Alerting:** Add method to provisioning API for obtaining a group and its rules. [#51761](https://github.com/grafana/grafana/pull/51761), [@alexweav](https://github.com/alexweav)
- **Alerting:** Add method to provisioning API for obtaining a group and its rules. [#51398](https://github.com/grafana/grafana/pull/51398), [@alexweav](https://github.com/alexweav)
- **Alerting:** Allow filtering of contact points by name. [#51933](https://github.com/grafana/grafana/pull/51933), [@alexweav](https://github.com/alexweav)
- **Alerting:** Disable /api/admin/pause-all-alerts with Unified Alerting. [#51895](https://github.com/grafana/grafana/pull/51895), [@joeblubaugh](https://github.com/joeblubaugh)
- **Analytics:** Add total queries and cached queries in usage insights logs. (Enterprise)
- **Annotations:** Use point marker for short time range annotations. [#51520](https://github.com/grafana/grafana/pull/51520), [@codeincarnate](https://github.com/codeincarnate)
- **AzureMonitor:** Update UI to experimental package. [#52123](https://github.com/grafana/grafana/pull/52123), [@asimpson](https://github.com/asimpson)
- **AzureMonitor:** Update resource and namespace metadata. [#52030](https://github.com/grafana/grafana/pull/52030), [@despian](https://github.com/despian)
- **CloudWatch:** Remove simplejson in favor of 'encoding/json'. [#51062](https://github.com/grafana/grafana/pull/51062), [@asimpson](https://github.com/asimpson)
- **DashboardRow:** Collapse shortcut prevent to move the collapsed rows. [#51589](https://github.com/grafana/grafana/pull/51589), [@ivanortegaalba](https://github.com/ivanortegaalba)
- **Insights:** Add dashboard UID to exported logs. (Enterprise)
- **Navigation:** Highlight active nav item when Grafana is served from subpath. [#51767](https://github.com/grafana/grafana/pull/51767), [@kianelbo](https://github.com/kianelbo)
- **Plugins:** InfluxDB datasource - set epoch query param value as "ms". [#51651](https://github.com/grafana/grafana/pull/51651), [@itsmylife](https://github.com/itsmylife)
- **Plugins:** InfluxDB update time range query. [#51833](https://github.com/grafana/grafana/pull/51833), [@itsmylife](https://github.com/itsmylife)
- **StateTimeline:** Try to sort time field. [#51569](https://github.com/grafana/grafana/pull/51569), [@zoltanbedi](https://github.com/zoltanbedi)
### Bug fixes
- **API:** Do not validate/save legacy alerts when saving a dashboard if legacy alerting is disabled. [#51883](https://github.com/grafana/grafana/pull/51883), [@papagian](https://github.com/papagian)
- **Alerting:** Add method to reset notification policy tree back to the default. [#51934](https://github.com/grafana/grafana/pull/51934), [@alexweav](https://github.com/alexweav)
- **Alerting:** Fix Teams notifier not failing on 200 response with error. [#52254](https://github.com/grafana/grafana/pull/52254), [@JacobsonMT](https://github.com/JacobsonMT)
- **Alerting:** Fix bug where state did not change between Alerting and Error. [#52204](https://github.com/grafana/grafana/pull/52204), [@grobinson-grafana](https://github.com/grobinson-grafana)
- **Alerting:** Fix consistency errors in OpenAPI documentation. [#51935](https://github.com/grafana/grafana/pull/51935), [@alexweav](https://github.com/alexweav)
- **Alerting:** Fix normalization of alert states for panel annotations. [#51637](https://github.com/grafana/grafana/pull/51637), [@gillesdemey](https://github.com/gillesdemey)
- **Alerting:** Provisioning API respects global rule quota. [#52180](https://github.com/grafana/grafana/pull/52180), [@alexweav](https://github.com/alexweav)
- **Loki:** Fix error when changing operations with different parameters. [#51779](https://github.com/grafana/grafana/pull/51779), [@svennergr](https://github.com/svennergr)
- **Loki:** Fix suggesting of correct operations in query builder. [#52034](https://github.com/grafana/grafana/pull/52034), [@ivanahuckova](https://github.com/ivanahuckova)
- **SQLstore:** Fix fetching an inexistent playlist. [#51962](https://github.com/grafana/grafana/pull/51962), [@papagian](https://github.com/papagian)
- **Security:** Fixes for CVE-2022-31107 and CVE-2022-31097. [#52279](https://github.com/grafana/grafana/pull/52279), [@kminehart](https://github.com/kminehart)
- **Snapshots:** Fix deleting external snapshots when using RBAC. [#51897](https://github.com/grafana/grafana/pull/51897), [@idafurjes](https://github.com/idafurjes)
- **Table:** Fix scrollbar being hidden by pagination. [#51501](https://github.com/grafana/grafana/pull/51501), [@zoltanbedi](https://github.com/zoltanbedi)
- **Templating:** Changing between variables with the same name now correctly triggers a dashboard refresh. [#51490](https://github.com/grafana/grafana/pull/51490), [@ashharrison90](https://github.com/ashharrison90)
- **Time series panel:** Fix an issue with stacks being not complete due to the incorrect data frame length. [#51910](https://github.com/grafana/grafana/pull/51910), [@dprokop](https://github.com/dprokop)
- **[v9.0.x] Snapshots:** Fix deleting external snapshots when using RBAC (#51897). [#51904](https://github.com/grafana/grafana/pull/51904), [@idafurjes](https://github.com/idafurjes)
<!-- 9.0.3 END -->
<!-- 9.0.2 START -->
# 9.0.2 (2022-06-28)
@@ -576,6 +688,16 @@ In the Loki data source, for consistency and performance reasons, we changed how
The dependency to [grafana/aws-sdk](https://github.com/grafana/grafana-aws-sdk-react) is moved from [grafana/ui](https://github.com/grafana/grafana/blob/main/packages/grafana-ui/package.json) to the plugin. This means that any plugin that use SIGV4 auth need to pass a SIGV4 editor component as a prop to the `DataSourceHttpSettings` component. Issue [#43559](https://github.com/grafana/grafana/issues/43559)
<!-- 8.5.9 START -->
# 8.5.9 (2022-07-14)
### Bug fixes
- **Security:** Fixes for CVE-2022-31107 and CVE-2022-31097. [#52238](https://github.com/grafana/grafana/pull/52238), [@xlson](https://github.com/xlson)
<!-- 8.5.9 END -->
<!-- 8.5.6 START -->
# 8.5.6 (2022-06-14)
@@ -816,6 +938,16 @@ When user is using Github OAuth, GitHub login is showed as both Grafana login an
The meaning of the default data source has now changed from being a persisted property in a panel. Before when you selected the default data source for a panel and later changed the default data source to another data source it would change all panels who were configured to use the default data source. From now on the default data source is just the default for new panels and changing the default will not impact any currently saved dashboards. Issue [#45132](https://github.com/grafana/grafana/issues/45132)
<!-- 8.4.10 START -->
# 8.4.10 (2022-07-14)
### Bug fixes
- **Security:** Fixes for CVE-2022-31107 and CVE-2022-31097. [#52218](https://github.com/grafana/grafana/pull/52218), [@IevaVasiljeva](https://github.com/IevaVasiljeva)
# For "sqlite3" only. cache mode setting used for connecting to the database
cache_mode=private
# For "mysql" only if lockingMigration feature toggle is set. How many seconds to wait before failing to lock the database for the migrations, default is 0.
# For "mysql" only if migrationLocking feature toggle is set. How many seconds to wait before failing to lock the database for the migrations, default is 0.
locking_attempt_timeout_sec=0
#################################### Cache server #############################
# Enable the Unified Alerting sub-system and interface. When enabled we'll migrate all of your alert rules and notification channels to the new system. New alert rules will be created and your notification channels will be converted into an Alertmanager configuration. Previous data is preserved to enable backwards compatibility but new data is removed when switching. When this configuration section and flag are not defined, the state is defined at runtime. See the documentation for more details.
@@ -861,8 +867,8 @@ max_attempts = 3
min_interval=10s
[unified_alerting.screenshots]
# Enable screenshots in notifications. This option requires a remote HTTP image rendering service. Please
# see [rendering] for further configuration options.
# Enable screenshots in notifications. This option requires the Grafana Image Renderer plugin.
# For more information on configuration options, refer to [rendering].
capture=false
# The maximum number of screenshots that can be taken at the same time. This option is different from
# Enable the legacy alerting sub-system and interface. If Unified Alerting is already enabled and you try to go back to legacy alerting, all data that is part of Unified Alerting will be deleted. When this configuration section and flag are not defined, the state is defined at runtime. See the documentation for more details.
@@ -1255,3 +1266,10 @@ max_crawl_duration =
# Minimum interval between two subsequent scheduler runs. Default is 12h.
# This setting should be expressed as a duration. Examples: 10s (seconds), 1m (minutes).
# For "sqlite3" only. cache mode setting used for connecting to the database. (private, shared)
;cache_mode = private
# For "mysql" only if lockingMigration feature toggle is set. How many seconds to wait before failing to lock the database for the migrations, default is 0.
# For "mysql" only if migrationLocking feature toggle is set. How many seconds to wait before failing to lock the database for the migrations, default is 0.
;locking_attempt_timeout_sec = 0
################################### Data sources #########################
@@ -847,6 +847,11 @@
# The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.
;min_interval = 10s
[unified_alerting.reserved_labels]
# Comma-separated list of reserved labels added by the Grafana Alerting engine that should be disabled.
Grafana uses the [LinguiJS](https://github.com/lingui/js-lingui) framework for managing translating phrases in the Grafana frontend.
@@ -59,7 +59,7 @@ For components used all over the site, use just two segments:
### Top-level provider
In [AppWrapper.tsx](/public/app/AppWrapper.tsx) the app is wrapped with `I18nProvider` from `public/app/core/localisation.tsx` where the Lingui instance is created with the user's preferred locale. This sets the appropriate context and allows any component from `@lingui/macro` to use the translations for the user's preferred locale.
In [AppWrapper.tsx](/public/app/AppWrapper.tsx) the app is wrapped with `I18nProvider` from `public/app/core/internationalization/index.tsx` where the Lingui instance is created with the user's preferred locale. This sets the appropriate context and allows any component from `@lingui/macro` to use the translations for the user's preferred locale.
### Message format
@@ -191,4 +191,4 @@ import { Plural } from "@lingui/macro"
## Documentation
[Grafana's documentation](https://grafana.com/docs/grafana/latest/) is not yet open for translation and should be authored in English only.
[Grafana's documentation](https://grafana.com/docs/grafana/latest/) is not yet open for translation and should be authored in American English only.
We _could_ target the field with a CSS selector like `.gf-form-input.login-form-input` but that would be brittle as style changes occur frequently. Furthermore there is nothing that signals to future developers that this input is part of an E2E test. At Grafana, we use `aria-label` attributes as our preferred way of defining selectors instead of [`data-*`](https://mdn.io/docs/Web/HTML/Global_attributes/data-*) as they also aid in [accessibility](https://mdn.io/docs/Learn/Accessibility/What_is_accessibility):
We _could_ target the field with a CSS selector like `.gf-form-input.login-form-input` but that would be brittle as style changes occur frequently. Furthermore there is nothing that signals to future developers that this input is part of an E2E test. At Grafana, we use `data-testid` attributes as our preferred way of defining selectors. See [Aria-Labels vs data-testid](#aria-labels-vs-data-testid) for more details.
The next step is to create a `Page` representation in our E2E framework to glue the test with the real implementation using the `pageFactory` function. For that function we can supply a `url` and `selectors` like in the example below:
@@ -39,10 +39,12 @@ export const Login = {
// Called via `Login.visit()`
url:'/login',
// Called via `Login.username()`
username:'Username input field',
username:'data-testid Username input field',
};
```
Note that the selector is prefixed with `data-testid` - this is a signal to the framework to look for the selector in the `data-testid` attribute.
The next step is to add the `Login` page to the `Pages` export within [_\<repo-root>/packages/grafana-e2e-selectors/src/selectors/pages.ts_](../../packages/grafana-e2e-selectors/src/selectors/pages.ts) so that it appears when we type `e2e.pages` in our IDE.
```typescript
@@ -59,7 +61,7 @@ Now that we have a `Page` called `Login` in our `Pages` const we can use that to
@@ -127,9 +129,9 @@ The next step is to use the `dataSources` selector function as in our example be
When this list is rendered with the data sources with names `A`, `B` and `C` ,the resulting HTML would look like:
```html
<divclass="card-item-name"aria-label="Data source list item A">A</div>
<divclass="card-item-name"aria-label="Data source list item B">B</div>
<divclass="card-item-name"aria-label="Data source list item C">C</div>
<divclass="card-item-name"data-testid="data-testid Data source list item A">A</div>
<divclass="card-item-name"data-testid="data-testid Data source list item B">B</div>
<divclass="card-item-name"data-testid="data-testid Data source list item C">C</div>
```
Now we can write our test. The one thing that differs from the [basic example](#basic-example) above is that we pass in which data source we want to click on as an argument to the selector function:
The new arm64 architecture does not build for the latest docker image of keycloack. Refer to https://github.com/docker/for-mac/issues/5310 for the issue to see if it resolved.
Until then you need to build the docker image locally and then run `devenv`.
The new arm64 architecture does not build for the latest docker image of keycloack. Refer to https://github.com/docker/for-mac/issues/5310 for the issue to see if it resolved.
Until then you need to build the docker image locally and then run `devenv`.
API keys can be used to interact with Grafana HTTP APIs.
We recommend using service accounts instead of API keys if you are on Grafana 8.5+, for more information refer to [About service accounts]({{< relref "../service-accounts/about-service-accounts/#" >}}).
{{< section >}}
## About API keys
An API key is a randomly generated string that external systems use to interact with Grafana HTTP APIs.
When you create an API key, you specify a **Role** that determines the permissions associated with the API key. Role permissions control that actions the API key can perform on Grafana resources. For more information about creating API keys, refer to [Create an API key]({{< relref "create-api-key/#" >}}).
When you create an API key, you specify a **Role** that determines the permissions associated with the API key. Role permissions control that actions the API key can perform on Grafana resources.
> **Note:** If you use Grafana v8.5 or newer, use service accounts instead of API keys. For more information, refer to [Grafana service accounts]({{< relref "../service-accounts/" >}}).
{{< section >}}
## Create an API key
Create an API key when you want to manage your computed workload with a user.
For more information about API keys, refer to [About API keys in Grafana]({{< relref "about-api-keys/" >}}).
This topic shows you how to create an API key using the Grafana UI. You can also create an API key using the Grafana HTTP API. For more information about creating API keys via the API, refer to [Create API key via API]({{< relref "../../developers/http_api/create-api-tokens-for-org/#how-to-create-a-new-organization-and-an-api-token" >}}).
### Before you begin:
- Ensure you have permission to create and edit API keys. For more information about permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/#" >}}).
- Ensure you have permission to create and edit API keys. For more information about permissions, refer to [Roles and permissions]({{< relref "../roles-and-permissions/#" >}}).
**To create an API key:**
@@ -50,3 +44,40 @@ This topic shows you how to create an API key using the Grafana UI. You can also
- The maximum length of time is 30 days (one month). You enter a number and a letter. Valid letters include `s` for seconds,`m` for minutes, `h` for hours, `d `for days, `w` for weeks, and `M `for month. For example, `12h` is 12 hours and `1M` is 1 month (30 days).
- If you are unsure about how long an API key should be valid, we recommend that you choose a short duration, such as a few hours. This approach limits the risk of having API keys that are valid for a long time.
1. Click **Add**.
## Migrate API Keys to Grafana service accounts
You can migrate one or all API keys to [Grafana service accounts]({{< relref "../service-accounts/" >}}). When you migrate an API key to a service account, a service account will be created with a service account token.
The API key will continue to work, and you can find it in the [Grafana service account tokens]({{< relref "../service-accounts/#service-account-benefits/#service-account-tokens" >}}) details.
For more information about benefits of service accounts, refer to [Grafana service account benefits]({{< relref "../service-accounts/#service-account-benefits" >}}).
You can choose to migrate a single API key or all API keys. Note that when you migrate all API keys, you can't create new API keys anymore and will have to use service accounts instead.
### Before you begin
- Ensure you have permission to create Grafana service accounts. For more information about permissions, refer to [Roles and permissions]({{< relref "../roles-and-permissions/#" >}}).
**To migrate all API keys to service accounts:**
1. Sign in to Grafana, hover your cursor over **Configuration** (the gear icon), and click **API Keys**.
2. In the top of the page, find the section which says **Switch from API keys to service accounts**
3. Click **Migrate to service accounts now**.
4. A confirmation window will appear, asking to confirm the migration. Click **Yes, migrate now** if you are willing to continue.
5. Once migration is successful, you can choose to forever hide the API keys page. Click **Hide API keys page forever** if you want to do that.
**To migrate single API key to a service account:**
1. Sign in to Grafana, hover your cursor over **Configuration** (the gear icon), and click **API Keys**.
1. Find the API Key you want to migrate.
1. Click **Migrate to service account**.
### Revert service account token to API key
**Note:** This is undesired operation and should be used only in emergency situations.
It is possible to convert back service account token to API key. You can use the [Revert service account token to API key HTTP API]({{< relref "../../developers/http_api/create-api-tokens-for-org/#how-to-create-a-new-organization-and-an-api-token" >}}) for that.
**The revert will perform the following actions:**
1. Convert the given service account token back to API key
1. Delete the service account associated with the given key. **Make sure there are no other tokens associated with the service account, otherwise they all will be deleted.**
@@ -29,7 +29,7 @@ If the user is aware of the change and intended it, then that's great! But if th
In Grafana, you can change your names and emails associated with groups or accounts in the Settings or Preferences. This topic provides instructions for each task.
Some tasks require certain permissions. For more information about roles, refer to [Roles and permissions]({{< relref "../roles-and-permissions/" >}}).
### Change organization name
@@ -39,24 +39,20 @@ Grafana server administrators and organization administrators can change organiz
Follow these instructions if you are a Grafana Server Admin.
1. Hover your cursor over the **Configuration** (gear) icon.
1. Click **Preferences**.
1. In **Organization name**, enter the new name.
1. Click **Update organization name**.
{{< /docs/list >}}
### Change team name or email
@@ -80,7 +76,7 @@ To learn how to edit your user information, refer to [Edit your profile]({{< rel
In Grafana, you can modify the UI theme configured in the Settings or Preferences. Set the UI theme for the server, an organization, a team, or your personal user account using the instructions in this topic.
Some tasks require certain permissions. For more information about roles, refer to [Roles and permissions]({{< relref "../roles-and-permissions/" >}}).
### Theme options
@@ -112,36 +108,34 @@ To see what the current settings are, refer to [View server settings]({{< relref
Organization administrators can change the UI theme for all users in an organization.
1. On the left menu, hover your cursor over your avatar and then click **Preferences**.
1. In the Preferences section, select the **UI theme**.
1. Click **Save**.
## Change the Grafana default timezone
By default, Grafana uses the timezone in your web browser. However, you can override this setting at the server, organization, team, or individual user level. This topic provides instructions for each task.
Some tasks require certain permissions. For more information about roles, refer to [Roles and permissions]({{< relref "../roles-and-permissions/" >}}).
### Set server timezone
@@ -151,36 +145,34 @@ Grafana server administrators can choose a default timezone for all users on the
Organization administrators can choose a default timezone for their organization.
1. Hover your cursor over the **Configuration** (gear) icon.
1. Click **Preferences**.
1. Click to select an option in the **Timezone** list. **Default** is either the browser local timezone or the timezone selected at a higher level. Refer to [Time range controls]({{< relref "../../dashboards/time-range-controls/" >}}) for more information about Grafana time settings.
1. Click **Save**.
### Set team timezone
Organization administrators and team administrators can choose a default timezone for all users in a team.
1. Click to select an option in the **Timezone** list. **Default** is either the browser local timezone or the timezone selected at a higher level. Refer to [Time range controls]({{< relref "../../dashboards/time-range-controls/" >}}) for more information about Grafana time settings.
1. Click **Save**.
### Set your personal timezone
You can change the timezone for your user account. This setting overrides timezone settings at higher levels.
1. On the left menu, hover your cursor over your avatar and then click **Preferences**.
1. Click to select an option in the **Timezone** list. **Default** is either the browser local timezone or the timezone selected at a higher level. Refer to [Time range controls]({{< relref "../../dashboards/time-range-controls/" >}}) for more information about Grafana time settings.
1. Click **Save**.
## Change the default home dashboard
The home dashboard you set is the one all users will see by default when they log in. You can set the home dashboard for the server, an organization, a team, or your personal user account. This topic provides instructions for each task.
Some tasks require certain permissions. For more information about roles, refer to [Roles and permissions]({{< relref "../roles-and-permissions/" >}}).
@@ -43,6 +43,16 @@ Apps can also add custom pages for things like control panels.
Use app plugins when you want to create an custom out-of-the-box monitoring experience.
### Managing app plugins access
With [RBAC]({{< relref "../roles-and-permissions/access-control/#about-rbac" >}}), it is now possible to customize access to app plugins.
By default, Viewers, Editors and Admins have access to all App Plugins that their organization role allows them to access, thanks to the `fixed:plugins.app:reader` role.
> **Note:** Revoking this RBAC role from some users, will prevent them from accessing app plugins. But granting this RBAC role to users will only allow them to see app plugins their organization role allows them to see.
To prevent users from seeing an app plugin, refer to [this permissions scenarios]({{< relref "../roles-and-permissions/access-control/plan-rbac-rollout-strategy#prevent-viewers-from-accessing-an-app-plugin" >}}).
## Plugin catalog
The Plugin catalog allows you to browse and manage plugins from within Grafana. Only Grafana server administrators and organization administrators can access and use the plugin catalog. The following access rules apply depending on the user role:
You can manage plugins in Grafana by adding one or more YAML config files in the [`provisioning/plugins`]({{< relref "../../setup-grafana/configure-grafana/#provisioning" >}}) directory. Each config file can contain a list of `apps` that will be updated during start up. Grafana updates each app to match the configuration file.
You can manage plugin applications in Grafana by adding one or more YAML config files in the [`provisioning/plugins`]({{< relref "../../setup-grafana/configure-grafana/#provisioning" >}}) directory. Each config file can contain a list of `apps` that will be updated during start up. Grafana updates each app to match the configuration file.
> **Note:** This feature enables you to provision plugin configurations, not the plugins themselves.
> The plugins must already be installed on the grafana instance
A _user_ is defined as any individual who can log in to Grafana. Each user is associated with a _role_ that includes _permissions_. Permissions determine the tasks a user can perform in the system. For example, the **Admin** role includes permissions for an administrator to create and delete users.
A _user_ is any individual who can log in to Grafana. Each user is associated with a _role_ that includes _permissions_. Permissions determine the tasks a user can perform in the system. For example, the **Admin** role includes permissions for an administrator to create and delete users.
You can assign a user one of three types of permissions:
@@ -92,16 +92,18 @@ The following table lists permissions for each role.
## Dashboard permissions
When you want to extend a viewer's ability to edit and save dashboard changes or limit an editor's permission to modify a dashboard, you can assign permissions to dashboards and dashboard folders. For example, you might want a certain viewer to be able to to edit a dashboard. While that user can _see_ all dashboards, you can grant them access to _update_ only one of them.
When you want to extend a viewer's ability to edit and save dashboard changes or limit an editor's permission to modify a dashboard, you can assign permissions to dashboards and dashboard folders. For example, you might want a certain viewer to be able to edit a dashboard. While that user can _see_ all dashboards, you can grant them access to _update_ only one of them.
> Important: The dashboard permissions you specify override the organization permissions you assign to the user for the selected entity.
You can specify the following permissions to dashboards and folders.
- **Admin**: Can create, edit, or delete a dashboard or folder. Administrators can also change dashboard and folder permissions.
- **Edit**: Can create and edit dashboards. Editors _cannot_ change folder or dashboard permissions, or add, edit, or delete folders.
- **Admin**: Can create, edit, or delete a dashboard. Can edit or delete a folder. Administrators can also change dashboard and folder permissions.
- **Edit**: Can create, edit, or delete a dashboard. Can edit or delete a folder. Editors _cannot_ change folder or dashboard permissions.
- **View**: Can only view dashboards and folders.
> Important: When a user creates a dashboard or a folder, he is set as **Admin** of it.
For more information about assigning dashboard folder permissions, refer to [Grant dashboard folder permissions]({{< relref "../user-management/manage-dashboard-permissions/#grant-dashboard-folder-permissions" >}}).
For more information about assigning dashboard permissions, refer to [Grant dashboard permissions]({{< relref "../user-management/manage-dashboard-permissions/#grant-dashboard-permissions" >}}).
> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
RBAC provides a standardized way of granting, changing, and revoking access when it comes to viewing and modifying Grafana resources, such as dashboards, reports, and administrative settings.
> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
In this topic you'll learn how to use the role picker, provisioning, and the HTTP API to assign fixed and custom roles to users and teams.
## Assign fixed roles in the UI using the role picker
This section describes how to:
- Assign a fixed role to a user or team as an organization administrator.
- Assign a fixed role to a user, team or service account as an organization administrator.
- Assign a fixed role to a user as a server administrator. This approach enables you to assign a fixed role to a user in multiple organizations, without needing to switch organizations.
In both cases, the assignment applies only to the user or team within the affected organization, and no other organizations. For example, if you grant the user the **Data source editor** role in the **Main** organization, then the user can edit data sources in the **Main** organization, but not in other organizations.
> **Note:** After you apply your changes, user and team permissions update immediately, and the UI reflects the new permissions the next time they reload their browser or visit another page.
In both cases, the assignment applies only to the user, team or service account within the affected organization, and no other organizations. For example, if you grant the user the **Data source editor** role in the **Main** organization, then the user can edit data sources in the **Main** organization, but not in other organizations.
<br/>
**Before you begin:**
- [Plan your RBAC rollout strategy]({{< relref "./plan-rbac-rollout-strategy/" >}}).
- Identify the fixed roles that you want to assign to the user or team.
- Identify the fixed roles that you want to assign to the user, team or service account.
For more information about available fixed roles, refer to [RBAC role definitions]({{< relref "./rbac-fixed-basic-role-definitions/" >}}).
- Ensure that your own user account has the correct permissions:
- If you are assigning permissions to a user or team within an organization, you must have organization administrator or server administrator permissions.
- If you are assigning permissions to a user, team or service account within an organization, you must have organization administrator or server administrator permissions.
- If you are assigning permissions to a user who belongs to multiple organizations, you must have server administrator permissions.
- Your Grafana user can also assign fixed role if it has either the `fixed:roles:writer` fixed role assigned to the same organization to which you are assigning RBAC to a user, or a custom role with `users.roles:add` and `users.roles:remove` permissions.
- Your own user account must have the roles you are granting. For example, if you would like to grant the `fixed:users:writer` role to a team, you must have that role yourself.
<br/>
**To assign a fixed role to a user or team:**
**To assign a fixed role to a user, team or service account:**
1. Sign in to Grafana.
2. Switch to the organization that contains the user or team.
2. Switch to the organization that contains the user, team or service account.
For more information about switching organizations, refer to [Switch organizations]({{< relref "../../user-management/user-preferences/_index.md#switch-organizations" >}}).
3. Hover your cursor over **Configuration** (the gear icon) in the left navigation menu, and click **Users** or **Teams**.
4. In the **Role** column, select the fixed role that you want to assign to the user or team.
3. Hover your cursor over **Configuration** (the gear icon) in the left navigation menu, and click **Users** or **Teams** or **Service Accounts**.
4. In the **Role** column, select the fixed role that you want to assign to the user, team or service account.
5. Click **Update**.

> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
The table below describes all RBAC configuration options. Like any other Grafana configuration, you can apply these options as [environment variables]({{< relref "../../../setup-grafana/configure-grafana/#configure-with-environment-variables" >}}).
> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
A permission is comprised of an action and a scope. When creating a custom role, consider the actions the user can perform and the resource(s) on which they can perform those actions.
To learn more about the Grafana resources to which you can apply RBAC, refer to [Resources with RBAC permissions]({{< relref "../#fixed-roles" >}}).
@@ -77,7 +79,7 @@ The following list contains role-based access control actions.
| `licensing:write` | n/a | Update the license token. |
| `org.users:write` | `users:*` <br> `users:id:*` | Update the organization role (`Viewer`, `Editor`, or `Admin`) of a user. |
| `org.users:add` | `users:*` | Add a user to an organization. |
| `org.users:add` | `users:*` | Add a user to an organization or invite a new user to an organization. |
| `org.users:read` | `users:*` <br> `users:id:*` | Get user profiles within an organization. |
| `org.users:remove` | `users:*` <br> `users:id:*` | Remove a user from an organization. |
| `org:create` | n/a | Create an organization. |
@@ -88,6 +90,7 @@ The following list contains role-based access control actions.
| `orgs:delete` | `orgs:*` <br> `orgs:id:*` | Delete one or more organizations. |
| `orgs:read` | `orgs:*` <br> `orgs:id:*` | Read one or more organizations. |
| `orgs:write` | `orgs:*` <br> `orgs:id:*` | Update one or more organizations. |
| `plugins.app:access` | `plugins:*` <br> `plugins:id:*` | Access one or more application plugins (still enforcing the organization role) |
| `provisioning:reload` | `provisioners:*` | Reload provisioning files. To find the exact scope for specific provisioner, see [Scope definitions]({{< relref "#scope-definitions" >}}). |
| `serviceaccounts:write` | `serviceaccounts:*` | Create Grafana service accounts. |
| `serviceaccounts:create` | n/a | Update Grafana service accounts. |
| `serviceaccounts:delete` | `serviceaccounts:*` | Delete Grafana service accounts. |
| `serviceaccounts:read` | `serviceaccounts:*` | Read Grafana service accounts. |
| `serviceaccounts.permissions:write` | `serviceaccounts:*` | Update Grafana service account permissions to control who can do what with the service account. |
| `serviceaccounts.permissions:read` | `serviceaccounts:*` | Read Grafana service account permissions to see who can do what with the service account. |
| `settings:write` | `settings:*`<br>`settings:auth.saml:*`<br>`settings:auth.saml:enabled` (property level) | Update any Grafana configuration settings that can be [updated at runtime]({{< relref "../../../enterprise/settings-updates/" >}}). |
| `status:accesscontrol` | `services:accesscontrol` | Get access-control enabled status. |
@@ -120,9 +129,9 @@ The following list contains role-based access control actions.
| `annotations:*`<br>`annotations:type:*` | Restrict an action to a set of annotations. For example, `annotations:*` matches any annotation, `annotations:type:dashboard` matches annotations associated with dashboards and `annotations:type:organization` matches organization annotations. |
| `apikeys:*`<br>`apikeys:id:*` | Restrict an action to a set of API keys. For example, `apikeys:*` matches any API key, `apikey:id:1` matches the API key whose id is `1`. |
| `dashboards:*`<br>`dashboards:uid:*` | Restrict an action to a set of dashboards. For example, `dashboards:*` matches any dashboard, and `dashboards:uid:1` matches the dashboard whose UID is `1`. |
| `datasources:*`<br>`datasources:uid:*` | Restrict an action to a set of data sources. For example, `datasources:*` matches any data source, and `datasources:uid:1` matches the data source whose UID is `1`. |
| `folders:*`<br>`folders:uid:*` | Restrict an action to a set of folders. For example, `folders:*` matches any folder, and `folders:uid:1` matches the folder whose UID is `1`. |
| `global.users:*` <br> `global.users:id:*` | Restrict an action to a set of global users. For example, `global.users:*` matches any user and `global.users:id:1` matches the user whose ID is `1`. |
| `orgs:*` <br> `orgs:id:*` | Restrict an action to a set of organizations. For example, `orgs:*` matches any organization and `orgs:id:1` matches the organization whose ID is `1`. |
| `permissions:type:delegate` | The scope is only applicable for roles associated with the Access Control itself and indicates that you can delegate your permissions only, or a subset of it, by creating a new role or making an assignment. |
| `permissions:type:escalate` | The scope is required to trigger the reset of basic roles permissions. It indicates that users might acquire additional permissions they did not previously have. |
| `provisioners:*` | Restrict an action to a set of provisioners. For example, `provisioners:*` matches any provisioner, and `provisioners:accesscontrol` matches the role-based access control [provisioner]({{< relref "./rbac-provisioning/" >}}). |
| `reports:*` <br> `reports:id:*` | Restrict an action to a set of reports. For example, `reports:*` matches any report and `reports:id:1` matches the report whose ID is `1`. |
| `roles:*` <br> `roles:uid:*` | Restrict an action to a set of roles. For example, `roles:*` matches any role and `roles:uid:randomuid` matches only the role whose UID is `randomuid`. |
| `services:accesscontrol` | Restrict an action to target only the role-based access control service. You can use this in conjunction with the `status:accesscontrol` actions. |
| `settings:*` | Restrict an action to a subset of settings. For example, `settings:*` matches all settings, `settings:auth.saml:*` matches all SAML settings, and `settings:auth.saml:enabled` matches the enable property on the SAML settings. |
| `teams:*` <br> `teams:id:*` | Restrict an action to a set of teams from an organization. For example, `teams:*` matches any team and `teams:id:1` matches the team whose ID is `1`. |
| `users:*` <br> `users:id:*` | Restrict an action to a set of users from an organization. For example, `users:*` matches any user and `users:id:1` matches the user whose ID is `1`. |
| `annotations:*`<br>`annotations:type:*` | Restrict an action to a set of annotations. For example, `annotations:*` matches any annotation, `annotations:type:dashboard` matches annotations associated with dashboards and `annotations:type:organization` matches organization annotations. |
| `apikeys:*`<br>`apikeys:id:*`| Restrict an action to a set of API keys. For example, `apikeys:*` matches any API key, `apikey:id:1` matches the API key whose id is `1`. |
| `dashboards:*`<br>`dashboards:uid:*` | Restrict an action to a set of dashboards. For example, `dashboards:*` matches any dashboard, and `dashboards:uid:1` matches the dashboard whose UID is `1`. |
| `datasources:*`<br>`datasources:uid:*` | Restrict an action to a set of data sources. For example, `datasources:*` matches any data source, and `datasources:uid:1` matches the data source whose UID is `1`. |
| `folders:*`<br>`folders:uid:*`| Restrict an action to a set of folders. For example, `folders:*` matches any folder, and `folders:uid:1` matches the folder whose UID is `1`. |
| `global.users:*` <br> `global.users:id:*` | Restrict an action to a set of global users. For example, `global.users:*` matches any user and `global.users:id:1` matches the user whose ID is `1`. |
| `orgs:*` <br> `orgs:id:*`| Restrict an action to a set of organizations. For example, `orgs:*` matches any organization and `orgs:id:1` matches the organization whose ID is `1`. |
| `permissions:type:delegate`| The scope is only applicable for roles associated with the Access Control itself and indicates that you can delegate your permissions only, or a subset of it, by creating a new role or making an assignment. |
| `permissions:type:escalate`| The scope is required to trigger the reset of basic roles permissions. It indicates that users might acquire additional permissions they did not previously have. |
| `provisioners:*`| Restrict an action to a set of provisioners. For example, `provisioners:*` matches any provisioner, and `provisioners:accesscontrol` matches the role-based access control [provisioner]({{< relref "./rbac-provisioning/" >}}). |
| `reports:*` <br> `reports:id:*`| Restrict an action to a set of reports. For example, `reports:*` matches any report and `reports:id:1` matches the report whose ID is `1`. |
| `roles:*` <br> `roles:uid:*`| Restrict an action to a set of roles. For example, `roles:*` matches any role and `roles:uid:randomuid` matches only the role whose UID is `randomuid`. |
| `services:accesscontrol`| Restrict an action to target only the role-based access control service. You can use this in conjunction with the `status:accesscontrol` actions. |
| `serviceaccounts:*` <br> `serviceaccounts:id:*` | Restrict an action to a set of service account from an organization. For example, `serviceaccounts:*` matches any service account and `serviceaccount:id:1` matches the service account whose ID is `1`. |
| `settings:*`| Restrict an action to a subset of settings. For example, `settings:*` matches all settings, `settings:auth.saml:*` matches all SAML settings, and `settings:auth.saml:enabled` matches the enable property on the SAML settings. |
| `teams:*` <br> `teams:id:*` | Restrict an action to a set of teams from an organization. For example, `teams:*` matches any team and `teams:id:1` matches the team whose ID is `1`. |
| `users:*` <br> `users:id:*` | Restrict an action to a set of users from an organization. For example, `users:*` matches any user and `users:id:1` matches the user whose ID is `1`. |
> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
An RBAC rollout strategy helps you determine _how_ you want to implement RBAC prior to assigning RBAC roles to users and teams.
Your rollout strategy should help you answer the following questions:
@@ -239,3 +241,53 @@ roles:
```
- Or use [RBAC HTTP API]({{< relref "../../../developers/http_api/access_control/#update-a-role" >}}).
### Prevent Viewers from accessing an App Plugin
By default, Viewers, Editors and Admins have access to all App Plugins that their organization role allows them to access.
To change this default behavior and prevent Viewers from accessing an App plugin, you must [update a basic role's permissions]({{< relref "./manage-rbac-roles/#update-basic-role-permissions" >}}).
In this example, three App plugins have been installed and enabled:
| Editor | `fixed:datasources:explorer`<br>`fixed:dashboards:creator`<br>`fixed:folders:creator`<br>`fixed:annotations:writer`<br>`fixed:teams:creator` if the `editors_can_admin` configuration flag is enabled<br>`fixed:alerting:writer` | Default [Editor]({{< relref "../#organization-users-and-permissions" >}}) assignments. |
@@ -61,16 +63,20 @@ The following tables list permissions associated with basic and fixed roles.
| `fixed:licensing:reader` | `licensing:read`<br>`licensing.reports:read` | Read licensing information and licensing reports. |
| `fixed:licensing:writer` | All permissions from `fixed:licensing:viewer` and <br>`licensing:write`<br>`licensing:delete` | Read licensing information and licensing reports, update and delete the license token. |
| `fixed:org.users:reader` | `org.users:read` | Read users within a single organization. |
| `fixed:org.users:writer` | All permissions from `fixed:org.users:reader` and <br>`org.users:add`<br>`org.users:remove`<br>`org.users:write` | Within a single organization, add a user, invite a user, read information about a user and their role, remove a user from that organization, or change the role of a user. |
| `fixed:org.users:writer` | All permissions from `fixed:org.users:reader` and <br>`org.users:add`<br>`org.users:remove`<br>`org.users:write` | Within a single organization, add a user, invite a new user, read information about a user and their role, remove a user from that organization, or change the role of a user. |
| `fixed:organization:maintainer` | All permissions from `fixed:organization:reader` and <br> `orgs:write`<br>`orgs:create`<br>`orgs:delete`<br>`orgs.quotas:write` | Create, read, write, or delete an organization. Read or write its quotas. This role needs to be assigned globally. |
| `fixed:organization:reader` | `orgs:read`<br>`orgs.quotas:read` | Read an organization and its quotas. |
| `fixed:organization:writer` | All permissions from `fixed:organization:reader` and <br> `orgs:write`<br>`orgs.preferences:read`<br>`orgs.preferences:write` | Read an organization, its quotas, or its preferences. Update organization properties, or its preferences. |
| `fixed:reports:reader` | `reports:read`<br>`reports:send`<br>`reports.settings:read` | Read all reports and shared report settings. |
| `fixed:reports:writer` | All permissions from `fixed:reports:reader` and <br>`reports:create`<br>`reports:write`<br>`reports:delete`<br>`reports.settings:write` | Create, read, update, or delete all reports and shared report settings. |
| `fixed:roles:reader` | `roles:read`<br>`teams.roles:read`<br>`users.roles:read`<br>`users.permissions:read` | Read all access control roles, roles and permissions assigned to users, teams. |
| `fixed:roles:writer` | All permissions from `fixed:roles:reader` and <br>`roles:write`<br>`roles:delete`<br>`teams.roles:add`<br>`teams.roles:remove`<br>`users.roles:add`<br>`users.roles:remove` | Create, read, update, or delete all roles, assign or unassign roles to users, teams. |
| `fixed:roles:resetter` | `roles:write` with scope `permissions:type:escalate` | Reset basic roles to their default. |
| `fixed:serviceaccounts:reader` | `serviceaccounts:read` | Read Grafana service accounts. |
| `fixed:serviceaccounts:creator` | `serviceaccounts:create` | Create Grafana service accounts. |
| `fixed:serviceaccounts:writer` | `serviceaccounts:read`<br>`serviceaccounts:create`<br>`serviceaccounts:write`<br>`serviceaccounts:delete`<br>`serviceaccounts.permissions:read`<br>`serviceaccounts.permissions:write` | Create, update, read and delete all Grafana service accounts and manage service account permissions. |
You can create, change or remove [Custom roles]({{< relref "./manage-rbac-roles/#create-custom-roles-using-provisioning" >}}) and create or remove [basic role assignments]({{< relref "./assign-rbac-roles/#assign-a-fixed-role-to-a-basic-role-using-provisioning" >}}), by adding one or more YAML configuration files in the `provisioning/access-control/` directory.
> **Note:** Available in [Grafana Enterprise]({{< relref "../../enterprise/" >}}) and [Grafana Cloud Advanced]({{< ref "/docs/grafana-cloud" >}}).
If you choose to use provisioning to assign and manage role, you must first enable it.
You can create, change or remove [Custom roles]({{< relref "./manage-rbac-roles/#create-custom-roles-using-provisioning" >}}) and create or remove [basic role assignments]({{< relref "./assign-rbac-roles/#assign-a-fixed-role-to-a-basic-role-using-provisioning" >}}), by adding one or more YAML configuration files in the `provisioning/access-control/` directory.
Grafana performs provisioning during startup. After you make a change to the configuration file, you can reload it during runtime. You do not need to restart the Grafana server for your changes to take effect.
You can use service accounts to run automated or compute workloads.
You can use a service account to run automated workloads in Grafana, such as dashboard provisioning, configuration, or report generation. Create service accounts and tokens to authenticate applications, such as Terraform, with the Grafana API.
{{< section >}}
## About service accounts
A service account can be used to run automated workloads in Grafana, like dashboard provisioning, configuration, or report generation. Create service accounts and tokens to authenticate applications like Terraform with the Grafana API.
> **Note:** Service accounts are available in Grafana 8.5+ as a beta feature. To enable service accounts, refer to the [Enable service accounts]({{< ref "#enable-service-accounts" >}}) section. Service accounts will eventually replace [API keys]({{< relref "../api-keys/" >}}) as the primary way to authenticate applications that interact with Grafana.
> **Note:** Service accounts will eventually replace [API keys]({{< relref "../api-keys/" >}}) as the primary way to authenticate applications that interact with Grafana.
A common use case for creating a service account is to perform operations on automated or triggered tasks. You can use service accounts to:
@@ -59,47 +53,16 @@ The added benefits of service accounts to API keys include:
- Unlike API keys, service account tokens are not associated with a specific user, which means that applications can be authenticated even if a Grafana user is deleted.
- You can grant granular permissions to service accounts by leveraging [role-based access control]({{< relref "../roles-and-permissions/access-control/" >}}). For more information about permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/" >}}).
## Enable service accounts in Grafana
Service accounts are available behind the `serviceAccounts` feature toggle, available in Grafana 8.5+.
You can enable service accounts by:
- modifying the Grafana configuration file, or
- configuring an environment variable
### Enable service accounts in the Grafana configuration file
This topic shows you how to enable service accounts by modifying the Grafana configuration file.
1. Sign in to the Grafana server and locate the configuration file. For more information about finding the configuration file, refer to LINK.
2. Open the configuration file and locate the [feature toggles section]({{< relref "../../setup-grafana/configure-grafana/#feature_toggles" >}}). Add `serviceAccounts` as a [feature_toggle]({{< relref "../../setup-grafana/configure-grafana/#feature_toggle" >}}).
```
[feature_toggles]
# enable features, separated by spaces
enable = serviceAccounts
```
1. Save your changes, Grafana should recognize your changes; in case of any issues we recommend restarting the Grafana server.
### Enable service accounts with an environment variable
This topic shows you how to enable service accounts by setting environment variables before starting Grafana.
Follow the instructions to [override configuration with environment variables]({{< relref "../../setup-grafana/configure-grafana/#override-configuration-with-environment-variables" >}}). Set the following environment variable: `GF_FEATURE_TOGGLES_ENABLE = serviceAccounts`.
A service account can be used to run automated workloads in Grafana, like dashboard provisioning, configuration, or report generation. For more information about how you can use service accounts, refer to [About service accounts]({{< ref "#about-service-accounts" >}}).
For more information about creating service accounts via the API, refer to [Create a service account in the HTTP API]({{< relref "../../developers/http_api/serviceaccount/#create-service-account" >}}).
Note that the user who created a service account will also be able to read, update and delete the service account that they created, as well as permissions associated with that service account.
### Before you begin
- Ensure you have added the feature toggle for service accounts `serviceAccounts`. For more information about adding the feature toggle, refer to [Enable service accounts]({{< ref "#enable-service-accounts" >}}).
- Ensure you have permission to create and edit service accounts. By default, the organization administrator role is required to create and edit service accounts. For more information about user permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/#" >}}).
### To create a service account
@@ -121,7 +84,6 @@ You can create a service account token using the Grafana UI or via the API. For
### Before you begin
- Ensure you have added the `serviceAccounts` feature toggle to Grafana. For more information about adding the feature toggle, refer to [Enable service accounts]({{< ref "#enable-service-accounts" >}}).
- Ensure you have permission to create and edit service accounts. By default, the organization administrator role is required to create and edit service accounts. For more information about user permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/#" >}}).
### To add a token to a service account
@@ -135,3 +97,56 @@ You can create a service account token using the Grafana UI or via the API. For
- The expiry date specifies how long you want the key to be valid.
- If you are unsure of an expiration date, we recommend that you set the token to expire after a short time, such as a few hours or less. This limits the risk associated with a token that is valid for a long time.
1. Click **Generate service account token**.
## Assign roles to a service account in Grafana
You can assign roles to a Grafana service account to control access for the associated service account tokens.
You can assign roles to a service account using the Grafana UI or via the API. For more information about assigning a role to a service account via the API, refer to [Update service account using the HTTP API]({{< relref "../../developers/http_api/serviceaccount/#update-service-account" >}}).
In [Grafana Enterprise]({{< relref "../../enterprise/" >}}), you can also [assign RBAC roles]({{< relref "../roles-and-permissions/access-control/assign-rbac-roles" >}}) to grant very specific permissions to applications that interact with Grafana.
### Before you begin
- Ensure you have permission to update service accounts roles. By default, the organization administrator role is required to update service accounts permissions. For more information about user permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/#" >}}).
### To assign a role to a service account
1. Sign in to Grafana, then hover your cursor over **Configuration** (the gear icon) in the sidebar.
1. Click **Service accounts**.
1. Click the service account to which you want to assign a role. As an alternative, find the service account in the list view.
1. Assign a role using the role picker.
1. Click **Update**.
## Manage users and teams permissions for a service account in Grafana
To control what and who can do with the service account you can assign permissions directly to users and teams. You can assign permissions using the Grafana UI.
### Before you begin
- Ensure you have permission to update user and team permissions of a service accounts. By default, the organization administrator role is required to update user and teams permissions for a service account. For more information about user permissions, refer to [About users and permissions]({{< relref "../roles-and-permissions/#" >}}).
- Ensure you have permission to read teams.
### User and team permissions for a service account
You can assign on of the following permissions to a specific user or a team:
1. **Edit**: A user or a team with this permission can view, edit, enable and disable a service account, and add or delete service account tokens.
1. **Admin**: User or a team with this permission will be able to everything from **Edit** permission, as well as manage user and team permissions for a service account.
### To update team permissions for a service account
1. Sign in to Grafana, then hover your cursor over **Configuration** (the gear icon) in the sidebar.
1. Click **Service accounts**.
1. Click the service account for which you want to update team permissions a role.
1. In the **Permissions** section at the bottom, click **Add permission**.
1. Choose **Team** in the dropdown and select your desired team.
1. Choose **View**, **Edit** or **Admin** role in the dropdown and click **Save**.
### To update user permissions for a service account
1. Sign in to Grafana, then hover your cursor over **Configuration** (the gear icon) in the sidebar.
1. Click **Service accounts**.
1. Click the service account for which you want to update team permissions a role.
1. In the **Permissions** section at the bottom, click **Add permission**.
1. Choose **User** in the dropdown and select your desired user.
1. Choose **View**, **Edit** or **Admin** role in the dropdown and click **Save**.
Grafana Alerting allows you to learn about problems in your systems moments after they occur. Create, manage, and take action on your alerts in a single, consolidated view, and improve your team’s ability to identify and resolve issues quickly.
Grafana Alerting is available for for Grafana OSS, Grafana Enterprise, or Grafana Cloud. With Mimir and Loki alert rules you can run alert expressions closer to your data and at massive scale, all managed by the Grafana UI you are already familiar with.
Grafana Alerting is available for Grafana OSS, Grafana Enterprise, or Grafana Cloud. With Mimir and Loki alert rules you can run alert expressions closer to your data and at massive scale, all managed by the Grafana UI you are already familiar with.
Watch this video to learn more about Grafana Alerting: {{< vimeo 720001629 >}}
@@ -69,4 +69,4 @@ With mute timings, you can specify a time interval when you don’t want new not
- [Role-based access control]({{< relref "../administration/roles-and-permissions/access-control/" >}}) in Grafana Enterprise.
@@ -21,7 +21,7 @@ As an example, if the current Prometheus version is `2.31.1`, we support >= `2.2
## Grafana is not an alert receiver
Grafana is not an alert receiver; is it an alert generator. This means that Grafana cannot receive alerts from anything other than its internal alert generator.
Grafana is not an alert receiver; it is an alert generator. This means that Grafana cannot receive alerts from anything other than its internal alert generator.
Receiving alerts from Prometheus (or anything else) is not supported at the time.
Grafana allows you to create alerting rules that query one or more data sources, reduce or transform the results and compare them to each other or to fix thresholds. When these are executed, Grafana sends notifications to the contact point. For information on Grafana Alerting, see [About Grafana Alerting]({{< relref "../about-alerting/" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
Grafana allows you to create alerting rules that query one or more data sources, reduce or transform the results and compare them to each other or to fix thresholds. When these are executed, Grafana sends notifications to the contact point. For information on Grafana Alerting, see [About Grafana Alerting]({{< relref "../" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
Watch this video to learn more about creating alerts: {{< vimeo 720001934 >}}
@@ -27,7 +27,7 @@ You can create and manage recording rules for an external Grafana Mimir or Loki
- **Loki** - The `local` rule storage type, default for the Loki data source, supports only viewing of rules. To edit rules, configure one of the other rule storage types.
- **Grafana Mimir** - use the [legacy `/api/prom` prefix](https://grafana.com/docs/mimir/latest/operators-guide/reference-http-api/#path-prefixes), not `/prometheus`. The Prometheus data source supports both Grafana Mimir and Prometheus, and Grafana expects that both the [Query API](https://grafana.com/docs/mimir/latest/operators-guide/reference-http-api/#querier--query-frontend) and [Ruler API](https://grafana.com/docs/mimir/latest/operators-guide/reference-http-api/#ruler) are under the same URL. You cannot provide a separate URL for the Ruler API.
- **Grafana Mimir** - use the `/prometheus` prefix. The Prometheus data source supports both Grafana Mimir and Prometheus, and Grafana expects that both the [Query API](https://grafana.com/docs/mimir/latest/operators-guide/reference-http-api/#querier--query-frontend) and [Ruler API](https://grafana.com/docs/mimir/latest/operators-guide/reference-http-api/#ruler) are under the same URL. You cannot provide a separate URL for the Ruler API.
> **Note:** If you do not want to manage alerting rules for a particular Loki or Prometheus data source, go to its settings and clear the **Manage alerts via Alerting UI** checkbox.
# Create a Grafana Mimir or Loki managed alerting rule
Grafana allows you to create alerting rules for an external Grafana Mimir or Loki instance that has ruler API enabled. For information on Grafana Alerting, see [About Grafana Alerting]({{< relref "../about-alerting/" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
Grafana allows you to create alerting rules for an external Grafana Mimir or Loki instance that has ruler API enabled. For information on Grafana Alerting, see [About Grafana Alerting]({{< relref "../" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
@@ -20,7 +20,7 @@ Use contact points to define how your contacts are notified when an alert fires.
You can configure Grafana managed contact points as well as contact points for an [external Alertmanager data source]({{< relref "../../datasources/alertmanager/" >}}). For more information, see [Alertmanager]({{< relref "../fundamentals/alertmanager/" >}}).
Before you begin, see [About Grafana Alerting]({{< relref "../about-alerting/" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
Before you begin, see [Grafana Alerting]({{< relref "../../alerting/" >}}) which explains the various components of Grafana Alerting. We also recommend that you familiarize yourself with some of the [fundamental concepts]({{< relref "../fundamentals/" >}}) of Grafana Alerting.
Annotations and labels are key value pairs associated with alerts originating from the alerting rule, datasource response, and as a result of alerting rule evaluation. They can be used in alert notifications directly or in [templates]({{< relref "../../contact-points/message-templating/" >}}) and [template functions]({{< relref "../../contact-points/message-templating/template-functions/" >}}) to create notification contact dynamically.
Annotations and labels are key value pairs associated with alerts originating from the alerting rule, datasource response, and as a result of alerting rule evaluation. They can be used in alert notifications directly or in [templates]({{< relref "../../contact-points/message-templating/" >}}) and [template functions]({{< relref "../../contact-points/fundamentals/annotation-label/template-functions/" >}}) to create notification contact dynamically.
@@ -26,6 +26,7 @@ This topic explains why labels are a fundamental component of alerting.
# Grafana reserved labels
> **Note:** Labels prefixed with `grafana_` are reserved by Grafana for special use. If a manually configured label is added beginning with `grafana_` it may be overwritten in case of collision.
> To stop the Grafana Alerting engine from adding a reserved label, you can disable it via the `disabled_labels` option in [unified_alerting.reserved_labels]({{< relref "../../../setup-grafana/configure-grafana/#unified_alertingreserved_labels" >}}) configuration.
Grafana reserved labels can be used in the same way as manually configured labels. The current list of available reserved labels are:
There are a number of data sources that are compatible with Grafana Alerting. Each data source is supported by a plugin. You can use one of the built-in data sources listed below, use [external data source plugins](https://grafana.com/grafana/plugins/?type=datasource), or create your own data source plugin.
If you are creating your own data source plugin, make sure it is a backend plugin as Grafana Alerting requires this in order to be able to evaluate rules using the data source. Frontend data sources are not supported, because the evaluation engine runs on the backend.
Specifying { "alerting": true, “backend”: true } in the plugin.json file indicates that the data source plugin is compatible with Grafana Alerting and includes the backend data-fetching code. For more information, refer to [Build a data source backend plugin](https://grafana.com/tutorials/build-a-data-source-backend-plugin/).
These are the data sources that are compatible with and supported by Grafana Alerting.
Images in notifications helps recipients of alert notifications better understand why an alert has fired or resolved by including an image of the panel for the Grafana managed alert rule.
Images in notifications helps recipients of alert notifications better understand why an alert has fired or resolved by including an image of the panel associated with the Grafana managed alert rule.
> **Note**: Images in notifications are not available for Grafana Mimir and Loki managed alert rules, or when Grafana is set up to send alert notifications to an external Alertmanager.
@@ -20,6 +20,8 @@ If Grafana is set up to send images in notifications, it takes a screenshot of t
1. The alert rule transitions from pending to firing
2. The alert rule transitions from firing to OK
Grafana does not support images for alert rules that are not associated with a panel. An alert rule is associated with a panel when it has both Dashboard UID and Panel ID annotations.
Images are stored in the [data]({{< relref "../setup-grafana/configure-grafana/#paths" >}}) path and so Grafana must have write-access to this path. If Grafana cannot write to this path then screenshots cannot be saved to disk and an error will be logged for each failed screenshot attempt. In addition to storing images on disk, Grafana can also store the image in an external image store such as Amazon S3, Azure Blob Storage, Google Cloud Storage and even Grafana where screenshots are stored in `public/img/attachments`. Screenshots older than `temp_data_lifetime` are deleted from disk but not the external image store. If Grafana is the external image store then screenshots are deleted from `data` but not from `public/img/attachments`.
> **Note**: It is recommended that you use an external image store, as not all contact points support uploading images from disk. It is also possible that the image on disk is deleted before an alert notification is sent if `temp_data_lifetime` is less than the `group_wait` and `group_interval` options used in Alertmanager.
@@ -32,8 +34,8 @@ To use images in notifications, Grafana must be set up to use [image rendering](
If Grafana has been set up to use [image rendering]({{< relref "../setup-grafana/image-rendering/" >}}) images in notifications can be turned on via the `capture` option in `[unified_alerting.screenshots]`:
# Enable screenshots in notifications. This option requires a remote HTTP image rendering service. Please
# see [rendering] for further configuration options.
# Enable screenshots in notifications. This option requires the Grafana Image Renderer plugin.
# For more information on configuration options, refer to [rendering].
capture = true
It is recommended that `max_concurrent_screenshots` is set to a value that is less than or equal to `concurrent_render_request_limit`. The default value for both `max_concurrent_screenshots` and `concurrent_render_request_limit` is `5`:
@@ -69,7 +71,7 @@ Images in notifications are supported in the following notifiers and additional
Grafana Alerting is enabled by default for new installations or existing installations whether or not legacy alerting is configured.
> **Note**: We recommend that Grafana Enterprise customers with more than a dozen Grafana dashboard alert rules do not upgrade and remain on legacy alerting for now by [opting out]({{< relref "opt-out/" >}}). If you do want to upgrade to Grafana Alerting, contact customer support.
> **Note**: When upgrading, your dashboard alerts are migrated to a new format. This migration can be rolled back easily by [opting out]({{< relref "opt-out/" >}}). If you have any questions regarding this migration, please contact us.
Existing installations that do not use legacy alerting will have Grafana Alerting enabled by default unless alerting is disabled in the configuration.
When Grafana Alerting is enabled or upgraded to Grafana 9.0 or later, existing legacy dashboard alerts migrate in a format compatible with the Grafana Alerting. In the Alerting page of your Grafana instance, you can view the migrated alerts alongside any new alerts.
This topic explains how legacy dashboard alerts are migrated and some limitations of the migration.
There are some differences between Grafana Alerting and legacy dashboard alerts, and a number of features that are no
longer supported. We refer to these as [Differences]({{< relref "#differences" >}}) and [Limitations]({{< relref "#limitations" >}}).
> **Note:** This topic is only relevant for OSS and Enterprise customers. Contact customer support to enable or disable Grafana Alerting for your Cloud stack.
## Differences
Read and write access to legacy dashboard alerts and Grafana alerts are governed by the permissions of the folders storing them. During migration, legacy dashboard alert permissions are matched to the new rules permissions as follows:
1. When Grafana Alerting is enabled or upgraded to Grafana 9.0 or later, existing legacy dashboard alerts migrate in a format compatible with the Grafana Alerting. In the Alerting page of your Grafana instance, you can view the migrated alerts alongside any new alerts.
This topic explains how legacy dashboard alerts are migrated and some limitations of the migration.
2. Read and write access to legacy dashboard alerts and Grafana alerts are governed by the permissions of the folders storing them. During migration, legacy dashboard alert permissions are matched to the new rules permissions as follows:
- If alert's dashboard has permissions, it will create a folder named like `Migrated {"dashboardUid": "UID", "panelId": 1, "alertId": 1}` to match permissions of the dashboard (including the inherited permissions from the folder).
- If there are no dashboard permissions and the dashboard is under a folder, then the rule is linked to this folder and inherits its permissions.
- If there are no dashboard permissions and the dashboard is under the General folder, then the rule is linked to the `General Alerting` folder, and the rule inherits the default permissions.
> **Note:** Since there is no `Keep Last State` option for [`No Data`]({{< relref "../alerting-rules/create-grafana-managed-rule/#no-data--error-handling" >}}) in Grafana Alerting, this option becomes `NoData` during the legacy rules migration. Option "Keep Last State" for [`Error handling`]({{< relref "../alerting-rules/create-grafana-managed-rule/#no-data--error-handling" >}}) is migrated to a new option `Error`. To match the behavior of the `Keep Last State`, in both cases, during the migration Grafana automatically creates a [silence]({{< relref "../silences/" >}}) for each alert rule with a duration of 1 year.
3. Since there is no `Keep Last State` option for [`No Data`]({{< relref "../alerting-rules/create-grafana-managed-rule/#no-data--error-handling" >}}) in Grafana Alerting, this option becomes `NoData` during the legacy rules migration. Option "Keep Last State" for [`Error handling`]({{< relref "../alerting-rules/create-grafana-managed-rule/#no-data--error-handling" >}}) is migrated to a new option `Error`. To match the behavior of the `Keep Last State`, in both cases, during the migration Grafana automatically creates a [silence]({{< relref "../silences/" >}}) for each alert rule with a duration of 1 year.
Notification channels are migrated to an Alertmanager configuration with the appropriate routes and receivers. Default notification channels are added as contact points to the default route. Notification channels not associated with any Dashboard alert go to the `autogen-unlinked-channel-recv` route.
4. Notification channels are migrated to an Alertmanager configuration with the appropriate routes and receivers. Default notification channels are added as contact points to the default route. Notification channels not associated with any Dashboard alert go to the `autogen-unlinked-channel-recv` route.
5. Unlike legacy dashboard alerts where images in notifications are enabled per contact point, images in notifications for Grafana Alerting must be enabled in the Grafana configuration, either in the configuration file or environment variables, and are enabled for either all or no contact points. Please refer to the [documentation for images in notifications]({{< relref "../images-in-notifications" >}}).
## Limitations
Since `Hipchat` and `Sensu` notification channels are no longer supported, legacy alerts associated with these channels are not automatically migrated to Grafana Alerting. Assign the legacy alerts to a supported notification channel so that you continue to receive notifications for those alerts.
Silences (expiring after one year) are created for all paused dashboard alerts.
1. Since `Hipchat` and `Sensu` notification channels are no longer supported, legacy alerts associated with these channels are not automatically migrated to Grafana Alerting. Assign the legacy alerts to a supported notification channel so that you continue to receive notifications for those alerts.
Silences (expiring after one year) are created for all paused dashboard alerts.
When linking to a silence form, provide the default matching labels and comment via `matchers` and `comment` query parameters. The `matchers` parameter requires one more matching labels of the type`[label][operator][value]`joined by a comma while the `operator` parameter can be one of the following: `=` (equals, not regex), `!=` (not equals, not regex), `=~` (equals, regex), `!~` (not equals, regex).
For example, to link to silence form with matching labels `severity=critical` & `cluster!~europe-.*` and comment `Silence critical EU alerts`, create a URL `https://mygrafana/alerting/silence/new?matchers=severity%3Dcritical%2Ccluster!~europe-*&comment=Silence%20critical%20EU%20alert`.
When linking to a silence form, provide the default matching labels and comment via `matcher` and `comment` query parameters. The `matcher` parameter should be in the following format`[label][operator][value]`where the `operator` parameter can be one of the following: `=` (equals, not regex), `!=` (not equals, not regex), `=~` (equals, regex), `!~` (not equals, regex).
The URL can contain many query parameters with the key `matcher`.
For example, to link to silence form with matching labels `severity=critical` & `cluster!~europe-.*` and comment `Silence critical EU alerts`, create a URL `https://mygrafana/alerting/silence/new?matcher=severity%3Dcritical&matcher=cluster!~europe-*&comment=Silence%20critical%20EU%20alert`.
To link to a new silence page for an [external Alertmanager]({{< relref "../../datasources/alertmanager/" >}}), add a `alertmanager` query parameter with the Alertmanager data source name.
@@ -51,6 +51,6 @@ Once you have a strategy or design guidelines, write them down to help maintain
- Use the left and right Y-axes when displaying time series with different units or ranges.
- Add documentation to dashboards and panels.
- To add documentation to a dashboard, add a [Text panel visualization]({{< relref "../visualizations/text-panel/" >}}) to the dashboard. Record things like the purpose of the dashboard, useful resource links, and any instructions users might need to interact with the dashboard. Check out this [Wikimedia example](https://grafana.wikimedia.org/d/000000066/resourceloader?orgId=1).
- To add documentation to a panel, [edit the panel settings]({{< relref "../panels/working-with-panels/add-panel/" >}}) and add a description. Any text you add will appear if you hover your cursor over the small `i` in the top left corner of the panel.
- To add documentation to a panel, edit the panel settings and add a description. Any text you add will appear if you hover your cursor over the small `i` in the top left corner of the panel.
- Reuse your dashboards and enforce consistency by using [templates and variables]({{< relref "../variables/" >}}).
- Be careful with stacking graph data. The visualizations can be misleading, and hide important data. We recommend turning it off in most cases.
@@ -31,9 +31,9 @@ What is your dashboard maturity level? Analyze your current dashboard setup and
- If you create a temporary dashboard, perhaps to test something, prefix the name with `TEST: `. Delete the dashboard when you are finished.
- Copying dashboards with no significant changes is not a good idea.
- You miss out on updates to the original dashboard, such as documentation changes, bug fixes, or additions to metrics.
- In many cases copies are being made to simply customize the view by setting template parameters. This should instead be done by maintaining a link to the master dashboard and customizing the view with [URL parameters]({{< relref "../linking/data-link-variables/" >}}).
- In many cases copies are being made to simply customize the view by setting template parameters. This should instead be done by maintaining a link to the master dashboard and customizing the view with [URL parameters]({{< relref "../panels/configure-data-links/#data-link-variables" >}}).
- When you must copy a dashboard, clearly rename it and _do not_ copy the dashboard tags. Tags are important metadata for dashboards that are used during search. Copying tags can result in false matches.
- Maintain a dashboard of dashboards or cross-reference dashboards. This can be done in several ways:
- Create dashboard links, panel, or data links. Links can go to other dashboards or to external systems. For more information, refer to [Linking]({{< relref "../linking/" >}}).
- Create dashboard links, panel, or data links. Links can go to other dashboards or to external systems. For more information, refer to [Manage dashboard links]({{< relref "../dashboards/manage-dashboard-links/" >}}).
- Add a [Dashboard list panel]({{< relref "../visualizations/dashboard-list-panel/" >}}). You can then customize what you see by doing tag or folder searches.
- Add a [Text panel]({{< relref "../visualizations/text-panel/" >}}) and use markdown to customize the display.
This section describes the areas of the Grafana panel editor.
1. Panel header: The header section lists the dashboard in which the panel appears and the following controls:
- **Dashboard settings (gear) icon -** Click to access the dashboard settings.
- **Discard -** Discards changes you have made to the panel since you last saved the dashboard.
- **Save -** Saves changes you made to the panel.
- **Apply -** Applies changes you made and closes the panel editor, returning you to the dashboard. You will have to save the dashboard to persist the applied changes.
1. Visualization preview: The visualization preview section contains the following options:
- **Table view -** Convert any visualization to a table so that you can see the data. Table views are useful for troubleshooting.
- **Fill -** The visualization preview fills the available space. If you change the width of the side pane or height of the bottom pane the visualization changes to fill the available space.
- **Actual -** The visualization preview will have the exact size as the size on the dashboard. If not enough space is available, the visualization will scale down preserving the aspect ratio.
- **Time range controls -** For more information, refer to [Time range controls]({{< relref "time-range-controls/" >}}).
1. Data section: The data section contains tabs where you enter queries, transform your data, and create alert rules (if applicable).
- **Query tab -** Select your data source and enter queries here. For more information, refer to [Add a query]({{< relref "../panels/query-a-data-source/add-a-query/" >}}).
- **Transform tab -** Apply data transformations. For more information, refer to [Transform data]({{< relref "../panels/transform-data/" >}}).
- **Alert tab -** Write alert rules. For more information, refer to [Overview of Grafana 8 alerting]({{< relref "../alerting/" >}}).
1. Panel display options: The display options section contains tabs where you configure almost every aspect of your data visualization.
> Not all options are available for each visualization.
The inspect drawer helps you understand and troubleshoot your panels. You can view the raw data for any panel, export that data to a comma-separated values (CSV) file, view query requests, and export panel and data JSON.
> **Note:** Not all panel types include all tabs. For example, dashboard list panels do not have raw data to inspect, so they do not display the Stats, Data, or Query tabs.
The panel inspector consists of the following options:
1. The panel inspect drawer displays opens a drawer on the right side. Click the arrow in the upper right corner to expand or reduce the drawer pane.
1. **Data tab -** Shows the raw data returned by the query with transformations applied. Field options such as overrides and value mappings are not applied by default.
1. **Stats tab -** Shows how long your query takes and how much it returns.
1. **JSON tab -** Allows you to view and copy the panel JSON, panel data JSON, and data frame structure JSON. This is useful if you are provisioning or administering Grafana.
1. **Query tab -** Shows you the requests to the server sent when Grafana queries the data source.
1. **Error tab -** Shows the error. Only visible when query returns error.
## Create a dashboard and add a panel
Dashboards and panels allow you to show your data in visual form. Each panel needs at least one query to display a visualization.
**Before you begin:**
- Ensure that you have the proper permissions. For more information about permissions, refer to [About users and permissions]({{< relref "../administration/roles-and-permissions/" >}}).
- Identify the dashboard to which you want to add the panel.
- Understand the query language of the target data source.
- Ensure that data source for which you are writing a query has been added. For more information about adding a data source, refer to [Add a data source]({{< relref "../datasources/add-a-data-source/" >}}) if you need instructions.
**To create a dashboard and add a panel**:
1. Sign in to Grafana, hover your cursor over **Dashboard**, and click **+ New Dashboard**.
1. Click **Add a new panel**.
1. In the first line of the **Query** tab, click the drop-down list and select a data source.
1. Write or construct a query in the query language of your data source.
For more information about data sources, refer to [Data sources]({{< relref "../datasources/" >}}) for specific guidelines.
1. In the Visualization list, select a visualization type.
Grafana displays a preview of your query results with the visualization applied.
> **Caution:** Making your dashboard public could result in a large number of queries to the datasources used by your dashboard.
> This can be mitigated by utilizing the enterprise [caching](https://grafana.com/docs/grafana/latest/enterprise/query-caching/) and/or rate limiting features.
Public dashboards allow you to share your Grafana dashboard with anyone. This is useful when you want to expose your
dashboard to the world.
#### Security implications of making your dashboard public
- Anyone with the URL can access the dashboard.
- Public dashboards are read-only.
- Arbitrary queries **cannot** be run against your datasources through public dashboards. Public dashboards can only execute the
queries stored on the original dashboard.
#### Enable the feature
Add the `publicDashboards` feature toggle to your `custom.ini` file.
> **Note:** For Grafana Cloud, you will need to contact support to have the feature enabled.
#### Make a dashboard public
- Click on the sharing icon to the right of the dashboard title.
- Click on the Public Dashboard tab.
- Acknowledge the implications of making the dashboard public by checking all the checkboxes.
- Turn on the Enabled toggle.
- Click `Save Sharing Configuration` to make the dashboard public and make your link live.
- Copy the public dashboard link if you'd like to share it. You can always come back later for it.
#### Revoke access
- Click on the sharing icon to the right of the dashboard title.
- Click on the Public Dashboard tab.
- Turn off the Enabled toggle.
- Click `Save Sharing Configuration` to save your changes.
- Anyone with the link will not be able to access the dashboard publicly anymore.
#### Limitations
- Panels that use frontend datasources will fail to fetch data.
- Template variables are currently not supported, but are planned to be in the future.
- The time range is permanently set to the default time range on the dashboard. If you update the default time range for a dashboard, it will be reflected in the public dashboard.
We are excited to share this enhancement with you and we’d love your feedback! Please check out the [Github](https://github.com/grafana/grafana/discussions/49253) discussion and join the conversation.
When you create a dashboard link, you can include the time range and current template variables to directly jump to the same context in another dashboard. This way, you don’t have to worry whether the person you send the link to is looking at the right data. For other types of links, refer to [Data link variables]({{< relref "data-link-variables/" >}}).
You can use links to navigate between commonly-used dashboards or to connect others to your visualizations. Links let you create shortcuts to other dashboards, panels, and even external websites.
Grafana supports dashboard links, panel links, and data links. Dashboard links are displayed at the top of the dashboard. Panel links are accessible by clicking an icon on the top left corner of the panel.
## Which link should you use?
Start by figuring out how you're currently navigating between dashboards. If you're often jumping between a set of dashboards and struggling to find the same context in each, links can help optimize your workflow.
The next step is to figure out which link type is right for your workflow. Even though all the link types in Grafana are used to create shortcuts to other dashboards or external websites, they work in different contexts.
- If the link relates to most if not all of the panels in the dashboard, use [dashboard links]({{< relref "#dashboard-links" >}}).
- If you want to drill down into specific panels, use [panel links]({{< relref "#panel-links" >}}).
- If you want to link to an external site, you can use either a dashboard link or a panel link.
- If you want to drill down into a specific series, or even a single measurement, use [data links]({{< relref "../../panels/configure-data-links/#data-links" >}}).
## Controlling time range using the URL
You can control the time range of a panel or dashboard by providing following query parameters in dashboard URL:
- `from` - defines lower limit of the time range, specified in ms epoch
- `to` - defines upper limit of the time range, specified in ms epoch
- `time` and `time.window` - defines a time range from `time-time.window/2` to `time+time.window/2`. Both params should be specified in ms. For example `?time=1500000000000&time.window=10000` will result in 10s time range from 1499999995000 to 1500000005000
## Dashboard links
When you create a dashboard link, you can include the time range and current template variables to directly jump to the same context in another dashboard. This way, you don’t have to worry whether the person you send the link to is looking at the right data. For other types of links, refer to [Data link variables]({{< relref "../../panels/configure-data-links/#data-link-variables/" >}}).
Dashboard links can also be used as shortcuts to external systems, such as submitting [a GitHub issue with the current dashboard name](https://github.com/grafana/grafana/issues/new?title=Dashboard%3A%20HTTP%20Requests).
@@ -25,7 +58,7 @@ To see an example of dashboard links in action, check out:
Once you've added a dashboard link, it appears in the upper right corner of your dashboard.
## Add links to dashboards
### Add links to dashboards
Add links to other dashboards at the top of your current dashboard.
@@ -40,7 +73,7 @@ Add links to other dashboards at the top of your current dashboard.
- **Open in new tab**– Select this option if you want the dashboard link to open in a new tab or window.
1. Click **Add**.
## Add a URL link to a dashboard
### Add a URL link to a dashboard
Add a link to a URL at the top of your current dashboard. You can link to any available URL, including dashboards, panels, or external sites. You can even control the time range to ensure the user is zoomed in on the right data in Grafana.
@@ -60,7 +93,7 @@ Add a link to a URL at the top of your current dashboard. You can link to any av
- **Open in new tab**– Select this option if you want the dashboard link to open in a new tab or window.
1. Click **Add**.
## Update a dashboard link
### Update a dashboard link
To change or update an existing dashboard link, follow this procedure.
@@ -71,6 +104,43 @@ To change or update an existing dashboard link, follow this procedure.
To duplicate an existing dashboard link, click the duplicate icon next to the existing link that you want to duplicate.
## Delete a dashboard link
### Delete a dashboard link
To delete an existing dashboard link, click the trash icon next to the duplicate icon that you want to delete.
## Panel links
Each panel can have its own set of links that are shown in the upper left corner of the panel. You can link to any available URL, including dashboards, panels, or external sites. You can even control the time range to ensure the user is zoomed in on the right data in Grafana.
Click the icon on the top left corner of a panel to see available panel links.
1. Hover your cursor over the panel that you want to add a link to and then press `e`. Or click the dropdown arrow next to the panel title and then click **Edit**.
1. On the Panel tab, scroll down to the Links section.
1. Expand Links and then click **Add link**.
1. Enter a **Title**. **Title** is a human-readable label for the link that will be displayed in the UI.
1. Enter the **URL** you want to link to.
You can even add one of the template variables defined in the dashboard. Press Ctrl+Space or Cmd+Space and click in the **URL** field to see the available variables. By adding template variables to your panel link, the link sends the user to the right context, with the relevant variables already set. You can also use time variables:
- `from` - Defines the lower limit of the time range, specified in ms epoch.
- `to` - Defines the upper limit of the time range, specified in ms epoch.
- `time` and `time.window` - Define a time range from `time-time.window/2` to `time+time.window/2`. Both params should be specified in ms. For example `?time=1500000000000&time.window=10000` will result in 10s time range from 1499999995000 to 1500000005000.
1. If you want the link to open in a new tab, then select **Open in a new tab**.
1. Click **Save** to save changes and close the window.
1. Click **Save** in the upper right to save your changes to the dashboard.
### Update a panel link
1. On the Panel tab, find the link that you want to make changes to.
1. Click the Edit (pencil) icon to open the Edit link window.
1. Make any necessary changes.
1. Click **Save** to save changes and close the window.
1. Click **Save** in the upper right to save your changes to the dashboard.
### Delete a panel link
1. On the Panel tab, find the link that you want to delete.
1. Click the **X** icon next to the link you want to delete.
1. Click **Save** in the upper right to save your changes to the dashboard.
A library panel is a reusable panel that you can use in any dashboard. When you make a change to a library panel, that change propagates to all instances of where the panel is used. Library panels streamline reuse of panels across multiple dashboards.
You can save a library panel in a folder alongside saved dashboards.
## Create a library panel
When you create a library panel, the panel on the source dashboard is converted to a library panel as well. You need to save the original dashboard once a panel is converted.
1. Open a panel in edit mode.
1. In the panel display options, click the down arrow option to bring changes to the visualization.
{{< figure src="/static/img/docs/library-panels/create-lib-panel-from-edit-8-0.png" class="docs-image--no-shadow" max-width= "800px" caption="Screenshot of the edit panel" >}}
1. Click the **Library panels** option, and then click **Create library panel** to open the create dialog.
{{< figure src="/static/img/docs/library-panels/create-lib-panel-8-0.png" class="docs-image--no-shadow" max-width= "500px" caption="Screenshot of the create library panel dialog" >}}
1. In **Library panel name**, enter the name.
1. In **Save in folder**, select the folder to save the library panel.
1. Click **Create library panel** to save your changes.
1. Save the dashboard.
Once created, you can modify the library panel using any dashboard on which it appears. After you save the changes, all instances of the library panel reflect these modifications.
{{< figure src="/static/img/docs/library-panels/create-from-more-8-0.png" class="docs-image--no-shadow" max-width= "900px" caption="Screenshot of the edit panel" >}}
## Add a library panel to a dashboard
Add a Grafana library panel to a dashboard when you want to provide visualizations to other dashboard users.
1. Hover over the **Dashboards** option on the left menu, then select **New dashboard** from the drop-down options.
The **Add** panel dialog opens.
{{< figure src="/static/img/docs/library-panels/add-library-panel-8-0.png" class="docs-image--no-shadow" max-width= "900px" caption="Screenshot of the edit panel" >}}
1. Click the **Add a panel from the panel library** option.
You will see a list of your library panels.
1. Filter the list or search to find the panel you want to add.
1. Click a panel to add it to the dashboard.
## Unlink a library panel
Unlink a library panel when you want to make a change to the panel and not affect other instances of the library panel.
1. Hover over **Dashboard** on the left menu, and then click **Library panels**.
1. Select a library panel that is being used in different dashboards.
1. Select the panel you want to unlink.
1. Click the title of the panel and then click **Edit**. The panel opens in edit mode.
1. Click the **Unlink** option on the top right corner of the page.
## View a list of library panels
You can view a list of available library panels and search for a library panel.
1. Hover over the **Dashboard** option on the left menu, then click **Library panels**.
You can see a list of previously defined library panels.
{{< figure src="/static/img/docs/library-panels/library-panel-list-8-0.png" class="docs-image--no-shadow" max-width= "900px" caption="Screenshot of the edit panel" >}}
1. Search for a specific library panel if you know its name.
You can also filter the panels by folder or type.
## Delete a library panel
Delete a library panel when you no longer need it.
1. Hover over **Dashboard** on the left menu, and select **Library panels**.
1. Select the panel you want to delete.
1. Click the delete icon next to the library panel name.
@@ -39,7 +39,7 @@ The dashboard header has the following sections.
- **Dashboard title** (2): This also opens the dashboard search when clicked.
- **Add panel** (3): Use this option to add a new panel or row to the current dashboard.
- **Star dashboard** (4): Use this option to star (or unstar) the current dashboard. Starred dashboards show up on your own home dashboard by default. It is a convenient way to mark Dashboards that you're interested in.
- **Star dashboard** (4): Use this option to star (or unstar) the current dashboard. Starred dashboards show up on your own home dashboard and in the navigation bar by default. It is a convenient way to mark Dashboards that you're interested in.
- **Share dashboard** (5): Use this option to share the current dashboard by link or snapshot. You can also export the dashboard definition from the share modal.
- **Save dashboard** (6): Use this option to save the current dashboard using its current name.
- **Settings** (7): Use this option to open dashboard settings. Here you change dashboard name, folder, tags as well as manage variables and annotation queries.
Grafana supports many different storage backends for your time series data (data source). Refer to [Add a data source]({{< relref "../../administration/datasources/add-a-data-source/" >}}) for instructions on how to add a data source to Grafana. Only users with the organization admin role can add data sources.
Grafana supports many different storage backends for your time series data (data source). Refer to [Add a data source]({{< relref "../administration/data-source-management/#add-a-data-source/" >}}) for instructions on how to add a data source to Grafana. Only users with the organization admin role can add data sources.
## Querying
@@ -18,23 +18,23 @@ Each data source has a specific Query Editor that is customized for the features
The following data sources are officially supported:
@@ -103,7 +103,7 @@ Further documentation on multi-dimensional metrics is available [here](https://d
#### Supported Azure Monitor metrics
Not all metrics returned by the Azure Monitor Metrics API have values. To make it easier for you when building a query, the Grafana data source has a list of supported metrics and ignores metrics which will never have values. This list is updated regularly as new services and metrics are added to the Azure cloud. For more information about the list of metrics, refer to [current supported namespaces](https://github.com/grafana/grafana/blob/main/public/app/plugins/datasource/grafana-azure-monitor-datasource/azure_monitor/supported_namespaces.ts).
Not all metrics returned by the Azure Monitor Metrics API have values. To make it easier for you when building a query, the Grafana data source has a list of supported metrics and ignores metrics which will never have values. This list is updated regularly as new services and metrics are added to the Azure cloud. For more information about the list of metrics, refer to [current supported namespaces](https://github.com/grafana/grafana/blob/main/public/app/plugins/datasource/grafana-azure-monitor-datasource/azureMetadata/metricNamespaces.ts).
| ResourceGroups | Returns resource groups for a specified subscription. |
| Namespaces | Returns metric namespaces for the specified subscription and resource group. |
| Resource Names | Returns a list of resource names for a specified subscription, resource group and namespace. |
| Metric Names | Returns a list of metric names for a resource. |
| Workspaces | Returns a list of workspaces for the specified subscription. |
| Logs | Use a KQL query to return values. |
Any Log Analytics KQL query that returns a single list of values can also be used in the Query field. For example:
@@ -62,3 +54,67 @@ Perf
| summarize avg(CounterValue) by bin(TimeGenerated, $__interval), Computer
| order by TimeGenerated asc
```
## Limitations
As of Grafana 9.0, a resource URI is constructed to identify resources using the resource picker. On dashboards created prior to Grafana 9.0, Grafana automatically migrates any queries using the prior resource-picking mechanism to use this method.
Some resource types use nested namespaces and resource names, such as `Microsoft.Storage/storageAccounts/tableServices` and `storageAccount/default`, or `Microsoft.Sql/servers/databases` and `serverName/databaseName`. Such template variables cannot be used because the result could be a malformed resource URI.
### Supported cases
#### Standard namespaces and resource names
```kusto
metricDefinition = $ns
$ns = Microsoft.Compute/virtualMachines
resourceName = $rs
$rs = testvirtualmachine
```
#### Namespaces with a non-templated sub-namespace
```kusto
metricDefinition = $ns/tableServices
$ns = Microsoft.Storage/storageAccounts
resourceName = $rs/default
$rs = storageaccount
```
#### Storage namespaces missing the `default` keyword
```kusto
metricDefinition = $ns/tableServices
$ns = Microsoft.Storage/storageAccounts
resourceName = $rs
$rs = storageaccount
```
#### Namespaces with a templated sub-namespace
```kusto
metricDefinition = $ns/$sns
$ns = Microsoft.Storage/storageAccounts
$sns = tableServices
resourceName = $rs
$rs = storageaccount
```
### Unsupported case
If a dashboard uses this unsupported case, migrate it to one of the [supported cases](#supported-cases).
If a namespace or resource name template variable contains multiple segments, Grafana will construct the resource URI incorrectly because the template variable cannot be appropriately split.
This would result in an incorrect resource URI containing `Microsoft.Storage/storageAccounts/tableServices/storageaccount/default`. However, the correct URI would have the format `Microsoft.Storage/storageAccounts/storageaccount/tableServices/default`.
An appropriate fix would be to update the template variable that does not match a supported case. If the namespace variable `$ns` is of the form `Microsoft.Storage/storageAccounts/tableServices` this could be split into two variables: `$ns1 = Microsoft.Storage/storageAccounts` and `$ns2 = tableServices`. The metric definition would then take the form `$ns1/$ns2` which leads to a correctly formatted URI.
@@ -66,6 +66,16 @@ This is a configuration for the beta Node Graph visualization. The Node Graph is
-- **Enable Node Graph -** Enables the Node Graph visualization.
### Span bar label
You can configure the span bar label. The span bar label allows you add additional information to the span bar row.
Select one of the following four options. The default selection is Duration.
- **None -** Do not show any additional information on the span bar row.
- **Duration -** Show the span duration on the span bar row.
- **Tag -** Show the span tag on the span bar row. Note: You will also need to specify the tag key to use to get the tag value. For example, `span.kind`.
## Query traces
You can query and display traces from Jaeger via [Explore]({{< relref "../explore/" >}}).
@@ -123,6 +123,10 @@ Operation can have additional parameters under the operation header. See the ope
Some operations make sense only in specific order, if adding an operation would result in nonsensical query, operation will be added to the correct place. To order operations manually drag operation box by the operation name and drop in appropriate place.
##### Hints
In same cases the query editor can detect which operations would be most appropriate for a selected log stream. In such cases it will show a hint next to the `+ Operations` button. Click on the hint to add the operations to your query.
#### Raw query
This section is shown only if the `Raw query` switch from the query editor top toolbar is set to `on`. It shows the raw query that will be created and executed by the query editor.
@@ -182,7 +182,7 @@ A time series query result is returned in a [wide data frame format]({{< relref
> For backward compatibility, there's an exception to the above rule for queries that return three columns including a string column named metric. Instead of transforming the metric column into field labels, it becomes the field name, and then the series name is formatted as the value of the metric column. See the example with the metric column below.
To optionally customize the default series name formatting, refer to [Standard field definitions]({{< relref "../panels/standard-field-definitions/#display-name" >}}).
To optionally customize the default series name formatting, refer to [Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}).
**Example with `metric` column:**
@@ -226,7 +226,7 @@ GROUP BY
ORDER BY 1
```
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [Standard field definition]({{< relref "../panels/standard-field-definitions/#display-name" >}}) display name value of `${__field.labels.hostname}`.
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}) display name value of `${__field.labels.hostname}`.
@@ -191,7 +191,7 @@ A time series query result is returned in a [wide data frame format]({{< relref
> For backward compatibility, there's an exception to the above rule for queries that return three columns including a string column named metric. Instead of transforming the metric column into field labels, it becomes the field name, and then the series name is formatted as the value of the metric column. See the example with the metric column below.
To optionally customize the default series name formatting, refer to [Standard field definitions]({{< relref "../panels/standard-field-definitions/#display-name" >}}).
To optionally customize the default series name formatting, refer to [Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}).
**Example with `metric` column:**
@@ -233,7 +233,7 @@ GROUP BY time, hostname
ORDER BY time
```
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [Standard field definition]({{< relref "../panels/standard-field-definitions/#display-name" >}}) display value of `${__field.labels.hostname}`.
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [[Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}) display value of `${__field.labels.hostname}`.
@@ -196,7 +196,7 @@ A time series query result is returned in a [wide data frame format]({{< relref
> For backward compatibility, there's an exception to the above rule for queries that return three columns including a string column named metric. Instead of transforming the metric column into field labels, it becomes the field name, and then the series name is formatted as the value of the metric column. See the example with the metric column below.
To optionally customize the default series name formatting, refer to [Standard field definitions]({{< relref "../panels/standard-field-definitions/#display-name" >}}).
To optionally customize the default series name formatting, refer to [Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}).
**Example with `metric` column:**
@@ -238,7 +238,7 @@ GROUP BY time, hostname
ORDER BY time
```
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [Standard field definition]({{< relref "../panels/standard-field-definitions/#display-name" >}}) display value of `${__field.labels.hostname}`.
Given the data frame result in the following example and using the graph panel, you will get two series named _value 10.0.1.1_ and _value 10.0.1.2_. To render the series with a name of _10.0.1.1_ and _10.0.1.2_ , use a [Standard options definitions]({{< relref "../panels/configure-standard-options/#display-name" >}}) display value of `${__field.labels.hostname}`.
Data frame result:
@@ -462,7 +462,7 @@ datasources:
timescaledb: false
```
> **Note:** In the above code, the `postgresVersion` value of `10` refers to version PotgreSQL 10 and above.
> **Note:** In the above code, the `postgresVersion` value of `10` refers to version PostgreSQL 10 and above.
If you encounter metric request errors or other issues:
@@ -84,6 +84,16 @@ This is a configuration for the Loki search query type.
-- **Data source -** The Loki instance in which you want to search traces. You must configure derived fields in the Loki instance.
### Span bar label
You can configure the span bar label. The span bar label allows you add additional information to the span bar row.
Select one of the following four options. The default selection is Duration.
- **None -** Do not show any additional information on the span bar row.
- **Duration -** Show the span duration on the span bar row.
- **Tag -** Show the span tag on the span bar row. Note: You will also need to specify the tag key to use to get the tag value. For example, `span.kind`.
## Query traces
You can query and display traces from Tempo via [Explore]({{< relref "../explore/" >}}).
@@ -65,6 +65,16 @@ This is a configuration for the beta Node Graph visualization. The Node Graph is
-- **Enable Node Graph -** Enables the Node Graph visualization.
### Span bar label
You can configure the span bar label. The span bar label allows you add additional information to the span bar row.
Select one of the following four options. The default selection is Duration.
- **None -** Do not show any additional information on the span bar row.
- **Duration -** Show the span duration on the span bar row.
- **Tag -** Show the span tag on the span bar row. Note: You will also need to specify the tag key to use to get the tag value. For example, `span.kind`.
## Query traces
Querying and displaying traces from Zipkin is available via [Explore]({{< relref "../explore/" >}}).
The API can be used to create, update, delete, get, and list roles.
To check which basic or fixed roles have the required permissions, refer to [RBAC role definitions]({{< ref "../../enterprise/access-control/rbac-fixed-basic-role-definitions.md" >}}).
To check which basic or fixed roles have the required permissions, refer to [RBAC role definitions]({{< ref "../../administration/roles-and-permissions/access-control/rbac-fixed-basic-role-definitions.md" >}}).
Creates a new custom role and maps given permissions to that role. Note that roles with the same prefix as [Fixed roles]({{< relref "../../enterprise/access-control/about-rbac/#fixed-roles" >}}) can't be created.
Creates a new custom role and maps given permissions to that role. Note that roles with the same prefix as [Fixed roles]({{< relref "../../administration/roles-and-permissions/access-control/#fixed-roles" >}}) can't be created.
| uid | string | No | UID of the role. If not present, the UID will be automatically created for you and returned in response. Refer to the [Custom roles]({{< relref "../../enterprise/access-control/about-rbac/#custom-roles" >}}) for more information. |
| global | boolean | No | A flag indicating if the role is global or not. If set to `false`, the default org ID of the authenticated user will be used from the request. |
| version | number | No | Version of the role. If not present, version 0 will be assigned to the role and returned in the response. Refer to the [Custom roles]({{< relref "../../enterprise/access-control/about-rbac/#custom-roles" >}}) for more information. |
| name | string | Yes | Name of the role. Refer to [Custom roles]({{< relref "../../enterprise/access-control/about-rbac/#custom-roles" >}}) for more information. |
| description | string | No | Description of the role. |
| displayName | string | No | Display name of the role, visible in the UI. |
| group | string | No | The group name the role belongs to. |
| hidden | boolean | No | Specify whether the role is hidden or not. If set to `true`, then the role does not show in the role picker. It will not be listed by API endpoints unless explicitly specified. |
| permissions | Permission | No | If not present, the role will be created without any permissions. |
| Field Name | Date Type | Required | Description |
| uid | string | No | UID of the role. If not present, the UID will be automatically created for you and returned in response. Refer to the [Custom roles]({{< relref "../../administration/roles-and-permissions/access-control/#custom-roles" >}}) for more information. |
| global | boolean | No | A flag indicating if the role is global or not. If set to `false`, the default org ID of the authenticated user will be used from the request. |
| version | number | No | Version of the role. If not present, version 0 will be assigned to the role and returned in the response. Refer to the [Custom roles]({{< relref "../../administration/roles-and-permissions/access-control/#custom-roles" >}}) for more information. |
| name | string | Yes | Name of the role. Refer to [Custom roles]({{< relref "../../administration/roles-and-permissions/access-control/#custom-roles" >}}) for more information. |
| description | string | No | Description of the role. |
| displayName | string | No | Display name of the role, visible in the UI. |
| group | string | No | The group name the role belongs to. |
| hidden | boolean | No | Specify whether the role is hidden or not. If set to `true`, then the role does not show in the role picker. It will not be listed by API endpoints unless explicitly specified. |
| permissions | Permission | No | If not present, the role will be created without any permissions. |
**Permission**
| Field Name | Data Type | Required | Description |
| action | string | Yes | Refer to [Custom role actions and scopes]({{< relref "../../enterprise/access-control/custom-role-actions-scopes/" >}}) for full list of available actions. |
| scope | string | No | If not present, no scope will be mapped to the permission. Refer to [[Custom role actions and scopes]({{< relref "../../enterprise/access-control/custom-role-actions-scopes/" >}}) for full list of available scopes. |
| Field Name | Data Type | Required | Description |
| action | string | Yes | Refer to [Custom role actions and scopes]({{< relref "../../administration/roles-and-permissions/access-control/custom-role-actions-scopes/" >}}) for full list of available actions. |
| scope | string | No | If not present, no scope will be mapped to the permission. Refer to [Custom role actions and scopes]({{< relref "../../administration/roles-and-permissions/access-control/custom-role-actions-scopes/" >}}) for full list of available scopes. |
| action | string | Yes | Refer to [Custom role actions and scopes]({{< relref "../../enterprise/access-control/custom-role-actions-scopes/" >}}) for full list of available actions. |
| scope | string | No | If not present, no scope will be mapped to the permission. Refer to [Custom role actions and scopes]({{< relref "../../enterprise/access-control/custom-role-actions-scopes/" >}}) for full list of available scopes. |
| Field Name | Data Type | Required | Description |
| action | string | Yes | Refer to [Custom role actions and scopes]({{< relref "../../administration/roles-and-permissions/access-control/custom-role-actions-scopes/" >}}) for full list of available actions. |
| scope | string | No | If not present, no scope will be mapped to the permission. Refer to [Custom role actions and scopes]({{< relref "../../administration/roles-and-permissions/access-control/custom-role-actions-scopes/" >}}) for full list of available scopes. |
| force | boolean | No | When set to `true`, the role will be deleted with all it's assignments. |
| global | boolean | No | A flag indicating if the role is global or not. If set to false, the default org ID of the authenticated user will be used from the request. Refer to the [About RBAC]({{< relref "../../enterprise/access-control/about-rbac/" >}}) for more information. |
| force | boolean | No | When set to `true`, the role will be deleted with all it's assignments. |
| global | boolean | No | A flag indicating if the role is global or not. If set to false, the default org ID of the authenticated user will be used from the request. Refer to the [About RBAC]({{< relref "../../administration/roles-and-permissions/access-control/" >}}) for more information. |
Lists the roles that have been directly assigned to a given service account. The list does not include basic roles (Viewer, Editor, Admin or Grafana Admin).
Query Parameters:
- `includeHidden`: Optional. Set to `true` to include roles that are `hidden`.
[Set service account role assignments]({{< ref "#set-service-account-role-assignments" >}}).
#### Required permissions
`permissions:type:delegate` scope ensures that users can only assign roles which have same, or a subset of permissions which the user has.
For example, if a user does not have required permissions for creating users, they won't be able to assign a role which will allow to do that. This is done to prevent escalation of privileges.
| Action | Scope |
| --------------- | ------------------------- |
| users.roles:add | permissions:type:delegate |
#### Example request
```http
POST /api/access-control/users/1/roles
Accept: application/json
Content-Type: application/json
{
"global": false,
"roleUid": "XvHQJq57z"
}
```
#### JSON body schema
| Field Name | Data Type | Required | Description |
| global | boolean | No | A flag indicating if the assignment is global or not. If set to `false`, the default org ID of the authenticated user will be used from the request to create organization local assignment. |
[Set service account role assignments]({{< ref "#set-service-account-role-assignments" >}}).
#### Required permissions
`permissions:type:delegate` scope ensures that users can only unassign roles which have same, or a subset of permissions which the user has.
For example, if a user does not have required permissions for creating users, they won't be able to unassign a role which will allow to do that. This is done to prevent escalation of privileges.
| global | boolean | No | A flag indicating if the assignment is global or not. If set to `false`, the default org ID of the authenticated user will be used from the request to remove assignment. |
Update the service accounts's role assignments to match the provided set of UIDs.
This will remove any assigned roles that aren't in the request and add
roles that are in the set but are not already assigned to the service account.
If you want to add or remove a single role, consider using
[Add a service account role assignment]({{< ref "#add-a-service-account-role-assignment" >}}) or
[Remove a service account role assignment]({{< ref "#remove-a-service-account-role-assignment" >}})
instead.
#### Required permissions
`permissions:type:delegate` scope ensures that users can only assign or unassign roles which have same, or a subset of permissions which the user has.
For example, if a user does not have required permissions for creating users, they won't be able to assign or unassign a role which will allow to do that. This is done to prevent escalation of privileges.
| global | boolean | No | A flag indicating if the assignment is global or not. If set to `false`, the default org ID of the authenticated user will be used from the request. |
| roleUids | list | Yes | List of role UIDs. |
| includeHidden | boolean | No | Specify whether the hidden role assignments should be updated. |
| 500 | Unexpected error. Refer to body and/or server logs for more details. |
## Create and remove team role assignments
### List roles assigned to a team
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.