Provide option to collect custom metrics inside filters

[chandu188]

Now one can collect the custom metrics inside the filter using the methods defined in the filters.Metrics interface.
Mentioned in this issue #352
Please give your suggestions.

Following is the idea the PR implemented:

1. Add an interface 'Metrics' in the filters package with following methods
   - MeasureSince(key, time)
   - IncCounter(key)
2. Add a method in the FilterContext interface to expose the above interface
3. add an extra field (metrics) in the context and implement the Metrics method added in the FilterContext interface
4. Implement the Metrics interface in metrics.Metrics struct.

[aryszka]

👍

[aryszka]

@lmineiro what do you think about this extension?

[lmineiro]

This looks like one good start but I wouldn't leave it as it is.

Although the metrics registry seems to be properly protected, the namespacing mentioned before is not. This can, potentially, lead to:

• A filter can use the same metric key as any other filter (breaking metrics for both)
• A filter can use a metric key that belongs to Skipper itself

One simple way could be to always prefix a filter's key with the filter name, which already needs to be unique in the filter registry.

What do you think?

[aryszka]

prefixing is a good point, i agree. It can be done in the proxy where it is iterating over the filters.

[aryszka]

i would prefer not using this as a package visible field. Let me contemplate a bit on a different approach..

[chandu188]

you are right. I should have thought a bit more before pushing the code. With this code, I can easily change the FiilterName to whatever in the filters which we don't want to.

[aryszka]

@lmineiro we applied the prefixing. Could you please check if it looks ok like this?

[aryszka]

👍

[vigneshshanmugam]

👍