- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Metric monitors offer enhanced options for handling missing data, allowing you to differentiate between missing data as a failure mode and a healthy state.
These options align with what’s available in other monitors types like Logs, Events, CI, Database, Error Tracking, and more.
When measuring the number of bad events, like errors, Monitors should reflect an “OK” when no data is detected. With the legacy No Data configurations, monitors would report No Data. The On Missing Data configuration options allows monitors to reflect health states more accurately, improving clarity.
If you manage your monitors from the UI, the configuration automatically updates the next time you edit them. To update the On Missing Data configuration sooner, see the following sections on adjusting through the API.
If you are managing your monitors with API or Terraform, replace notify_no_data
and no_data_timeframe
with on_missing_data
. The no_data_timeframe
parameter is not required since on_missing_data
uses the same time frame as the time window.
The previous No Data parameter, notify_no_data
, remains available on existing monitors and are not automatically upgraded to the new on_missing_data
features.
Parameter | UI Description |
---|---|
"on_missing_data": "show_and_notify_no_data" | If data is missing Show NO DATA and notify (Formerly, “Notify if data is missing”) |
"on_missing_data": "show_no_data" | If data is missing Show NO DATA (Formerly, “Do not notify if data is missing”) |
"on_missing_data": "resolve" | If data is missing Show OK |
"on_missing_data": "default" if using sum or count aggregation | If data is missing Evaluate as 0 (or other default value) |
"on_missing_data": "default" if using all other aggregation types | If data is missing Show last known status |
For all the available fields, see the API Documentation.
Here’s an example of before and after of a JSON monitor with those fields:
Before
{
"name": "CPU usage is high for host $host.value",
"type": "query alert",
"query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90",
"message": "A high CPU usage has been detected for host $host.value, which can impact the system performance.",
"tags": [],
"options": {
"thresholds": { "critical": 90 },
"notify_audit": false,
"include_tags": false,
"notify_no_data": true,
"no_data_timeframe": 10
}
}
After
{
"name": "CPU usage is high for host $host.value",
"type": "query alert",
"query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90",
"message": "A high CPU usage has been detected for host $host.value, which can impact the system performance.",
"tags": [],
"options": {
"thresholds": { "critical": 90 },
"notify_audit": false,
"include_tags": false,
"on_missing_data": "show_and_notify_no_data"
}
}
SLOs treat uptime and downtime according to this mapping:
On Missing Data Configuration | Monitor Status | SLO Treatment |
---|---|---|
Show OK | OK | Uptime |
Show No Data | No Data | Uptime |
Show No Data and Notify | No Data | Downtime |
Show last known status | Whatever the last status was | If OK, Uptime If Alert, Downtime |
Evaluate as zero | Depends on the threshold configuration | If OK, Uptime If Alert, Downtime |
추가 유용한 문서, 링크 및 기사: