Rule component: Add a new API /api/v1/alerts/:state for pull alerts from Thanos Rule

[wklken]

We want to use a pull monitoring system to replace the alertmanager, which needs to fetch the firing alerts from Thanos Rule. So, after the rule apis added by this issue #851 from V0.3.2, we add one more API to fetch the alerts in specific state, like firing

Changes

• /api/v1/alerts/:state

Verification

• Tested query and rule components locally
• Tested in a Thanos cluster which monitoring a lot of k8s clusters

BTW, while the AlertingRule.active is not public, it's difficult to mock the Alerts and do the unittest here, still trying:)

[povilasv]

Could you add proper tests mock some firing alerts and check that they are returned currectly

[brancz]

How is this different from querying the ALERTS time-series?

[povilasv]

@wklken does Prometheus / alertmanager have a similiar api? Couldn't find this exact api.

[wklken]

@povilasv

• alertmanger has the api
• we want to pull the firing alerts from thanos-rule directly, without alertmanger been deployed.
  -since /alerts is supported by rule-api now, it's reasonable to add one more API to filter the firing alerts

[povilasv]

could you link me to that api? I couldn't find the :state part.

[wklken]

https://github.com/prometheus/alertmanager/blob/master/api/v2/openapi.yaml#L130

/alerts, in query active default is true;

In rule, /alerts will return all alerts, include pending/firing;

[povilasv]

I think we want to mimic Prometheus API, so I'm against introducing new API if it's not in Prometheus.
I would suggest doing this in Prometheus first and then we could port it here.

Alertmanager is a different beast all together.

Thoughts about this @bwplotka ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.