Skip to content
This repository was archived by the owner on Jan 23, 2019. It is now read-only.

Conversation

@ipmb
Copy link
Member

@ipmb ipmb commented Aug 4, 2013

For instance, this fine example of a fail2ban munin plugin:

fail2ban munin

@ipmb
Copy link
Member

ipmb commented Jun 19, 2013

Yep, we need this functionality. The YAML configuration file doesn't provide a way to define multiple values yet, so we can start there. Any suggestions on how you might define a graph like this?

@supervacuo
Copy link
Contributor Author

Good point. How about (based on the example):

"*.example.com":
    munin.run diskstats:
        name: 'disk stats (avg)'
        type: float
        keys: 
            "/.util":
                name: 'utilisation'
                assert: "{value} < 80"
            "/.avgwrrqsz":
                name: 'write queue size'
                assert: "{value} < 200"
            "/.avgrdqsz":
                name: 'read queue size'
                assert: "{value} < 200"

It's getting a little verbose, but it seems important to be able to configure name and assert per-subcheck. Presumably type needs to be set at the higher level to have any chance of getting the stats on the same chart.

@yml
Copy link
Member

yml commented Jun 20, 2013

This is a bit verbose but it will gives us a lot of flexibility we will also need to add alert_email.

@ipmb
Copy link
Member

ipmb commented Jun 20, 2013

This assumes that all the stats you want to graph come from the same Salt
command. I'm thinking that's a limitation we should accept in order to keep
things simple.

On Thu, Jun 20, 2013 at 3:52 AM, yml notifications@github.com wrote:

This is a bit verbose but it will gives us a lot of flexibility we will
also need to add alert_email.


Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-19738143
.

@nicolaslara
Copy link
Contributor

If we have to graph information from different commands, we can always "wrap" those commands by writing a salt module/function that returns their results in a datastructure. We may need to allow some sort of notation to access dict values, though (something like "{value.disk} > 200")

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling fe6af30 on features/multi-keys into d399c95 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0%) when pulling 11ad41f on features/multi-keys into d6caa9f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0%) when pulling ff7875a on features/multi-keys into d6caa9f on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0%) when pulling 7c185ce on features/multi-keys into d6caa9f on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 8fcbf94 on features/multi-keys into d6caa9f on master.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants