Merge lp:~james-w/charms/precise/haproxy/metrics into lp:charms/haproxy
Proposed by
James Westby
Status: | Merged |
---|---|
Merged at revision: | 79 |
Proposed branch: | lp:~james-w/charms/precise/haproxy/metrics |
Merge into: | lp:charms/haproxy |
Diff against target: |
298 lines (+206/-1) 7 files modified
README.md (+12/-0) config.yaml (+17/-0) files/metrics/haproxy_to_statsd.sh (+27/-0) hooks/hooks.py (+71/-1) hooks/tests/test_config_changed_hooks.py (+1/-0) hooks/tests/test_metrics.py (+75/-0) templates/metrics_cronjob.template (+3/-0) |
To merge this branch: | bzr merge lp:~james-w/charms/precise/haproxy/metrics |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
David Ames (community) | Approve | ||
Simon Davy (community) | Approve | ||
Review via email: mp+219724@code.launchpad.net |
Description of the change
Hi,
This is based on https:/
carbon format and sending to graphite or a compatible server.
It relies on monitoring being enabled, rather than forcing a
localhost monitoring declaration.
Thanks,
James
To post a comment you must log in.
Shouldn't enabled_monitoring be added to config.yaml?
A thought: in the squid version, squid actually provides average aggregate measures for 1min/5min/60min windows, which is nice as your 5 min cron can use that for better accuracy.
I am assuming the we're sampling current unaggregated metrics here? So, it it worth thinking about a more frequent cron timing? Is 5min enough?
Another thing - I thing it would be worth trying to use statsd rather than carbon?
We'd need to do 2 things
1. change the "| nc ..." part to:
... | while read line; do echo $line | nc -u {{ statsd_host }} {{ statsd_port }}; done
which would send 1 metric per packet? Note: we could also update txstatsd to support multi-metric packets, which would then simplify this back to just "| nc -u ..."
2. add a function to output statsd format rather than carbonify (untested)
statsdify() { PREFIX} .\1.${PERIOD} :\2|g/"
sed -r "s/([^ ]+) (.*)/${
}
(ps I like explicitly putting the period in there, rather than assuming it's in the metric_scheme, I may change the squid version to that, only reason I didn't was that I think it's custom to our statsd setup, wasn't sure it was valid to put upstream, but maybe its useful info even if your statsd setup doesn't do anything special with it)