Servicio target_lifecycle — un solo camino para borrar y desactivar MonitoringTarget

Descripción

Módulo: monitoring/services/target_lifecycle.py (nuevo, 59 LOC)

Centraliza el ciclo de vida de baja de un MonitoringTarget en dos funciones. Antes la lógica de borrado estaba duplicada — y desincronizada — entre el endpoint DELETE /targets/{id} y el borrado en cascada de una ficha de dispositivo.

Introducido en la auditoría #261, ciclo 3 (task #264, PR #435, commit 39c13ea8):

• A21 — DELETE /targets/{id} purgaba grupos de incidencias vacíos (#250) y avisaba al Agente Local tras borrar, pero el botón “Delete” de la ficha de dispositivo (delete_profile_full) se limitaba a targets.delete() sin hacer ninguna de las dos cosas: tarjetas fantasma en ITSM y el Agente sondeando equipos que ya no existían.
• A23 — borrar un racks.Device dejaba su target huérfano (device=NULL por el SET_NULL del FK) pero activo y sondeado: un “target manual” que nadie había pedido.

Contrato

delete_targets(org, targets) -> int

Borra targets (queryset o lista) de org dejando el sistema coherente:

1. MonitoringTarget.objects.filter(organization=org, id__in=ids).delete().
2. purge_empty_groups(org) — limpia los grupos de IncidentGroup que el borrado en cascada de alertas/insights deja vacíos.
3. notify_agents(org.id) — el Agente Local no hace pull periódico; sin este aviso seguiría sondeando el target borrado hasta la próxima reconexión.

Devuelve cuántos targets se borraron; con lista vacía no toca la base de datos.

Llamadores: DELETE /api/monitoring/targets/{id} (monitoring/api/targets.py::delete_target) y delete_profile_full (network/api/profiles.py, borrado en cascada desde la ficha de dispositivo) — mismo camino, mismo comportamiento.

disable_targets_of_device(device) -> int

Desactiva (enabled=False) los targets de device sin borrarlos — conserva el histórico de métricas y alertas. Si más tarde un Device con la misma IP de gestión vuelve a existir, MonitoringTarget.get_or_create_for_device lo reactiva por el invariante “gestión de red válida → target activo”.

Llamador: señal pre_delete de racks.Device, conectada en MonitoringConfig.ready() (monitoring/apps.py). Se usa pre_delete — no post_delete — porque en post_delete el SET_NULL del FK ya habría desvinculado el target, y no podría localizarse por device_id.

Dependencias

• monitoring.models.MonitoringTarget — entidad operada por ambas funciones.
• monitoring.api.common.notify_agents — aviso al Agente Local (import diferido para evitar ciclo de imports).
• monitoring.services.correlation_service.purge_empty_groups — limpieza de IncidentGroup tras el borrado (#250).
• racks.models.Device — dispara disable_targets_of_device vía señal pre_delete.

Ejemplo de uso

from monitoring.services.target_lifecycle import delete_targets

deleted = delete_targets(org, MonitoringTarget.objects.filter(organization=org, ip_address=ip))

Cambios relacionados del mismo PR

El mismo commit toca otros puntos del ciclo de vida de los targets que no viven en este módulo pero son parte de la misma auditoría: AutoConfigService.configure_observatory deja de pisar los flags del usuario (A51, ver entity--network--service--auto-config) y MonitoringTarget.get_or_create_for_device deja de reenlazar el target entre Devices con la misma IP (A52, ver entity--monitoring--model--monitoringtarget).

Véase también

• [[entity—monitoring—model—monitoringtarget]]
• [[entity—racks—model—device]]
• [[entity—network—service—auto-config]]
• [[entity—monitoring—service—provisioning]]
• [[entity—monitoring—service—reopen-group]]