New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
attach request info to log events #28
attach request info to log events #28
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
src/withAxiom.ts
Outdated
ev.waitUntil(log.flush()); | ||
return res; | ||
} catch (error) { | ||
log.error('Error in edge function', { error }); | ||
report.request.statusCode = 500; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this do anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably would have been useful in case of EDGE_REPORT. I will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to collect logs until flush in functions. Then we can attach the report (including the correct status code) to each log and send them all out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm this would have very different behavior than frontend I guess. how should we approach this? different logger class that doesn't throttle and send?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am also wondering if seeing the status of the request on each log is that useful. for checking the status of request, wouldn't one record of that be enough?
export type AxiomMiddleware = ( | ||
request: AxiomRequest, | ||
event: NextFetchEvent | ||
) => NextMiddlewareResult | Promise<NextMiddlewareResult>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll also need an AxiomApiRequest
, the API function logs have the same issue don't they?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the NextAPIRequest structure is different than NextRequest. I can't find request ip and geo info for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you still blocked on this @schehata ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was able to get the IP from the headers, and for the region information I used VERCEL_REGION. I believe we can move forward with those
4dc845e
to
6be6ddd
Compare
ed8926f
to
690f95b
Compare
690f95b
to
7190ae3
Compare
7190ae3
to
4cb3d3b
Compare
4cb3d3b
to
b42b39e
Compare
83ff5b3
to
fe3889c
Compare
52cf53d
to
175b8dd
Compare
6e888ee
to
72459ec
Compare
I was able to attach environment, region, and route to vercel object. e.g:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good from my side but I feel like I'm the wrong person to push the button on this. Is there somebody that has been more involved than me?
Probably only arne. Neil was involved in the payload structure. |
when we print logs to vercel console we receive request information with the logs. Those are missing when we send logs using axiom logger. This collects the request information and attach them as part of the fields object, they would be parsed in the backend.
we intercept res so that we can flush beforing sending out the response so we need to attach the res statusCode as well befor flush
72459ec
to
9d03d9a
Compare
when we print logs to vercel console we receive request information
with the logs. Those are missing when we send logs using axiom logger.
This collects the request information and attach them as part of the
fields object, they would be parsed in the backend.