in_windows_exporter_metrics: Implement user-defined performance counters w/ PDH#12006
Conversation
📝 WalkthroughWalkthroughAdds a Windows PerformanceCounter collector, its PDH-backed registration and sampling code, and plugin wiring for configuration, scheduling, lifecycle, and metric publication. ChangesWindows PerformanceCounter collector
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c15919bfb9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/in_windows_exporter_metrics/we_performancecounter.c`:
- Around line 397-403: The PDH query open failure path in
we_performancecounter_init should return a non-zero failure code instead of 0 so
the caller can reject the collector initialization. Update the error branch
after PdhOpenQueryW in we_performancecounter_init to propagate failure
consistently with the rest of the init flow, ensuring we.c sees the
initialization as failed and does not leave the plugin enabled in a broken
state.
- Around line 187-192: The allocation-failure path in add_counter_path() is
freeing caller-owned metric_name, which later gets freed again by add_counter()
and the wildcard path. Update the failure handling around the counter allocation
in add_counter_path() so it only releases memory owned by that function (such as
path_w) and leaves metric_name for the caller to free after the return value is
handled.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 97d64cad-0c95-45b4-ab8b-42988ebb7055
📒 Files selected for processing (5)
plugins/in_windows_exporter_metrics/CMakeLists.txtplugins/in_windows_exporter_metrics/we.cplugins/in_windows_exporter_metrics/we.hplugins/in_windows_exporter_metrics/we_performancecounter.cplugins/in_windows_exporter_metrics/we_performancecounter.h
…ers w/ PDH Signed-off-by: Hiroshi Hatake <hiroshi@chronosphere.io>
c15919b to
eb7ae2d
Compare
In the current implementation of windows exporter metrics, we do not provide user-defined PerformanceCounter query capability.
So, it'll be useful to define an arbitrary query not to be implemented by default.
Enter
[N/A]in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-testlabel to test for all targets (requires maintainer to do).Documentation
fluent/fluent-bit-docs#2610
Backporting
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.
Summary by CodeRabbit
New Features
Bug Fixes