Registro de logs

Última actualización: February 20, 2026

El registro de logs eficaz en entornos de Kubernetes es esencial para la visibilidad del sistema, la resolución de problemas y la auditoría de seguridad. Este documento abarca los fundamentos del registro de logs, la arquitectura del pipeline de recopilación de logs y las estrategias de registro de logs para entornos de EKS.

Tabla de contenidos

Fundamentos del registro de logs

Registro de logs estructurado

El registro de logs estructurado genera mensajes de log en un formato consistente, lo que facilita el análisis y el procesamiento. A diferencia de los logs de texto no estructurados, los logs estructurados constan de pares campo-valor que permiten búsquedas y filtrados mucho más eficientes.

Logs no estructurados frente a estructurados

plaintext

# Unstructured log (difficult to parse)
2025-02-15 10:23:45 ERROR Failed to connect to database: connection timeout after 30s

# Structured log (JSON format)
{
  "timestamp": "2025-02-15T10:23:45.123Z",
  "level": "ERROR",
  "message": "Failed to connect to database",
  "error": "connection timeout",
  "timeout_seconds": 30,
  "service": "user-api",
  "pod": "user-api-7d4f8b9c6-x2k9m",
  "namespace": "production",
  "trace_id": "abc123def456"
}

Beneficios del registro de logs estructurado

Beneficio	Descripción
Eficiencia de búsqueda	Filtrado rápido por campos específicos
Consistencia	Mismo formato en todos los servicios
Análisis de correlación	Seguimiento de solicitudes mediante trace_id, request_id
Automatización	Uso inmediato en herramientas de análisis sin procesamiento
Configuración de alertas	Fácil creación de reglas de alerta según valores de campos específicos

Niveles de log

Los niveles de log indican la importancia y la gravedad de los mensajes. El uso adecuado de los niveles de log es crucial para una resolución de problemas eficaz y la reducción del ruido.

Nivel	Número	Propósito	Ejemplo
TRACE	0	Información de depuración más detallada	Entrada/salida de funciones, valores de variables
DEBUG	1	Información de depuración durante el desarrollo	Consultas SQL, parámetros de solicitud
INFO	2	Información operativa general	Inicio de Service, finalización de solicitud
WARN	3	Situaciones de posibles problemas	Reintentos en curso, degradación del rendimiento
ERROR	4	Se produjo un error (recuperable)	Error de llamada a API, error de validación
FATAL	5	Error crítico (irrecuperable)	Error de inicio de Service, falta de dependencia requerida

Niveles de log recomendados por entorno

yaml

# Development environment
LOG_LEVEL: DEBUG

# Staging environment
LOG_LEVEL: INFO

# Production environment
LOG_LEVEL: INFO  # or WARN (for high traffic)

Formato de logs JSON

En entornos de Kubernetes, el formato JSON es el estándar de facto. La mayoría de los recopiladores de logs y herramientas de análisis admiten JSON de forma nativa.

Campos JSON recomendados

json

{
  "timestamp": "2025-02-15T10:23:45.123Z",
  "level": "INFO",
  "logger": "com.example.UserService",
  "message": "User login successful",
  "context": {
    "user_id": "user-12345",
    "session_id": "sess-abc123",
    "ip_address": "10.0.1.50"
  },
  "kubernetes": {
    "namespace": "production",
    "pod": "user-api-7d4f8b9c6-x2k9m",
    "container": "user-api",
    "node": "ip-10-0-1-100.ec2.internal"
  },
  "trace": {
    "trace_id": "abc123def456",
    "span_id": "789ghi",
    "parent_span_id": "456def"
  }
}

Descripciones de los campos clave

Grupo de campos	Campo	Descripción
Básico	timestamp	Marca de tiempo en formato ISO 8601
	level	Nivel de log
	message	Mensaje legible para humanos
Contexto	context.*	Información relacionada con la lógica de negocio
Kubernetes	kubernetes.*	Metadatos de K8s como pod, namespace
Traza	trace.*	IDs de trazado distribuido (integración con OpenTelemetry)

