Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Osservabilità
Introduzione
Gli strumenti di osservabilità ti aiutano a rilevare, correggere e analizzare in modo efficiente i tuoi carichi di lavoro. Il costo dei dati di telemetria aumenta naturalmente con l'aumento dell'utilizzo di EKS. A volte può essere difficile bilanciare le esigenze operative e misurare ciò che conta per l'azienda e tenere sotto controllo i costi di osservabilità. Questa guida si concentra sulle strategie di ottimizzazione dei costi per i tre pilastri dell'osservabilità: log, metriche e tracce. Ognuna di queste best practice può essere applicata indipendentemente per soddisfare gli obiettivi di ottimizzazione dell'organizzazione.
Registrazione
La registrazione svolge un ruolo fondamentale nel monitoraggio e nella risoluzione dei problemi delle applicazioni del cluster. Esistono diverse strategie che possono essere utilizzate per ottimizzare i costi di registrazione. Le strategie di best practice elencate di seguito includono l'esame delle politiche di conservazione dei log per implementare controlli granulari sulla durata di conservazione dei dati di registro, l'invio dei dati di log a diverse opzioni di archiviazione in base all'importanza e l'utilizzo del filtro dei log per restringere i tipi di messaggi di log archiviati. Una gestione efficiente della telemetria dei log può portare a risparmi sui costi per gli ambienti.
Piano di controllo EKS
Ottimizza i log del tuo Control Plane
Il piano di controllo Kubernetes è un insieme di componenti
Ad esempio, nei cluster non di produzione, abilita selettivamente tipi di log specifici, come i log del server api, solo per l'analisi e disattivali in seguito. Tuttavia, per i cluster di produzione, in cui potrebbe non essere possibile riprodurre gli eventi e la risoluzione dei problemi richiede più informazioni di registro, è possibile abilitare tutti i tipi di log. Ulteriori dettagli sull'implementazione dell'ottimizzazione dei costi del piano di controllo sono disponibili in questo post del blog.
Trasmetti i log su S3
Un'altra best practice per l'ottimizzazione dei costi è lo streaming dei log del piano di controllo su S3 tramite abbonamenti Logs. CloudWatch L'utilizzo CloudWatch degli abbonamenti Logs consente di inoltrare selettivamente i log a S3, il che offre uno storage a lungo termine più efficiente in termini di costi rispetto alla conservazione dei log a tempo indeterminato. CloudWatch Ad esempio, per i cluster di produzione, puoi creare un gruppo di log critico e sfruttare gli abbonamenti per trasmettere questi log a S3 dopo 15 giorni. Ciò garantirà un accesso rapido ai log per l'analisi, ma anche un risparmio sui costi spostando i log in uno storage più efficiente in termini di costi.
Importante
A partire dal 5/09/2023, i log EKS sono classificati come Vended Logs in Amazon Logs. CloudWatch I Vended Logs sono log di servizio AWS specifici pubblicati nativamente dai servizi AWS per conto del cliente e disponibili a prezzi scontati in base al volume. Visita la pagina CloudWatch dei prezzi di Amazon
Piano dati EKS
Retention dei log
La politica CloudWatch di conservazione predefinita di Amazon prevede la conservazione dei log a tempo indeterminato e senza scadenza, con costi di storage applicabili alla tua regione AWS. Per ridurre i costi di archiviazione, puoi personalizzare la politica di conservazione per ogni gruppo di log in base ai requisiti del carico di lavoro.
In un ambiente di sviluppo, potrebbe non essere necessario un lungo periodo di conservazione. In un ambiente di produzione, tuttavia, è possibile impostare una politica di conservazione più lunga per soddisfare i requisiti di risoluzione dei problemi, conformità e pianificazione della capacità. Ad esempio, se utilizzate un'applicazione di e-commerce durante l'alta stagione delle festività natalizie, il sistema è sottoposto a un carico maggiore e possono insorgere problemi che potrebbero non essere immediatamente evidenti, vi consigliamo di impostare una conservazione dei log più lunga per una risoluzione dettagliata dei problemi e un'analisi post-evento.
Puoi configurare i periodi di conservazione nella CloudWatch console AWS o nell'API AWS con una durata da 1 giorno a 10 anni in base a ciascun gruppo di log. Un periodo di conservazione flessibile può far risparmiare sui costi di archiviazione dei log, mantenendo allo stesso tempo i log critici.
Opzioni di archiviazione dei log
Lo storage è un fattore importante dei costi di osservabilità, pertanto è fondamentale ottimizzare la strategia di archiviazione dei log. Le strategie devono essere in linea con i requisiti dei carichi di lavoro, mantenendo al contempo prestazioni e scalabilità. Una strategia per ridurre i costi di archiviazione dei log consiste nell'utilizzare i bucket AWS S3 e i diversi livelli di storage.
Inoltra i log direttamente a S3
Valuta la possibilità di inoltrare i log meno critici, come gli ambienti di sviluppo, direttamente a S3 anziché a Cloudwatch. Ciò può avere un impatto immediato sui costi di archiviazione dei log. Un'opzione è inoltrare i log direttamente a S3 utilizzando Fluentbit. Lo definisci nella [OUTPUT] sezione, la destinazione in cui FluentBit trasmette i log del contenitore per la conservazione. Consulta i parametri di configurazione aggiuntivi qui.
[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
Inoltra i log CloudWatch solo per analisi a breve termine
Per i log più critici, ad esempio ambienti di produzione in cui potrebbe essere necessario eseguire un'analisi immediata dei dati, è consigliabile inoltrare i log a. CloudWatch Lo definisci nella [OUTPUT] sezione, la destinazione in cui FluentBit trasmette i log dei contenitori per la conservazione. Consulta i parametri di configurazione aggiuntivi qui.
[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
Tuttavia, ciò non avrà un impatto immediato sui risparmi sui costi. Per ulteriori risparmi, dovrai esportare questi log in Amazon S3.
Esporta in Amazon S3 da CloudWatch
Per archiviare CloudWatch i log di Amazon a lungo termine, consigliamo di esportare i CloudWatch log di Amazon EKS su Amazon Simple Storage Service (Amazon S3). Puoi inoltrare i log al bucket Amazon S3 creando un'attività di esportazione tramite la console o l'API. Dopo averlo fatto, Amazon S3 presenta molte opzioni per ridurre ulteriormente i costi. Puoi definire le tue regole del ciclo di vita di Amazon S3 per spostare i log in una classe di storage più adatta alle tue esigenze o sfruttare la classe di storage Amazon S3
Riduci i livelli di log
Pratica la registrazione selettiva per la tua applicazione. Per impostazione predefinita, sia le applicazioni che i nodi generano i log. Per i log delle applicazioni, regola i livelli di registro in base alla criticità del carico di lavoro e dell'ambiente. Ad esempio, l'applicazione java riportata di seguito genera INFO log, che è la tipica configurazione predefinita dell'applicazione e, a seconda del codice, può generare un volume elevato di dati di 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!"); } }
In un ambiente di sviluppo, imposta il livello di log in questo modo puoi eseguire DEBUG il debug dei problemi o individuarne di potenziali prima che entrino in produzione.
log.setLevel(Level.DEBUG);
In un ambiente di produzione, valuta la possibilità di modificare il livello di registro in ERROR o. FATAL Ciò genererà il log solo quando l'applicazione presenta errori, riducendo l'output del registro e aiutandovi a concentrarvi sui dati importanti sullo stato dell'applicazione.
log.setLevel(Level.ERROR);
Puoi ottimizzare i vari livelli di log dei componenti di Kubernetes. Ad esempio, se si utilizza Bottlerocketkubelet
[settings.kubernetes] log-level = "2" image-gc-high-threshold-percent = "85" image-gc-low-threshold-percent = "80"
Per un ambiente di sviluppo, è possibile impostare un livello di registro maggiore di 2 per visualizzare eventi aggiuntivi, utile per il debug. Per un ambiente di produzione, è possibile impostare il livello su 0 per visualizzare solo gli eventi critici.
Sfrutta i filtri
Quando si utilizza una configurazione EKS Fluentbit predefinita per inviare i log dei container a Cloudwatch, FluentBit acquisisce e invia TUTTI i log dei contenitori delle applicazioni arricchiti con metadati Kubernetes a Cloudwatch, come mostrato nel riquadro di configurazione riportato di seguito. [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}
La sezione precedente [INPUT] sta importando tutti i log del contenitore. Questo può generare una grande quantità di dati che potrebbero non essere necessari. Il filtraggio di questi dati può ridurre la quantità di dati di registro inviati e CloudWatch quindi ridurre i costi. È possibile applicare un filtro ai log prima che vengano emessi. CloudWatch Fluentbit lo definisce nella sezione. [FILTER] Ad esempio, filtrare i metadati di Kubernetes per evitare che vengano aggiunti agli eventi di registro può ridurre il volume dei log.
[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.
Metriche
Le metriche
Monitora ciò che conta e raccogli solo ciò di cui hai bisogno
La prima strategia di riduzione dei costi consiste nel ridurre il numero di metriche raccolte e, a sua volta, ridurre i costi di conservazione.
-
Iniziate a lavorare a ritroso rispetto ai vostri requisiti e/o a quelli dei vostri stakeholder per determinare le metriche
più importanti. Le metriche di successo sono diverse per tutti! Scopri com'è bello e misuralo. -
Valuta la possibilità di approfondire i carichi di lavoro che stai supportando e identificandone i Key Performance Indicators (KPIs), noti anche come «Golden Signals». Questi dovrebbero essere in linea con i requisiti aziendali e delle parti interessate. Il calcolo e SLIs l' SLOs SLAs utilizzo di Amazon CloudWatch e Metric Math sono fondamentali per la gestione dell'affidabilità del servizio. Segui le migliori pratiche descritte in questa guida
per monitorare e mantenere efficacemente le prestazioni del tuo ambiente EKS. -
Quindi continua attraverso i diversi livelli dell'infrastruttura per connettere e correlare
i parametri del cluster, del nodo e dell'infrastruttura EKS aggiuntivi al tuo carico di lavoro. KPIs Archivia le metriche aziendali e le metriche operative in un sistema in cui è possibile correlarle tra loro e trarre conclusioni sulla base degli impatti osservati su entrambe. -
EKS espone le metriche provenienti dal piano di controllo, dal cluster kube-state-metrics, dai pod e dai nodi. La rilevanza di tutte queste metriche dipende dalle tue esigenze, tuttavia è probabile che non ti serva ogni singola metrica nei diversi livelli. Puoi utilizzare questa guida alle metriche essenziali di EKS
come base per monitorare lo stato generale di un cluster EKS e dei tuoi carichi di lavoro.
Ecco un esempio di configurazione di prometheus scrape in cui utilizziamo le metriche per mantenere solo le metriche di Kubelet e relabel_config per eliminare tutte le metriche dei container. metric_relabel_config
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
Riduci la cardinalità ove applicabile
La cardinalità si riferisce all'unicità dei valori dei dati in combinazione con le relative dimensioni (ad esempio le etichette di Prometheus) per uno specifico set di metriche. Le metriche ad alta cardinalità hanno molte dimensioni e ogni combinazione di metriche dimensionali ha una maggiore unicità. Una cardinalità più elevata comporta un aumento delle dimensioni dei dati di telemetria metrica e delle esigenze di archiviazione, con un conseguente aumento dei costi.
Nell'esempio ad alta cardinalità riportato di seguito, vediamo che Metric, Latency, ha Dimensions, RequestId, CustomerId e Service e ogni dimensione ha molti valori univoci. La cardinalità è la misura della combinazione del numero di valori possibili per dimensione. In Prometheus, ogni set di dimensioni/etichette uniche viene considerato come una nuova metrica, quindi una cardinalità elevata significa più metriche.
Negli ambienti EKS con molte metriche e dimensioni/etichette per metrica (Cluster, Namespace, Service, Pod, Container, ecc.), la cardinalità tende a crescere. Per ottimizzare i costi, considera attentamente la cardinalità delle metriche che stai raccogliendo. Ad esempio, se stai aggregando una metrica specifica per la visualizzazione a livello di cluster, puoi eliminare etichette aggiuntive che si trovano su un livello inferiore, come l'etichetta del namespace.
Per identificare le metriche ad alta cardinalità in Prometheus, puoi eseguire la seguente query PROMQL per determinare quali destinazioni di scrape hanno il maggior numero di metriche (cardinalità):
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
e la seguente query PROMQL può aiutarti a determinare quali target di scrape hanno i tassi di abbandono delle metriche più elevati (quante nuove serie di metriche sono state create in un determinato scrape):
topk_max(5, max_over_time(scrape_series_added[1h]))
Se utilizzi Grafana, puoi utilizzare Mimirtool di Grafana Lab per analizzare i dashboard di Grafana e le regole di Prometheus per identificare metriche ad alta cardinalità non utilizzate. Segui questa guidamimirtool analyze dashboardmimirtool analyze prometheus.
Prendi in considerazione la granularità delle metriche
La raccolta di metriche con una granularità più elevata, ad esempio ogni secondo anziché ogni minuto, può avere un grande impatto sulla quantità di telemetria raccolta e archiviata, con un conseguente aumento dei costi. Stabilisci intervalli ragionevoli per la raccolta dei dati o delle metriche che offrano un equilibrio tra una granularità sufficiente per rilevare problemi transitori e un livello sufficientemente basso da garantire un ottimo rapporto qualità-prezzo. Riduci la granularità delle metriche utilizzate per la pianificazione della capacità e l'analisi di finestre temporali più ampie.
Importante
l'intervallo globale di scrape di Prometheus è impostato su 15 secondi. Questo intervallo di scraping può essere aumentato con conseguente diminuzione della quantità di dati metrici raccolti in 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
Tracciamento
Il costo principale associato al tracciamento deriva dalla generazione dello storage delle tracce. Con il tracciamento, l'obiettivo è raccogliere dati sufficienti per diagnosticare e comprendere gli aspetti prestazionali. Tuttavia, poiché i costi delle tracce a raggi X si basano sui dati inoltrati a X-Ray, la cancellazione delle tracce dopo l'inoltro non ridurrà i costi. Esaminiamo i modi per ridurre i costi di tracciamento conservando al contempo i dati per consentirvi di eseguire un'analisi adeguata.
Applica le regole di campionamento
La frequenza di campionamento dei raggi X è conservativa per impostazione predefinita. Definite le regole di campionamento che consentono di controllare la quantità di dati raccolti. Ciò migliorerà l'efficienza delle prestazioni riducendo al contempo i costi. Riducendo la frequenza di campionamento, è possibile raccogliere tracce dalla richiesta solo per ciò di cui hanno bisogno i carichi di lavoro, mantenendo al contempo una struttura a costi inferiori.
Ad esempio, avete un'applicazione java di cui volete eseguire il debug delle tracce di tutte le richieste per 1 route problematica.
Configura tramite l'SDK per caricare le regole di campionamento da 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 } }
Tramite la console
Applica Tail Sampling con AWS Distro for OpenTelemetry (ADOT)
ADOT Tail Sampling consente di controllare il volume di tracce inserite nel servizio. Tuttavia, Tail Sampling consente di definire le politiche di campionamento dopo che tutti gli intervalli della richiesta sono stati completati anziché all'inizio. Ciò limita ulteriormente la quantità di dati grezzi trasferiti CloudWatch, riducendo così i costi.
Ad esempio, se stai campionando l'1% del traffico verso una pagina di destinazione e il 10% delle richieste verso una pagina di pagamento, potresti lasciare 300 tracce per un periodo di 30 minuti. Con una regola ADOT Tail Sampling che filtra errori specifici, potresti rimanere con 200 tracce, il che riduce il numero di tracce memorizzate.
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]
Sfrutta le opzioni di storage di Amazon S3
È necessario sfruttare il bucket AWS S3 e le sue diverse classi di storage per archiviare le tracce. Esporta le tracce su S3 prima della scadenza del periodo di conservazione. Utilizza le regole del ciclo di vita di Amazon S3 per spostare i dati di traccia nella classe di storage che soddisfa i tuoi requisiti.
Ad esempio, se hai tracce che risalgono a 90 giorni fa, Amazon S3 Intelligent-Tiering
Risorse aggiuntive:
