Service metrics support via Generic Extensions

[gberche-orange]

As a service user:

• in order to use services managed by a 3rd party provider but still:
  • monitor my app usage of the service. E.g.
    • getting close to quotas/define service plans, and I need to update plans,
    • suboptimal service usage by my app that requires optimization from app developers
  • monitor performance of the service is within defined SLO
• I need to discover metrics exposed by the services I subscribed through my preferred platform,
• I need my app to access these metrics through the platform

As a service user, the metrics discovery is quite similar to service discovery in the catalog (along with discovery of service params, binding response, etc...). I.e. I can discover the list of metrics exposed to me, their format and a potential human description describing their semantics.

As a broker author, in order to provide metrics to service users and bound apps, I need a standard way of exposing metrics to platforms:

• a secured, authenticated way to provide metrics associated to each service instance and possibly service binding
• a portable way to provide metrics across platforms:
  • available to both public services and private on-prem services (i.e. the service broker is'nt required to acquire privileged platform permissions to expose metrics to end-users)

Related pointers:

• F2F Nov 2017 Topic: Metrics, health, logging - Problem Discovery
• CF Loggregator Service Drains
  • cloudfoundry/service-metrics and its associated service-metrics-release

[n3wscott]

I think this is a case where the ask is out of scope for OSBAPI but the hooks are getting in place for a broker to provide this functionality through a combination of Generic Actions and Broker Generic Actions.

A valid argument is to say exposing metrics breaks the blackbox provided by the broker and it should be the concern of the broker author to monitor and maintain their SaaS product without need for the customer to do this. Now we all know OSBAPI is not being used in this model exclusively so the Generic Actions work allows broker authors the hooks to provide this functionality generically, even if it is not in the OSBAPI directly.

[pmorie]

I think this is a case where the ask is out of scope for OSBAPI but the hooks are getting in place for a broker to provide this functionality through a combination of Generic Actions and Broker Generic Actions.

I could see a metrics scrape endpoint being associated with the instance via generic actions.

[n3wscott]

OK I am back, give me a little bit of time to work on this now. My Q2 is a little tight on time so feel free for someone else to pick up this task or work with me.

[mattmcneeney]

I agree that the Generic Actions proposal #431 is going to be the right place to solve this. What we will want (somewhere) is an example (or standard?) OpenAPI doc for a service instance that wants to expose a metrics endpoint. Maybe this issue can be used to track the creation of that standard?

[gberche-orange]

For the CF community, the related epic in SAPI backlog, if this may help follow CF exchanges on the topic.

[mattmcneeney]

Closing this. Work on the generic extensions work can be tracked in #670 !

[mattmcneeney]

Reopened, updated title and added the blocked label so that we tackle this after the generic extensions (#670) work is done.