Arquitectura del pipeline de recopilación de logs

Descripción general de la arquitectura

Responsabilidades de las capas

1. Capa de recopilación

Responsable de recopilar logs sin procesar de las fuentes de logs.

Método	Ventajas	Desventajas	Mejor para
DaemonSet	Uso eficiente de recursos, gestión centralizada	Solo uno por nodo	La mayoría de las cargas de trabajo estándar
Sidecar	Aislamiento por aplicación, procesamiento personalizado	Sobrecarga de recursos	Formatos de log especiales, multi-tenant
Direct Push	Entrega en tiempo real, flexible	Requiere modificación de la aplicación	Requisitos de alto rendimiento

2. Capa de procesamiento

Normaliza los logs recopilados y añade metadatos.

yaml

# FluentBit processing pipeline example
[FILTER]
    Name         kubernetes
    Match        kube.*
    Kube_URL     https://kubernetes.default.svc:443
    Merge_Log    On
    K8S-Logging.Parser  On

[FILTER]
    Name         modify
    Match        *
    Add          cluster_name eks-production
    Add          environment production

[FILTER]
    Name         grep
    Match        *
    Exclude      log HealthCheck

3. Capa de almacenamiento

Almacena e indexa los logs procesados. Los métodos de almacenamiento varían según las características de la solución.

4. Capa de análisis

Busca y visualiza los logs almacenados.

Criterios de selección de almacenamiento de logs

Consideraciones clave

1. Costo

Monthly log volume: Estimated cost based on 1TB (2025)

+------------------+------------------+-----------------+
|     Solution     |   Storage/GB     |   Query Cost    |
+------------------+------------------+-----------------+
| Loki (S3)        | $0.023 (S3)      | Free            |
| OpenSearch       | $0.10-0.15       | Free            |
| CloudWatch       | $0.50 (ingest)   | $0.005/GB scan  |
| ClickHouse       | $0.023 (S3)      | Free            |
+------------------+------------------+-----------------+

2. Rendimiento de las consultas

Solución	Consulta en tiempo real	Agregación	Búsqueda de texto completo	Panel
Loki	Excelente	Bueno	Limitada	Grafana
OpenSearch	Excelente	Excelente	Excelente	OpenSearch Dashboards
CloudWatch	Bueno	Bueno	Bueno	Consola de CloudWatch
ClickHouse	Excelente	Excelente	Bueno	Grafana

3. Período de retención

yaml

# Recommended retention policies
regulatory_compliance:
  financial: 7 years
  healthcare: 6 years
  general: 1 year

operational:
  hot_storage: 7-14 days    # Fast queries
  warm_storage: 30-90 days  # Investigation
  cold_storage: 1 year+     # Compliance

4. Complejidad operativa

Solución	Instalación	Operaciones	Escalabilidad
Loki	Baja	Baja	Alta
OpenSearch	Media	Alta	Media
CloudWatch	Muy baja	Muy bajas	Alta
ClickHouse	Alta	Media	Alta

Estrategia de registro de logs de EKS

Patrones de recopilación de logs

1. Patrón stdout/stderr (recomendado)

El registro de logs mediante la salida/error estándar del contenedor es el patrón predeterminado de Kubernetes.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    # Application outputs logs to stdout/stderr
    # kubelet saves to files in /var/log/containers/
    # DaemonSet agent collects

Ventajas:

Enfoque nativo de Kubernetes
Gestión automática de la rotación de logs (/var/log/containers/)
Comando kubectl logs disponible
No se requiere un montaje de volumen independiente

Ubicaciones de los archivos de log:

bash

# Actual log files
/var/log/containers/<pod-name>_<namespace>_<container-name>-<container-id>.log

# Symbolic links
/var/log/pods/<namespace>_<pod-name>_<pod-uid>/<container-name>/0.log

2. Patrón Sidecar

