feature: victoriametric-alert should have default rules like the combined stack provides.

[greenaar]

Chart name and version, where you feel a lack of requested feature
chart: victoria-metrics-alert
version: any

Is your feature request related to a problem? Please describe.
A minor gripe. The all in one stack includes the 'alert' service, but also includes all of the default rules. The standalone component does not, which is less ideal if you're adding these tools one at a time to an existing cluster. It forces the consumer to build them or take them from an existing config.

Describe the solution you'd like
It looks like most of the work is already done with the cumulative stack. I'd love to see the rules section ported to the alerts chart, ideally disabled by default, but available.

Describe alternatives you've considered
I've considered (and tried) manually duplicating the rules from my existing prometheus config. There are enough of them to make it an unenjoyable job, and not easily done in batch. Manually iterating ended up being no fun at all, putting a pause to my conversion task.

A conversion tool would be a nice alternative, but I feel like that'd be a bigger ask. Getting the defaults in place is the lion's share of the work, any anything nonstandard is a reasonable task to add after. Having the default rules would also make it viable to NOT bulk up the main helm chart by 3000 lines trying to add them.

[tiny-pangolin]

We do publish some alerting rules on github that can help you alerts from Victoriametrics components.

The only issue I can see these by default is that vmalert cannot assume which components are used or even if Victoriametrics is the timeseries database being used with vmalert.

[greenaar]

Thanks for the link to those - as they're not in the helm repo, they are not immediately obvious.

I ended up using the operator to port the prometheus metrics -- if the standalone chart would've done the same, I would've leaned towards using that instead, as it has support for additional desired items (ie ingress). Do you happen to know why the non-operator installs (agent, alerts, etc) don't still leverage the operator crds if available?

It would be nice for them to be 'automatic', but you make a good point, it's hard to guarantee end user configuration, or even if the given rules would be appropriate (some were not in my case).

As such, I would like to alter my above request, and suggest linking or copying the rules over as samples, and including some brief bit of documentation for applying them either as operator objects, or perhaps even as would be used for the standalone vmalerts chart.

[tiny-pangolin]

Would enabling certain groups with a binary toggle ex enable_vmalert_rules: true work?

[greenaar]

That would be a welcome addition, and a good starting point should other people require additional granularity - that would get the framework in place.

[tiny-pangolin]

@AndrewChubatiuk would it possible to add the default rules from the k8s-stack but leave them off by default in the vmalert helm chart?

[AndrewChubatiuk]

it's possible, but not sure if it makes sense. it will just increase bundle size for most of the users.
maybe it's reasonable to add a link to files or add examples instead