You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The withTelemetryContext() decorator adds context to telemetry
but not thrown errors.
Solution:
Adding this decorator to a method will add context to any thrown exceptions.
This is helpful in telemetry as it will provide information about the caller.
Signed-off-by: nkomonen-amazon <[email protected]>
Copy file name to clipboardExpand all lines: docs/telemetry.md
+47-30Lines changed: 47 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -142,7 +142,10 @@ Finally, if `setupStep2()` was the thing that failed we would see a metric like:
142
142
143
143
## Adding a "Stack Trace" to your metric
144
144
145
-
### Problem
145
+
When errors are thrown we do not attach the stack trace in telemetry. We only know about the error itself, but
146
+
not the path it took to get there. We sometimes need this stack trace to debug, and only have telemetry to get insight on what happened since we do not have access to logs.
147
+
148
+
### Scenario
146
149
147
150
Common example: _"I have a function, `thisFailsSometimes()` that is called in multiple places. The function sometimes fails, I know from telemetry, but I do not know if it is failing when it is a specific caller. If I knew the call stack/trace that it took to call my function that would help me debug."_
148
151
@@ -168,34 +171,67 @@ function thisFailsSometimes(num: number) {
168
171
### Solution
169
172
170
173
Add a value to `function` in the options of a `run()`. This will result in a stack of functions identifiers that were previously called
171
-
before `thisFailsSometimes()` was run. You can then retrieve the stack in the `run()` of your final metric using `getFunctionStack()`.
174
+
before `failsDependingOnInput()` was run. You can then retrieve the stack in the `run()` of your final metric using `getFunctionStack()`.
// Results in a metric: { theCallStack: 'outerB:thisFailsSometimes', result: 'Failed' }
193
-
// { theCallStack: 'outerB:thisFailsSometimes' } implies 'outerB' was run first, then 'thisFailsSometimes'. See docstrings for more info.
194
-
outerB()
195
+
// Results in a metric: { theCallStack: 'thisThrows:failsDependingOnInput', result: 'Failed' }
196
+
// { theCallStack: 'thisThrows:failsDependingOnInput' } implies 'thisThrows' was run first, then 'failsDependingOnInput'. See docstrings for more info.
197
+
thisThrows()
198
+
```
199
+
200
+
Additionally the `@withTelemetryContext()` decorator can be added to methods to do the same as above, but with a cleaner syntax.
0 commit comments