Se utiliza cuando se requiere registro de logs basado en archivos o procesamiento especial.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: app
    image: legacy-app:1.0
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app

  - name: log-collector
    image: fluent/fluent-bit:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app
      readOnly: true
    - name: fluent-bit-config
      mountPath: /fluent-bit/etc/

  volumes:
  - name: log-volume
    emptyDir: {}
  - name: fluent-bit-config
    configMap:
      name: fluent-bit-sidecar-config

Casos de uso:

Aplicaciones heredadas (solo registro en archivos)
Aislamiento de logs en entornos multi-tenant
Análisis especial requerido por aplicación
Requisitos de alta seguridad

3. Patrón DaemonSet (el más común)

Un agente por nodo recopila todos los logs de los contenedores.

yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      serviceAccountName: fluent-bit
      tolerations:
      - operator: Exists  # Deploy on all nodes
      containers:
      - name: fluent-bit
        image: public.ecr.aws/aws-observability/aws-for-fluent-bit:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
          readOnly: true
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        resources:
          limits:
            memory: 200Mi
            cpu: 200m
          requests:
            memory: 100Mi
            cpu: 100m
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Registro de logs del control plane de EKS

Los logs del control plane de EKS se envían a CloudWatch Logs.

bash

# Enable control plane logging via AWS CLI
aws eks update-cluster-config \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Tipo de log	Descripción	Recomendado
api	Logs del servidor API	Obligatorio
audit	Logs de auditoría de Kubernetes	Obligatorio (seguridad)
authenticator	Logs de autenticación de IAM	Recomendado
controllerManager	Logs de Controller manager	Opcional
scheduler	Logs de Scheduler	Opcional

Registro de logs de Container Insights

yaml

# CloudWatch Agent ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: cloudwatch-agent-config
  namespace: amazon-cloudwatch
data:
  cwagentconfig.json: |
    {
      "logs": {
        "metrics_collected": {
          "kubernetes": {
            "cluster_name": "my-cluster",
            "metrics_collection_interval": 60
          }
        },
        "force_flush_interval": 5
      }
    }

Comparación de soluciones

Tabla de comparación de características

Característica	Loki	OpenSearch	CloudWatch	ClickHouse
Complejidad de instalación	Baja	Media	Ninguna (gestionado)	Alta
Lenguaje de consulta	LogQL	Lucene/DQL	Insights QL	SQL
Búsqueda de texto completo	Limitada	Excelente	Buena	Buena
Esquema	Sin esquema	Sin esquema	Sin esquema	Esquema definido
Compresión	Alta	Media	N/D	Muy alta
Seguimiento en tiempo real	Compatible	Compatible	Limitado	Compatible
Alertas	Grafana	Integradas	Integradas	Grafana
Multi-tenancy	Compatible	Compatible	Compatible	Compatible
Backend de S3	Nativo	Solo snapshots	N/D	Nativo

Soluciones recomendadas por caso de uso

+-------------------------------------+---------------------+
|           Use Case                  |  Recommended        |
+-------------------------------------+---------------------+
| Cost optimization is top priority   | Loki + S3           |
| Full-text search and analytics      | OpenSearch          |
| AWS native, simple operations       | CloudWatch Logs     |
| Large-scale analytics, SQL pref.    | ClickHouse          |
| Existing Grafana stack              | Loki                |
| Compliance requirements             | OpenSearch/CloudWatch|
| Startup/small team                  | Loki or CloudWatch  |
| Enterprise/complex analytics        | OpenSearch          |
+-------------------------------------+---------------------+

Simulación de costos (basada en 100 GB/mes de logs)

Estimated monthly cost by solution:

Loki (S3 Simple Scalable):
  +- S3 storage: $2.30
  +- S3 requests: $0.50
  +- EC2 (3x m5.large): $180
  +- Total: ~$183

OpenSearch (3x m5.large):
  +- Instances: $300
  +- EBS storage: $15
  +- Total: ~$315

CloudWatch Logs:
  +- Ingestion: $50
  +- Storage: $3
  +- Queries (estimated): $10
  +- Total: ~$63

