The app_usage_events endpoint was not designed to be a live billing
interface. Typically what you would do is have another app that polls the
endpoint, collects the billing data, and saves it off in a format that is
easy to generate bills from.


http://apidocs.cloudfoundry.org/214/app_usage_events/list_all_app_usage_events.html

This is the reason the app_usage_events endpoint has the after_guid query
parameter. Ideally your billing system would keep track of the last guid
that it fetched, then when it polled again, it could get everything after
that event.

Be aware of the warnings at the top of the api docs. In general you should
not process app usage events that are close to the current time (within a
couple of minutes is probably fine). The reason for this is that you could
miss events that are being created in a transaction that has not yet been
committed.

The destructively_purge_all_and_reseed_started_apps endpoint is not
intended to be used monthly. This endpoint exists because the billing data
only goes back so far, and if you haven't been collecting it from the
very beginning, you don't know what apps have been started before the usage
data starts. What you should do is get your billing infrastructure in
place, then call this endpoint one time. This will seed the usage events
feed with a STARTED record for each app that is currently running. You can
then just process the changes you get from the usage endpoint after that.

And of course, as Noburou mentioned, you can always increase the
cc.app_usage_events.cutoff_age_in_days manifest parameter.

Joseph
OSS Release Integration Team

On Tue, Jul 28, 2015 at 6:10 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I have deployed CF env in AWS, and there are some applications running on
it. I found one useful article talking about billing CF users :
https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/
.

I tried cf curl /v2/app_usage_events in my CF env, I found that I could
only retrieve app events for one month, is this exepcted? Is it able to
change the default "one month" in CF deployment manifest?

If I want to track the app usage for one org, for example org1, and org1
have one app running for more than one month, then there will be no app
usage for this long running app, then how to meter such app? Should I list
all apps available in the org currenlty, if the app is not in the app usage
event, I could image the app has been created more than one month?

Another thing, if I want to bill app usage by month, should I call
/v2/app_usage_events/destructively_purge_all_and_reseed_started_apps at the
end of each month?

Is there anyone have done similar things in the past and share your
experience? Many thanks.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Hi, there

I have deployed CF env in AWS, and there are some applications running on
it. I found one useful article talking about billing CF users :
https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/
.

I tried cf curl /v2/app_usage_events in my CF env, I found that I could
only retrieve app events for one month, is this exepcted? Is it able to
change the default "one month" in CF deployment manifest?

If I want to track the app usage for one org, for example org1, and org1
have one app running for more than one month, then there will be no app
usage for this long running app, then how to meter such app? Should I list
all apps available in the org currenlty, if the app is not in the app usage
event, I could image the app has been created more than one month?

Another thing, if I want to bill app usage by month, should I call
/v2/app_usage_events/destructively_purge_all_and_reseed_started_apps at the
end of each month?

Is there anyone have done similar things in the past and share your
experience? Many thanks.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev