Skip to content

Conversation

@AndrewChubatiuk
Copy link
Contributor

Describe Your Changes

Please provide a brief description of the changes you made. Be as specific as possible to help others understand the purpose and impact of your modifications.

Checklist

The following checks are mandatory:

…iers, /api/v1/alerts and /api/v1/rules requests to VMAlert
@AndrewChubatiuk AndrewChubatiuk force-pushed the vlselect-proxy-vmalert-requests branch from 5778668 to c032e53 Compare June 27, 2025 15:48
@makasim
Copy link
Contributor

makasim commented Jul 1, 2025

Should the proxy enforce datasource_type introduced in #9046 ?

The same question applies to VM proxy PR #9267

@AndrewChubatiuk
Copy link
Contributor Author

Should the proxy enforce datasource_type introduced in #9046 ?

Since there's no consensus on ability to use the same vmalert instance for multiple datasource types such filtering is not required at the moment

@AndrewChubatiuk AndrewChubatiuk deleted the vlselect-proxy-vmalert-requests branch July 7, 2025 05:33
@AndrewChubatiuk
Copy link
Contributor Author

closing this PR and opened another one in VictoriaLogs repo instead

@makasim
Copy link
Contributor

makasim commented Jul 7, 2025

We should filter alerts to include only those related to the specific product (either metrics or logs). Returning metrics-related alerts or rules through a VictoriaLogs instance doesn't make much sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants