# Repaso sesión 5

### **Limpieza de datos históricos en InfluxDB**

Para eliminar datos históricos en InfluxDB 2.x, utiliza el comando CLI `influx delete` o el endpoint `/api/v2/delete`. Puedes especificar el bucket, el rango temporal (`--start` y `--stop`), y opcionalmente un predicado para filtrar por measurement o tags. No es posible borrar datos por field directamente. Los datos eliminados dejan de estar disponibles para consulta, pero permanecen en disco hasta que el proceso de compactación los elimina físicamente.

**Ejemplo CLI:**

{% code title="text" overflow="wrap" %}

```bash
influx delete --bucket mediciones_sensores \
  --start '2024-06-01T00:00:00Z' \
  --stop '2024-06-14T00:00:00Z' \
  --predicate '_measurement="sensor01" AND ubicacion="ubicacionA0"'
```

{% endcode %}

***

### **Principal limpieza de datos históricos**

La principal automatización de limpieza se realiza mediante políticas de retención (Retention Policies, RP). InfluxDB elimina automáticamente los shards completos que exceden el tiempo definido en la RP. Configura la duración de la RP según la necesidad de retención de tus datos. Para tareas más complejas, puedes crear scripts periódicos que ejecuten comandos de borrado por rango temporal o tags.

***

### **Recomendaciones de shard**

* **Duración del shard:** La duración óptima depende de la frecuencia de escritura y el período de retención. Shards más cortos permiten eliminar datos antiguos más eficientemente, pero demasiados shards pueden afectar el rendimiento y el uso de memoria.
* **Ejemplo práctico:** Si tu RP es de 30 días, una duración de shard de 7 días es común. Para retención diaria, shards de 1 hora pueden ser útiles. Para retenciones largas, considera shards mensuales para evitar tener miles de shards pequeños.

***

### **Diagnóstico InfluxQL con Explain Analyze**

El comando `EXPLAIN ANALYZE` en InfluxQL ejecuta la consulta y devuelve un árbol con métricas de rendimiento: tiempo de planificación, tiempo de ejecución, tipo de iteradores y estadísticas de bloques leídos. Es fundamental para identificar cuellos de botella en consultas complejas.

**Ejemplo:**

{% code title="InfluxQL" overflow="wrap" %}

```sql
EXPLAIN ANALYZE SELECT mean("temperatura") FROM "ambiente" WHERE time >= '2023-06-06T00:00:00Z' AND time <= '2023-06-07T23:59:59Z'
```

{% endcode %}

* **execution\_time**: Tiempo total de ejecución de la consulta.
* **planning\_time**: Tiempo dedicado a planificar la consulta.
* **Iteradores y cursores**: Indican cómo InfluxDB accede y procesa los datos.

***

### **Diagnóstico Flux con Profiler**

Flux dispone del paquete `profiler` para analizar el rendimiento de las consultas. Puedes habilitar los perfiles `query` y `operator` para obtener métricas detalladas sobre la ejecución global y por operación.

**Ejemplo de uso:**

{% code title="Flux" overflow="wrap" %}

```
import "profiler"
option profiler.enabledProfilers = ["query", "operator"]

// Tu consulta Flux aquí
```

{% endcode %}

* **query profiler**: Estadísticas globales (duración total, compilación, planificación, ejecución, memoria usada, errores).
* **operator profiler**: Métricas por cada operación de la consulta (tipo, cantidad, duración mínima/máxima/promedio).

***

### **Qué revisar en las ejecuciones con Profiler**

* **TotalDuration**: Tiempo total de la consulta.
* **CompileDuration, PlanDuration, ExecuteDuration**: Identifica si el cuello de botella está en la compilación, planificación o ejecución.
* **Concurrency**: Número de goroutines utilizadas (funciones o métodos que se ejecutan concurrentemente en Go, permitiendo realizar operaciones de la consulta sin bloquear el flujo principal del programa).
* **MaxAllocated/TotalAllocated**: Uso máximo y total de memoria.
* **RuntimeErrors**: Errores durante la ejecución.
* **Para operator profiler**: Observa operaciones con duración desproporcionada o alta cantidad de ejecuciones.

***

### **Configuración de alertas en InfluxDB 2.x y comparación con Kapacitor**

### **InfluxDB 2.x**

* Incluye alertas nativas y la gestión de notificaciones desde la propia interfaz.
* Permite definir reglas, umbrales y acciones (correo, Slack, etc.) sin depender de Kapacitor.
* Las notificaciones pueden configurarse para múltiples endpoints, aunque algunas integraciones específicas pueden requerir soluciones externas.

### **Kapacitor**

* Era el componente de alertas en el stack TICK (InfluxDB 1.x).
* Permite scripts avanzados de procesamiento y alertado, integración con múltiples servicios y lógica compleja.
* En InfluxDB 2.x, muchas funciones de alertas básicas están integradas, pero Kapacitor sigue siendo útil para flujos complejos o integraciones no soportadas nativamente.

***

### **Resumen de comparación**

| Característica      | InfluxDB 2.x Alertas Nativas | Kapacitor (1.x/2.x)         |
| ------------------- | ---------------------------- | --------------------------- |
| Configuración       | Interfaz web, API            | Scripts TICK, configuración |
| Integraciones       | Limitadas, extensibles       | Amplias, personalizables    |
| Complejidad         | Baja (alertas simples)       | Alta (flujos complejos)     |
| Dependencia externa | No                           | Sí                          |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://darioaplicano.gitbook.io/influxdb2.x/sesion-6/guion-de-la-sesion/documentacion/repaso-sesion-5.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.