chore: introduce metrics change #307
Conversation
| metrics. Customers can then ask for updates to the implementations | ||
| CT provides or customers can go an implement their own interfaces that are fine-tuned | ||
| to their use cases. | ||
|
|
There was a problem hiding this comment.
Is there a middle ground? For example, logging information locally without uploading it anywhere.
|
@josecorella I have a meta/macro question. I appreciate that the Background doc highlights issues and alternatives, but I feel like we a missing a "User Stories" document, that can be used to measure success criteria and what are the table stakes of this work. It is also possible I just missed such a proposal doc; but without it, it is difficult to work backwards. |
framework/metrics-agent.md
Outdated
| operation AddDate { | ||
| input: AddDateInput, | ||
| output: AddOutput, | ||
| errors: [MetricsPutError] |
There was a problem hiding this comment.
Nit: You say that the interface should not error, but you have errors here.
| // Common output structure | ||
| structure AddOutput {} |
There was a problem hiding this comment.
I get why you might optimize this. But is this really the best choice? why not have a output per operation?
|
|
||
| This change will allow Crypto Tools to introduce a Metrics Agent in a | ||
| non-breaking way as the Metrics Agent will be an optional parameter | ||
| at customer facing API call sites. |
There was a problem hiding this comment.
Should we support providing a metrics agent to the client constructor? Such that the same instance would then be used for each API call.
I don't necessarily think we should but it might be worth discussing here.
| algorithmSuiteId: aws.cryptography.materialProviders#ESDKAlgorithmSuiteId, | ||
|
|
||
| frameLength: FrameLength, | ||
|
|
There was a problem hiding this comment.
I guess this probably isn't possible in Smithy/Smithy-Dafny but we might want to consider having a more open-ended "request override" option for things like this. (This is the same way the SDK does it.)
|
Potential Issue/Alternative/User Story: Users of the MPL/ESDK/DB-ESDK are also users of the AWS SDKs. The AWS SDKs have established logging and metric interfaces. There likely is an implicit customer expectation that Crypto Tools products behave and appear to be consistent with the AWS SDKs. Therefore, I suggest we carefully evaluate if we can utilize the SDKs metric and logging tooling, and offer a customer experience that closely mimics the SDKs experience. The current collection of docs does not state this as a goal, but it does leave it open as an opportunity. i.e: the proposed metric interface could wrap an SDK metric class. |
6 participants
For best reading and commenting experience, I suggest splitting your window in two; the review page and the rendered page.
Here are the rendered files:
Goals for 9-15-2025 Spec Review:
Goals for 2-2-2025 Spec Review:
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Check any applicable: