search

cloudfoundry / diego-release

BOSH Release for Diego
Apache License 2.0
201 stars 212 forks source link

Endpoint for container status #291

Closed izgredajd closed 7 years ago

izgredajd commented 7 years ago

How do I get the container status (CPU, memory) from Diego about app containers? Is there an endpoint I can curl?

cf-gitbot commented 7 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/142465673

The labels on this github issue will be updated when the story is started.

emalm commented 7 years ago

Hi, @cornhustler,

The Diego cells each emit usage metrics about their containers periodically through the CF Loggregator system, and the Loggregator Traffic Controller exposes an endpoint to retrieve those metrics. The noaa library uses that endpoint in its consumer package: from the code, it looks like it's the /apps/APP_GUID/containermetrics endpoint, and requires the same kind of OAuth2 access token for authorization that the Cloud Controller API requires.

Best, Eric, CF Diego PM

izgredajd commented 7 years ago

I didn't realize loggregator persisted data. That's interesting that I would query loggregator about diego.

Is that an advisable pattern? It seems to couple the components in an unnecessary way.

emalm commented 7 years ago

I think the Loggregator system retains the last container-metric value that it received for each app instance, but the Loggregator team would know that for sure.

From the perspective of Diego as an isolated system, the Loggregator API gives it a way to push metrics out periodically, and theoretically another service could implement the same API as the local metron agent and receive those metrics to send elsewhere: it's just protobuf-encoded messages in UDP datagrams, with the still-developing v2 a gRPC-defined service. The Loggregator system happened already to aggregate those metrics and to provide a pull-based API for other components such as Cloud Controller, so we opted to delegate that responsibility to that system rather than implement the same pull-based interface on the internal Diego APIs. If there's an independent case for Diego to provide that kind of API directly, I'd be interested in hearing about it, but so far the current arrangement has been adequate for the case where Diego is part of a Cloud Foundry deployment.

Thanks, Eric

emalm commented 7 years ago

Closing due to inactivity.