Build better products with our product team.
Hi,There is any plan to implement a Connector to OCI?Currently we are migrating our systems to this cloud provider and I can’t see a way to integrate with this cloud provider to get alarms and metrics.It is very similar to AWS and Azure implementation.We need to get informations for Load Balancer, Computer Instances, Kubernets(OKE), Databases Intances and Logs/Annoucements.All of this informations can be get with OCI's native tool oci-cli or API.https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm
Le message de fermeture de ticket dans Open Ticket devrait dépendre du provider parce que dans mon cas, j’utilise Service Now et la fermeture des tickets n’est pas comprise dans les options et les superviseurs sont confus à chaque fois qu’ils voient ce message :
Persona:Centreon administratorProblem to solve:In the current Linux SSH – Files-Size mode, thresholds are calculated based only on the raw directory size in bytes. For directories subject to operational "soft limits" or logical growth policies (where no system-level quotas are enabled), the lack of a reference capacity makes percentage-based monitoring impossible. This requires administrators to manually recalculate byte-based thresholds whenever a logical limit is adjusted.Current behavior:The plugin retrieves the directory size using the du command via SSH but does not provide a parameter to define a reference capacity. Thresholds are strictly compared against absolute byte counts, and no percentage usage is calculated in the status output or performance data.Expected outcome:Allow the plugin to use a user-defined "Logical Maximum Size" as an optional reference for threshold calculation. Users could choose between: Default: Thresholds based on the raw directory size in bytes. Optional: Thresholds based on a percentage of a manually defined --max-size. Potential solutions: Add a new option (e.g., --max-size) to define the 100% reference value (supporting units like G, M, or bytes). Add a new option (e.g., --use-percentage) to interpret warning and critical inputs as percentage values of the maximum size. Enhance performance data by populating the "max" field of the size metric and adding a dedicated size_prct metric. Update the status output to display the usage ratio (e.g., "Used / Max (Usage %)"). Benefits / Impact: Scalability: Enables the use of generic Service Templates where only a capacity macro is adjusted per host. Operational Clarity: Provides intuitive feedback (percentage of a limit) rather than raw byte counts for operators.
Hello,I would like the name of a token to appear in the Administration logs section of the Centreon Cloud platform, perhaps by adding an additional column or through another method.This feature would be appreciated, especially when you have multiple tokens in production.
Right now when a use is on Centreon and wants to create a host, the only component they can use to decide what to implement is the Template select field.This is a little bit raw to let users discover what they want to install.In a similar way as Connectors or the new wizard for pollers, i would like to be able to let users go in a cleaner interface to choose what template they are looking to implement.This could take many forms as it’s more related to how the UI would show the information to the user and i’m unsure how easily we can structure this from the list of templates.But this is my idea, to avoid the hassle of the user going through documentation to find what host template to use, to prefer to stay on the centreon and go through a wizard to choose what template to integrate. What does the community think of this ?
referenced tohttps://github.com/centreon/centreon-plugins/issues/6117 I can add more information if required in github issue
Persona:Centreon administratorProblem to solve:In the current NetApp Ontap REST API – volumes mode, thresholds are calculated based only on the current volume size.For volumes with autogrow enabled, this makes percentage usage misleading since the effective limit is defined by the autosize maximum setting.Current behavior:The plugin retrieves size but does not consider the autosize object returned by the ONTAP REST API.Example from a production environment (anonymized):"autosize": { "maximum": 274877906944, "minimum": 10737418240, "grow_threshold": 85, "shrink_threshold": 50, "mode": "grow_shrink" } Expected outcome:Allow the plugin to use autosize.maximum as an optional reference for threshold calculation.Users could choose between: Default: thresholds based on the current volume size. Optional: thresholds based on the autosize.maximum value. Potential solutions: Extend the REST query to include autosize.maximum from /api/storage/volumes (API reference). Add a new option (e.g. --use-autosize-maximum or similar). Adjust perfdata labels to clearly distinguish between both reference types. Benefits / Impact: Enables accurate monitoring of autogrow volumes. Prevents false alerts when volumes expand automatically. Aligns threshold logic with NetApp’s operational behavior, improving reliability in large environments.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK