惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
The Blog of Author Tim Ferriss
I
InfoQ
H
Hackread – Cybersecurity News, Data Breaches, AI and More
aimingoo的专栏
aimingoo的专栏
小众软件
小众软件
有赞技术团队
有赞技术团队
J
Java Code Geeks
Apple Machine Learning Research
Apple Machine Learning Research
大猫的无限游戏
大猫的无限游戏
Engineering at Meta
Engineering at Meta
B
Blog RSS Feed
博客园_首页
Y
Y Combinator Blog
V
Visual Studio Blog
Google DeepMind News
Google DeepMind News
M
MIT News - Artificial intelligence
雷峰网
雷峰网
博客园 - 司徒正美
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
H
Help Net Security
P
Proofpoint News Feed
B
Blog
云风的 BLOG
云风的 BLOG
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis
AWS CPU Steal: How to detect it with Datadog
2013-08-27 · via Datadog | The Monitor blog

CPU steal is a fundamental property of virtual environments. Virtualization offers the ability to over-subscribe compute between multiple instances because not all instances need CPU at the same time. This results in lower compute costs for AWS but may lead to inconsistent performance for the user.

Since the price per instance type is generally the same in a given region, through the use of hypervisors, AWS ensures that all virtual machines get a fair share of access to the underlying hardware. When a hypervisor has to juggle among a large number of virtual machines, the overhead of virtualization becomes higher and scheduling fairness (how often the hypervisor will run a particular instance) can get in the way of optimally sharing resources. This is what’s known as “CPU Steal” or “Stolen CPU”. In the step-by-step explanation below, we will show you how to detect when CPU Steal is occurring in your AWS instances using Datadog.

How to detect AWS CPU steal With Datadog

To detect CPU steal you need to track the system metric “system.cpu.stolen.” To see CPU steal in AWS with Datadog, sign up for a free trial account, enable the AWS integration and install the Datadog Agent on your instance.

The system.cpu.stolen metric measures the percentage of cycles that were reclaimed by the hypervisor because the instance has reached the capacity of some underlying quota or hardware limitation. By analyzing system.cpu.stolen over time and comparing it to the CPU idle metric (system.cpu.idle), you can determine if stolen CPU is a result of the hypervisor enforcing a quota or because other tenants on the same hardware are requesting more cycles than are available. More information on how this occurs is available in our Understanding AWS stolen CPU and how it affects your apps blog post

To see system.cpu.stolen and system.cpu.idle in Datadog, go to the metrics explorer by hovering over the “Metrics” tab and selecting “Explorer” from the dropdown menu.

Datadog Metrics Toolbar

On the left of the Metrics Explorer screen, begin typing “system.cpu.stolen” in the “Graph:” text box and select it from the dropdown options. Do the same for “system.cpu.idle”.

Selecting CPU metrics in Datadog to measure steal

By default the Metrics Explorer will track all the hosts you’re monitoring with Datadog. To track a specific host, enter the hostname in the “Over:” text box.

Selecting hosts to detect AWS CPU Steal

Finally, select the time period to analyze. For this example, we will look at the past week.

Selecting the time frame to detect CPU steal

CPU Steal typically increases as CPU Idle approaches zero. High variations in the amount of CPU steal you see for different occurrences of CPU idle going to zero can be an indication that your application’s performance is being adversely affected by other tenants on the same hardware who are also requesting cycles at the same time.

Graphs to detect AWS CPU steal in Datadog

Getting this visibility into your AWS CPU utilization should take just a few minutes after signing up for Datadog.