Add useful logging #33
Add useful logging #33
Conversation
src/main/java/com/amazon/opendistroforelasticsearch/sql/esdomain/LocalClusterState.java
Outdated
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/esdomain/LocalClusterState.java
Outdated
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/AsyncRestExecutor.java
Show resolved
Hide resolved
Map<String, String> params, | ||
QueryAction action, | ||
RestChannel channel) throws Exception { | ||
Instant startTime = Instant.now(); |
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.
Instant.now() can have pretty big errors depending on time drift/skew/last time of sync of system time/etc. Please use System.nanoTime()
for anything where you need to measure a period and not get a specific point in time (https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--).
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.
Instant.now() can have pretty big errors depending on time drift/skew/last time of sync of system time/etc. Please use
System.nanoTime()
for anything where you need to measure a period and not get a specific point in time (https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--).
Thanks for the suggestion! I wasn't aware of this. Could you pass me some reference for the problem you mentioned? Because we only care about the delta value returned from Duration.between
, is it possible to be wrong too in some 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.
This one touches upon the problem a little bit: https://www.baeldung.com/java-measure-elapsed-time. Most of the sources say that resolution of nanoTime is better, but that's not the issue. The real difference is that System.currentTimeMillis()
and Instant.now()
(which relies on the former) both use wall-clock time from the JVM, which in its turn gets it from OS. Depending on what protocol the machine is using to synchronize the time, it can lag behind or go far ahead and then during sync get a huge change (either negative or positive). The System.nanoTime()
is based on software-based counter (not related to wall clock), which only increases, and does not need to be synced with any other machine/server/clock, so the diffs of values from nanoTime will always be pretty accurate (I guess as long as you are using it on the same thread).
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 one touches upon the problem a little bit: https://www.baeldung.com/java-measure-elapsed-time. Most of the sources say that resolution of nanoTime is better, but that's not the issue. The real difference is that
System.currentTimeMillis()
andInstant.now()
(which relies on the former) both use wall-clock time from the JVM, which in its turn gets it from OS. Depending on what protocol the machine is using to synchronize the time, it can lag behind or go far ahead and then during sync get a huge change (either negative or positive). TheSystem.nanoTime()
is based on software-based counter (not related to wall clock), which only increases, and does not need to be synced with any other machine/server/clock, so the diffs of values from nanoTime will always be pretty accurate (I guess as long as you are using it on the same thread).
Thanks! Good to know the subtle difference. I think Instant
and Duration
is sufficient in our case. Because we are not benchmarking, we just need a rough elapsed time in second(s). nanoTime()
may be more accurate in some edge case, though it's hassle to convert it to sec or millisec for logging or comparison. Hopefully this makes sense to you.
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.
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.
It's just two lines that need to be changed:
#140 should befinal long startNanos = System.nanoTime();
#145 should be `final Duration elapsed = Duration.ofNanos(System.nanoTime() - startNanos);It's up to you if you want to keep it this way, not a blocker.
Easier than I thought. Testing it. Will push very soon. Thanks!
src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/AsyncRestExecutor.java
Outdated
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/format/ErrorMessage.java
Outdated
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/plugin/RestSqlAction.java
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/plugin/RestSqlAction.java
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/plugin/SqlPlug.java
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/request/SqlRequest.java
Show resolved
Hide resolved
src/main/java/com/amazon/opendistroforelasticsearch/sql/executor/AsyncRestExecutor.java
Outdated
Show resolved
Hide resolved
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.
Please create the issue for updating the request id logging approach and include in the response to the relevant comment before merging and closing this PR.
Done! |
Issue #, if available: #19
Description of changes: The following changes are being introduced in this PR:
All unit test and legacy/new integration tests passed. Checked added log in elasticsearch.log and did some manually testing in Kibana, primarily for slow log threshold:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.