# Logs y métricas
Todo lo que tus unidades escriben en la salida estándar y en la salida de error se guarda, y se muestrean CPU, memoria y red. Ambos se conservan **30 días**, también para las unidades que ya se han retirado y para los Workloads que están parados.

## Logs

- **Todas las unidades juntas**, ordenadas por tiempo, o **una unidad** (viva o ya retirada) con `unit_id`.
- Cada línea lleva el número de hueco de su unidad, el nombre del contenedor y la encarnación (de qué pod viene), para distinguir un reinicio de otra copia.
- La **búsqueda** es una subcadena sin distinguir mayúsculas de hasta 200 caracteres. No es una expresión regular.
- Una página son 500 líneas por defecto, 2000 como máximo.
- Entre las líneas hay **marcas**: `pod_started`, `pod_replaced`, `pod_stopped`, `pod_lost`, `pod_torn_down`, `container_restarted` (con el motivo, por ejemplo `OOMKilled`) y `overflow`.

### Leer hacia atrás y seguir en directo

`direction=backward` (el valor por defecto) devuelve primero las líneas más nuevas y es como se abre un log y se retrocede. Devuelve el `next_cursor` para obtener la página anterior. `direction=forward` con el último `follow_cursor` devuelve lo escrito desde entonces; espera `poll_after_ms` entre consultas en lugar de fijar un intervalo. La guía [Lee los logs de un Workload](/es/guides/containers-logs) trae código ejecutable para ambos.

### El archivo de desbordamiento

Hasta **500 líneas por segundo por contenedor** (medidas en 10 segundos) van al almacén de logs y se pueden buscar. No se descarta nada por encima de ese ritmo. Las líneas sobrantes se comprimen y se mueven a un archivo que se conserva los mismos 30 días, y el log muestra una marca donde ocurrió:

```text
[zaroz] 1234 lines over the log rate limit moved to archive
```

La marca incluye el rango de tiempo. La consola puede cargar ese rango desde la marca. La ruta de descarga de logs vuelve a mezclar en orden las líneas archivadas, así que una descarga está completa. El número de líneas desbordadas también es una gráfica en las métricas, `log_lines_archived`, así que un proceso que escribe sin parar se detecta fácilmente.

## Métricas

`GET .../units/metrics` devuelve, para 1 hora, 6 horas, 24 horas, 7 días o 30 días, 120 puntos equiespaciados por serie:

| ventana | cubeta |
|---|---|
| 1h | 30 segundos |
| 6h | 3 minutos |
| 24h | 12 minutos |
| 7d | 84 minutos |
| 30d | 6 horas |

Las series son `cpu` (milicores), `memory` (bytes), `network_in` y `network_out` (bytes por segundo) y `log_lines_archived`. Obtienes el Workload entero sumado y la línea propia de cada unidad (como máximo diez, empezando por el hueco más bajo); `omitted_units` dice cuántas se dejaron fuera. La línea de cada unidad tiene un `limit`, el techo contra el que se mide. Un Workload nuevo solo ofrece las ventanas de las que tiene historial (`available_windows`).

Cada respuesta trae una frase `coverage` que dice lo que realmente cubrió la lectura, por ejemplo cuando parte de los datos no estaba disponible. Muéstrala junto a la gráfica.

## El número de unidades

`GET .../units/count` dibuja cuántas unidades se ejecutaron en las mismas ventanas: el máximo y el mínimo en ejecución en cada cubeta, el máximo facturado como extra, el número que la plataforma quería y marcas de los cambios de escalado. Se construye con los mismos registros que la factura.

Por qué terminó una unidad está en `GET .../units/{unit_id}/terminations`.