-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
add analytics to APIGW NextGen REST API handler chain #11860
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
Conversation
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 26m 27s ⏱️ - 1h 17m 34s Results for commit cb1fc52. ± Comparison against base commit 5b44747. This pull request removes 2718 tests.
|
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.
Thanks for adding this! So awesome how clean it is to add this as a handler! 🚀
I have a couple questions as to the relevancy of some of the captured data point. If you feel those are important, let's merge. But if not, we might be better to eliminate some noise? 🤔
# if the invocation does not have an integration attached, it probably failed before routing the request, | ||
# hence we should count it as a NOT_FOUND invocation | ||
invocation_type = "NOT_FOUND" |
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.
Question: I wonder if this is a relevant data point? On it's own, what intel can we gather from it, except for maybe knowing the total amount of requests sent to apigw? But is it relevant?
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 it would be good to know the total amount of requests sent to the endpoint. Not very relevant directly, but I think relevant if we do the sum of all types regardless of their value?
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.
Maybe @thrau could chime in too, I also see the point, so yeah I think it depends on expectations!
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.
Btw, I am OK either way! 👍 I was simply raising a question, to make sure we are deliberate with logging 😉
if not integration_uri: | ||
return "null" | ||
|
||
if len(split_arn := integration_uri.split(":", maxsplit=5)) < 4: | ||
return "null" |
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.
Question: Same here. It seems we are we just capturing misconfigured Api? Is it relevant?
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 check is mostly to avoid exceptions, making sure we have a proper value to send
Motivation
As part of our effort to improve our analytics, this PR implements usage counters for API Gateway.
We can now properly have usage data on APIGW invocations, with the integration type (
AWS_PROXY
,MOCK
etc), and in case of theAWS
integration, the service the integration is targeting (dynamodb
,sqs
etc..)Changes