Enhancement: expose per-customer statuses, GET parameter value, url location

[samsk]

Hello, first sorry, that this pull request cumulates more features, but they are all small, and we needed them before it was decided to upstream it.

New features:

• per-consumer status collection, controlled by per_consumer boolean switch

  • creates new metric kong_http_consumer_status similar to existing kong_http_status with additional consumer label
  • new label was created for this, to avoid breaking existing setups/queries

• per-url param metric

  • collects hits per first defined url param in param_collect_list, attaching its value as param label
  • creates kong_http_url_param_total or kong_http_url_param_consumer_total depending on per_consumer switch
  • optionally extracts/validates param label value according to param_value_extract regexp, (to avoid possible problems with metric cardinality)

• per-url location metric

  • collects hits per ngx.var.uri ($uri) location, attaching its value as location label
  • creates kong_http_url_location_total or kong_http_url_location_consumer_total depending on per_consumer switch
  • optionally extracts/validates location label value according to location_extract regexp, (to avoid possible problems with metric cardinality)

All new features are off by default, so they should not affect existing systems until enabled. These new metrics make sense especially for people that don't want to setup/run/maintain additional log-collection/extraction system (like fluentd/splunk). With this they can still have at least basic insight about (per-consumer) usage of some services identified by URL param and/or URL location part. I've done basic tests, and performance degradation seems to be negligible, where maybe the most expensive part is the REGEXP extraction, but that is necessary to provide protection from metrics overpopulation.

I'll be happy to make any changes necessary to upstream this, if possible. Thank you ;-)

[CLAassistant]

All committers have signed the CLA.

[samsk]

Ok, I'll split it, give me few days please. Yes, you might be right that something similar should be preferable done somewhere else, but everything else beyond this requires much much (much) more effort, either to implement tracing or do log analysis. This is cheap, plug&play solution, that can serve good for most of the use-cases.