c238e54808
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.
156 lines
5.5 KiB
Markdown
156 lines
5.5 KiB
Markdown
===================================
|
|
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](https://github.com/elabore-coop/maintenance-tools/issues). 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:
|
|
|
|
- Elabore (https://elabore.coop)
|
|
|
|
## Maintainer
|
|
|
|
This module is maintained by Elabore.
|