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 ejemploOOMKilled) yoverflow.
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 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ó:
Code
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.