-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service metrics support via Generic Extensions #485
Comments
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. |
I could see a metrics scrape endpoint being associated with the instance via generic actions. |
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. |
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? |
For the CF community, the related epic in SAPI backlog, if this may help follow CF exchanges on the topic. |
Closing this. Work on the generic extensions work can be tracked in #670 ! |
Reopened, updated title and added the blocked label so that we tackle this after the generic extensions (#670) work is done. |
As a service user:
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:
Related pointers:
The text was updated successfully, but these errors were encountered: