enh(clm): new plugin for centreon log management#5980
Open
enh(clm): new plugin for centreon log management#5980
Conversation
|
New Issues (10)Checkmarx found the following issues in this Pull Request
|
There was a problem hiding this comment.
Pull request overview
Adds a new Centreon plugin (apps::centreon::logmanagement::restapi) to query Centreon Log Management via its REST API and expose a log-count mode for thresholding on log volume over a period.
Changes:
- Added plugin entry point registering the
log-countmode and the REST API custom mode. - Implemented REST API custom mode to POST metric queries and decode JSON responses.
- Implemented
log-countmode and added usage documentation (README).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/apps/centreon/logmanagement/restapi/plugin.pm | Registers the new plugin mode and custom REST API handler. |
| src/apps/centreon/logmanagement/restapi/custom/api.pm | Implements the CLM REST API client (options, request, JSON parsing). |
| src/apps/centreon/logmanagement/restapi/mode/logcount.pm | Implements log count retrieval/parsing and exposes counter + thresholds. |
| src/apps/centreon/logmanagement/restapi/README.md | Documents usage, parameters, request/response, and errors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+91
to
+115
|
|
||
| # Parse the response to extract the count from curves->data[0] | ||
| if (defined($result->{curves}) && ref($result->{curves}) eq 'ARRAY' && @{$result->{curves}} > 0) { | ||
| my $first_curve = $result->{curves}->[0]; | ||
| if (defined($first_curve->{data}) && ref($first_curve->{data}) eq 'ARRAY' && @{$first_curve->{data}} > 0) { | ||
| $count = $first_curve->{data}->[0]; | ||
| # Convert to integer if it's a float like 0.0 | ||
| $count = int($count) if $count =~ /\.\d+/; | ||
| } | ||
| } | ||
|
|
||
| # If we still don't have a count, try fallback methods | ||
| if ($count == 0) { | ||
| # Try alternative response structures | ||
| if (defined($result->{data}->{count})) { | ||
| $count = $result->{data}->{count}; | ||
| } elsif (defined($result->{count})) { | ||
| $count = $result->{count}; | ||
| } elsif (defined($result->{result}->{count})) { | ||
| $count = $result->{result}->{count}; | ||
| } | ||
| } | ||
|
|
||
| # If we still can't find the count, show debug info and exit | ||
| if ($count == 0 && (!defined($result->{curves}) || !@{$result->{curves}})) { |
There was a problem hiding this comment.
The parsing logic defaults to 0 when curves exists but curves->[0]{data} is missing/empty, which can silently report "0 logs" for an unexpected response. Track whether a count value was actually found (e.g., with a boolean/defined check on data->[0]) and raise a critical error when the expected field is absent, instead of relying on $count == 0.
Suggested change
| # Parse the response to extract the count from curves->data[0] | |
| if (defined($result->{curves}) && ref($result->{curves}) eq 'ARRAY' && @{$result->{curves}} > 0) { | |
| my $first_curve = $result->{curves}->[0]; | |
| if (defined($first_curve->{data}) && ref($first_curve->{data}) eq 'ARRAY' && @{$first_curve->{data}} > 0) { | |
| $count = $first_curve->{data}->[0]; | |
| # Convert to integer if it's a float like 0.0 | |
| $count = int($count) if $count =~ /\.\d+/; | |
| } | |
| } | |
| # If we still don't have a count, try fallback methods | |
| if ($count == 0) { | |
| # Try alternative response structures | |
| if (defined($result->{data}->{count})) { | |
| $count = $result->{data}->{count}; | |
| } elsif (defined($result->{count})) { | |
| $count = $result->{count}; | |
| } elsif (defined($result->{result}->{count})) { | |
| $count = $result->{result}->{count}; | |
| } | |
| } | |
| # If we still can't find the count, show debug info and exit | |
| if ($count == 0 && (!defined($result->{curves}) || !@{$result->{curves}})) { | |
| my $count_found = 0; | |
| # Parse the response to extract the count from curves->data[0] | |
| if (defined($result->{curves}) && ref($result->{curves}) eq 'ARRAY' && @{$result->{curves}} > 0) { | |
| my $first_curve = $result->{curves}->[0]; | |
| if (defined($first_curve->{data}) && ref($first_curve->{data}) eq 'ARRAY' && @{$first_curve->{data}} > 0) { | |
| my $first_value = $first_curve->{data}->[0]; | |
| if (defined($first_value)) { | |
| $count = $first_value; | |
| # Convert to integer if it's a float like 0.0 | |
| $count = int($count) if (!ref($count) && $count =~ /\.\d+/); | |
| $count_found = 1; | |
| } | |
| } | |
| } | |
| # If we still don't have a count, try fallback methods | |
| if (!$count_found) { | |
| # Try alternative response structures | |
| if (defined($result->{data}) && ref($result->{data}) eq 'HASH' && defined($result->{data}->{count})) { | |
| $count = $result->{data}->{count}; | |
| $count_found = 1; | |
| } elsif (defined($result->{count})) { | |
| $count = $result->{count}; | |
| $count_found = 1; | |
| } elsif (defined($result->{result}) && ref($result->{result}) eq 'HASH' && defined($result->{result}->{count})) { | |
| $count = $result->{result}->{count}; | |
| $count_found = 1; | |
| } | |
| } | |
| # If we still can't find the count, show debug info and exit | |
| if (!$count_found) { |
Comment on lines
+114
to
+118
| # If we still can't find the count, show debug info and exit | ||
| if ($count == 0 && (!defined($result->{curves}) || !@{$result->{curves}})) { | ||
| $self->{output}->output_add(long_msg => "API response: " . JSON::XS->new->utf8->encode($result), debug => 1); | ||
| $self->{output}->option_exit(exit_litteral => 'critical', short_msg => "Cannot find log count in API response"); | ||
| } |
There was a problem hiding this comment.
The "cannot find log count" guard only triggers when curves is undefined/empty; if curves is present but doesn't contain a usable count (e.g., empty data), the mode will still return 0. Consider basing this check on whether a count was successfully extracted (defined/looks_like_number) rather than on curves presence.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
github-actions
bot
added
skip-workflow-plugins
and removed
skip-workflow-plugins
labels
github-actions
bot
added
skip-workflow-plugins
and removed
skip-workflow-plugins
labels
github-actions
bot
added
skip-workflow-plugins
and removed
skip-workflow-plugins
labels
|
@Nohzoh Should there also be a mode to retrieve Alert Events counts by status (with ability to filter on status)? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Community contributors
Description
This pull request introduces a new Centreon plugin for monitoring log counts from Centreon Log Management via its REST API.
It includes the implementation of the plugin framework, the API integration, the log count mode, and comprehensive documentation.
The most important changes are:
New Plugin Implementation
plugin.pm, which registers thelog-countmode and sets up the custom API mode for Centreon Log Management REST API integration.API Integration
custom/api.pm, handling authentication, parameter validation, HTTP requests, error handling, and JSON response parsing for the Centreon Log Management REST API.Log Count Mode
mode/logcount.pmmode, which queries the API for log counts based on user-specified queries and periods, extracts the count from the API response, supports threshold checking, and provides error handling for unexpected responses.Documentation
README.mdexplaining plugin usage, parameters, API request/response formats, and error handling, including example invocations.Type of change
How this pull request can be tested ?
To test the new plugin, follow the Readme instructions.
Checklist