stigi opened a new issue, #9124: URL: https://github.com/apache/devlake/issues/9124
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and found no similar feature requirement. ### Use case As an engineering leader using DevLake for DORA metrics, I want to ingest incidents from [Datadog Incident Management](https://docs.datadoghq.com/incident_response/incident_management/), so that change failure rate and time to restore service keep working after a team moves its on-call off PagerDuty and onto Datadog. DevLake already supports PagerDuty, Opsgenie, Rootly and incident.io. Datadog is a common destination for teams consolidating monitoring, paging and incident response in one tool, and today those teams lose their incident source when they migrate. The only path left is the generic webhook plugin, which cannot carry severity history, detection timestamps or per-incident custom fields. ### Description Datadog Incident Management exposes incidents through the public API (`/api/v2/incidents`, paginated). Auth is the standard Datadog pair of an API key plus an application key, against a site-specific host (`api.datadoghq.com`, `api.datadoghq.eu`, `api.us3.datadoghq.com`, …), so the connection needs an endpoint or site field like other multi-region plugins. Proposed plugin, modeled on `incidentio` and `rootly`: - **Connection**: API key + application key + site/endpoint. - **Scope**: incident types, analogous to the incident-type scope in the incident.io plugin. A single organization-wide scope is the fallback for orgs that do not use incident types. - **Entities**: incidents → domain `issues` with `type = INCIDENT` plus `incidents`. Field mapping, verified against a production Datadog organization: | Datadog | Domain | |---|---| | `public_id` (and `slug`, e.g. `IR-22`) | `issue_key` | | `title` | `title` | | `severity` (`SEV-1`…`SEV-5`, `UNKNOWN`) | `severity`, via a configurable mapping | | `state` (`active` / `stable` / `resolved`) | `status`, `original_status` | | `created` | `created_date` | | `detected` | detection timestamp, for time to detect | | `resolved` | `resolution_date`, `lead_time_minutes` | | `customer_impacted`, `customer_impact_duration` | impact attributes | | `url` | `url` | | `is_test` | excluded from collection, like incident.io's test/tutorial incidents | - **Custom fields**: Datadog incidents carry both default fields (`detection_method`, `root_cause`, `services`, `teams`) and org-defined single-select, multi-select and free-text fields. The plugin would collect these verbatim into the tool layer, and the **scope config** would name which field maps onto `component` and which onto `severity`. The same shape as the deployment-name pattern in the CircleCI scope config. This keeps organization-specific vocabulary out of the plugin while making the fields usable for change-failure attribution. - No framework changes: the result feeds the existing DORA incident metrics. **Out of scope** for a first PR: Datadog On-Call (schedules, pages, escalation policies), monitors and alerts, and the Datadog DORA Metrics product. We have mapped the fields above against our own production Datadog organization through the API, and intend to implement the plugin in Go following the `incidentio` plugin layout (`models/raw`, tool models with migration scripts, collector/extractor/converter tasks, connection and scope APIs, e2e fixtures). Flagging the intent here first in case maintainers want a different scope model or a different approach to the custom-field mapping before we open the PR. ### Related issues - #9023 - incident.io plugin, the closest precedent for scope and field mapping - #8877 - Rootly plugin ### Are you willing to submit a PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
