- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
",t};e.buildCustomizationMenuUi=t;function n(e){let t='
",t}function s(e){let n=e.filter.currentValue||e.filter.defaultValue,t='${e.filter.label}
`,e.filter.options.forEach(s=>{let o=s.id===n;t+=``}),t+="${e.filter.label}
`,t+=`Follow this migration workflow to rebuild your PagerDuty on-call structure in Datadog, team by team. It reuses your existing PagerDuty schedules and escalation policies as building blocks so you can review, tweak, or discard each resource before it goes live.
By rebuilding your on‑call setup from only current, relevant PagerDuty data, you avoid bringing legacy clutter into Datadog and start with a concise, maintainable configuration.
on_call_write
and teams_manage
permissions.Select one of the following options:
Map with another Datadog team: Choose the appropriate Datadog team from the list.
Create a new team: Enter a team name when prompted. Datadog builds the team using the structure and members from your PagerDuty team.
Handle unmapped users:
Datadog matches users by email address. For unmapped users you can:
When the mapping looks correct, select Import team.
Choose a template to define how alerts reach the team:
When you edit routing rules, you can import existing PagerDuty escalation policies and schedules instead of recreating them.
Datadog will automatically apply the imported configurations. You can change the policies and schedules at any time.
추가 유용한 문서, 링크 및 기사: