[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-cloudwatch-metrics-and-logs-cloudwatch-metrics-fundamentals-en":3,"lesson-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-cloudwatch-metrics-and-logs-cloudwatch-metrics-fundamentals-en":4,"next-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-cloudwatch-metrics-and-logs-cloudwatch-metrics-fundamentals-en":662},null,{"locked":5,"reason":3,"meta":6,"item":19},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"CloudWatch Metrics Fundamentals","How CloudWatch identifies, stores, and ages metric data: namespaces, dimensions, resolution, statistics, and the retention rollup that decides what you can still query six months from now.",true,20,"beginner",[13,14,15,16,17,18],"Identify a CloudWatch metric by its namespace, name, and dimension set","Explain why a dimension combination you never published cannot be queried","Compare standard resolution with high resolution, and basic EC2 monitoring with detailed monitoring","Predict the resolution a metric is still available at after 15 days, 63 days, and 15 months","Choose between Average, Maximum, and percentile statistics for a given operational question","Publish a custom metric without the timestamp mistakes that leave alarms in INSUFFICIENT_DATA",{"id":20,"title":7,"body":21,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":585,"infographics":586,"isFree":9,"learningObjectives":599,"meta":600,"navigation":9,"path":601,"quiz":602,"seo":659,"stem":660,"__hash__":661},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/01-cloudwatch-metrics-and-logs/01-cloudwatch-metrics-fundamentals.md",{"type":22,"value":23,"toc":575},"minimark",[24,28,31,36,39,42,93,111,115,118,129,139,150,156,165,168,172,175,181,187,194,201,205,233,239,269,272,279,283,286,338,343,346,353,356,360,363,402,405,425,429,434,507,510,519,532,538,541,545,568,571],[25,26,27],"p",{},"An alert fires at 09:14: the checkout API is timing out. You open the EC2 console, look at the instance, and see CPU at 22 percent. Nothing looks wrong. The reason nothing looks wrong is that the instance ran out of memory, and CloudWatch has no memory metric for EC2 unless you put one there yourself.",[25,29,30],{},"Every lesson in this course eventually reads a number out of CloudWatch. Before you can trust those numbers you need to know how CloudWatch stores them: what makes one metric different from another, how often values arrive, how long they survive, and which statistic answers which question. Get this layer wrong and everything built on top of it, alarms, scaling policies, dashboards, gives you confident answers to the wrong question.",[32,33,35],"h2",{"id":34},"the-address-of-a-metric","The address of a metric",[25,37,38],{},"A metric is a time-ordered set of data points. Each one has a value, a timestamp, and optionally a unit. On its own that is just a list of numbers, so CloudWatch needs a way to tell one list from another.",[25,40,41],{},"Three things make up the address:",[43,44,45,66,83],"ul",{},[46,47,48,52,53,57,58,61,62,65],"li",{},[49,50,51],"strong",{},"Namespace",": the container. AWS services use the pattern ",[54,55,56],"code",{},"AWS/service",", so EC2 metrics live in ",[54,59,60],{},"AWS/EC2",", Lambda metrics in ",[54,63,64],{},"AWS/Lambda",". There is no default namespace, and you must name one for every data point you publish.",[46,67,68,71,72,75,76,75,79,82],{},[49,69,70],{},"Metric name",": ",[54,73,74],{},"CPUUtilization",", ",[54,77,78],{},"Invocations",[54,80,81],{},"FreeStorageSpace",".",[46,84,85,88,89,92],{},[49,86,87],{},"Dimensions",": zero or more name/value pairs, such as ",[54,90,91],{},"InstanceId=i-0a1b2c3d",". A metric can carry up to 30 of them.",[25,94,95,96,99,100,102,103,106,107,110],{},"Namespaces isolate. Metrics in different namespaces never get aggregated together, which is why a custom application metric called ",[54,97,98],{},"Errors"," will not contaminate Lambda's ",[54,101,98],{},". Metrics also live only in the Region where they were created. A dashboard in ",[54,104,105],{},"eu-west-1"," will not find a metric published in ",[54,108,109],{},"us-east-1"," unless you build a cross-Region view deliberately.",[32,112,114],{"id":113},"dimensions-are-part-of-the-identity-not-a-filter","Dimensions are part of the identity, not a filter",[25,116,117],{},"This is the part that trips people up, so work through it with real values.",[25,119,120,121,124,125,128],{},"Suppose you publish four data points to a namespace called ",[54,122,123],{},"Checkout",", all with the metric name ",[54,126,127],{},"OrdersProcessed",":",[130,131,136],"pre",{"className":132,"code":134,"language":135},[133],"language-text","Dimensions: Service=api,    Stage=prod  Value: 105\nDimensions: Service=api,    Stage=beta  Value: 115\nDimensions: Service=worker, Stage=prod  Value: 95\nDimensions: Service=worker, Stage=beta  Value: 97\n","text",[54,137,134],{"__ignoreMap":138},"",[25,140,141,142,145,146,149],{},"You can retrieve statistics for exactly those four combinations. You cannot retrieve ",[54,143,144],{},"Service=api"," on its own, and you cannot retrieve ",[54,147,148],{},"Stage=prod"," on its own, because you never published a data point with only those dimensions. The query returns nothing at all, which reads on a dashboard like \"the metric is broken\" when it actually means \"that metric was never created\".",[25,151,152,153,155],{},"The misconception worth naming out loud: dimensions feel like filters on one big table, so people expect ",[54,154,148],{}," to slice the data. They are not filters. CloudWatch treats every unique combination of dimensions as its own separate metric. Adding one new dimension value creates a new variation of the metric rather than a new row inside the old one.",[25,157,158,159,161,162,164],{},"There is one exception that makes the confusion worse. For metrics from certain AWS services, EC2 among them, CloudWatch does aggregate across dimensions: search ",[54,160,60],{}," for ",[54,163,74],{}," with no dimensions and you get an average across your instances. CloudWatch never does this for custom metrics. So the behavior you learn from clicking around EC2 graphs is exactly the behavior that will not happen to the metrics your own code publishes.",[25,166,167],{},"If you want a total as well as a per-instance breakdown for a custom metric, publish both: one data point with the full dimension set, and one with the dimensions you want the rollup on.",[32,169,171],{"id":170},"resolution-how-often-a-number-arrives","Resolution: how often a number arrives",[25,173,174],{},"Every metric is one of two resolutions.",[25,176,177,180],{},[49,178,179],{},"Standard resolution"," has one-minute granularity. Everything AWS services publish is standard resolution.",[25,182,183,186],{},[49,184,185],{},"High resolution"," stores data at 1-second granularity and is only available for custom metrics you publish yourself. You can then read it back at a period of 1, 5, 10, or 30 seconds, or any multiple of 60.",[25,188,189,190,193],{},"A ",[49,191,192],{},"period"," is the length of time a statistic covers. Valid values are 1, 5, 10, 30, or any multiple of 60 seconds, and the default is 60. Aggregated data is stamped with the start of its period, so data covering 19:00 to 20:00 is stamped 19:00.",[25,195,196,197,200],{},"High resolution costs more in two places. Every ",[54,198,199],{},"PutMetricData"," call is billed, so publishing every second multiplies that charge, and a high-resolution alarm with a 10-second or 30-second period carries a higher alarm charge than a normal one. Reach for it when you genuinely need sub-minute reaction time, not by default.",[32,202,204],{"id":203},"basic-and-detailed-monitoring-on-ec2","Basic and detailed monitoring on EC2",[25,206,207,208,75,210,75,213,75,216,75,219,75,222,75,225,228,229,232],{},"EC2 publishes a fixed set of metrics for free at 5-minute intervals: ",[54,209,74],{},[54,211,212],{},"NetworkIn",[54,214,215],{},"NetworkOut",[54,217,218],{},"DiskReadOps",[54,220,221],{},"DiskWriteOps",[54,223,224],{},"DiskReadBytes",[54,226,227],{},"DiskWriteBytes",", and a few others. That is ",[49,230,231],{},"basic monitoring",", and it is on by default.",[25,234,235,238],{},[49,236,237],{},"Detailed monitoring"," is a paid per-instance option that drops the interval to 1 minute. Same metrics, five times the resolution.",[130,240,244],{"className":241,"code":242,"language":243,"meta":138,"style":138},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","aws ec2 monitor-instances --instance-ids i-0a1b2c3d4e5f67890\n","bash",[54,245,246],{"__ignoreMap":138},[247,248,251,255,259,262,266],"span",{"class":249,"line":250},"line",1,[247,252,254],{"class":253},"sbgvK","aws",[247,256,258],{"class":257},"s_sjI"," ec2",[247,260,261],{"class":257}," monitor-instances",[247,263,265],{"class":264},"stzsN"," --instance-ids",[247,267,268],{"class":257}," i-0a1b2c3d4e5f67890\n",[25,270,271],{},"Neither setting adds memory utilization or file system usage. Those numbers live inside the guest operating system, and the hypervisor that publishes EC2 metrics cannot see in. Collecting them needs the CloudWatch agent, which is the subject of a later lesson in this topic.",[25,273,274,275,278],{},"The exam-relevant consequence: an alarm's period must be at least as long as the metric's resolution. Put a 60-second period on a basic-monitoring metric and four out of five periods contain no data, so the alarm parks itself in ",[54,276,277],{},"INSUFFICIENT_DATA"," and never tells you anything. Either use a 300-second period or turn on detailed monitoring.",[32,280,282],{"id":281},"retention-your-data-ages-into-coarser-buckets","Retention: your data ages into coarser buckets",[25,284,285],{},"CloudWatch does not keep your 1-minute data forever, and it does not throw it away either. It aggregates it.",[287,288,289,302],"table",{},[290,291,292],"thead",{},[293,294,295,299],"tr",{},[296,297,298],"th",{},"Period of the data point",[296,300,301],{},"How long it stays available",[303,304,305,314,322,330],"tbody",{},[293,306,307,311],{},[308,309,310],"td",{},"Under 60 seconds (high resolution)",[308,312,313],{},"3 hours",[293,315,316,319],{},[308,317,318],{},"60 seconds",[308,320,321],{},"15 days",[293,323,324,327],{},[308,325,326],{},"300 seconds (5 minutes)",[308,328,329],{},"63 days",[293,331,332,335],{},[308,333,334],{},"3600 seconds (1 hour)",[308,336,337],{},"455 days (15 months)",[339,340],"infographic",{"alt":341,"slug":342},"A timeline showing a CloudWatch data point aging through four storage tiers, from sub-minute data kept for 3 hours to one-hour aggregates kept for 15 months.","cloudwatch-metric-retention-rollup",[25,344,345],{},"Follow one data point published today at 1-minute resolution. For 15 days you can graph it minute by minute. On day 16 the minute detail is gone, but the data still exists as 5-minute aggregates, and stays that way until day 63. After that only the hourly rollup survives, for a total of 455 days.",[25,347,348,349,352],{},"Two consequences that show up in real incidents. First, a post-mortem written three weeks after the event cannot show you the exact minute a spike started, only the 5-minute bucket it fell into. If minute-level detail matters for compliance or analysis, export it or stream it somewhere durable while it still exists. Second, a metric that stops receiving data disappears from the console search after two weeks even though ",[54,350,351],{},"get-metric-data"," can still return it. A metric nobody can find in the console is not the same as a metric that was deleted.",[25,354,355],{},"Metrics cannot be deleted at all. They expire on their own after 15 months without new data. That makes a badly chosen dimension, an instance ID baked into a metric name, or a stray namespace something you live with rather than clean up.",[32,357,359],{"id":358},"statistics-the-same-data-different-stories","Statistics: the same data, different stories",[25,361,362],{},"A statistic is an aggregation over a period. The choice changes the answer.",[43,364,365,371,377,383,389],{},[46,366,367,370],{},[49,368,369],{},"Average"," smooths. Good for capacity trends, bad for finding the one bad instance, because a fleet average of 40 percent hides the instance at 99 percent.",[46,372,373,376],{},[49,374,375],{},"Maximum"," is the opposite. One anomalous spike sets the whole graph's ceiling and makes a healthy system look sick.",[46,378,379,382],{},[49,380,381],{},"Sum"," is right for counters. Errors, invocations, request counts: the question is \"how many\", not \"how big\".",[46,384,385,388],{},[49,386,387],{},"SampleCount"," tells you how many data points went into the period, which is how you notice that a metric quietly stopped reporting.",[46,390,391,394,395,398,399,82],{},[49,392,393],{},"Percentiles"," sit between Average and Maximum. ",[54,396,397],{},"p95"," is the value below which 95 percent of your data falls, so it shows sustained heavy load while ignoring the occasional outlier. You can specify up to ten decimal places, as in ",[54,400,401],{},"p95.0123456789",[25,403,404],{},"Percentiles come with conditions. CloudWatch needs the raw, unsummarized data points to calculate them, so if you published a pre-aggregated statistic set, percentiles are usually unavailable. They also do not work on metrics with negative values. Services that support percentile statistics include API Gateway, Application Load Balancer, EC2, ELB, Kinesis, Lambda, and RDS.",[25,406,407,408,410,411,414,415,410,417,419,420,410,422,82],{},"A concrete pick: for \"is my latency acceptable for most users\", use ",[54,409,397],{}," on ",[54,412,413],{},"Duration",". For \"did anything break\", use ",[54,416,381],{},[54,418,98],{},". For \"am I about to hit a concurrency limit\", use ",[54,421,375],{},[54,423,424],{},"ConcurrentExecutions",[32,426,428],{"id":427},"publishing-your-own-metrics","Publishing your own metrics",[25,430,431,432,82],{},"Anything CloudWatch does not measure for you, you can publish yourself with ",[54,433,199],{},[130,435,437],{"className":241,"code":436,"language":243,"meta":138,"style":138},"aws cloudwatch put-metric-data \\\n  --namespace Checkout \\\n  --metric-name QueueDepth \\\n  --dimensions Service=worker,Stage=prod \\\n  --value 47 \\\n  --unit Count\n",[54,438,439,453,464,475,486,498],{"__ignoreMap":138},[247,440,441,443,446,449],{"class":249,"line":250},[247,442,254],{"class":253},[247,444,445],{"class":257}," cloudwatch",[247,447,448],{"class":257}," put-metric-data",[247,450,452],{"class":451},"s_hVV"," \\\n",[247,454,456,459,462],{"class":249,"line":455},2,[247,457,458],{"class":264},"  --namespace",[247,460,461],{"class":257}," Checkout",[247,463,452],{"class":451},[247,465,467,470,473],{"class":249,"line":466},3,[247,468,469],{"class":264},"  --metric-name",[247,471,472],{"class":257}," QueueDepth",[247,474,452],{"class":451},[247,476,478,481,484],{"class":249,"line":477},4,[247,479,480],{"class":264},"  --dimensions",[247,482,483],{"class":257}," Service=worker,Stage=prod",[247,485,452],{"class":451},[247,487,489,492,496],{"class":249,"line":488},5,[247,490,491],{"class":264},"  --value",[247,493,495],{"class":494},"srdBf"," 47",[247,497,452],{"class":451},[247,499,501,504],{"class":249,"line":500},6,[247,502,503],{"class":264},"  --unit",[247,505,506],{"class":257}," Count\n",[25,508,509],{},"Three details decide whether this works in production.",[25,511,512,515,516,518],{},[49,513,514],{},"Timestamps."," A data point can be stamped up to two weeks in the past and up to two hours into the future. Omit the timestamp and CloudWatch stamps it on arrival. Alarms evaluate against the current UTC time, so a metric arriving with a skewed clock lands in periods the alarm has already evaluated. The symptom is an alarm stuck in ",[54,517,277],{}," or firing long after the event, not an API error, which makes clock skew a genuinely hard bug to spot.",[25,520,521,524,525,527,528,531],{},[49,522,523],{},"Volume."," Every ",[54,526,199],{}," call is billed. If you need many samples per minute, publish a ",[49,529,530],{},"statistic set"," instead: give CloudWatch the Min, Max, Sum, and SampleCount for a batch of observations in one call. The tradeoff is that you lose percentile statistics, since the raw points are gone.",[25,533,534,537],{},[49,535,536],{},"Same identity, many sources."," CloudWatch does not care which host sent a data point. Twenty web servers publishing to the same namespace, metric name, and dimensions produce one metric describing all of them. That is often exactly what you want for a fleet-level latency number.",[25,539,540],{},"For applications that already write structured logs, the embedded metric format (EMF) is worth knowing: you write a specially structured JSON log event to CloudWatch Logs, and CloudWatch extracts metrics from it automatically. Container Insights and Lambda Insights both work this way, which you will see later in this topic.",[32,542,544],{"id":543},"exam-tips","Exam tips",[43,546,547,550,556,559,562,565],{},[46,548,549],{},"\"Memory utilization\" and \"disk space used on the file system\" always point at the CloudWatch agent, never at basic or detailed monitoring. Detailed monitoring changes frequency, not coverage.",[46,551,552,553,555],{},"Basic monitoring is 5 minutes, detailed is 1 minute. An alarm in ",[54,554,277],{}," with a 60-second period on an EC2 metric is the classic basic-monitoring trap.",[46,557,558],{},"A query that returns no data for a partial dimension set is not a bug. Check whether that exact combination was ever published, and remember that custom metrics never aggregate across dimensions.",[46,560,561],{},"High resolution means 1 second, and it applies only to custom metrics. High-resolution alarms can use 10 or 30 second periods and cost more.",[46,563,564],{},"Memorize the retention ladder as 3 hours, 15 days, 63 days, 455 days. Questions phrase it as \"can we still see minute-level data from three months ago\", and the answer is no, only the hourly rollup.",[46,566,567],{},"If a question contrasts hiding outliers with being dominated by them, the intended answer is a percentile.",[25,569,570],{},"The rule to carry forward: a metric is defined by namespace plus name plus its exact dimension set, and everything else, resolution, retention, statistics, follows from how it was published. Next you will move from numbers to text, where the raw evidence lives: CloudWatch Logs, and the query language that turns a million log lines into an answer.",[572,573,574],"style",{},"html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .stzsN, html code.shiki .stzsN{--shiki-light:#91B859;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .s_hVV, html code.shiki .s_hVV{--shiki-light:#90A4AE;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}",{"title":138,"searchDepth":466,"depth":466,"links":576},[577,578,579,580,581,582,583,584],{"id":34,"depth":455,"text":35},{"id":113,"depth":455,"text":114},{"id":170,"depth":455,"text":171},{"id":203,"depth":455,"text":204},{"id":281,"depth":455,"text":282},{"id":358,"depth":455,"text":359},{"id":427,"depth":455,"text":428},{"id":543,"depth":455,"text":544},"md",[587],{"slug":342,"concept":588,"style":589,"aspectRatio":590,"labels":591},"A left-to-right timeline showing how one CloudWatch data point ages through four storage tiers. Four segments of increasing width along a single horizontal age axis, each labeled with the period it is stored at and how long it survives, with the arrows between segments marked as aggregation rather than deletion. The visual emphasis is that data is never lost, it becomes coarser, and that a 1-second data point is gone within hours.","timeline","16:9",[592,593,594,595,596,597,597,597,598],"Age of the data point","Under 60 seconds: kept 3 hours (high resolution custom metrics only)","60 seconds: kept 15 days","300 seconds: kept 63 days","3600 seconds: kept 455 days (15 months)","aggregated, not deleted","Old data does not disappear, it gets coarser. Sub-minute detail survives only 3 hours.",[13,14,15,16,17,18],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/01-cloudwatch-metrics-and-logs/01-cloudwatch-metrics-fundamentals",{"passingScore":603,"questions":604},70,[605,614,622,630,640,645,653],{"question":606,"type":607,"options":608,"correctAnswer":611,"explanation":613},"You published a custom metric named ServerStats with the dimensions Server=Prod and Region=Frankfurt, and separately with Server=Prod and Region=Dublin. You now try to graph ServerStats with only Server=Prod specified. What happens?","single",[609,610,611,612],"CloudWatch returns the sum of the Frankfurt and Dublin values","CloudWatch returns the average of the two dimension sets","No data is returned, because you never published a data point with Server=Prod alone","CloudWatch returns the most recent of the two data points","Each unique dimension combination is a separate metric, and you can only retrieve combinations you actually published. CloudWatch does aggregate across dimensions for some AWS services such as EC2, but never for custom metrics, which is why the partial-dimension query comes back empty.",{"question":615,"type":607,"options":616,"correctAnswer":617,"explanation":621},"An EC2 instance uses basic monitoring. An engineer creates an alarm on CPUUtilization with a period of 60 seconds and the alarm sits in INSUFFICIENT_DATA. What is the cause?",[617,618,619,620],"Basic monitoring publishes data every 5 minutes, so most 60-second periods have no data point","CPUUtilization is not published for EC2 instances without the CloudWatch agent","Alarms cannot use a 60-second period","The instance needs a CloudWatch VPC endpoint","The alarm period must be at least as long as the metric's resolution. Basic monitoring delivers one CPUUtilization point every 300 seconds, so four out of every five 60-second periods are empty. Either raise the period to 300 seconds or enable detailed monitoring.",{"question":623,"type":607,"options":624,"correctAnswer":628,"explanation":629},"A data point was published today with a period of 1 minute. In 90 days, at what resolution can you still retrieve it?",[625,626,627,628],"1 minute","It is deleted after 63 days","5 minutes","1 hour","CloudWatch keeps 1-minute data for 15 days, rolls it up to 5-minute data available for 63 days, then to 1-hour data available for 455 days. At 90 days you are past the 63-day boundary, so only the 1-hour aggregate remains. Nothing is deleted at these boundaries, it just gets coarser.",{"question":631,"type":632,"options":633,"correctAnswers":638,"explanation":639},"Which statements about high-resolution custom metrics are accurate? (Choose 2.)","multiple",[634,635,636,637],"They are stored with a resolution of 1 second and can be read at periods of 1, 5, 10, or 30 seconds","Data points with a period under 60 seconds are retained for 3 hours","AWS services publish their metrics as high resolution by default","High-resolution metrics are retained for 15 days at 1-second resolution",[634,635],"High resolution is an opt-in property of custom metrics only, and sub-minute data survives just 3 hours before it rolls up. Metrics produced by AWS services are standard resolution, meaning one-minute granularity at best, so the third option is the tempting but wrong one.",{"question":641,"type":607,"options":642,"correctAnswer":643,"explanation":644},"Your team wants an alarm that catches individual instances with unusually heavy CPU load, without a single spiking instance skewing the result or a fleet-wide average hiding it. Which statistic fits?",[381,643,369,387],"A percentile such as p95","Average smooths outliers away and Maximum lets one anomaly dominate the graph. A percentile shows the value below which 95 percent of the data falls, which surfaces sustained heavy load while ignoring a single spike. Percentiles need raw data points, so they will not work if you published a statistic set instead.",{"question":646,"type":607,"options":647,"correctAnswer":650,"explanation":652},"A monitoring script publishes custom metrics with timestamps taken from a server whose clock is 6 hours behind UTC. What is the most likely operational symptom?",[648,649,650,651],"PutMetricData rejects every call with a validation error","The metric appears under the wrong namespace","The alarm on that metric stays in INSUFFICIENT_DATA or fires late","The data points are stored at high resolution automatically","CloudWatch accepts timestamps up to two weeks in the past, so a 6-hour skew is accepted rather than rejected. Alarms evaluate against the current UTC time, so the data lands in periods the alarm has already finished evaluating, which produces empty periods now and delayed evaluations later.",{"question":654,"type":607,"options":655,"correctAnswer":657,"explanation":658},"True or False: a CloudWatch metric can be deleted through the console once you no longer need it.",[656,657],"True","False","Metrics cannot be deleted. They expire on their own after 15 months with no new data points, and they stop appearing in the console after two weeks of silence even though get-metric-data can still retrieve them. Plan namespaces and dimensions carefully, because a bad dimension choice cannot be cleaned up later.",{"title":7,"description":8},"courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/01-cloudwatch-metrics-and-logs/01-cloudwatch-metrics-fundamentals","jkl5LmaZH1U0r0Eot2bLRjTUw2jnz4Zo20GrZjGIDCY",{"locked":9,"reason":663,"meta":664,"item":3},"paywall",{"title":665,"description":666,"isFree":5,"estimatedMinutes":667,"difficulty":668,"learningObjectives":669},"CloudWatch Logs and Logs Insights","Log groups, retention, and the three ways log data leaves CloudWatch Logs: metric filters that create alarms, subscription filters that stream in near real time, and Logs Insights queries that answer one-off questions.",22,"intermediate",[670,671,672,673,674,675],"Describe the relationship between log events, log streams, and log groups","Set retention deliberately and explain what the default costs you","Choose between a metric filter, a subscription filter, and a Logs Insights query for a given requirement","Write a Logs Insights query using fields, filter, stats, and sort","Distinguish filter pattern syntax from Logs Insights query syntax","Control Logs Insights cost with time ranges, log group scope, and field indexes"]