Recently active topics

Hi, when I open a host's  ticket via open-tickets  using dashboard or via notification connector centreon_notification_centreon_opentickets_api.pl , only the host receives the ACK, even though the default acknowledgement configuration is set to “acknowledge services attached to the host”.My idea is to make the open-tickets ACK to respect the default acknowledgement configuration for hosts, or this parameter should be configurable within the provider rule.

Hi, We have configured parent-child relationships between hosts, and we would like this parentage information to be visible somewhere in the Resources Status page.This could be implemented, for example, as:An additional column showing the parent/child relationship for each host, and/or Additional information displayed in the side panel when selecting a host/serviceThis would make it easier to quickly identify dependency relationships between hosts directly from the Resources Status view, without having to navigate to another page. Regards,Thomas

Hello. The MySQL/MariaDB connector stores the credentials in the monitored host's macros. The problem is that if I need to have a service that connects to the server of that monitored host but with another user, there is no way to override the "default" credentials from the host's macros. We have several MySQL servers with several databases and users in each that we need to monitor. So for now, you need to create a new monitored host (for the same server) with those credentials or use a modified command based on the one provided by the connector. Could it be possible to add that functionality (overriding the credential stored in the host) to the service templates for the MySQL/MariaDB connector? That also be consistent with how other connectors work, which allow to override macro's values stored in the host with its own macros or passed as options in the EXTRAOPTIONS macro (for example, hostname, protocol, port...). The connector allows to specify a database and port to connect to; it

 Almost exclusively, our team uses poller settings with checkboxed “Move Export Files”, “Restart Monitoring Engine” turned On as shown below: I’m not sure about other people’s needs, but the setting shown is so common during our daily operations, and especially when exports are very frequent - that is, when things don’t work as expected and Configuration File Export becomes a debugging tool - it is quite rare for us to use these checkboxes in a different setting. This proposal suggests implementing configuration settings for default states of the following UI elements:Checkboxes Monitoring Engine restart method and eventually, Post generation command,to improve the UX and make frequent daily exports as smooth as possible. Cumulatively in operations, this change would save a a lot of time and friction when services don’t work as expected and need more time to fix, while this page becomes an unnecessary mental burden in the process. Currently, in order to save us thousands of daily mouse

Context & Problem: In the new Dashboards, the "Group Monitoring" widget systematically displays all status badges (Down, Up, Critical, Warning, Ok) even when their count is 0.While the new Dashboard Engine is great, displaying these (0) values creates significant visual noise. When monitoring dozens of hostgroups, the screen becomes cluttered with green and red badges that don't actually require any action. It makes it much harder for operators to spot real alerts at a glance.In the legacy Custom Views, the old hostgroup-monitoring widget naturally hid these zero values, offering a much cleaner and efficient UX.Suggested Solution: Please add a simple toggle in the widget configuration panel (e.g., a checkbox: "Hide empty statuses" or "Hide counters at 0").When enabled, the React component would simply not render the badge if the count is exactly 0.Value: This small UI tweak would massively improve the readability of the Dashboards, reduce cognitive load for IT operators, and help t

 Hello, We are missing a way in the UI, where a list of services/templates can be found, filtered by a particular Command that is being referenced.The usage scenario is making sure that changes to the underlying Command do not break the existing hosts when they get regenerated in the future. The existing list of Commands with just a reference count is far from being fit for the purpose. Thank you. BR, Lubos MedovarskyScheidt & Bachmann 

Currently, MIB data is not sufficient, and it would be useful to be able to monitor the appliance and the buckets.Actuellement la MiB n'est pas suffisante et il serait intéressant de pouvoir superviser l'appliance et les buckets.

Hello.In VMware8 vCenter REST API there is the service template Vm-Count. Is it possible to add a filter for ESX, so the listing is just of the VMs the in the filtered ESX. Also, can this service template be added to the VMware8 ESX REST API?Regards

Bonjour,Les courbes de graphes sont actuellement adaptés pour une interface en mode “light” mais en mode “dark”, les courbes en gris, noir, bleu foncé, ne sont pas très visibles.Je sais qu’on peut changer les couleurs des courbes mais le changement s’applique aussi au mode “light” et donc changer une courbe noir en blanc va reporter le problème sur les utilisateurs en mode “light”.Est-il possible que les couleurs par défaut s’adaptent en fonction du mode choisi par l’interface ? Et/ou qu’il soit possible de choisir 2 couleurs différentes pour une même courbe, selon que l’interface est configurée en mode “light” ou “dark” ?Merci d’avance

As a user, I would like to know which parameters are actually applied from my template when it begins to be a complex configuration.Presently only the macros are displayed as inherited parameters, and I would like to have the others like the notification, the monitoring configuration, contact, etc.In that case, I will have a better understanding of my configuration and I will not set useless parameters that can break the principle of the template (like putting 5 minutes as a retry interval on my host even if it’s inherited by the template).

DescriptionCurrently, when a service inherits configuration values from a service template in Centreon, the inherited values are not clearly visible when viewing the service configuration.For example, when opening a service and navigating to sections such as Service Scheduling Options, Notification Scheduling Options, Service severity or URLs, the fields may appear empty or without any indication of the values inherited from the associated service template.To determine the actual configuration, the user must navigate to the related service template and open its settings separately.This makes it difficult to understand the effective configuration of a service and requires additional navigation between the service and its template.Proposed ImprovementDisplay the inherited values directly within the service configuration interface.Inherited settings should be visually distinguished from values explicitly configured on the service. For example:The interface should clearly distinguish the s

Sometimes the team that administrate Centreon is different from the ones that make the daily configuration, like adding new host.This could lead to some scenario where you have overused pollers and underused pollers.Maybe we can add a feature that could “lock a poller”:The default poller can not be locked and viceversa. You can’t see nor select a locked poller if you add a new host If you duplicate an host monitored by a locked poller, it will lbe monitored by the default. Thanks for reading!