Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support configure alertmanager #148

Merged
merged 6 commits into from
Sep 23, 2020
Merged

Support configure alertmanager #148

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
6eee0db
support configure alertmanager
clyang82 Sep 22, 2020
a9f39ef
read all yaml file in /etc/thanos/rules
clyang82 Sep 22, 2020
23894fd
support ruleFileKey
clyang82 Sep 22, 2020
f08555a
Update message
clyang82 Sep 22, 2020
84a4bfb
separate alertmanager with rules
clyang82 Sep 23, 2020
e701891
Support multiple configmap
clyang82 Sep 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions jsonnet/kube-thanos/kube-thanos-rule.libsonnet
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,4 +183,41 @@ local k = import 'ksonnet/ksonnet.beta.4/k.libsonnet';
},
},
},

withAlertmanagers:: {
local tr = self,
config+:: {
rulesConfigMapName: error 'must provide rulesConfigMapName',
alertmanagersURL: error 'must provide alertmanagersURL',
},

statefulSet+: {
spec+: {
template+: {
spec+: {
containers: [
if c.name == 'thanos-rule' then c {
args+: [
'--alertmanagers.url=' + alertmanagerURL,
for alertmanagerURL in tr.config.alertmanagersURL
] + [
'--rule-file=/etc/thanos/rules/*.rules.yaml',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assumes that the key used in the configmap ends in rules.yaml, which is mysterious because it is not communicated to the user. Can we instead use the pattern of requiring a rulesFileKey in the jsonnet config and use that name instead?

Copy link
Contributor Author

@clyang82 clyang82 Sep 22, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great comments. Thanks @squat I would like to just use *.yaml instead, because the configmap may contain multiple files. Is that OK?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trouble is that there is no guarantee that the configmap key will even end in .yaml. The user could write a configmap where the keys are

foo: ...
bar: ...
rules: ...

each of these keys could have a valid rules file for the value, but the keys don't end in .yaml and thus this flag wouldn't work. File extensions are helpful hints and conventions but are not required.
Similarly, what if the configmap hold multiple keys that end in .yaml but only ONE of them is actually a rules file? Then the ruler would be attempting to read something it can't understand, potentially causing problems.

],
volumeMounts+: [
{ name: 'rules-config', mountPath: '/etc/thanos/rules' },
],
} else c
for c in super.containers
],

local volume = k.apps.v1.statefulSet.mixin.spec.template.spec.volumesType,
volumes+: [
volume.withName('rules-config') +
volume.mixin.configMap.withName(tr.config.rulesConfigMapName),
],
},
},
},
},
},
}