feat(agent): Adds label forwarding to log events #1027
Conversation
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #1027 +/- ##
==========================================
+ Coverage 77.58% 77.63% +0.05%
==========================================
Files 198 198
Lines 27715 27786 +71
==========================================
+ Hits 21503 21573 +70
- Misses 6212 6213 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
The function nr_txn_begin() now accepts a nrobj_t *log_labels parameter which contains the logging labels to be associated with log events.
…ding labels metric
- skipped PHP5 specific tests
- added PHP5 tests - these are not for PHP 5 but are intended to run on PHP5+!
| nrl_debug(NRL_INIT, "unable to begin transaction: app '%.128s' is unknown", | ||
| appnames ? appnames : ""); | ||
| return NR_FAILURE; | ||
| } | ||
|
|
||
| attribute_config = nr_php_create_attribute_config(TSRMLS_C); | ||
| NRPRG(txn) = nr_txn_begin(NRPRG(app), &opts, attribute_config); | ||
| log_forwarding_labels | ||
| = nr_php_txn_get_log_forwarding_labels(NRPRG(app)->info.labels); |
There was a problem hiding this comment.
Why not just have log_forwarding_labels be part of NRPRG(app)->info? Why does it need to be passed separately?
It could just be added as a var here: https://github.com/newrelic/newrelic-php-agent/pull/1027/files#diff-f5f8c5da8db458c336e8505b331bcb42a571175d89cdd0e65fbc39c1121a5960L881
There was a problem hiding this comment.
I considered that but it would be odd to put it in "appinfo" but send it to the daemon in the "transaction" payload. Also I believe the information needed to make the filtered log labels list is not available when "appinfo" is initialized.
There was a problem hiding this comment.
Does the label filtering need to happen at the start of the transaction? Could it happen in cmd_txndata_transmit? The advantage of the latter is that it doesn't affect transaction latency because cmd_txndata_transmit happens after response has been sent to the client.
There was a problem hiding this comment.
Why wouldn't the info needed to make the filtered list not be available when appinfo is initialized?
Isn't the info is already available from the INI?
Otherwise, all of this logic is being done and added to the overhead of the beginning of every txn when it's a known value that won't change and only needs to be done once even if you still send it via the txn payload.
You could compute it once here after the labels are added: https://github.com/newrelic/newrelic-php-agent/pull/1027/files#diff-f5f8c5da8db458c336e8505b331bcb42a571175d89cdd0e65fbc39c1121a5960L881.
Then you could keep your same logic to send it in the txn payload
by just doing
log_forwarding_labels
= NRPRG(app)->info.log_labels;
The above would keep all the sending labels in the txn payload logic, but would save the agent from having to do all the string manipulation and exclude comparisons and hash creations/looksups/etc needed to recompute the log labels (which never change since they are set in the INI) in every txn.
Alternatively, you could also just theoretically send it with the appinfo payload once, then it could be set somewhere on the daemon side where the daemon could consult the appinfo for any log labels before sending a logevent.
There was a problem hiding this comment.
Alternatively, you could also just theoretically send it with the appinfo payload once, then it could be set somewhere on the daemon side where the daemon could consult the appinfo for any log labels before sending a logevent.
I also like this idea.
mfulb
force-pushed
the
feat/apm_logging_labels
branch
from
bc18e12 to
df096d7
Compare
| ; Info : Toggles whether the agent adds labels as attributes to log records for | ||
| ; sending to New Relic. The labels can be defined by the newrelic.labels | ||
| ; configuration value, and filtered using the | ||
| ; newrelic.application_logging.forwawrding.labels.exclude configuration value. |
There was a problem hiding this comment.
| ; Info : Toggles whether the agent adds labels as attributes to log records for | |
| ; sending to New Relic. The labels can be defined by the newrelic.labels | |
| ; configuration value, and filtered using the | |
| ; newrelic.application_logging.forwawrding.labels.exclude configuration value. | |
| ; Info : Toggles whether the agent adds labels as attributes to log records which | |
| ; are sent to New Relic. The labels can be defined by the newrelic.labels | |
| ; configuration value, and filtered using the | |
| ; newrelic.application_logging.forwarding.labels.exclude configuration value. |
| ; Scope : per-directory | ||
| ; Default: "" | ||
| ; Info : A list of labels to NOT add as attributes to logs which are forwarded | ||
| ; to New Relic. This list can be separated by commas. |
There was a problem hiding this comment.
Please update description to state that label matching is case insensitive and multiple list elements MUST be separated by commas.
| "common": { | ||
| "attributes": { } | ||
| }, |
There was a problem hiding this comment.
For other reviewers - sending "common" object with empty "attributes" is an existing functionality.
| @@ -95,7 +95,6 @@ test_segment | |||
| test_segment_children | |||
| test_segment_datastore | |||
| test_segment_external | |||
| test_segment_message | |||
There was a problem hiding this comment.
I think this has been removed by a mistake during rebase.
| @@ -666,6 +777,11 @@ static void nr_php_txn_send_metrics_once(nrtxn_t* txn TSRMLS_DC) { | |||
| nrm_force_add(NRTXN(unscoped_metrics), metname, 0); | |||
| nr_free(metname); | |||
|
|
|||
| metname = nr_formatf("Supportability/Logging/Labels/PHP/%s", | |||
There was a problem hiding this comment.
Has this been added to angler?
There was a problem hiding this comment.
I will create a PR associated with the next release to add this. I will also create a ticket as part of the epic to track this.
|
Thanks for adding the new tests_monolog_label* tests.
|
This PR adds the ability for labels to be forwarded with any log messages forwarded by the PHP agent.