-
Notifications
You must be signed in to change notification settings - Fork 81
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
feat(jans-cedarling): Improve log searching and retrieval #10772
Conversation
…rtant for the memory logger Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
…it is unused Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
…xisting key Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
…in trait `Indexed` to not forget implement them It lead to less amount of the bugs, because of compiler highlight Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
…t allows to load information from `memory` logger Signed-off-by: Oleh Bohzok <[email protected]>
…tag` to the `get_logs_by_id_and_tag` Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
…ogger API Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
- rename `get_log_by_request_id` to `get_logs_by_request_id` - remove in trait `LogWriter` method `log` and now use only `log_any` Signed-off-by: Oleh Bohzok <[email protected]>
…related to getting logs from memory logger by `request_id` and tags Signed-off-by: Oleh Bohzok <[email protected]>
…aling-issue-10705 Signed-off-by: Oleh Bohzok <[email protected]>
…nerator Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
Signed-off-by: Oleh Bohzok <[email protected]>
fn get_logs_by_tag(&self, tag: &str) -> Vec<serde_json::Value> { | ||
self.storage | ||
.lock() | ||
.expect(STORAGE_MUTEX_EXPECT_MESSAGE) | ||
.get_by_index_key(tag) | ||
.map(|v| v.to_owned()) | ||
.collect() | ||
} | ||
|
||
fn get_logs_by_request_id(&self, request_id: &str) -> Vec<serde_json::Value> { | ||
self.storage | ||
.lock() | ||
.expect(STORAGE_MUTEX_EXPECT_MESSAGE) | ||
.get_by_index_key(request_id) | ||
.map(|v| v.to_owned()) | ||
.collect() | ||
} | ||
|
||
fn get_logs_by_request_id_and_tag( | ||
&self, | ||
request_id: &str, | ||
tag: &str, | ||
) -> Vec<serde_json::Value> { | ||
let key = composite_key(request_id, tag); | ||
|
||
self.storage | ||
.lock() | ||
.expect(STORAGE_MUTEX_EXPECT_MESSAGE) | ||
.get_by_index_key(&key) | ||
.map(|v| v.to_owned()) | ||
.collect() | ||
} |
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.
shouldn't we return errors here instead of panicking?
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.
From my point of view poisoned lock is not recoverable state of program, so returning error has no sense, because this error will newer be fixed. And we need reload program to fix.
Also in our case storage lock
can newer be poisoned.
I think using panicking
instead of return error (in this case) is a good tradeoff. Because It will newer happen.
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.
From my point of view poisoned lock is not recoverable state of program, so returning error has no sense
My concern if the user of the Cedarling library wants to gracefully handle the situation. For example, what if the system they're building shouldn't shut down unexpectedly without logging the current state and the error?
Also in our case storage lock can newer be poisoned.
Im not sure about that since we're writing bindings to other languages that do not implement Rust's safety guarantees.
But if you think that will still never happen, then go ahead.
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.
Hmm, in case if target
does not support atomic
it will panic anyway and returning PoisonError
does not help. And in our situation poisoning is impossible. Because we don't use some tricky recursive function calling that tries to call same lock
. So I'm pretty sure about that.
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.
alright, then it's ok for me
.lock() | ||
.expect(STORAGE_MUTEX_EXPECT_MESSAGE) | ||
.set(&entry.get_request_id().to_string(), json); | ||
let mut storage = self.storage.lock().expect(STORAGE_MUTEX_EXPECT_MESSAGE); |
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.
isn't it better if we return an error instead of calling .expect()
in case the user wants some to implement a tear-down sequence in their code in case of a poisoned lock?
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.
Could you describe how lock can be poisoned (in our 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.
In the bindings code for other languages, code might panic in undefined ways.
It probably won't happen in the rust code but I don't think we can guarantee that in the bindings code. I think we already saw that problem in the Kotlin bindings where the control over memory is limited.
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.
Responded here
#10772 (comment)
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.
Python side looks good to me
06d3032
to
823fe70
Compare
Sorry, I slightly messed up the commits, but everything is OK now. |
Prepare
Description
Target issue
link
closes #10705
Implementation Details
extended API of memory logger
Test and Document the changes
Please check the below before submitting your PR. The PR will not be merged if there are no commits that start with
docs:
to indicate documentation changes or if the below checklist is not selected.