Skip to content
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

More direct access to processes states #3306

Open
oliveti opened this issue Jun 1, 2023 · 1 comment
Open

More direct access to processes states #3306

oliveti opened this issue Jun 1, 2023 · 1 comment

Comments

@oliveti
Copy link

oliveti commented Jun 1, 2023

Context

Creation of a centralised monitoring dashboard of apps based on the api (list of crashed apps).

Issue

With the current existing endpoints, getting "real" state for a list of apps requires too many network calls.
As far as I know, the only way to know if an app is crashed is to call the stats endpoints which requires one call per process /v3/processes/process-id/stats.

Current result

When getting an app, the received object only contains the desired state of the app (STARTED, STOPPED). This desired
state does not reflect the "real" state of the app processes (we might be crashed).

Possible Fix

A few ideas :

  • Provide an endpoint to get all the stats for all process : v3/stats
  • Include the "real" state (processes states) in the app response.
@FloThinksPi
Copy link
Member

AFAIK the /stats endpoint calls the Diego API for information on the apps intances. Its not an information the CC has and is thus costly and seperated into an own endpoint. Have to read this up in code though. Hoever i think one possibility would be to have a /v3/apps/stats endpoint which ahs the same query parameters for the apps as the normal apps listing endpoint. But only if we can then fetch all stats infors from diego in one call also. Needs some investigation but i can understand the use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants