Support scraping multiple controllers. #27
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why? #26 (comment)
Why not auto-detect the controllers? To remain in the spirit of the current behavior of the exporter. Although a list is shown in the CLI along with usage help when run without any argument, there is no explicit CLI command to return the number of controllers. Running e.g.
sys info
for an increasing controller index until failure is noticed works but it is difficult to disambiguate a non-existing controller from a failed run (which are metric reported and skipped) without introducing fragility. It seems simpler and sufficient to have this number specified.numctrl=<n>
param support appears present in all CLI versions found at ftp://ftp.areca.com.tw/.Tested, on system with 3 controllers:
--controllers 2
,--controllers 3
works as expected. Allareca_...
metrics (but the implicitareca_exporter_build_info
) are reported with a newcontroller_index=<n>
label (controller_index
was preferred overcontroller
b/c there's an existingcontroller_name
). E.g.:--controllers 4
behaves like--controllers 3
but with additional error logs and metrics for the fourth controller: