RFC: Usage Snapshots for App and Service Usage Baselines

[joyvuu-dave]

This RFC proposes new V3 API endpoints for capturing point-in-time usage snapshots of app and service usage, as a non-destructive alternative to destructively_purge_all_and_reseed. See the RFC document for details.

Related:

• Issue #4182 — Problems related to pruning old AppUsageEvent and ServiceUsageEvent records
• PR #4858 — Reference implementation
• PR #4646 — Complementary keep-running-records change

@cloudfoundry/toc @cloudfoundry/wg-app-runtime-interfaces-leads

[beyhan]

MD read link

[stephanme]

Is the snapshot functionality still needed if the last usage event of running apps/services is not pruned as proposed in ccng #4646 assuming that this functionality would have existed from the start of the foundation?

If so, it might be sufficient to think about how to generate missing STARTED events once, e.g. as part of a CCDB migration instead of extending the CF API.

[joyvuu-dave]

Is the snapshot functionality still needed if the last usage event of running apps/services is not pruned as proposed in #4646 assuming that this functionality would have existed from the start of the foundation?

On a greenfield foundation, no -- snapshots wouldn't be necessary. Just a convenience, really. A consumer of usage events could get what's running using just the usage events themselves.

If so, it might be sufficient to think about how to generate missing STARTED events once, e.g. as part of a CCDB migration instead of extending the CF API.

The problem with backfilling events is that there's no way to distinguish a synthetic event from a real one. Existing consumers would see these new STARTED events the next time they grabbed events and would have no way of knowing that they were generated by a migration. For the system our team uses, this would lead to problems. I think any solution we implement has to be safe for existing consumers. And I don't think we can make that guarantee if we're injecting into the event stream.

Now, writing to a separate table avoids that problem, because then you could have consumers query separately for "missing" events. But we'd still need to provide a read API for that data. So now we're back to building an API and the question becomes which API to build.

The thing that's nice about a snapshots API is that it remains useful. While a migration would give usage consumers a one-time baseline, with snapshots you get fresh data whenever you need it. So, you can onboard a new usage consumer, but also recover from a bad state, or just get a snapshot of current state without having to process usage events.