-
Notifications
You must be signed in to change notification settings - Fork 2.6k
feat(datadog): Improve Datadog plugin tag support #11943
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
base: master
Are you sure you want to change the base?
Conversation
826b279
to
7767c7d
Compare
Hi @deiwin, I see PR is still in draft status, is there still time to advance? |
Hi! I haven't been able to work on this recently, but would love to see this completed. Based on how I read the code, the code changes should work as-is, but the docs & tests still need work. Unfortunately I wasn't able to get the tests to run on mac (following this guide), so I put this on hold for now. |
Can you share the specific problem? |
Following the linked guide, everything seems to work up to and including the
|
I actually opened this PR hoping that I could use the CI system to validate my changes, but unfortunately it looks like not all PRs are automatically validated by CI. |
Hi @deiwin, the running Docker container may have limited resources, causing the process to execute slowly and fail to complete within the time expected by the test framework. You can try to modify the timeout parameters of the test framework to give the process more time to complete the operation. You can check the configuration of the Test::Nginx::Socket module to see if the timeout parameter can be adjusted. |
Any specific conf changes (file & parameter) you could recommend? My Docker should have 8 (M1) cores & 15.5GB of memory available, so it shouldn't be too constrained. |
For example timeout in |
Currently there is no way to distinguish Datadog metrics for different HTTP endpoints if these endpoints are served through a single Apisix route. With these changes, if `include_path` is set to true, the path pattern by which the HTTP request was matched to a route is included as a metric tag with the `path:` key. This allows different endpoints to be distinguished in metrics.
Currently there is no way to distinguish Datadog metrics for e.g. GET & POST requests for the same endpoint within a single Apisix route, although their performance characteristics are likely to be quite different. With these changes, if `include_method` is set to true, HTTP method is included as a metric tag with the `method:` key, enabling such requests to be differentiated.
7767c7d
to
216c7b6
Compare
Looks like that worked and I am now able to reliably run at least the relevant Datadog plugin tests! 🎉 Thank you, @Baoyuantop! 🙇 I've finished the changes now and updated the PR with them. I'll now open it for review. |
`constant_tags` are already supported at the plugin configuration level. However, sometimes different values may be required for each route, but this was previously not possible. For example, if some routes are owned by team A and some routes by team B, they could add `constant_tags: ["owner:team_a"]` or `constant_tags: ["owner:team_b"]` to each route, and would then be able to group metrics by team on Datadog.
216c7b6
to
da581f7
Compare
I fixed the lint issue (I hope) but the other CI errors seemed unrelated to my changes. |
9b34b89
to
ab93afb
Compare
I realized there's one more change required for what I'm trying to achieve, so I added another commit to also add a |
Having a separate tag for the HTTP response code class allows useful grouping in Datadog by e.g. successful requests (2xx), client errors (4xx), and server errors (5xx). The existing `response_status` already essentially includes that information, but because of how Datadog works, one would need to list out each possible value between 400 and 431 to group all client errors, for example. Having a separate tag for the class greatly simplifies this. Generally it may be problematic to add new tags by default without an opt-in configuration option, because Datadog charges based on [custom metrics count][1] and additional tags can increase that count. However, the additional tag is safe to add here, because it is guaranteed not to increase the custom metric count. That is because the new tag is based on the already included `response_status` value, which is more granular than the new `response_status_class` value, so the number of unique tag combinations will not change. [1]: https://docs.datadoghq.com/metrics/custom_metrics/
ab93afb
to
5120f05
Compare
I fixed the lint issue with the too long line: https://github.com/apache/apisix/compare/ab93afb5125b041bbc90ffab1cd2a0ec1b8834af..5120f05bed6eef9248d0a8a8f0dccc59cafdedcd I also found a way to run the lint (or at least luacheck) locally in the container ( The other CI failures seem unrelated to my changes again. |
Description
Added options to include
path
andmethod
tags in the Datadog plugin and added support forconstant_tags
in route-level plugin configuration. More detailed reasoning in each commit's message.Checklist