CFn telemetry: capture actions on resources #12798
Conversation
simonrw
added
the
semver: patch
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 34m 20s ⏱️ Results for commit b7308e1. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 23m 12s ⏱️ - 1h 23m 6s Results for commit b7308e1. ± Comparison against base commit a6ec498. This pull request removes 4019 tests.♻️ This comment has been updated with latest results. |
| @@ -559,7 +560,7 @@ def execute_action( | |||
| raise NotImplementedError(change_type) # TODO: change error type | |||
|
|
|||
| @staticmethod | |||
| def try_load_resource_provider(resource_type: str) -> ResourceProvider | None: | |||
| def try_load_resource_provider(action: str, resource_type: str) -> ResourceProvider | None: | |||
There was a problem hiding this comment.
nit (but mostly just a comment): I get the intent but it does feel a bit weird passing it in here like this just for analytics purposes.
There was a problem hiding this comment.
I thought that when I wrote it. I might have a think about how to reorganise this information. I wonder if I can capture the same intent from the caller scope (where the action is available).
| from localstack.utils.analytics.metrics import LabeledCounter | ||
|
|
||
| COUNTER_NAMESPACE = "cloudformation" | ||
| COUNTER_VERSION = 2 |
There was a problem hiding this comment.
nice, already coming in useful here!
We want to know which operations are being used with our resources. This change means that we capture the operation/action the user is performing on the resource. We want to see which resources are most common to be updated.
Motivation
We want to know which operations are being used with our resources. This change means that we capture the operation/action the user is performing on the resource. We want to see which resources are most common to be updated.
Changes
When we load a resource provider, we capture which operation we are applying to that resource provider.
Note: for v1 and v2 we have to handle the case of both
strandChangeAction. This can be simplified when we remove the v1, HOWEVER we must not change the names of the event actions fromcreate,updateanddeleteor else we won't be able to map metrics captured from different times.