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à operativa L'osservabilità è necessaria per ottenere informazioni utili sulle prestazioni degli ambienti e aiutarvi a rilevare e analizzare i problemi. Ha anche uno scopo secondario che consente di definire e misurare gli indicatori chiave di prestazione () e gli obiettivi dei livelli di servizio (KPIs), come l'SLOsoperatività. Per la maggior parte delle organizzazioni, le operazioni più importanti KPIs sono il tempo medio di rilevamento (MTTD) e il tempo medio di ripristino (MTTR) a seguito di un incidente. In termini di osservabilità, il contesto è importante, poiché i dati vengono raccolti e quindi vengono raccolti i tag associati. Indipendentemente dal servizio, dall'applicazione o dal livello di applicazione su cui ti stai concentrando, puoi filtrare e analizzare per quel set di dati specifico. I tag possono essere utilizzati per automatizzare l'onboarding di CloudWatch Alarms in modo che i team giusti possano essere avvisati quando vengono superate determinate soglie metriche. Ad esempio, una chiave di tag `example-inc:ops:alarm-tag` e il relativo valore potrebbero indicare la creazione dell'allarme. CloudWatch Una soluzione che lo dimostra è descritta in [Utilizzare i tag per creare e mantenere CloudWatch allarmi Amazon per le istanze Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/). La configurazione di troppi allarmi può facilmente creare una tempesta di avvisi, quando un gran numero di allarmi o notifiche sovraccarica rapidamente gli operatori e ne riduce l'efficacia complessiva, mentre gli operatori sono impegnati a classificare manualmente e a dare priorità ai singoli allarmi. È possibile fornire un contesto aggiuntivo per gli allarmi sotto forma di tag, il che significa che è possibile definire regole all'interno di Amazon EventBridge per garantire che venga prestata attenzione al problema originario anziché alle dipendenze a valle. Il ruolo delle operazioni parallele DevOps viene spesso trascurato, ma per molte organizzazioni i team operativi centrali forniscono ancora una prima risposta fondamentale al di fuori del normale orario lavorativo. (Maggiori dettagli su questo modello sono disponibili nel [white paper Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) [A differenza del DevOps team responsabile del carico di lavoro, in genere non hanno la stessa conoscenza approfondita, quindi il contesto fornito dai tag all'interno di dashboard e avvisi può indirizzarli al runbook corretto per il problema o avviare un runbook automatizzato (consulta il post sul blog Automating Amazon Alarms with). CloudWatch AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/)