[pipeline-error-handling] High-impact log pipelines still miss pipeline_error classification in on_failure

## Scan summary

- Pipelines scanned: **1671** (`packages/*/data_stream/*/elasticsearch/ingest_pipeline/*.yml`)
- Missing top-level `on_failure`: **207**
- Incomplete top-level `on_failure` (missing `event.kind: pipeline_error` and/or `error.message`): **212**

This report only includes **high-severity**, operator-impacting cases that were re-verified in the repository and are **not** covered by open tracker issues `#18026`, `#18580`, or `#18701`.

## Findings

### 1. Nginx log pipelines do not mark ingest failures as `pipeline_error`

**Locations**
- `packages/nginx/data_stream/access/elasticsearch/ingest_pipeline/default.yml:224-227`
- `packages/nginx/data_stream/error/elasticsearch/ingest_pipeline/default.yml:64-67`

**Evidence**
```yaml
on_failure:
- set:
field: error.message
value: '\{\{ _ingest.on_failure_message }}'
```

Normal flow sets `event.kind: event` (`access`: lines 160-162, `error`: lines 56-57), but failure flow never sets `event.kind: pipeline_error`.

**What is wrong**
Parse failures are captured in `error.message` only; documents are not explicitly classified as pipeline failures.

**Why it matters**
Nginx access/error logs are free-form and variant-heavy in real deployments. Without `event.kind: pipeline_error`, failed parses are hard to discover with standard failure filters and alerts.

**Suggested fix**
Add this to each top-level `on_failure`:
```yaml
- set:
field: event.kind
value: pipeline_error
```
(keep existing `error.message` assignment)

---

### 2. Apache access/error pipelines have the same failure-classification gap

**Locations**
- `packages/apache/data_stream/access/elasticsearch/ingest_pipeline/default.yml:248-251`
- `packages/apache/data_stream/error/elasticsearch/ingest_pipeline/default.yml:138-141`

**Evidence**
```yaml
on_failure:
- set:
field: error.message
value: '\{\{ _ingest.on_failure_message }}'
```

Normal flow sets `event.kind: event` (`access`: lines 95-96, `error`: lines 69-70), but top-level failure flow does not set `pipeline_error`.

**What is wrong**
Failure documents are not reliably classifiable as ingest pipeline failures.

**Why it matters**
Apache logs are free-form and commonly customized; parse failures are inevitable. Missing `pipeline_error` weakens operational detection and triage.

**Suggested fix**
Add `event.kind: pipeline_error` to both top-level `on_failure` blocks while preserving current `error.message` behavior.

---

### 3. MongoDB log pipelines omit `pipeline_error` across all parse paths

**Locations**
- `packages/mongodb/data_stream/log/elasticsearch/ingest_pipeline/default.yml:54-57`
- `packages/mongodb/data_stream/log/elasticsearch/ingest_pipeline/pipeline-json.yml:52-55`
- `packages/mongodb/data_stream/log/elasticsearch/ingest_pipeline/pipeline-plaintext.yml:32-35`

**Evidence**
Each top-level `on_failure` only sets `error.message`, e.g.:
```yaml
on_failure:
- set:
field: error.message
value: '\{\{ _ingest.on_failure_message }}'
```

**What is wrong**
None of the top-level failure handlers set `event.kind: pipeline_error`.

**Why it matters**
This dataset processes mixed JSON/plaintext logs and routes by first-character parsing; failures are realistic and need explicit failure classification for reliable observability.

**Suggested fix**
Add `set event.kind = pipeline_error` in all three top-level `on_failure` handlers.

## Missing-handler and `preserve_original_event` review

- No new high-priority **missing top-level `on_failure`** case was confirmed in core free-form network/syslog integrations during this run.
- `preserve_original_event` packages reviewed: `azure_blob_storage`, `google_cloud_storage`, `http_endpoint`, `sonicwall_firewall`, `tcp`, `udp`, `winlog`.
- No new high-severity preserve gap was identified beyond already-tracked `sonicwall_firewall` in `#18026`.

## Suggested actions

- [ ] Add `event.kind: pipeline_error` to the Nginx, Apache, and MongoDB top-level `on_failure` handlers listed above.
- [ ] Add ingest pipeline tests asserting failure-path documents include both `error.message` and `event.kind: pipeline_error` for these datasets.

> [!NOTE]
>
> 🔒 Integrity filter blocked 9 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#18159](https://github.com/elastic/integrations/issues/18159) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#14205](https://github.com/elastic/integrations/issues/14205) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#17278](https://github.com/elastic/integrations/issues/17278) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#11443](https://github.com/elastic/integrations/issues/11443) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#18587](https://github.com/elastic/integrations/issues/18587) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#18067](https://github.com/elastic/integrations/issues/18067) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#12213](https://github.com/elastic/integrations/issues/12213) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#12986](https://github.com/elastic/integrations/issues/12986) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#15483](https://github.com/elastic/integrations/issues/15483) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Sweeper: Pipeline Error Handler Compliance](https://github.com/elastic/integrations/actions/runs/25427948391)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on May 13, 2026, 9:59 AM UTC