-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Implement Python API for submitting logs #26978
Conversation
--- | ||
enhancements: | ||
- | | ||
Implement API that allows Python checks to send logs for |
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.
Implement API that allows Python checks to send logs for | |
Implements API that allows Python checks to send logs for |
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'm not sure this is desirable as these entries get directly put on the Agent release change log. In that context, it's less so that we are describing this specific patch but rather as a whole. Does that make sense?
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.
Minor feedback but otherwise looks good!
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv create-vm --pipeline-id=40520993 --os-family=ubuntu Note: This applies to commit a775579 |
Regression DetectorRegression Detector ResultsRun ID: 17736aeb-9360-4daa-92b7-fbc816faa9fb Metrics dashboard Target profiles Baseline: fc52f43 Performance changes are noted in the perf column of each table:
No significant changes in experiment optimization goalsConfidence level: 90.00% There were no significant changes in experiment optimization goals at this confidence level and effect size tolerance.
|
perf | experiment | goal | Δ mean % | Δ mean % CI | links |
---|---|---|---|---|---|
➖ | otel_to_otel_logs | ingress throughput | +0.10 | [-0.71, +0.91] | Logs |
➖ | tcp_dd_logs_filter_exclude | ingress throughput | -0.00 | [-0.01, +0.01] | Logs |
➖ | uds_dogstatsd_to_api | ingress throughput | -0.00 | [-0.00, +0.00] | Logs |
➖ | file_tree | memory utilization | -0.41 | [-0.49, -0.33] | Logs |
➖ | basic_py_check | % cpu utilization | -0.63 | [-3.14, +1.88] | Logs |
➖ | idle | memory utilization | -0.64 | [-0.68, -0.60] | Logs |
➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | -2.21 | [-3.09, -1.32] | Logs |
➖ | pycheck_1000_100byte_tags | % cpu utilization | -2.22 | [-6.90, +2.45] | Logs |
➖ | tcp_syslog_to_blackhole | ingress throughput | -3.93 | [-16.32, +8.46] | Logs |
Explanation
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
4cd843a
to
b489f51
Compare
Py_RETURN_NONE; | ||
} | ||
|
||
char *log_line, *check_id; |
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.
If I understand Python's documentation correctly, these should be const char*
as the memory is owned by python
This would imply the cb_send_log_t
type should also be updated to pass both parameters as pointers to constant chars
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 is the same as every function in this file; are you certain?
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.
Quite certain:
Other formats take a str or a read-only bytes-like object, such as bytes, and provide a const char * pointer to its buffer. In this case the buffer is “borrowed”: it is managed by the corresponding Python object, and shares the lifetime of this object. You won’t have to release any memory yourself.
https://docs.python.org/3/c-api/arg.html#strings-and-buffers
It doesn't make an actual difference for most purposes, but having a const char'
makes it clear that we don't own that memory
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! This will be done in a follow-up PR.
|
||
This function is callable as the `datadog_agent.send_log` Python method and | ||
uses the `cb_send_log()` callback to retrieve the value from the agent | ||
with CGO. If the callback has not been set `None` will be returned. |
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.
If the callback has not been set
None
will be returned.
This seems to imply that a different result would be returned if a callback was set, which isn't the case
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.
Every function has this documentation; are they all incorrect?
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 don't think it's incorrect, but the last sentence seems misleading since None
is always returned.
Now to be clear, this is definitely in the nit picking realm and can be ignored
I realized that most of my comments are about code from #26753 which is already merged, you might want to pull main to remove those commits |
/merge |
🚂 MergeQueue: pull request added to the queue The median merge time in Use |
/merge |
🚂 MergeQueue: pull request added to the queue The median merge time in Use |
This reverts commit eee54f7.
Motivation
Expose the new functionality to Python checks #26753
Additional Notes
After the base PR is merged this PR will re-target
main