Een DevOps-team ondersteunt een applicatie die draait op veel EC2-instances in een Auto Scaling-groep, geïmplementeerd via CloudFormation. Eén instance gaf onlangs fouten terug voor een groot deel van de verzoeken, terwijl deze gezond bleef volgens EC2- en ELB-health checks. Applicatielogs worden verzameld in CloudWatch met behulp van embedded metric format. Het team heeft een waarschuwing nodig als een enkele EC2-instance verantwoordelijk is voor meer dan de helft van alle fouten, met minimale operationele overhead. Welke combinatie van stappen bereikt dit? (Kies twee.)

De combinatie van een CloudWatch Contributor Insights-regel en een CloudWatch-alarm met de INSIGHTRULEMETRIC-functie is de meest efficiënte oplossing. Contributor Insights is ontworpen om top-N-contributors te identificeren in loggegevens, zoals de instance die de meeste fouten genereert, met minimale operationele overhead. Door te groeperen op instance ID en foutmeldingen, kan het de problematische instance isoleren. Het CloudWatch-alarm kan vervolgens de output van deze Contributor Insights-regel monitoren met behulp van de INSIGHTRULEMETRIC-functie om te detecteren wanneer één instance meer dan 50% van de fouten veroorzaakt en het team waarschuwen. De andere opties zijn minder geschikt: Het maken van een resourcegroep en het toevoegen aan Application Insights is nuttig voor algemeen applicatiemonitoring, maar niet specifiek gericht op het identificeren van een enkele foutieve instance in verhouding tot het totaal. Een metrisch filter en alarm op basis van METRICCOUNT telt alleen het totale aantal fouten en identificeert niet de bijdragende instance. Een CloudWatch Logs-abonnementfilter met een Lambda-functie zou meer operationele overhead met zich meebrengen voor het schrijven en onderhouden van de Lambda-code, en is complexer dan Contributor Insights voor dit specifieke gebruiksscenario.