MonitoringTarget · Modelo monitoring
Propósito
MonitoringTarget es la entidad central del subsistema CNS (CreaRack Network Sentinel). Representa un dispositivo o IP que el sistema observa periódicamente. Cada instancia define qué IP sondear, protocolos activos (ICMP, SNMP, HTTP) y cadencia. Cachea el último resultado para consultas rápidas sin releer histórico.
⚠️ El campo
scopeFUE ELIMINADO (Ficha Central F4, migración 0025): el target es 1:1 por host y la pertenencia a las páginas Wireless/UPS/Signage la decideDeviceProfile.assigned_page, no el target.
Contrato
Campos:
| Campo | Tipo | Default | Descripción |
|---|---|---|---|
name | CharField(100) | — | Nombre legible |
ip_address | GenericIPAddressField | — | IP monitorizada IPv4/IPv6 |
device | FK(racks.Device, SET_NULL, null) | — | Dispositivo de rack asociado (opcional) |
ping_enabled | BooleanField | True | Activa sondeo ICMP |
snmp_enabled | BooleanField | True | Activa polling SNMP |
http_enabled | BooleanField | True | Activa health check HTTP |
interval_seconds | IntegerField | 60 | Cadencia de polling por target (suelos por protocolo en el Agent) |
timeout_ms | IntegerField | 5000 | Timeout por check |
enabled | BooleanField | True | Habilitación global |
config | JSONField | {} | community SNMP, OIDs, interfaces uplink |
last_status | CharField(20) | unknown | unknown, up, down, degraded |
last_latency_ms | FloatField(null) | — | Última latencia medida |
last_packet_loss | FloatField(null) | — | Último packet loss |
last_check | DateTimeField(null) | — | Timestamp último check |
producer_state | JSONField(null) | None | A19 (Agente 2.24.0, migración 0033, 28-08-2026): por qué el Agente NO produce dato para este target, por bucle SNMP — {"bandwidth": {"reason": "no_counters", "since": ts, "ok_ts": ts|None}}. Lo manda el heartbeat del Agente (2.24.0+) solo para los targets que fallan; None = todo produce (o Agente viejo). Último valor, no historial — ver [[crearack-tech—architecture—sentinel-mode]] §4.2 |
organization | FK(Organization, CASCADE) | — | Tenant propietario |
Métodos y propiedades:
is_up—Truesilast_status == "up".monitor_types—list[str]de protocolos activos (ping,snmp,http).monitor_type— propiedad legacy; protocolo primario (snmp>http>ping).status_color— color CSS hex del estado actual.get_or_create_for_device(device, organization)(classmethod) — crea o recupera target vinculado a Device conhas_network_management=True; sincroniza IP y nombre, reactiva el target si estaba desactivado (enabled=True); maneja races conIntegrityError. Si la IP ya pertenece a OTRO Device (mismo org, distintodevice_id), NO reenlaza — el primer dueño se queda (auditoría #261 A52: evita que el target “salte” de dueño en cada render; el mismo guard se aplica enmonitoring/views.py::observatory_view).
Meta:
unique_together:[organization, ip_address]— un target por host y tenant (post-Ficha Central F4).ordering:["name"].- Índice compuesto
idx_target_org_enabledsobre(organization, enabled).
Dependencias entrantes
| Módulo | Archivo | Uso |
|---|---|---|
MonitoringAlert | monitoring/models.py | FK target — alertas configuradas |
AlertEvent | monitoring/models.py | FK target — eventos disparados |
DeviceProfile | network/models.py | FK linked_monitoring_target |
alert_service | monitoring/services/alert_service.py | Evalúa condiciones y crea AlertEvent |
AutoConfigService | network/services/auto_config.py | Crea/actualiza post-discovery |
views Observatory/Wireless/UPS/Signage | monitoring/views.py | Auto-provisiona en bulk |
RackService | racks/services/racks.py | Invoca AutoConfigService tras rack |
backup_service / restore | core/services/backup_service.py | Serializa targets |
workspace_api | core/workspace_api.py | Cuenta targets activos |
MonitoringConfig.ready() (señal pre_delete de Device) | monitoring/apps.py | Desactiva el target al borrar su Device — ver entity--monitoring--service--target-lifecycle |
target_lifecycle.delete_targets | monitoring/services/target_lifecycle.py | Camino único de borrado (DELETE /targets + delete_profile_full) |
AgentConsumer | terminal/consumers.py | _apply_producers() persiste producer_state desde el heartbeat del Agente |
Dependencias salientes
racks.Device— FK opcional; enlace físico.core.Organization— FK obligatoria.monitoring.MonitoringAlert— relación inversaalerts.
Ejemplos
- Creación desde discovery:
AutoConfigService().configure_observatory(profile)crea/actualiza el target del host, activasnmp_enabledsi soporta SNMP e inyecta OIDs/community enconfig(cifrado at-rest; servir siempre víapublic_config). - Desde rack:
MonitoringTarget.get_or_create_for_device(device, org)vincula dispositivo con gestión de red; si la IP cambia, actualiza. Si la IP ya está enlazada a OTRO Device, se queda como está (A52). - Bulk Wireless:
MonitoringTarget.objects.bulk_create(new_targets, ignore_conflicts=True)+ refetch porip_address__in. - Evaluación:
evaluate_and_trigger_alerts(target, latency_ms=12.5, packet_loss=0.0, status="up")itera alertas y crea AlertEvent si supera umbral. - Borrado de Device: al borrar un
racks.Device,pre_deletedesactiva (no borra) su target — conserva el histórico y lo reactiva si el Device vuelve con la misma IP. - Por qué no hay bandwidth (A19): si
producer_state.bandwidth.reason == "no_counters", el Observatory muestra “No bandwidth data: the device has no octet counters on interface N” en vez de dejar la gráfica vacía sin explicación.
Related
entity--racks--model--device— dispositivo físico al que puede estar vinculado.entity--monitoring--model--monitoringalert— reglas evaluadas sobre este target.entity--monitoring--service--target-lifecycle— ciclo de vida de baja (borrado y desactivación).crearack-tech--architecture--sentinel-mode— mecanismo A19 y scheduler del Agente que alimentaproducer_state.feature--monitoring--agente-2-24-0-task-270— release que introduce el campo.
Véase también
- [[entity—racks—model—device]]
- [[entity—monitoring—model—monitoringalert]]
- [[entity—monitoring—model—aiinsight]]
- [[entity—monitoring—service—target-lifecycle]]
- [[crearack-tech—architecture—sentinel-mode]]
- [[feature—monitoring—agente-2-24-0-task-270]]
Referenciado desde
- Agente · dev-observatory
- Agente 2.24.0 — task #270: rotación de logs, timeout de insights, y por qué no hay bandwidth (A19)
- AIInsight · Modelo monitoring
- Auditoría Suprema 2 · Cola monitoring D: rendimiento de deep-discovery y de Wireless/UPS
- Cambiar la IP de un equipo desde su ficha (readdress)
- CNS — CreaRack Network Sentinel
- Deduplicación de episodios de Sentinel — un insight por avería (v1.66.15)
- Device · Modelo racks
- DeviceTrashEntry · Modelo network
- Disponibilidad honesta: uptime_pct sale null si faltan más del 20% de las horas (v1.125.0)
- Incidente: Informante reportaba "0 alertas" con 128 devices caídos (s56)
- Local Agent v2.x
- Monitoring Tools — VictoriaMetrics, Prometheus
- Network Observatory - Documentación Técnica
- Papelera de dispositivos: borrar de todas partes y restaurar desde la Home
- Plan: Monitoreo en Tiempo Real + Sistema de MIBs Mejorado
- Registro de caídas y vueltas de cada equipo monitorizado (v1.169.0)
- Retirar el camino cloud de monitorización (batch-ping/snmp/http) y las tablas MetricSample/AggregatedMetric
- Servicio target_lifecycle — un solo camino para borrar y desactivar MonitoringTarget