This repository has been archived by the owner on Aug 2, 2022. It is now read-only.
Improve Tracking Request ID in Logging #34
Assignees
Labels
enhancement
New feature or request
Comments
|
I think it would be great if we could do this programmatically without touching Log4j config file. |
Merged
arsen-es
added a commit
that referenced
this issue
Jun 13, 2019
*Issue:* #34 *Description of changes:* Removed id field from SqlRequest class. Using logging library's ThreadContext to store the request id as soon as we get it, and passing it around to make it available in case new threads are started from the main one. Provided a utility class to make the access to the ThreadContext simpler. The current layout pattern of elasticsearch log messages is [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %m%n, if we pre-pend [%X{request_id}] all the messages will automatically be pre-pended with the request id. However, the plugin code does not manage the log configuration, and I didn't want to modify it at run-time. *How tested:* Made some requests on local cluster, made sure request id is getting properly populated. Tested for tasks running on worker threads as well.
zhongnansu
pushed a commit
to zhongnansu/sql
that referenced
this issue
Jun 14, 2019
*Issue:* opendistro-for-elasticsearch#34 *Description of changes:* Removed id field from SqlRequest class. Using logging library's ThreadContext to store the request id as soon as we get it, and passing it around to make it available in case new threads are started from the main one. Provided a utility class to make the access to the ThreadContext simpler. The current layout pattern of elasticsearch log messages is [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %m%n, if we pre-pend [%X{request_id}] all the messages will automatically be pre-pended with the request id. However, the plugin code does not manage the log configuration, and I didn't want to modify it at run-time. *How tested:* Made some requests on local cluster, made sure request id is getting properly populated. Tested for tasks running on worker threads as well.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently we prepended a generated request ID to logging related to a request. In the PR, @arsen-es proposed to investigate other approach provided by Log4j, such as maintain thread context and let Log4j take care of this.
The text was updated successfully, but these errors were encountered: