Define dataflows for agent-integrations-owned integrations

[philjlee]

Jira: TXP-277

Adds assets/dataflows.yaml to 9 integrations owned by @DataDog/agent-integrations, declaring 13 dataflows. Mechanical change: no code, no metrics, no manifests touched.

Precedent: #2925 "Define dataflows for saas-integrations", which created 13 of the 14 existing dataflow files in this repo.

Selection criteria

A directory is in this batch only if all of the following hold:

1. It has no assets/dataflows.yaml today.
2. It has a parseable manifest.json. The dataflows validator hard-requires one — dataflows_validation_handler.go:56.
3. The correct data_type is mechanically derivable from a committed artifact, with no judgement call:
   • metadata.csv with at least one data row → metrics
   • a log pipeline under assets/logs/*.yaml → logs
   • a self.event(...) call in the check, or a README-documented event path → events
   • any combination → one entry each
4. .github/CODEOWNERS resolves <dir>/assets/dataflows.yaml (last-match-wins) to @DataDog/agent-integrations.

Every directory in this batch has @DataDog/agent-integrations as its Datadog team CODEOWNER (mendix is co-owned with @DataDog/ecosystems-review), so review from @DataDog/agent-integrations covers the whole PR.

Field values

provides:
  - id: <app_id>-<data_type>
    always_on: true
    granular: false
    data_type: <metrics|logs|events>
    direction: inbound

granular: false / direction: inbound throughout. always_on is set per entry rather than uniformly: true where the data reaches Datadog for every configured account, false where the vendor side must be deliberately switched on first. lacework-events is the one false in this batch — Lacework's alert channel exposes a single datadog_service selector that defaults to Logs Detail, so events only flow if an operator changes it to Events Summary. Per accountconf/internal/catalog_custom_overrides.py:69, always_on asserts that a datastream "is always enabled for all accounts", which that case does not satisfy.

Dataflow IDs are <app_id>-<data_type>, taking app_id from manifest.json rather than the directory name. All IDs were checked for collisions against every existing ID in the repo, and against each other.

Validation

These files were validated against the real validation logic of DataflowsValidationHandler from dd-source/domains/integrationscatalog/libs/catalogassetslib/dataflows_validation_handler.go, run over every dataflows.yaml file in the repo working tree with this PR applied. Result: 23 files, 30 distinct dataflow IDs, 0 failures, covering per-file unmarshalling, proto constraint validation, and the cross-file ID-uniqueness check.

The harness links the genuine generated proto package (integrationscatalog/libs/domain), so DataflowsConfig.Validate() and the protojson unmarshal path are the real ones rather than reimplementations; validDataTypes and the always_on / string-direction checks are copied verbatim from the handler. The handler package itself cannot be built outside Bazel on darwin — it transitively pulls the cgo cobs client, whose cobs.h and libcobs_client.so are Bazel-generated and absent from a plain go build.

The harness was negative-tested first and confirmed to reject: a missing always_on; a data_type outside validDataTypes; an id breaking ^[a-z0-9-]+$; an id under 3 characters; a numeric rather than string direction; a file with neither provides nor uses; a .yml extension; a missing manifest.json; and the same dataflow ID provided by two apps.

This matters because APW does not post validator comments on integrations-extras PRs (enable_validator_comments is set only for pub-platform-staging and publishing-platform). A malformed dataflows.yaml merges cleanly here and only fails afterwards, in the shared asset pipeline.

No data_type was guessed anywhere. Any integration whose correct value was not unambiguous is deferred to a later batch rather than approximated.

Contents

Metrics only (4)

Integration	Dataflow IDs
concourse_ci	concourse-ci-metrics
lighthouse	lighthouse-metrics
mendix	mendix-metrics
vns3	vns3-metrics

Logs only (1)

Integration	Dataflow IDs
sqreen	sqreen-logs

Metrics and logs (2)

Integration	Dataflow IDs
auth0	auth0-metrics, auth0-logs
bind9	bind9-metrics, bind9-logs

With events (2)

Integration	Dataflow IDs
lacework	lacework-logs, lacework-events
redis_sentinel	redis-sentinel-metrics, redis-sentinel-events

Both events entries were added in response to Codex review comments on this PR, and lacework-events was set to always_on: false in response to review from @alexeypilyugin. lacework offers an Events Summary outgoing type that targets the Datadog Events platform (lacework/README.md); the Redis Sentinel check calls self.event(...) on master failover (redis_sentinel.py). The other 7 integrations in this batch each explicitly document that they emit no events, so no further events entries are owed here.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: aa82e7c512

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[davidfeng-datadog]

looks like logs validator had a system error. Feel free to rebase the PR to trigger the CI again!