For AI agents: the complete documentation index is available at https://docs.dataplatform.ovh.net/llms.txt, the full documentation bundle is available at https://docs.dataplatform.ovh.net/llms-full.txt, and this page is available as Markdown at https://docs.dataplatform.ovh.net/control-center-alerting-health-checks.md.
  • 🇬🇧 English

    • Configure a health check alert

    Alerts can be set to monitor metrics of deployed instances on the Platform, such as the status of APIs or the CPU usage of a query engine

    Objective

    Alerts can be set to monitor metrics of deployed instances on the Platform, such as the status of APIs or the CPU usage of a query engine. They are called health check alerts on the Platform.

    alerts

    A health check alert is configured by specifying a target as well as trigger conditions and triggering options.

    Configure the target of the alert

    When creating a new health check alert, it is necessary to choose the type of deployment to monitor. The following types are available:

    If not done already, you also need to choose the Project in which to create the alert.

    alerts

    If you choose to monitor one specific object (app, API, etc..), the alert will only be triggered if that specific instance meets the trigger conditions.
    For example in the screenshot below, the alert will only be triggered if API "public" uses more than 99% of its RAM for more than 1 minute.

    alerts

    Configure the trigger conditions of the alert

    A trigger condition on an alert is a logical statement made of a metric, an operator, and a value. Multiple conditions can be added to the same alert: in that case, they will be combined with an AND condition. At each evaluation loop - occurring every minute - the Platform runs the expression defined in each alert trigger. The alert's status is thus changed to active if all trigger conditions are and stay true for longer than the waiting period of the alert (configurable downstream in the process).

    To add a new trigger condition, press Add in the corresponding panel.

    alerts

    Triggers can be set on the following metrics for deployed instances:

    • Status: an alert will be raised if the monitored target is unavailable (for value DOWN).
      • Note that status DOWN will not raise an alert if the monitored target is stopped/rebooted manually by a user
    • CPU usage (in %): an alert will be raised if the CPU used by the monitored target goes above/below a certain threshold
    • RAM usage (in %): an alert will be raised if the memory used by the monitored target goes above/below a certain threshold
    • Log detection (coming soon!)

    Configure the triggering options of the alert

    The triggering options are used to specify how exactly is the alert triggered, based on the trigger set above, and how are notifications sent to subscribers.

    Specify the waiting period for the alert

    The waiting period is the duration during which the alert's triggers must stay true for the alert to be effectively triggered.

    alerts

    This optional parameter causes the Platform to wait for a certain duration between first meeting the trigger condition of the alert (like an instance with a high CPU usage) and counting the alert as active.

    If this duration is 0 (default value), the alert will immediately be triggered to an active status as soon as the trigger conditions are all true.
    If it is higher than 0, the alert will stay in watching status until enough evaluation loops that keep validating the trigger condition are performed by the Platform to reach this waiting duration, after which it will be triggered to an active status

    Info

    Let's take the example of an alert on CPU usage > 99% for an API, where such duration is set to 5 minutes. The first time that the CPU goes above the threshold of 99%, an invisible countdown of 5 minutes will begin. If the CPU stays above 99% for more than 5 minutes, then the alert will transition to active.

    Info

    Since the Platform only evaluates trigger conditions every minute, it may take a few more seconds (up to one minute) of delay on top of the waiting duration before the system effectively acknowledges the alert has being triggered.

    Specify the notification frequency

    For each alert, it is possible to either:

    • notify the subscribers only once at the moment of triggering (when the alert transitions to active state). Subscribers won't be notified again until the alert is resolved and triggered again.
    • notify the subscribers regularly as long as the alert is active. You can set the frequency of notification per alert.

    It is also possible to activate resolution notifications. This will send a notification to all subscribers when the alert is resolved - which happens automatically as soon as the evaluated trigger condition is no longer verified.

    Go further

    If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.

    Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated Discord channel.

    If you need support with your OVHcloud services, create a request in our Help Centre.

    Join our community of users.