Bug 62885 - AccessLogSampler Parser for AWS load balancer
Summary: AccessLogSampler Parser for AWS load balancer
Status: NEEDINFO
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.0
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-05 14:00 UTC by paulca
Modified: 2018-11-09 20:59 UTC (History)
1 user (show)



Attachments
AWS ALB LOG SNIPPET (43.97 KB, text/plain)
2018-11-05 14:01 UTC, paulca
Details
Add more http methods for parsing log files (9.64 KB, patch)
2018-11-08 19:47 UTC, Felix Schumacher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description paulca 2018-11-05 14:00:31 UTC
Hi , I've just found your access log sampler, and think it's fantastic. I can now run a load test from prod in QA , which is great.

I then thought I'd do the same with our AWS site , and discovered the standard parsers do not handle the AWS ALB log format very well. I've attached a small snippet of an AWS ALB access log .... any chance you could knock up a parser for it ?
Comment 1 paulca 2018-11-05 14:01:26 UTC
Created attachment 36244 [details]
AWS ALB LOG SNIPPET
Comment 2 Felix Schumacher 2018-11-08 19:03:00 UTC
Can you elaborate a bit more on what is not working for you? Is it the OPTIONS http verb or something entirely different?
Comment 3 Felix Schumacher 2018-11-08 19:47:25 UTC
Created attachment 36252 [details]
Add more http methods for parsing log files

The attached patch adds all the http methods, that are available in the HTTPSamplerBase. OPTIONS is one of them, so the AWS log files should be parseable with this patch.
Comment 4 Philippe Mouawad 2018-11-08 21:27:06 UTC
Hi Felix, 
Thanks for the patch.
Wouldn't it be an occasion to rename the TCLogParser so that they respect naming conventions ? 
Maybe before applying the patch so that it's clear ?

Thanks
Comment 5 Felix Schumacher 2018-11-09 20:59:51 UTC
Renaming is probably not a good idea, since the class seems to be intended to be used for subclassing.

Having slept a night about the changes, I am not so sure anymore, that is OK to add more methods by default, as those could change existing tests. So I think it would be better to introduce a new property that allows more methods, or add a variable to the bean, that would be used for configuration.