ClickHouse (self-hosted):
  +- EC2 (3x m5.large): $180
  +- S3 storage: $2.30
  +- Total: ~$183

Nota: Los costos reales pueden variar considerablemente según los patrones de consulta, el período de retención y la región.

Diagrama de flujo de decisión

Próximos pasos

Para obtener información detallada sobre cada solución de almacenamiento de logs, consulte los siguientes documentos:

Grafana Loki - Agregación de logs rentable
Amazon OpenSearch Service - Búsqueda y análisis potentes
CloudWatch Logs - Registro de logs nativo de AWS
ClickHouse - Análisis de logs de alto rendimiento
Comparación de recopiladores de logs - FluentBit, Promtail, Alloy, OTEL

Cuestionario

Ponga a prueba sus conocimientos con el Cuestionario de descripción general de logging.

Laboratorios integrales de observabilidad

Cuestionario de ArgoCD en detalle

Cuestionario de Istio detallado

Cuestionario de Linkerd detallado

Cuestionario de Cilium Service Mesh detallado

Profundización en Cilium

Profundización en Calico

Métricas

Registro

Trazado

Alertas

Laboratorios de observabilidad

ArgoCD

Gestión del tráfico

Seguridad

Observabilidad

Resiliencia

Avanzado

Guía comparativa

Métricas

Registro

Trazado

Alertas

Registro de logs ​

Tabla de contenidos ​

Fundamentos del registro de logs ​

Registro de logs estructurado ​

Logs no estructurados frente a estructurados ​

Beneficios del registro de logs estructurado ​

Niveles de log ​

Niveles de log recomendados por entorno ​

Formato de logs JSON ​

Campos JSON recomendados ​

Descripciones de los campos clave ​

Arquitectura del pipeline de recopilación de logs ​

Descripción general de la arquitectura ​

Responsabilidades de las capas ​

1. Capa de recopilación ​

2. Capa de procesamiento ​

3. Capa de almacenamiento ​

4. Capa de análisis ​

Criterios de selección de almacenamiento de logs ​

Consideraciones clave ​

1. Costo ​

2. Rendimiento de las consultas ​

3. Período de retención ​

4. Complejidad operativa ​

Estrategia de registro de logs de EKS ​

Patrones de recopilación de logs ​

1. Patrón stdout/stderr (recomendado) ​

2. Patrón Sidecar ​

3. Patrón DaemonSet (el más común) ​

Registro de logs del control plane de EKS ​

Registro de logs de Container Insights ​

Comparación de soluciones ​

Tabla de comparación de características ​

Soluciones recomendadas por caso de uso ​

Simulación de costos (basada en 100 GB/mes de logs) ​

Diagrama de flujo de decisión ​

Próximos pasos ​

Cuestionario ​

Registro de logs

Tabla de contenidos

Fundamentos del registro de logs

Registro de logs estructurado

Logs no estructurados frente a estructurados

Beneficios del registro de logs estructurado

Niveles de log

Niveles de log recomendados por entorno

Formato de logs JSON

Campos JSON recomendados

Descripciones de los campos clave

Arquitectura del pipeline de recopilación de logs

Descripción general de la arquitectura

Responsabilidades de las capas

1. Capa de recopilación

2. Capa de procesamiento

3. Capa de almacenamiento

4. Capa de análisis

Criterios de selección de almacenamiento de logs

Consideraciones clave

1. Costo

2. Rendimiento de las consultas

3. Período de retención

4. Complejidad operativa

Estrategia de registro de logs de EKS

Patrones de recopilación de logs

1. Patrón stdout/stderr (recomendado)

2. Patrón Sidecar

3. Patrón DaemonSet (el más común)

Registro de logs del control plane de EKS

Registro de logs de Container Insights

Comparación de soluciones

Tabla de comparación de características

Soluciones recomendadas por caso de uso

Simulación de costos (basada en 100 GB/mes de logs)

Diagrama de flujo de decisión

Próximos pasos

Cuestionario