David Douardchanged title from Actiave gunicorn's statsd monitoring for objstorage services to Activate gunicorn's statsd monitoring for objstorage services
changed title from Actiave gunicorn's statsd monitoring for objstorage services to Activate gunicorn's statsd monitoring for objstorage services
Tryout with douardda and I failed so far.
After setting the right logger in the configuration, it actually started logging but only workers event (gunicorn.workers: number of workers managed by the arbiter - gauge).
Tried to dig in in the code but did not find the right solution yet.
There are apparently compatibility issues with the gunicorn workers we use (aiohttp) and gunicorn to send the information we are interested in (gunicorn.requests*).
Well, at least with a default setup [1]
I spent some time trying to check whether we could activate those metrics
(focusing on the objstorage for now).
I had to evolve the objstorage image so we could activate the statsd relative
flags [1].
Then I had to also evolve the objstorage deployment to expose another
environment variable to ease the objstorage metric configuration [2]. The end goal
being able to map those metrics with statsd_exporter [2]
I've been fighting the mapping as some documented metrics [3] are not
outputted/mapped. But statsd exporter is not raising any issues with the
mapping nor the debug level being helpful at all.
One of the missing metrics though requests_workers would be interesting to
have for the autoscaling part (as in this example [4]).
Besides that, that sounds ok.
I'll stop there for now.
Note that i'm not sure whether I have some other keys to add (like the
environment) or whether it's our overall monitoring orchestration that will do
it.
Note that i'm not sure whether I have some other keys to add (like the
environment) or whether it's our overall monitoring orchestration that will do
it.
Well, to ensure that, the next step would be to run the test in staging.
I've adapted the attached mr to that end (only testing it in staging).
I've been fighting the mapping as some documented metrics [3] are not
outputted/mapped. But statsd exporter is not raising any issues with the
mapping nor the debug level being helpful at all.
One of the missing metrics though requests_workers would be interesting to
have for the autoscaling part (as in this example [4]).
d'oh, the objstorage pods needed to be restarted for those to appear.
curl -s http://localhost:9102/metrics | grep gunicorn_worker# HELP objstorage_read_only_gunicorn_workers Metric autogenerated by statsd_exporter.# TYPE objstorage_read_only_gunicorn_workers gaugeobjstorage_read_only_gunicorn_workers 2# HELP objstorage_read_write_gunicorn_workers Metric autogenerated by statsd_exporter.# TYPE objstorage_read_write_gunicorn_workers gaugeobjstorage_read_write_gunicorn_workers 2tony@kessel:~/work/swh/sysadm-environment/swh-charts (add-objstorage-gunicorn-statsd) $ curl -s http://localhost:9102/metrics | grep gunicorn_log# HELP gunicorn_log Metric autogenerated by statsd_exporter.# TYPE gunicorn_log countergunicorn_log{deployment="objstorage-read-only",level="error"} 4gunicorn_log{deployment="objstorage-read-write",level="error"} 4