[Cloud Security][Metering] Report all assets details#186777
[Cloud Security][Metering] Report all assets details#186777CohenIdo merged 19 commits intoelastic:mainfrom
Conversation
| @@ -212,21 +219,20 @@ export const getCloudSecurityUsageRecord = async ({ | |||
| logger, | |||
| }: CloudSecurityMeteringCallbackInput): Promise<UsageRecord[] | undefined> => { | |||
| try { | |||
There was a problem hiding this comment.
Following our decision to prevent overbilling and until we implement a recovery mechanism, getSearchStartDate is redundant.
| @@ -21,6 +21,15 @@ export const cloudSecurityMetringCallback = async ({ | |||
| lastSuccessfulReport, | |||
| config, | |||
| }: MeteringCallbackInput): Promise<MeteringCallBackResponse> => { | |||
There was a problem hiding this comment.
Following FP alerts we had, I found it more effective to skip cloud metering earlier.
|
Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security) |
d7ce66b to
3c86f6f
Compare
a467e97 to
c323796
Compare
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]
History
To update your PR or re-run it, just comment with: |
joeypoon
left a comment
There was a problem hiding this comment.
My knowledge of cloud billing isn't that intimate so with that in mind, it looks good overall. I believe we should make one change though. We should use usage.metadata here instead of source.metadata since these are billing details, not source/project details.
@joeypoon I agree, I moved it to |
eyalkraft
left a comment
There was a problem hiding this comment.
Thanks @CohenIdo!
Actually I'd expect the complete deletion of BILLABLE_ASSETS_CONFIG and billable notion whatsoever from the Kibana code.
The list of billable assets should be moved to the glue function where we will be free to change what's billable and what's not without even changing Kibana.
I think that' a better separation of responsibilities and aligns with the value we're trying to achieve with this change.
wdyt?
@eyalkraft, that's was the original plan, together with @kfirpeled we decided to not have breaking change but to achieve most of the goals with the current implementation. |
joeypoon
left a comment
There was a problem hiding this comment.
I have one tiny comment which would be great if you can fix before merge. Otherwise 👍.
| period_seconds?: number; | ||
| cause?: string; | ||
| metadata?: unknown; | ||
| metadata?: ResourceSubtypeCounter; |
There was a problem hiding this comment.
It feels a bit strange to import from a child file upward. We should move ResourceSubtypeCounter into this file or just use [key: string]: string directly.
⏳ Build in-progress
History
|
solves:
Summary
The Cloud Security solution charges solely for billable assets in a serverless project.
With this PR, we utilize the
metadataobject from the usage-v2-schema to report the complete list of cloud assets for future debugging and optimization purposes.Note: the API spec doesn't allow nested objects in metadata, that's the reason the
tierremains at the same level as the resource dub type details. In addition the metadata object in both the UsageMetrics and UsageSource schemas can contain a dictionary of key-value pairs where both the keys and the values are strings.Example
In the payload below, you can find the environment containing 4 unique assets, but we only charge for 3.