Skip to content

Commit 1ac77be

Browse files
authored
DecisionLog for EMFMetricPublisher added (#5717)
* DecisionLog for EMFMetricPublisher added * decisionLog for emfMetricPublisher added * decisionLog for emfMetricPublisher added
1 parent 021491d commit 1ac77be

File tree

1 file changed

+20
-0
lines changed

1 file changed

+20
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
# Decision Log for AWS SDK for Java v2 EMFMetricPublisher
2+
3+
4+
## 11/19/2024
5+
6+
**Source:** Team design doc review meeting for the issue that CloudWatchMetricPublisher doesn't work well for lambda functions
7+
8+
**Attendees:** Bole, David, Debora, Olivier, Dongie, Zoe
9+
10+
**Closed Decisions:**
11+
12+
1. Should we support a cw client in it? No, just writing to the logs is fine, if a cw client is needed then CloudWatchMetricPublisher is sufficient.
13+
2. Should we create a logger or take an instance of a logger? No, We should avoid taking a logger from the customer to prevent misconfiguration for now. We should also explore possible use cases and try it. Also, passing in the level of the logger might be a good idea. Logger.info is set as default logger level.
14+
3. Do we use jackson(easier but slower) (two way door) in the convert method? Yes, We can use third party Jackson-core in the convert method, because it is a two way door and we can try to implement different method and do performance test afterwards.
15+
4. Should we use SDK's LoggingMetricPublisher as alternative? No, the dealbreaker is that it is under core/metric-spi, we should separate the module from it.
16+
5. Should we use MetricLogger as alternative? No, it depends on jackson-databind, which is prone to CVEs.
17+
18+
**Open Decisions:**
19+
20+
None

0 commit comments

Comments
 (0)