fix: use configured datasource instead of default one

[VikaCep]

Ref https://github.com/grafana/support-escalations/issues/19505
Related to #911

Support custom Loki datasources in Synthetic Monitoring

Problem

The Synthetic Monitoring app hardcoded fallbacks to uid: 'grafanacloud-logs' for log queries, preventing users from configuring alternative Loki datasources. This blocked use cases where customers need to use different Loki datasources.

Affected areas:

• Runtime log queries always tried grafanacloud-logs UID first
• Initialization logic prioritized hardcoded UIDs over provisioned configuration

Solution

Updated the datasource resolution logic to respect the configured datasource in jsonData.logs before falling back to hardcoded defaults.

Changes:

1. DataSource.ts - getLogsDS() and getMetricsDS()

   • Now attempt to use the configured datasource from jsonData first
   • Only fall back to hardcoded Grafana Cloud UIDs if the configured datasource doesn't exist

2. useAppInitializer.ts - findDatasourceByNameAndUid()

   • Updated to try finding datasources by configured UID before falling back to default Cloud UIDs
   • Respects datasource configuration from provisioning metadata

Testing

To test:

1. Provision SM plugin with custom Loki datasource in jsonData.logs
2. Verify runtime queries use the configured datasource
3. Verify fallback behavior when configured datasource doesn't exist

Notes

GCOM Provisioning Required:
If the SM datasource is deleted and re-initialized, it will reset to whatever GCOM provisions (the default datasource).

Future Enhancement:
We may evaluate adding a UI dropdown in the plugin configuration to allow users to select from available Loki datasources, removing the dependency on GCOM provisioning for this use case.

[github-actions]

Script size changes

Name	+/-	Main	This PR	Outcome
[502.js]	=	1,736.41 kB	1,736.41 kB	✅
[832.js]	+0.01%	958.91 kB	959.03 kB	✅
[datasource/module.js]	-0.12%	24.49 kB	24.46 kB	✅
[692.js]	=	20.19 kB	20.19 kB	✅
[663.js]	=	5.84 kB	5.84 kB	✅
[module.js]	=	4.92 kB	4.92 kB	✅

Totals

Name	+/-	Main	This PR	Outcome
[Scripts]	=	2,750.77 kB	2,750.86 kB	✅
[Non-script Assets]	=	2,655.48 kB	2,655.48 kB	✅
[All]	=	5,406.25 kB	5,406.33 kB	✅

Generated by 🚫 dangerJS against 8ed0447

[ka3de]

If the SM datasource is deleted and re-initialized, it will reset to whatever GCOM provisions (the default datasource).

That sentence I think indicates that, if we want to support this, we probably need to do it at a higher level.
The current situation is that Hosted Grafana presets the Hosted Metrics and Hosted Logs as the metrics and logs destinations for Synthetic Monitoring. There are some assumptions that count on this, for example in the plugin, which is what this PR tries to change, but also in the backend, for example alerts expect to find the metrics through the grafanacloud-prom datasource. The backend actually enforces the usage of the Hosted Metrics and Hosted Logs instances by comparing supplied data in the registration endpoint with the data in GCOM.

If we want to support this, we probably need to allow the user to specify the data source configuration, that will have to be stored in backend, and the plugin should consume whatever is set there. Additionally this should be propagated to HG somehow, so resetting the plugin does not revert the configuration.
This probably deserves a better discussion. I would consider creating an issue for it so we can triage it.

[VikaCep]

If we want to support this, we probably need to allow the user to specify the data source configuration, that will have to be stored in backend, and the plugin should consume whatever is set there. Additionally this should be propagated to HG somehow, so resetting the plugin does not revert the configuration.
This probably deserves a better discussion. I would consider creating an issue for it so we can triage it.

I agree, this PR was aimed specifically to address the use case of https://github.com/grafana/support-escalations/issues/19505. They were previously taking advantage of a workaround in order to consume the LBAC datasource and it stopped working, so this solution was a temporary fix. (see https://raintank-corp.slack.com/archives/C0162C1K9E1/p1763384093931469)

I do agree the right and long-term solution is to explicitly allow users to select the desired datasources in the UI and store it, so it doesn't reset when the app is reinstalled or the SM datasource restored, but as you said, that would have to be triaged and treated as a new feature. We can close this PR if we want to take that road.

[ar2pi]

@VikaCep any update on the fix? From the perspective of anyone using Synthetics this is a regression and should be fixed. Long term improvement sounds good, but let's address restoring a working version first 🙏

[VikaCep]

@ar2pi this PR is still up for review, and while it does try address the customer’s immediate issue, there are some inconsistencies in other layers of the architecture that we should consider as well, as Daniel pointed out. The customer was relying on a workaround that we had previously confirmed was not something we officially support, so I think it’s debatable whether this qualifies as a regression:

In a past thread, some of you confirmed that there are no supported ways to change the datasource used by synthetics tests. The workaround mentioned in that thread no longer works for the customer.

[ar2pi]

@VikaCep This absolutely counts as a regression from a user perspective. For context: Synthetics logs worked fine for users who rely on a LBAC datasource for logs. Now, it doesn't.

Could we think in terms of win-win here? Have the temporary fix asap, restore user satisfaction. Then think longer term.

[ckbedwell]

Let's just do it. What's the worst that can happen? 😬

It'll be up to the user to manage this properly and we can look at supporting this more officially in the future.