Re: Adding previous_instances and previous_memory fields to cf_event

Dieu Cao <dcao@...>

Hi Hristo,

Correct me if I'm wrong but it sounds like you are calling purge multiple
times. Am I misunderstanding the work flow you are describing?

Purge should only be called only one time EVER on any deployment. It
should not be called on each billing cycle. Cloud contoller will purge
older billing events itself based on the configured
and cc.service_usage_events.cutoff_age_in_days which both default to 31


On Wed, Mar 9, 2016 at 11:57 PM, Hristo Iliev <hsiliev(a)> wrote:

Hi Dieu,

We are polling app-usage-events with Abacus, but because of purge the
events may be out of order right after billing epoch started. But that's
only part of the problem.

To consume app-usage-events every integrator needs to build additional
infrastructure like:
- simple filter, loadbalancer or API management product to disable purging
once billing epoch started
- DB replication software that pulls data and deals with wrongly ordered
events after purge (we use abacus-cf-bridge)
- the Data warehouse described in the doc you sent

Introducing the previous values in the usage events will help us get rid
of most of the infrastructure we need in order to be able to deal with
usage events, before they even reach a billing system. We won't need to
care for purge calls or additional db, but instead simply pull events. The
previous values help us to:
- use formulas that do not care for the order of events (solves the purge
- get the info about a billing relevant change (we don't have to cache,
access DB or scan a stream to know what changed)
- simplify the processing logic in Abacus (or other metering/aggregation

We now pull the usage events, but we would like to be notified to offload
the CC from the constant /v2/app_usage_events calls. This however will not
solve any of the problems we now have and in fact may mess the ordering of
the events.

Hristo Iliev

2016-03-10 6:32 GMT+02:00 Dieu Cao <dcao(a)>:

We don't advise using /v2/events for metering/billing for precisely the
reason you mention, that order of events is not guaranteed.

You can find more information about app usage events and service usage
events which are guaranteed to be in order here:

CF Runtime PMC Lead

On Wed, Mar 9, 2016 at 10:27 AM, KRuelY <kevinyudhiswara(a)>


I am currently working on metering runtime usage, and one issue I'm
is that there is a possibility that usage submission comes in out of
order(due to network error / other possibilities). Before the issue, the
metering runtime usage works is quiet simple. There is an app that will
at cf_events and submit usages to

"metadata": {
"guid": "40afe01a-b15a-4b8d-8bd1-e36a0ba2f6f5",
"created_at": "2016-03-02T09:48:09Z"
"entity": {
"state": "STARTED",
"memory_in_mb_per_instance": 512,
"instance_count": 1,
"app_guid": "a2ab1b5a-94c0-4344-9a71-a1d2b11f483a",
"app_name": "abacus-usage-collector",
"space_guid": "d34d770d-4cd0-4bdc-8c83-8fdfa5f0b3cb",
"space_name": "dev",
"org_guid": "238a3e78-3fc8-4542-928a-88ee99643732",
"buildpack_guid": "b77d0ef8-da1f-4c0a-99cc-193449324706",
"buildpack_name": "nodejs_buildpack",
"package_state": "STAGED",
"parent_app_guid": null,
"parent_app_name": null,
"process_type": "web"

The way this app works is by looking at the state.
If the state is STARTED, it will submit usage to abacus with the
instance_memory = memory_in_mb_per_instance, running_instances =
instance_count, and since = created_at.
If the state is STOPPED, it will submit usage to abacus with the
instance_memory = 0, running_instances = 0, and since = created_at.

In ideal situation, where there is no out of order submission this is
'Simple, but Exaggerated' Example:
Usage instance_memory = 1GB, running_instances = 1, since = 3/9 00:00
Usage instance_memory = 0GB, running_instances = 0, since = 3/10 00:00
Then Abacus know that the app consumed 1GB * (3/10 - 3/9 = 24 hours) = 24

But when the usage comes in out of order:
Usage instance_memory = 0GB, running_instances = 0, since = 3/10 00:00
Usage instance_memory = 1GB, running_instances = 1, since = 3/9 00:00
The formula that Abacus currently have would not works.

Abacus has another formula that would take care of this out of order
submission, but it would only works if we have previous_instance_memory

When looking for a way to have this fields, we concluded that the
way would be to add previous_memory_in_mb_per_instance and
previous_instance_count to the cf_event. It will make App reconfigure or
scale makes more sense too because currently cf scale is a STOP and a

To sum up, the cf_event state submitted would include information:

// Starting
"state": "STARTED",
"memory_in_mb_per_instance": 512,
"instance_count": 1,
"previous_memory_in_mb_per_instance": 0,
"previous_instance_count": 0

// Scaling up
"state": "SCALE"?,
"memory_in_mb_per_instance": 512,
"instance_count": 2,
"previous_memory_in_mb_per_instance": 512,
"previous_instance_count": 1

// Scale down
"state": "SCALE"?,
"memory_in_mb_per_instance": 512,
"instance_count": 1,
"previous_memory_in_mb_per_instance": 512,
"previous_instance_count": 2

// Stopping
"state": "STOPPED",
"memory_in_mb_per_instance": 0,
"instance_count": 0,
"previous_memory_in_mb_per_instance": 512,
"previous_instance_count": 1

Any thoughts/feedbacks/guidance?

View this message in context:
Sent from the CF Dev mailing list archive at

Join { to automatically receive all group messages.