Elabore/maintenance-tools
9
0
Fork 0
Code Issues Pull Requests Actions Packages Releases Activity
Files
c238e548087ddbe3fb00cce6743ade6eb976f882
maintenance-tools/maintenance_service_http_monitoring/README.md
Stéphan Sainléger c238e54808 [IMP] maintenance_service_http_monitoring: rework maintenance.request creation 
Previously, a single ``maintenance.request`` was created per equipment,
regardless of how many services were down on that equipment. The name
was ``[HTTP KO] {equipment.name}`` and deduplication relied on a
name+date+equipment search that was fragile (manual clear of the field
would lose the reference to an existing open request).

This commit reworks the whole creation logic:

- **1 request per KO service** instead of 1 per equipment. Each failing
  ``service.instance`` gets its own ``maintenance.request``, allowing
  fine-grained tracking and independent resolution.

- **Request name** is now ``[HTTP KO] {service_url}``, making it
  immediately identifiable without opening the record.

- **Description** includes the error detail: ``HTTP {status_code}`` for
  HTTP errors, or a human-readable network error label when
  ``last_http_status_code == -1`` (timeout / DNS / SSL failures).

- **Deduplication** is now based solely on whether an open (non-done)
  ``maintenance.request`` already exists on the ``service.instance``
  via the new ``http_maintenance_request`` field. No date boundary —
  as long as the request is open, no new one is created.

- **``http_maintenance_request``** field moved from
  ``maintenance.equipment`` to ``service.instance``, where it belongs
  given the 1-request-per-service model. It is exposed as an optional
  hidden column in the service instance list view.

- ``_build_ko_services_description()`` is removed (no longer needed).

- ``create_http_maintenance_request()`` now receives a single
  ``service.instance`` recordset instead of a list.

Tests updated accordingly (14 tests total):
- Tests 2, 4, 9, 10, 12, 13 now assert on
  ``service_instance.http_maintenance_request``.
- Test 2 also verifies the request name contains the service URL and
  the description contains the HTTP status code.
- New test 14 asserts that two KO services on the same equipment
  produce two distinct requests with the correct names.
2026-06-15 17:47:25 +02:00

5.5 KiB
Raw Blame History

=================================== maintenance_service_http_monitoring

This module provides automated HTTP availability monitoring for services defined on maintenance equipment. It periodically checks the HTTP status of service URLs and automatically creates maintenance requests when services are detected as unavailable.

Key features:

  • Automated HTTP checks: Scheduled cron job checks all active services
  • Maintenance mode: Temporarily disable monitoring during planned maintenance
  • Automatic maintenance requests: Creates corrective maintenance requests when services fail HTTP checks
  • Status tracking: Records last HTTP status code and check date per service

Installation

Use Odoo normal module installation procedure to install maintenance_service_http_monitoring.

This module depends on:

  • maintenance
  • maintenance_server_data

Python dependencies: This module requires the requests library.

Configuration

Maintenance Mode Duration

By default, maintenance mode lasts 4 hours. To change this:

  1. Go to Settings > Technical > System Parameters
  2. Create or edit the parameter:
    • Key: maintenance_service_http_monitoring.maintenance_mode_duration
    • Value: Duration in hours (e.g., 8)

Cron Jobs

Two scheduled actions are installed:

  1. HTTP Service Monitoring: check all services

    • Runs every 15 minutes
    • Checks HTTP status of all active service instances with URLs

  2. HTTP Service Monitoring: deactivate expired maintenance mode

    • Runs every 15 minutes
    • Automatically disables maintenance mode when the end time is reached

Webhook Notifications

Go to Settings > Technical > Parameters > System Parameters and configure:

+--------------------------------------------------------+----------------------------------------+ | Key | Description | +========================================================+========================================+ | maintenance_service_http_monitoring.webhook_url | Webhook URL (POST endpoint) | +--------------------------------------------------------+----------------------------------------+ | maintenance_service_http_monitoring.webhook_user | Basic Auth username (optional) | +--------------------------------------------------------+----------------------------------------+ | maintenance_service_http_monitoring.webhook_password| Basic Auth password (optional) | +--------------------------------------------------------+----------------------------------------+

Usage

Monitoring Services

Services are automatically monitored if they have:

  • A service URL defined
  • An associated equipment
  • The equipment is not in maintenance mode
  • The service instance is active

The monitoring checks HTTPS availability (HTTP URLs are automatically upgraded to HTTPS). A service is considered OK if it returns HTTP 200.

Using Maintenance Mode

When performing planned maintenance on a server:

  1. Go to Maintenance > Equipments
  2. Open the equipment record
  3. Click "Activer le mode maintenance" (Activate maintenance mode)
  4. HTTP monitoring is suspended for this equipment
  5. The mode automatically expires after the configured duration
  6. Or click "Désactiver le mode maintenance" to end it manually

Viewing HTTP Status

On service instances, you can see:

  • Last HTTP Status Code: The last received HTTP status (200, 404, 500, etc.)
  • Last HTTP Check Date: When the last check was performed
  • HTTP Status OK: Quick visual indicator of service health

Automatic Maintenance Requests

When a service fails HTTP checks:

  • A corrective maintenance request is created per failing service, named [HTTP KO] {service_url}
  • The request description includes the error detail: the HTTP status code, or a network error label (timeout / DNS / SSL) when no HTTP response was received
  • No duplicate is created as long as an open request already exists for that service
  • A double-check is performed before creating the request: the service is retested after 2 seconds. A maintenance request is only created if the service fails both checks, reducing noise from transient HTTP errors

Webhook notifications

When a new maintenance request is created (HTTP check failure), the module can send a webhook notification to an external service (e.g., n8n, Rocket.Chat, Slack).

The webhook sends a JSON POST with the following structure::

{
    "id": 42,
    "name": "[HTTP KO] Server Name",
    "priority": "2",
    "description": "Service KO: https://example.com",
    "equipment": "Server Name",
    "link": "https://odoo.example.com/web#id=42&model=maintenance.request&view_type=form"
}

Known issues / Roadmap

  • Add configurable alert thresholds (e.g., alert after N consecutive failures)
  • Add email/notification on service failure
  • Support custom HTTP check endpoints (e.g., /health)
  • Add support for basic authentication

Bug Tracker

Bugs are tracked on our issues website. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback.

Credits

Contributors

  • Stéphan Sainléger

Funders

The development of this module has been financially supported by:

Maintainer

This module is maintained by Elabore.