[IIS] Fix access log parsing on newer IIS 10 versions#17461
[IIS] Fix access log parsing on newer IIS 10 versions#17461muthu-mps merged 11 commits intoelastic:mainfrom
Conversation
ReviewersBuildkite won't run for external contributors automatically; you need to add a comment:
NOTE: https://github.com/elastic/integrations/blob/main/.buildkite/pull-requests.json contains all those details. |
|
@team Please run CI and approve if applicable. Thanks |
|
@claude and @muthu-mps for review. |
|
Claude finished @lalit-satapathy's task in 2m 26s —— View job PR Review Completed
I have approved this PR. The fix correctly addresses the IIS 10 access log parsing issue where response bytes were incorrectly being parsed into the event duration field on newer IIS versions (10.0.17763.1+). Key findings:
See my full review for technical details. --- | Branch: Why is Claude responding? | Type Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. |
There was a problem hiding this comment.
This is a well-implemented fix for IIS 10 access log parsing on newer versions (10.0.17763.1+).
Summary
The PR correctly addresses the issue where response bytes were being incorrectly parsed into the event duration field. The root cause was that newer IIS 10 versions added sc-bytes (response body bytes) and cs-bytes (request body bytes) fields to the log format, which weren't captured by any existing grok pattern.
Technical Analysis
The new grok pattern (now first in the patterns list):
- Correctly parses: timestamp, dest_ip, method, path, query, port, user, source_ip, user_agent, referrer, status, sub_status, win32_status, response_bytes, request_bytes, duration, [forwarded_ip]
- The previous matching pattern was missing the
http.response.body.bytesandhttp.request.body.bytesfields, causing the response bytes value to be incorrectly assigned to_temp_.duration
Changes Reviewed
- Ingest pipeline: New grok pattern added at the correct position (first)
- Test case: New log line added representing IIS 10.0.17763.1+ format
- Expected output: Correctly validates parsing with:
event.duration: 12000000(12ms × 1000000)http.response.body.bytes: 862954http.request.body.bytes: 907
- Version bump: 1.24.4 → 1.24.5 with appropriate changelog entry
The package passes elastic-package check.
Lower-priority observations (1)
💬 NITPICK Minor typo in changelog — packages/iis/changelog.yml:4
Why: Minor typo that doesn't affect functionality, but worth fixing for documentation quality
- description: Add a new grok pattern for access log parsing to fix parsing issues on newer IIS 10 versionsWhy is Claude responding? | Type @claude to interact further
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
|
@muthu-mps / @lalit-satapathy Any updates on when this PR is getting reviewed? |
|
@lalit-satapathy / @muthu-mps Still asking kindly for an update of the codeowner approval. Also could you please run CI tests, to make sure those work? |
|
@muthu-mps @lalit-satapathy Still asking for review for this PR. Its been 2 months now. |
|
If the missing CI tests are an issue, I would request you to run them, as I am not allowed to do so. |
|
/test |
@Alphayeeeet - Let me take a look. |
🚀 Benchmarks reportTo see the full report comment with |
|
@muthu-mps Could it be, that the CI status is not correctly reported? As far as I see, is the build succeeded or am I wrong? |
|
Ah I see, that because of the merge after the test. Could you please run CI again and merge if successful? Thanks |
|
/test |
|
/test |
💚 Build Succeeded
History
|
|
Package iis - 1.24.5 containing this change is available at https://epr.elastic.co/package/iis/1.24.5/ |
Please label as bugfix
Proposed commit message
Fix access log parsing on newer IIS 10 versions
During newest IIS updates, the access log parsing was broken and response bytes have been falsely inserted into the event duration field.
This PR introduces a new grok pattern in the access log parsing ingest pipeline, to support the changed log format that IIS introduced.
For reference:
Our broken IIS instances are Version 10.0.17763.1 (and probably any newer too).
As the log format changed silently, we didn't find the issue in the integration very easily. However after huge response times were shown in our dashboards, we debugged and found that another grok pattern falsely matched, and therefore values were parsed into wrong fields.
This PR fixes exactly this issue and introduced a new testcase line, to prevent any future breaking of this.