Skip to content
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

Merged
merged 30 commits into from
Feb 4, 2025

Conversation

olehbozhok
Copy link
Contributor

@olehbozhok olehbozhok commented Jan 30, 2025

Prepare


Description

Target issue

link

closes #10705

Implementation Details

extended API of memory logger

/// Get logs by tag, like `log_kind` or `log level`.
/// Tag can be `log_kind`, `log_level`.
fn get_logs_by_tag(&self, tag: &str) -> Vec<serde_json::Value>;

/// Get logs by request_id.
/// Return log entries that match the given request_id.
fn get_logs_by_request_id(&self, request_id: &str) -> Vec<serde_json::Value>;

/// Get log by request_id and tag, like composite key `request_id` + `log_kind`.
/// Tag can be `log_kind`, `log_level`.
/// Return log entries that match the given request_id and tag.
fn get_logs_by_request_id_and_tag(&self, request_id: &str, tag: &str)
-> Vec<serde_json::Value>;

Test and Document the changes

  • Static code analysis has been run locally and issues have been fixed
  • Relevant unit and integration tests have been added/updated
  • Relevant documentation has been updated if any (i.e. user guides, installation and configuration guides, technical design docs etc)

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.

  • I confirm that there is no impact on the docs due to the code changes in this PR.

…rtant for the memory logger

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]>
…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]>
- 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]>
@mo-auto mo-auto added the area-documentation Documentation needs to change as part of issue or PR label Jan 30, 2025
@mo-auto mo-auto added comp-docs Touching folder /docs comp-jans-cedarling Touching folder /jans-cedarling kind-feature Issue or PR is a new feature request labels Jan 30, 2025
@olehbozhok olehbozhok changed the title feat(jans-cedarling): improve getting logs from memory logger feat(jans-cedarling): Improve log searching and retrieval Jan 30, 2025
@olehbozhok olehbozhok self-assigned this Jan 30, 2025
Comment on lines +148 to +179
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()
}
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor Author

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)?

Copy link
Contributor

@rmarinn rmarinn Feb 1, 2025

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Responded here
#10772 (comment)

jans-cedarling/sparkv/src/index.rs Show resolved Hide resolved
SafinWasi
SafinWasi previously approved these changes Jan 31, 2025
Copy link
Contributor

@SafinWasi SafinWasi left a 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

nynymike
nynymike previously approved these changes Feb 3, 2025
@olehbozhok
Copy link
Contributor Author

Sorry, I slightly messed up the commits, but everything is OK now.
I’d appreciate it if you could approve it again.

@olehbozhok olehbozhok enabled auto-merge (squash) February 4, 2025 16:19
@olehbozhok olehbozhok merged commit 9286f82 into main Feb 4, 2025
1 of 2 checks passed
@olehbozhok olehbozhok deleted the jans-cedaling-issue-10705 branch February 4, 2025 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-documentation Documentation needs to change as part of issue or PR comp-docs Touching folder /docs comp-jans-cedarling Touching folder /jans-cedarling kind-feature Issue or PR is a new feature request