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

About parameter full_search_strategy in drain match method #68

Closed
doudoublues opened this issue Aug 24, 2022 · 12 comments
Closed

About parameter full_search_strategy in drain match method #68

doudoublues opened this issue Aug 24, 2022 · 12 comments
Assignees
Labels
question Further information is requested

Comments

@doudoublues
Copy link

As the comments said
(3) "always" is the slowest. It will select the best match among all known clusters, by always evaluating all clusters with the same token count, and selecting the cluster with perfect all token match and least count of wildcard matches.

I have two clusters as below, one has wildcard and another not
1

And I have a log to be matched
IPPROTO_TCP fd: 100, errno: 100, option: 100, value: 100

After masked it become
IPPROTO_TCP fd <NUM> errno <NUM> option <NUM> value <NUM>
And I use "always" strategy, as the comments said, I should get the cluster(id=1) which has least wildcard, but I get result

ID=2 : size=1 : IPPROTO_TCP fd <NUM> errno <NUM> option <NUM> value <*>
So I read the code in fast_match, and I found this code seg will always return the cluster which has most param_count, is it wrong?

2

Should I modified it like this

3

@davidohana
Copy link
Collaborator

What you suggest makes sense to me. However I checked also the original Drain code here: https://github.com/logpai/logparser/blob/e8d96cd4de1121c5d2b517982c6028cd06e643f1/logparser/Drain/Drain.py#L172 and the same max-param-count selection logic exists, so it's not a translation bug. I also read the part of the Drain paper https://jiemingzhu.github.io/pub/pjhe_icws2017.pdf on page 4 (step 4), but unfortunately, the text does not describe what happens in a case of equal similarity score.
I think best action now is to check with original Drain authors the reason for this logic, before making any change.

@davidohana davidohana self-assigned this Aug 25, 2022
@davidohana davidohana added the question Further information is requested label Aug 25, 2022
@davidohana
Copy link
Collaborator

Actually while writing an issue to the Drain team, I think I understand the reason. Follow this example:

For the two templates:

request type <*> result <*> took <*> <*>
request type create result <*> took <*> ms

and log message:

request type delete result OK took 0.21 sec

Equal tokens to the 1st template = 4, param count in first message = 4
Equal tokens to the 2nd template = 4, param count in first message = 2

Here the message has a bettter match with 1st template.

@davidohana
Copy link
Collaborator

Also, something in your first example does not make sense.
You provide IPPROTO_TCP fd: 100, errno: 100, option: 100, value: 100 with : in some tokens, but the templates does not contain :, e.g IPPROTO_TCP fd <NUM> errno <NUM> option <NUM> value <NUM>. So this is not a perfect match. and therefore match should fail.

@doudoublues
Copy link
Author

while enbale include_param=True,the similarity 1st template is (4+4)/ 8 = 1.0, the sim of 2st template is (4+2) / 8 = 0.75, it will not go to the logical comparsion cur_sim == max_sim and param_count > max_param_count.

@doudoublues
Copy link
Author

for this case IPPROTO_TCP fd: 100, errno: 100, option: 100, value: 100, we have set extra_delimiters = [':', '@', '&', '[', ']', '(', ')', ',', '=', '{', '}', ';', '!', '?'] which include : .

@davidohana
Copy link
Collaborator

But the template has 9 tokens, not 8 ?
Also, you want to match against the first template so isn't this the expected behavior?

@doudoublues
Copy link
Author

But the template has 9 tokens, not 8 ? Also, you want to match against the first template so isn't this the expected behavior?

what I want to talk about is when two template has same similarity, the one with less wildcards will be match. But in this case, when we enable include_param=True, the similariteis of 1st and 2nd template is not equal, it will not go to the logical comparsion cur_sim == max_sim and param_count > max_param_count.

@davidohana
Copy link
Collaborator

include_param=True by default in match(), so the behavior is fine as I understand.
Closing this issue.

@doudoublues
Copy link
Author

include_param=True by default in match(), so the behavior is fine as I understand. Closing this issue.

I know, So that in my cases,

IPPROTO_TCP fd: 100, errno: 100, option: 100, value: 100

two template similarity is 1.0, we should choose 1st template which has no wildcard, but drain it return the 2st template.

ID=2 : size=1 : IPPROTO_TCP fd <NUM> errno <NUM> option <NUM> value <*>

@davidohana
Copy link
Collaborator

#68 (comment)

This is an example where more params is the better choice.

@doudoublues
Copy link
Author

Got it, but it didn't work on my case. Is it something wrong in its logic? In other words, I think when two template both get 1.0 similarity score, the template has the less wildcard will be match, isn't it? But drain doesn't work on this case.

@davidohana
Copy link
Collaborator

If you want, you can provide a sample code that reproduces the problem in a branch, and I will check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants