Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Observabilidad
Introducción
Las herramientas de observabilidad le ayudan a detectar, corregir e investigar sus cargas de trabajo de manera eficiente. El costo de los datos de telemetría aumenta naturalmente a medida que aumenta el uso de EKS. A veces, puede resultar difícil equilibrar sus necesidades operativas y medir lo que es importante para su empresa y mantener los costes de observabilidad bajo control. Esta guía se centra en las estrategias de optimización de costes para los tres pilares de la observabilidad: los registros, las métricas y los rastreos. Cada una de estas mejores prácticas se puede aplicar de forma independiente para adaptarse a los objetivos de optimización de su organización.
Registro
El registro desempeña un papel fundamental en la supervisión y la solución de problemas de las aplicaciones de su clúster. Existen varias estrategias que se pueden emplear para optimizar los costos de registro. Las estrategias recomendadas que se enumeran a continuación incluyen examinar sus políticas de retención de registros para implementar controles detallados sobre el tiempo que se conservan los datos de registro, enviar los datos de registro a diferentes opciones de almacenamiento según su importancia y utilizar el filtrado de registros para reducir los tipos de mensajes de registro que se almacenan. La administración eficiente de la telemetría de registros puede suponer un ahorro de costes para sus entornos.
Plano de control EKS
Optimice los registros de su plano de control
El plano de control de Kubernetes es un conjunto de componentes
Por ejemplo, en los clústeres que no son de producción, habilite de forma selectiva tipos de registro específicos, como los registros del servidor api, solo para su análisis y desactívelos después. Sin embargo, en el caso de los clústeres de producción, en los que es posible que no puedas reproducir eventos y para resolver problemas se requiera más información de registro, puedes habilitar todos los tipos de registro. En esta entrada de blog
Transmita los registros a S3
Otra práctica recomendada para la optimización de costes es transmitir los registros del plano de control a S3 mediante suscripciones a CloudWatch Logs. Aprovechar las suscripciones a CloudWatch Logs le permite reenviar los registros de forma selectiva a S3, lo que proporciona un almacenamiento a largo plazo más rentable en comparación con conservar los registros indefinidamente. CloudWatch Por ejemplo, en el caso de los clústeres de producción, puede crear un grupo de registros importante y aprovechar las suscripciones para transmitir estos registros a S3 después de 15 días. Esto garantizará que tenga acceso rápido a los registros para su análisis, pero también ahorrará costos al mover los registros a un almacenamiento más rentable.
importante
A partir del 5 de septiembre de 2023, los registros de EKS se clasifican como registros vendidos en Amazon Logs. CloudWatch Los registros vendidos son registros de servicios de AWS específicos que los servicios de AWS publican de forma nativa en nombre del cliente y están disponibles a precios de descuento por volumen. Visita la página de CloudWatch precios de Amazon
Plano de datos EKS
Retención de registros
La política CloudWatch de retención predeterminada de Amazon consiste en conservar los registros indefinidamente y no caducar nunca, lo que implica costes de almacenamiento aplicables a su región de AWS. Para reducir los costes de almacenamiento, puede personalizar la política de retención para cada grupo de registros en función de sus requisitos de carga de trabajo.
En un entorno de desarrollo, puede que no sea necesario un período de retención prolongado. Sin embargo, en un entorno de producción, puede establecer una política de retención más prolongada para cumplir con los requisitos de resolución de problemas, conformidad y planificación de la capacidad. Por ejemplo, si ejecuta una aplicación de comercio electrónico durante la temporada alta de fiestas, el sistema está sobrecargado y pueden surgir problemas que no se noten de inmediato, querrá configurar una retención de registros más prolongada para solucionar problemas detallados y realizar un análisis posterior al evento.
Puede configurar sus períodos de retención en la CloudWatch consola de AWS o en la API de AWS con una duración de 1 día a 10 años en función de cada grupo de registros. Tener un período de retención flexible puede ahorrar costos de almacenamiento de registros y, al mismo tiempo, mantener los registros críticos.
Opciones de almacenamiento de registros
El almacenamiento es un factor importante de los costos de observabilidad, por lo que es crucial optimizar la estrategia de almacenamiento de registros. Sus estrategias deben ajustarse a los requisitos de sus cargas de trabajo y, al mismo tiempo, mantener el rendimiento y la escalabilidad. Una estrategia para reducir los costes de almacenamiento de registros consiste en aprovechar los buckets S3 de AWS y sus diferentes niveles de almacenamiento.
Reenvíe los registros directamente a S3
Considere la posibilidad de reenviar los registros menos críticos, como los entornos de desarrollo, directamente a S3 en lugar de a Cloudwatch. Esto puede tener un impacto inmediato en los costes de almacenamiento de registros. Una opción es reenviar los registros directamente a S3 con Fluentbit. Defina esto en la [OUTPUT] sección, el destino al que se FluentBit transmiten los registros del contenedor para su retención. Revise los parámetros de configuración adicionales aquí
[OUTPUT]
Name eks_to_s3
Match application.*
bucket $S3_BUCKET name
region us-east-2
store_dir /var/log/fluentbit
total_file_size 30M
upload_timeout 3m
Reenvíe los registros a CloudWatch solo para su análisis a corto plazo
Para los registros más críticos, como los entornos de producción en los que podría necesitar realizar un análisis inmediato de los datos, considere la posibilidad de reenviar los registros a CloudWatch. Defina esto en la [OUTPUT] sección, el destino al que se FluentBit transmiten los registros del contenedor para su conservación. Revise los parámetros de configuración adicionales aquí
[OUTPUT]
Name eks_to_cloudwatch_logs
Match application.*
region us-east-2
log_group_name fluent-bit-cloudwatch
log_stream_prefix from-fluent-bit-
auto_create_group On
Sin embargo, esto no tendrá un efecto inmediato en sus ahorros de costos. Para ahorrar más, tendrá que exportar estos registros a Amazon S3.
Exportación a Amazon S3 desde CloudWatch
Para almacenar CloudWatch los registros de Amazon a largo plazo, recomendamos exportar CloudWatch los registros de Amazon EKS a Amazon Simple Storage Service (Amazon S3). Puede reenviar los registros al bucket de Amazon S3 creando una tarea de exportación a través de la consola o la API. Una vez hecho esto, Amazon S3 presenta muchas opciones para reducir aún más los costos. Puede definir sus propias reglas del ciclo de vida de Amazon S3 para mover sus registros a una clase de almacenamiento que se adapte a sus necesidades, o aprovechar la clase de almacenamiento por niveles inteligentes de Amazon S3
Reduzca los niveles de registro
Practique el registro selectivo para su aplicación. Tanto las aplicaciones como los nodos generan registros de forma predeterminada. Para los registros de sus aplicaciones, ajuste los niveles de registro para adaptarlos a la importancia de la carga de trabajo y el entorno. Por ejemplo, la siguiente aplicación java genera INFO registros, que es la configuración de aplicación predeterminada típica y, según el código, puede generar un gran volumen de datos de registro.
import org.apache.log4j.*; public class LogClass { private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class); public static void main(String[] args) { log.setLevel(Level.INFO); log.debug("This is a DEBUG message, check this out!"); log.info("This is an INFO message, nothing to see here!"); log.warn("This is a WARN message, investigate this!"); log.error("This is an ERROR message, check this out!"); log.fatal("This is a FATAL message, investigate this!"); } }
En un entorno de desarrollo, cambia el nivel de registro aDEBUG, ya que esto puede ayudarte a depurar problemas o a atrapar los posibles antes de que entren en producción.
log.setLevel(Level.DEBUG);
En un entorno de producción, considere la posibilidad de modificar el nivel de registro a ERROR oFATAL. Esto generará un registro solo cuando la aplicación tenga errores, lo que reducirá la salida del registro y le ayudará a centrarse en los datos importantes sobre el estado de la solicitud.
log.setLevel(Level.ERROR);
Puedes ajustar con precisión los niveles de registro de varios componentes de Kubernetes. Por ejemplo, si utilizas Bottlerocketkubelet
[settings.kubernetes] log-level = "2" image-gc-high-threshold-percent = "85" image-gc-low-threshold-percent = "80"
En un entorno de desarrollo, puede establecer un nivel de registro superior a 2 para ver eventos adicionales, lo que resulta útil para la depuración. En un entorno de producción, puede establecer el nivel en 0 para ver solo los eventos críticos.
Aproveche los filtros
Si utiliza una configuración predeterminada de EKS Fluentbit para enviar los registros de contenedores a Cloudwatch, FluentBit captura y envía TODOS los registros de contenedores de aplicaciones enriquecidos con metadatos de Kubernetes a Cloudwatch, tal y como se muestra en el bloque de configuración siguiente. [INPUT]
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
Docker_Mode On
Docker_Mode_Flush 5
Docker_Mode_Parser container_firstline
Parser docker
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
En la [INPUT] sección anterior se recopilan todos los registros del contenedor. Esto puede generar una gran cantidad de datos que podrían no ser necesarios. Filtrar estos datos puede reducir la cantidad de datos de registro enviados y, CloudWatch por lo tanto, reducir los costos. Puede aplicar un filtro a sus registros antes de que se envíen a CloudWatch. Fluentbit define esto en la [FILTER] sección. Por ejemplo, filtrar los metadatos de Kubernetes para que no se adjunten a los eventos de registro puede reducir el volumen de registro.
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.<Metadata_1>
Remove Kube.<Metadata_2>
Remove Kube.<Metadata_3>
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
Métricas
Las métricas
Supervise lo que importa y recopile solo lo que necesita
La primera estrategia de reducción de costos consiste en reducir la cantidad de métricas que se recopilan y, a su vez, reducir los costos de retención.
-
Comience por analizar sus requisitos o los de las partes interesadas para determinar las métricas más importantes
. ¡Las métricas de éxito son diferentes para cada persona! Sepa qué se ve bien y mídalo. -
Considere analizar en profundidad las cargas de trabajo a las que está dando soporte e identificar sus indicadores clave de rendimiento (KPIs), también conocidos como «señales de oro». Estos deben ajustarse a los requisitos empresariales y de las partes interesadas. Calcular SLIs y SLAs utilizar Amazon CloudWatch y Metric Math es crucial para gestionar la fiabilidad del servicio. SLOs Siga las mejores prácticas descritas en esta guía
para supervisar y mantener de forma eficaz el rendimiento de su entorno EKS. -
Luego, continúe recorriendo los diferentes niveles de infraestructura para conectar y correlacionar las métricas de clúster, nodo e infraestructura adicional de EKS con
su carga KPIs de trabajo. Guarde sus métricas empresariales y operativas en un sistema donde pueda correlacionarlas y sacar conclusiones basadas en los impactos observados en ambas. -
EKS expone las métricas del plano de control, el clúster kube-state-metrics, los módulos y los nodos. La relevancia de todas estas métricas depende de sus necesidades, sin embargo, es probable que no necesite todas las métricas de los distintos niveles. Puede utilizar esta guía de métricas esenciales de EKS
como referencia para supervisar el estado general de un clúster de EKS y sus cargas de trabajo.
A continuación se muestra un ejemplo de la configuración Scrape de Prometheus, en la que utilizamos únicamente las relabel_config métricas de Kubelet y metric_relabel_config descartamos todas las métricas de contenedores.
kubernetes_sd_configs: - role: endpoints namespaces: names: - kube-system bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_label_k8s_app] regex: kubelet action: keep metric_relabel_configs: - source_labels: [__name__] regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s) action: drop
Reduzca la cardinalidad cuando proceda
La cardinalidad se refiere a la unicidad de los valores de los datos en combinación con sus dimensiones (por ejemplo, las etiquetas de Prometheus) para un conjunto de métricas específico. Las métricas de alta cardinalidad tienen muchas dimensiones y cada combinación de métricas dimensionales tiene una singularidad mayor. Una mayor cardinalidad se traduce en un mayor tamaño de los datos de telemetría métrica y en mayores necesidades de almacenamiento, lo que aumenta el coste.
En el ejemplo de cardinalidad alta que aparece a continuación, vemos que la métrica Latency tiene Dimensiones, RequestID, CustomeriD y Service, y cada dimensión tiene muchos valores únicos. La cardinalidad es la medida de la combinación del número de valores posibles por dimensión. En Prometheus, cada conjunto de dimensiones/etiquetas únicas se considera una métrica nueva, por lo que una cardinalidad alta significa más métricas.
En los entornos de EKS con muchas métricas y dimensiones o etiquetas por métrica (clúster, espacio de nombres, servicio, pod, contenedor, etc.), la cardinalidad tiende a aumentar. Para optimizar los costos, considere cuidadosamente la cardinalidad de las métricas que está recopilando. Por ejemplo, si va a agregar una métrica específica para visualizarla a nivel de clúster, puede eliminar las etiquetas adicionales que se encuentran en una capa inferior, como la etiqueta del espacio de nombres.
Para identificar las métricas de alta cardinalidad en Prometheus, puede ejecutar la siguiente consulta de PROMQL para determinar qué objetivos de raspado tienen el mayor número de métricas (cardinalidad):
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
y la siguiente consulta de PROMQL puede ayudarle a determinar qué objetivos de raspado tienen las tasas más altas de abandono de métricas (cuántas series de métricas nuevas se crearon en un raspado determinado):
topk_max(5, max_over_time(scrape_series_added[1h]))
Si está utilizando grafana, puede usar la herramienta Mimirtool de Grafana Lab para analizar sus paneles de grafana y las reglas de Prometheus para identificar las métricas de alta cardinalidad no utilizadas. Sigue esta guíamimirtool analyze prometheus comandos mimirtool analyze y para identificar las métricas activas a las que no se hace referencia en tus paneles.
Tenga en cuenta la granularidad de las métricas
La recopilación de métricas con una granularidad mayor, como cada segundo en lugar de cada minuto, puede tener un gran impacto en la cantidad de telemetría que se recopila y almacena, lo que aumenta el costo. Determine intervalos razonables de recopilación de métricas o de recopilación de métricas que equilibren entre una granularidad suficiente para detectar problemas transitorios y lo suficientemente bajos como para ser rentables. Reduzca la granularidad de las métricas que se utilizan para planificar la capacidad y analizar intervalos de tiempo más amplios.
importante
el intervalo global de raspado de Prometheus está establecido en 15 segundos. Este intervalo de raspado se puede aumentar, lo que resulta en una disminución de la cantidad de datos métricos recopilados en Prometheus.
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector-amp
...
config: |
extensions:
sigv4auth:
region: "+++<YOUR_AWS_REGION>+++" service: "aps"+++</YOUR_AWS_REGION>+++
receivers:
#
# Scrape configuration for the Prometheus Receiver
# This is the same configuration used when Prometheus is installed using the community Helm chart
#
prometheus:
config:
global: scrape_interval: 15s
scrape_timeout: 10s
Rastreo
El coste principal asociado al rastreo proviene de la generación de almacenamiento de trazas. Con el rastreo, el objetivo es recopilar datos suficientes para diagnosticar y comprender los aspectos del rendimiento. Sin embargo, dado que los costos de las trazas de rayos X se basan en los datos enviados a X-Ray, borrar las trazas una vez reenviadas no reducirá sus costos. Repasemos las formas de reducir los costes de rastreo y, al mismo tiempo, conservar los datos para que pueda realizar un análisis adecuado.
Aplique las reglas de muestreo
La frecuencia de muestreo de rayos X es conservadora por defecto. Defina reglas de muestreo que le permitan controlar la cantidad de datos que recopila. Esto mejorará la eficiencia del rendimiento y, al mismo tiempo, reducirá los costes. Al reducir la frecuencia de muestreo, puede recopilar las trazas de la solicitud únicamente en función de las necesidades de sus cargas de trabajo y, al mismo tiempo, mantener una estructura de costes más baja.
Por ejemplo, tiene una aplicación Java que desea depurar los rastros de todas las solicitudes de una ruta problemática.
Configure mediante el SDK para cargar las reglas de muestreo desde un documento JSON
{ "version": 2, "rules": [ { "description": "debug-eks", "host": "*", "http_method": "PUT", "url_path": "/history/*", "fixed_target": 0, "rate": 1, "service_type": "debug-eks" } ], "default": { "fixed_target": 1, "rate": 0.1 } }
A través de la consola
Aplique Tail Sampling con AWS Distro for OpenTelemetry (ADOT)
ADOT Tail Sampling le permite controlar el volumen de trazas ingeridas en el servicio. Sin embargo, Tail Sampling le permite definir las políticas de muestreo una vez que se hayan completado todos los períodos de la solicitud, en lugar de hacerlo al principio. Esto limita aún más la cantidad de datos sin procesar a los que se transfieren y CloudWatch, por lo tanto, reduce los costos.
Por ejemplo, si muestreas el 1% del tráfico a una página de destino y el 10% de las solicitudes a una página de pago, es posible que obtengas 300 seguimientos durante un período de 30 minutos. Con una regla de muestreo gradual de ADOT que filtra errores específicos, podrías quedarte con 200 trazas, lo que reduce el número de trazas almacenadas.
processors:
groupbytrace:
wait_duration: 10s
num_traces: 300
tail_sampling:
decision_wait: 1s # This value should be smaller than wait_duration
policies:
- ..... # Applicable policies**
batch/tracesampling:
timeout: 0s # No need to wait more since this will happen in previous processors
send_batch_max_size: 8196 # This will still allow us to limit the size of the batches sent to subsequent exporters
service:
pipelines:
traces/tailsampling:
receivers: [otlp]
processors: [groupbytrace, tail_sampling, batch/tracesampling]
exporters: [awsxray]
Aproveche las opciones de almacenamiento de Amazon S3
Debe aprovechar el bucket de AWS S3 y sus diferentes clases de almacenamiento para almacenar las trazas. Exporte las trazas a S3 antes de que venza el período de retención. Utilice las reglas del ciclo de vida de Amazon S3 para mover los datos de rastreo a la clase de almacenamiento que cumpla con sus requisitos.
Por ejemplo, si tiene trazas que tienen 90 días de antigüedad, Amazon S3 Intelligent-Tiering
Recursos adicionales:
