{"owner":"elastic","repo":"beats","hasSkills":true,"totalSkillsCount":9,"totalTokensCount":6540,"categories":["anthropic-skill","plugin-manifest","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/docs-authoring/SKILL.md","dev-tools/README.md","dev-tools/packaging/templates/ironbank/filebeat/README.md","dev-tools/packaging/templates/ironbank/auditbeat/README.md","AGENTS.md","dev-tools/kubernetes/README.md","dev-tools/packaging/templates/ironbank/heartbeat/README.md","dev-tools/packaging/templates/ironbank/metricbeat/README.md","dev-tools/packaging/templates/ironbank/packetbeat/README.md"],"skills":{".agents/skills/docs-authoring/SKILL.md":"---\nname: docs-authoring\ndescription: >\n  Write or edit user-facing documentation. Use when a change adds or edits a\n  published doc page, a snippet, navigation, or the source that generates a page.\n  Decides whether a change needs docs, where the content goes, what must be\n  verified against the product, and how to scope it with applies_to. Does not\n  cover changelog fragments or release-note entries.\nmetadata:\n  source: elastic-docs-authoring\n  source_version: \"1.0.0\"\n---\n\n# Documentation\n\nUse `docs/extend/contributing-docs.md` for the repository-specific publishing, placement, and generation instructions.\n\nA page is published as written. Write for the person doing the task, and write it as the final text they will read.\n\nAsk when the change does not tell you who it is for or what they can now do. Never invent a UI label, a default, a limit, a permission, or a behavior, and never generate a screenshot. Name the screenshot that is needed and where it goes.\n\n## Whether to write\n\n| The change | What to do |\n|---|---|\n| Nothing new for the reader to choose, configure, or do | No page change. Say so. |\n| A page already says this | Show where, and narrow or drop the edit |\n| A page states something that is now false | Fix that page |\n| A workflow gained a step or option a reader would otherwise miss | Add it |\n| A page is deliberately general and the request adds specifics | Usually not a gap. Say so |\n| Something the page documents was removed | Keep the content and scope it. Do not delete it |\n\n\"Remove X\" describes the product change, not the edit. The docs are cumulative, and readers on versions that still have the feature still need the page. For a GA or deprecated feature in a versioned product, keep the content and mark it `removed <version>` with `applies_to`. Deleting is reasonable only when the feature was only ever a preview or beta, or only ever existed in a product that has no versions. Say which reading you took.\n\nConcluding that nothing needs documenting is a valid result. Report it and stop.\n\n## Where it goes\n\nStart from the assumption that an existing page should absorb the change. Adding a page is the exception.\n\nSearch before you add. Search the published docs and the `docs/` tree of this repository, including snippets and pages that are not linked yet. A search that did not run is not evidence that nothing covers the topic, so do not report \"nothing covers this yet\" unless you looked.\n\nPropose the lightest change that closes the gap, in this order: a sentence in an existing section, a new section, a new page. Pause when you are about to add a page, or when the change touches several pages.\n\nPut each fact in one place. A caveat that belongs on every page belongs on the one page that owns the concept, with the others linking to it. A sentence, admonition, or requirement repeated at the top of every page in a section is that mistake. A shared snippet is not, when its only job is to say which of two similar systems the page documents: no `applies_to` value can say that, and the wording lives once. Check the nearest `_snippets/` directory before writing prose that more than one page needs.\n\n## Verify, then write\n\nList every concrete claim the page will make: each UI string, field name, setting, default, limit, permission, and behavior. Then verify each one against the product source as it is now, not against the issue or the pull request description. A diff shows one change. The current source shows what the reader will meet.\n\nAnything you cannot verify goes back to the author as a question. It does not go in the page.\n\nBecause the page covers every supported version, a statement that is true only in the latest code is wrong for most readers. Confirm each claim for the versions the page covers, or scope it.\n\nThe product's own lifecycle field outranks the request. A release-note label, a bare version number, and \"on by default\" all mean something shipped. None of them means generally available. A backport label is not a released version, and neither is a merged pull request. Use the minor version in an `applies_to` badge. When a critical difference really is patch-specific, explain the exact patch in prose.\n\n## Versioning\n\nOne page covers every version. Do not copy a page per release. Mark a difference with `applies_to` on the page or on the section that differs.\n\n```yaml\napplies_to:\n  stack: ga 9.1\n  serverless: ga\n```\n\nA feature that exists only in some versions gets `applies_to` on that section. When it is removed from a versioned product, keep the section and add the removal, for example `stack: removed 9.1`. When the page is generated, the repository contributing guide says where the version is set. Do not hand-edit `applies_to` in a generated page.\n\nIf `docs-applies-to-tagging` is installed, let it choose the values and the placement. Collect the version, lifecycle, and deployment answers and hand them over.\n\n## Write the page\n\nWrite what the reader can now do, see, configure, or avoid. The notes you were given describe an implementation. Nothing later will translate them for you, so do it as you draft. Cut anything that does not serve the task, including a detail that is there only because the issue mentioned it.\n\nOrder the page for the task: what it is, then how to do it, then the edge cases. Open a new option or mode on the outcome, not the control. For example, use **View documents as JSON**, then write the sentence that names the control. The labels and defaults you verified are a checklist the page must not contradict. They are not an outline.\n\n- Address the reader as you. Do not call them users or customers.\n- Present tense. Active voice. One idea per sentence.\n- Sentence case for headings. No trailing period on a heading.\n- Name the product, feature, page, or setting on first mention. No internal names: packages, functions, struct fields, ticket numbers, or team names.\n- Backticks for settings, field names, file names, CLI flags, and values the reader types.\n- Quote a UI label only when it would otherwise read as prose. Feature names are capitalized and not quoted.\n- US English.\n\nUse the substitutions the repository defines (`{{kib}}`, `{{es}}`, and the product's own) the way the surrounding page does. Do not spell out a name that page writes as a substitution, and do not introduce one it does not use.\n\n## Links and navigation\n\nA new page goes in the `toc.yml` for its section. Navigation is per docset, and some sections nest their toc, so copy the shape of the section you are adding to rather than inventing one.\n\nUse descriptive link text rather than a bare URL or generic call to action. A link to a page in another Elastic docset uses that docset's form (`docs-content://...`, `integration-docs://...`), not `https://www.elastic.co/docs/...`.\n\nA page you moved, renamed, or deleted needs an entry in `redirects.yml`. If `docs-redirects` is installed, hand it the old path and the new one.\n\nA link to a page being added in another repository cannot resolve until that change publishes. Leave the link, name the change it waits on, and do not point it at a placeholder. Every other unresolved link is a defect.\n\n## Generated pages\n\nIf a page says it is generated, edit the source it names and regenerate. An edit to the generated file is overwritten on the next run. The repository contributing guide names the source and the command.\n\n## Checks\n\nApply these rules while you write, not after. Run the repository's docs build and Vale checks. If the `elastic-docs-skills` plugin is installed, run the individual checks that apply for content type, `applies_to`, style, frontmatter, jargon, syntax, and redirects. `docs-draft-feature-docs` is an end-to-end drafting workflow, not a post-edit checker. Do not copy its companion skills into this repository.\n\nReference: [Elastic style guide](https://www.elastic.co/docs/contribute-docs/style-guide), [cumulative docs](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs), [`applies_to` reference](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs/reference), [content types](https://www.elastic.co/docs/contribute-docs/content-types).\n","dev-tools/README.md":"Available scripts\n-----------------\n\n\nThe following scripts are used by the unified release process:\n\n| File                 | Description |\n|----------------------|-------------|\n| get_version          | Returns the current version |\n| set_version          | Sets the current version in all places where change is required. Doesn't commit changes. |\n| deploy               | Builds all artifacts for the officially supported Beats |\n\n\n\nOther scripts:\n\n\n| File                 | Description |\n|----------------------|-------------|\n| aggregate_coverage.py | Used to create coverage reports that contain both unit and system tests data |\n| merge_pr | Used to make it easier to open a PR that merges one branch into another. |\n\n\nImport / export the dashboards of a single Beat:\n\n| File                  | Description |\n|-----------------------|-------------|\n| export_dashboards.py  | Python script to export the Beat dashboards from Elasticsearch to a local directory|\n\nRunning export_dashboards.py in environment\n----------------------------------------------\n\nIf you are running the python script for the first time, you need to create the\nenvironment by running the following commands in the `beats/dev-tools`\ndirectory:\n\n```\nvirtualenv env\n. env/bin/activate\npip install -r requirements.txt\n```\n\nThis creates the environment that contains all the python packages required to\nrun the `export_dashboards.py` script. Thus, for the next runs you just need\nto enable the environment:\n\n```\n. env/bin/activate\n```\n","dev-tools/packaging/templates/ironbank/filebeat/README.md":"# filebeat\n\n**filebeat** Lightweight shipper for logs\n\nForget using SSH when you have tens, hundreds, or even thousands of servers, virtual machines, and containers generating logs. Filebeat helps you keep the simple things simple by offering a lightweight way to forward and centralize logs and files.\n\nFor more information about filebeat, please visit\nhttps://www.elastic.co/products/beats/filebeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running filebeat on Docker](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [filebeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/filebeat)\n- [filebeat Documentation](https://www.elastic.co/guide/en/beats/filebeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/auditbeat/README.md":"# Auditbeat\n\n**Auditbeat** Lightweight shipper for audit data\n\nCollect your Linux audit framework data and monitor the integrity of your files.\nAuditbeat ships these events in real time to the rest of the Elastic Stack for further analysis.\n\nFor more information about Auditbeat, please visit\nhttps://www.elastic.co/products/beats/auditbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running Auditbeat on Docker](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [Auditbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/auditbeat)\n- [Auditbeat Documentation](https://www.elastic.co/guide/en/beats/auditbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","AGENTS.md":"## Repository Overview\n\nElastic Beats is a Go monorepo containing lightweight data shippers for the Elastic Stack. The module path is `github.com/elastic/beats/v7`. Go version: see `.go-version`.\n\n## Build System\n\nThe primary build tool is **Mage** (Go-based). Makefile wraps mage for some targets. Each beat has its own `magefile.go`; shared build logic lives in `dev-tools/mage/`.\n\n### Per-Beat Commands (run from the beat's directory, e.g. `cd filebeat`)\n\n```bash\nmage build              # Build the beat binary\nmage unitTest           # Run Go unit tests\nmage integTest          # Run integration tests (requires Docker)\nmage goIntegTest        # Go integration tests only\nmage pythonIntegTest    # Python integration tests only\nmage update             # Regenerate fields, configs, dashboards, includes\nmage fields             # Regenerate fields.yml and fields.go\nmage config             # Regenerate config files\nmage check              # Run checks (lint, headers, go mod)\nmage docker:composeUp   # Start integration test containers, wait until healthy\nmage docker:composeDown # Stop integration test containers\nmage crossBuild         # Cross-compile for all platforms\nSNAPSHOT=true DEV=true PLATFORMS=$GOOS/$GOARCH PACKAGES=tar.gz mage package  # Build and package the beat\n```\n\nFor `mage package`, set `PLATFORMS` to match the current OS/architecture. Check with `go env GOOS GOARCH` before running. Common values: `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`. `PACKAGES` sets the format: `tar.gz`, `zip`, `rpm`, `deb`, `docker` (comma-separated).\n\n### Running Tests\n\n**Do not run all unit or integration tests** (e.g. `mage unitTest` from root) unless explicitly requested. They take too long and require too many dependencies. Always run tests scoped to the package you're working on:\n\n```bash\n# Run a single test or package tests\ncd filebeat  # or any beat directory\ngo test -v -race -run TestName ./path/to/package/...\n\n# Stress test to find flaky tests (runs a test repeatedly with x/tools/cmd/stress)\n# It runs FOREVER (stress -timeout is per-run, not total); bound it with an outer `timeout`.\ntimeout 5m script/stresstest.sh [--tags integration] [--race] ./path/to/package ^TestName$ -p 32 [-failfast]\n```\n\n### Integration Tests\n\nIntegration tests may need external dependencies that can be started with mage\nor manually. The Go test binary is built automatically via `TestMain`.\n\n```bash\n# Run integration tests for a specific package\ngo test -v -race -run TestName -tags integration ./path/to/package/...\n```\n\n### Running a Beat\n\n```bash\nDEV=true mage build\n./filebeat -e --strict.perms=false -c filebeat.yml -path.home=<temp_dir>\n```\n\nAlways pass `--strict.perms=false` during development — it disables strict config\nfile permission checks. Set `-path.home` to a temporary directory to avoid\nwriting data/logs into the source tree.\n\n### Pre-Push Check\n\nBefore pushing, run `mage check` from the beat directory — it's a required CI check and catches lint, header, and module issues early.\n\n### Root-Level Commands\n\n```bash\nmage fmt                     # Format code + add license headers\nmake check                   # Full check suite (lint, headers, go mod, python)\n```\n\n### Linting\n\n```bash\n# Running golangci-lint for the whole codebase is slow, prefer running only on changed lines by default.\ngolangci-lint run --max-issues-per-linter 0 --max-same-issues 0 --new-from-merge-base upstream/main\n```\n\n## Architecture\n\n### Beats\n\n| Beat | Description |\n|------|-------------|\n| `filebeat` | Lightweight agent that ships log files and journals |\n| `metricbeat` | Collects metrics from systems and services |\n| `heartbeat` | Monitors availability of services and endpoints, detecting uptime/downtime |\n| `auditbeat` | Gathers audit data from systems to track security events, user activities, and compliance requirements |\n| `packetbeat` | Analyzes network traffic by capturing and inspecting packets for application and network visibility |\n| `winlogbeat` | Collects Windows Event logs for centralized monitoring and troubleshooting of Windows systems |\n| `x-pack/osquerybeat` | Manages and queries Osquery endpoints (Elastic license) |\n| `x-pack/dockerlogbeat` | Ships Docker container logs as a Docker log driver plugin (Elastic license) |\n| `x-pack/otel` | OTel Collector components that wrap beats as receivers, processors, and exporters for the Elastic Distribution of OpenTelemetry (Elastic license) |\n\nEach beat follows the pattern: `cmd/` (CLI entry), `beater/` (implements `beat.Beater` interface from `libbeat/beat/beat.go`), `module/` or `input/` (data collection).\n\n### libbeat (shared framework)\n\nAll beats build on `libbeat/`, which provides:\n- `beat/` — `Beater` interface (Run/Stop), `Beat` struct, `Pipeline`/`Client` for event publishing\n- `outputs/` — Output plugins (Elasticsearch, Logstash, Kafka, Redis, etc.)\n- `processors/` — Event processing pipeline\n- `publisher/` — Internal publishing pipeline\n- `cmd/` — Shared CLI infrastructure and beat instance bootstrapping\n- `autodiscover/` — Dynamic service discovery (Docker, Kubernetes)\n- `management/` — Elastic Agent management integration\n- `statestore/` — Persistent state\n\n### x-pack\n\n`x-pack/` contains Elastic-licensed extensions for each beat and x-pack-only beats. Each `x-pack/{beat}` extends the corresponding OSS beat with additional modules, inputs, or features.\n\n### Licensing Boundary\n\nOSS code (Apache 2.0) **cannot** import from `x-pack/` or `elastic-agent-client`. This is enforced by `depguard` in `.golangci.yml`. X-pack code can import OSS code freely.\n\n## Code Rules\n\n- Logging: accept `*logp.Logger` as a parameter. For tests prefer `logptest`\n- Use `github.com/stretchr/testify` in tests — always add a message explaining the failure. Use `assert` by default, `require` only when you actually need to interrupt the test\n- Use `github.com/gofrs/uuid/v5`\n- Write unit tests for new functionality. Use table-driven tests when appropriate\n- Document exported functions and types\n- Keep comments concise, focused on \"why\" not \"what\"\n- Update documentation when changing behavior\n\n## Documentation\n\nFor changes that affect published documentation or documentation generation, use the `docs-authoring` skill (`.agents/skills/docs-authoring/SKILL.md`).\n\n## Code References\n\nWhen referencing code, always use exact locations and names:\n- Format: `filepath:line_number` or `filepath:start-end`\n- Use specific element names (functions, methods, variables)\n- Quote exact text from code and logs — zero paraphrasing\n\n## Changelog\n\nIf the change is user-visible (not tests, CI, refactoring, or docs), add a changelog fragment: run `go run github.com/elastic/elastic-agent-changelog-tool@latest new` and edit the emitted fragment following the instructions in its comments. Otherwise, add the `skip-changelog` label to the PR.\n\n## Commits and PRs\n\nWhen writing commit messages, explain WHAT changed and WHY — the rationale and motivation, not just a description of the diff. The commit title is used as the squash-merge message. Add a trailer line `Assisted-By: <tool name>` for each AI tool used.\n\nWhen creating PRs, follow the template in `.github/PULL_REQUEST_TEMPLATE.md`\n","dev-tools/kubernetes/README.md":"# Readme\n\nThis folder contains some dev tools that make it easier to develop and deploy filebeat and metricbeat running inside a Kubernetes cluster. This is especially useful when developing the metricbeat module `kubernetes` since it requires metricbeat to run inside a Kubernetes cluster in order to interact with kube-state-metrics and the Kubernetes APIs.\n\nIn details, a combination of Dockerfiles, Kubernetes manifests and Tiltfile make it possible to have features like:\n- hot reloading of code running in Kubernetes, without re-applying the Kubernetes manifest\n- remote debugging (with breakpoints) both metricbeat/filebeat running as a pod in a Kind Kubernetes cluster\n\n[Tilt](https://tilt.dev/) is a dev toolkit for microservices.\n\n\n## Setup\nYou can install Tilt by using the command\n\n```shell\ncurl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash\n```\n\n\n## How to run\nThe Tiltfile that orchestrates everything is located at `dev-tools/kubernetes/Tiltfile`. All the following commands need to be run from `dev-tools/kubernetes`, in the same folder where the Tiltfile is located.\n\nHow to run Tilt\n\n```shell\ntilt up\n```\n\nThis will open a terminal and optionally a web UI where you can interact with Tilt, see container logs and restart resources.\n\nOnce you are done with Tilt, you can simply `CTRL+C` from the open Tilt terminal. The resources that you started in k8s will still be running though.\n\nFor more information on how to configure Tilt to run different scenarios look at the comments in the Tiltfile.\n\nIf you want to remove all the k8s resources that you started with Tilt, you can run\n\n```shell\ntilt down\n```\n\nIf you want to use a remote debugger with Visual Studio code, you need to provide a `.vscode/launch.json` similar to the following file. In order for this to work on your laptop, you need to replace `<absolute_path_to_beats_folder>` with the absolute path of the root folder in this project. This file is currently not under git because it depends on the user configuration, it is only useful for VisualStudio Code and in a folder usually ignored by git.\n\n```json\n{\n    \"version\": \"0.2.0\",\n    \"configurations\": [\n        {\n            \"name\": \"Connect to server\",\n            \"type\": \"go\",\n            \"request\": \"attach\",\n            \"mode\": \"remote\",\n            \"debugAdapter\": \"dlv-dap\",\n            \"port\": 56268,\n            \"host\": \"127.0.0.1\",\n            \"showLog\": true,\n            \"trace\": \"trace\",\n            \"cwd\": \"${workspaceFolder}\",\n            \"substitutePath\": [\n                {\n\t                \"from\": \"${workspaceFolder}\",\n                    \"to\": \"<absolute_path_to_beats_folder>\"\n                }\n            ]\n        }\n\n    ]\n}\n```\n\n\n## Run vs debug mode\nThe behavior of the Tiltfile can be changed by calling the function `beat()` with different parameters:\n- `beat`: `metricbeat` to test Metricbeat, `filebeat` to test Filebeat\n- `mode`: `debug` to start a remote debugger that you can connect to from your IDE with hot reloading enabled, `run` to just run Metricbeat without a debugger but still with hot reloading enabled\n- `arch`: `amd64` to build go binary for amd64 architecture, `arm64` to build go binary for arm64 (aka M1 Apple chip) architecture\n- `k8s_env`: `kind` to run against a Kind cluster with no docker registry, `gcp` to use a docker registry on GCP. More info on docker registry on GCP at https://cloud.google.com/container-registry/docs/advanced-authentication#gcloud-helper.\n- `k8s_cluster`: `single` to use a single node k8s cluster, `multi` to use a k8s with more than 1 node.\n      if running on a multi-node cluster we expect to have at least 2 workers and a control plane node.\n      A Beat in debugger mode will run on a node with a Tain `debugger=yes:NoSchedule`, while 1 Beat per node will run on all the other worker nodes.\n      More info on Taints and Tolerations at https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/.\n      You can add a taint with the following command:\n          `kubectl taint nodes <node_name> debugger=yes:NoSchedule`\n\nYou can modify the Tiltfile while `tilt up` is running in the background. Tilt will try its best to update everything in place but depending what changes you made, you might want to `tilt down` and `tilt up` again just to make sure that everything was updated correctly.\n","dev-tools/packaging/templates/ironbank/heartbeat/README.md":"# heartbeat\n\n**heartbeat** Lightweight shipper for uptime monitoring\n\nMonitor services for their availability with active probing. Given a list of URLs, Heartbeat asks the simple question: Are you alive? Heartbeat ships this information and response time to the rest of the Elastic Stack for further analysis.\n\nFor more information about heartbeat, please visit\nhttps://www.elastic.co/products/beats/heartbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running heartbeat on Docker](https://www.elastic.co/guide/en/beats/heartbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [heartbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/heartbeat)\n- [heartbeat Documentation](https://www.elastic.co/guide/en/beats/heartbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/metricbeat/README.md":"# metricbeat\n\n**metricbeat** Lightweight shipper for metrics\n\nCollect metrics from your systems and services. From CPU to memory, Redis to NGINX, and much more, Metricbeat is a lightweight way to send system and service statistics.\n\nFor more information about metricbeat, please visit\nhttps://www.elastic.co/products/beats/metricbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running metricbeat on Docker](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [metricbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/metricbeat)\n- [metricbeat Documentation](https://www.elastic.co/guide/en/beats/metricbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/packetbeat/README.md":"# packetbeat\n\n**packetbeat** Lightweight shipper for network data\n\nMonitoring your network traffic is critical to gaining observability over your environment — ensuring high levels of performance and security. Packetbeat is a lightweight network packet analyzer that sends data from your hosts and containers to Logstash or Elasticsearch.\n\nFor more information about packetbeat, please visit\nhttps://www.elastic.co/products/beats/packetbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running packetbeat on Docker](https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [packetbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/packetbeat)\n- [packetbeat Documentation](https://www.elastic.co/guide/en/beats/packetbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n"},"files":{".agents/skills/docs-authoring/SKILL.md":"---\nname: docs-authoring\ndescription: >\n  Write or edit user-facing documentation. Use when a change adds or edits a\n  published doc page, a snippet, navigation, or the source that generates a page.\n  Decides whether a change needs docs, where the content goes, what must be\n  verified against the product, and how to scope it with applies_to. Does not\n  cover changelog fragments or release-note entries.\nmetadata:\n  source: elastic-docs-authoring\n  source_version: \"1.0.0\"\n---\n\n# Documentation\n\nUse `docs/extend/contributing-docs.md` for the repository-specific publishing, placement, and generation instructions.\n\nA page is published as written. Write for the person doing the task, and write it as the final text they will read.\n\nAsk when the change does not tell you who it is for or what they can now do. Never invent a UI label, a default, a limit, a permission, or a behavior, and never generate a screenshot. Name the screenshot that is needed and where it goes.\n\n## Whether to write\n\n| The change | What to do |\n|---|---|\n| Nothing new for the reader to choose, configure, or do | No page change. Say so. |\n| A page already says this | Show where, and narrow or drop the edit |\n| A page states something that is now false | Fix that page |\n| A workflow gained a step or option a reader would otherwise miss | Add it |\n| A page is deliberately general and the request adds specifics | Usually not a gap. Say so |\n| Something the page documents was removed | Keep the content and scope it. Do not delete it |\n\n\"Remove X\" describes the product change, not the edit. The docs are cumulative, and readers on versions that still have the feature still need the page. For a GA or deprecated feature in a versioned product, keep the content and mark it `removed <version>` with `applies_to`. Deleting is reasonable only when the feature was only ever a preview or beta, or only ever existed in a product that has no versions. Say which reading you took.\n\nConcluding that nothing needs documenting is a valid result. Report it and stop.\n\n## Where it goes\n\nStart from the assumption that an existing page should absorb the change. Adding a page is the exception.\n\nSearch before you add. Search the published docs and the `docs/` tree of this repository, including snippets and pages that are not linked yet. A search that did not run is not evidence that nothing covers the topic, so do not report \"nothing covers this yet\" unless you looked.\n\nPropose the lightest change that closes the gap, in this order: a sentence in an existing section, a new section, a new page. Pause when you are about to add a page, or when the change touches several pages.\n\nPut each fact in one place. A caveat that belongs on every page belongs on the one page that owns the concept, with the others linking to it. A sentence, admonition, or requirement repeated at the top of every page in a section is that mistake. A shared snippet is not, when its only job is to say which of two similar systems the page documents: no `applies_to` value can say that, and the wording lives once. Check the nearest `_snippets/` directory before writing prose that more than one page needs.\n\n## Verify, then write\n\nList every concrete claim the page will make: each UI string, field name, setting, default, limit, permission, and behavior. Then verify each one against the product source as it is now, not against the issue or the pull request description. A diff shows one change. The current source shows what the reader will meet.\n\nAnything you cannot verify goes back to the author as a question. It does not go in the page.\n\nBecause the page covers every supported version, a statement that is true only in the latest code is wrong for most readers. Confirm each claim for the versions the page covers, or scope it.\n\nThe product's own lifecycle field outranks the request. A release-note label, a bare version number, and \"on by default\" all mean something shipped. None of them means generally available. A backport label is not a released version, and neither is a merged pull request. Use the minor version in an `applies_to` badge. When a critical difference really is patch-specific, explain the exact patch in prose.\n\n## Versioning\n\nOne page covers every version. Do not copy a page per release. Mark a difference with `applies_to` on the page or on the section that differs.\n\n```yaml\napplies_to:\n  stack: ga 9.1\n  serverless: ga\n```\n\nA feature that exists only in some versions gets `applies_to` on that section. When it is removed from a versioned product, keep the section and add the removal, for example `stack: removed 9.1`. When the page is generated, the repository contributing guide says where the version is set. Do not hand-edit `applies_to` in a generated page.\n\nIf `docs-applies-to-tagging` is installed, let it choose the values and the placement. Collect the version, lifecycle, and deployment answers and hand them over.\n\n## Write the page\n\nWrite what the reader can now do, see, configure, or avoid. The notes you were given describe an implementation. Nothing later will translate them for you, so do it as you draft. Cut anything that does not serve the task, including a detail that is there only because the issue mentioned it.\n\nOrder the page for the task: what it is, then how to do it, then the edge cases. Open a new option or mode on the outcome, not the control. For example, use **View documents as JSON**, then write the sentence that names the control. The labels and defaults you verified are a checklist the page must not contradict. They are not an outline.\n\n- Address the reader as you. Do not call them users or customers.\n- Present tense. Active voice. One idea per sentence.\n- Sentence case for headings. No trailing period on a heading.\n- Name the product, feature, page, or setting on first mention. No internal names: packages, functions, struct fields, ticket numbers, or team names.\n- Backticks for settings, field names, file names, CLI flags, and values the reader types.\n- Quote a UI label only when it would otherwise read as prose. Feature names are capitalized and not quoted.\n- US English.\n\nUse the substitutions the repository defines (`{{kib}}`, `{{es}}`, and the product's own) the way the surrounding page does. Do not spell out a name that page writes as a substitution, and do not introduce one it does not use.\n\n## Links and navigation\n\nA new page goes in the `toc.yml` for its section. Navigation is per docset, and some sections nest their toc, so copy the shape of the section you are adding to rather than inventing one.\n\nUse descriptive link text rather than a bare URL or generic call to action. A link to a page in another Elastic docset uses that docset's form (`docs-content://...`, `integration-docs://...`), not `https://www.elastic.co/docs/...`.\n\nA page you moved, renamed, or deleted needs an entry in `redirects.yml`. If `docs-redirects` is installed, hand it the old path and the new one.\n\nA link to a page being added in another repository cannot resolve until that change publishes. Leave the link, name the change it waits on, and do not point it at a placeholder. Every other unresolved link is a defect.\n\n## Generated pages\n\nIf a page says it is generated, edit the source it names and regenerate. An edit to the generated file is overwritten on the next run. The repository contributing guide names the source and the command.\n\n## Checks\n\nApply these rules while you write, not after. Run the repository's docs build and Vale checks. If the `elastic-docs-skills` plugin is installed, run the individual checks that apply for content type, `applies_to`, style, frontmatter, jargon, syntax, and redirects. `docs-draft-feature-docs` is an end-to-end drafting workflow, not a post-edit checker. Do not copy its companion skills into this repository.\n\nReference: [Elastic style guide](https://www.elastic.co/docs/contribute-docs/style-guide), [cumulative docs](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs), [`applies_to` reference](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs/reference), [content types](https://www.elastic.co/docs/contribute-docs/content-types).\n","dev-tools/README.md":"Available scripts\n-----------------\n\n\nThe following scripts are used by the unified release process:\n\n| File                 | Description |\n|----------------------|-------------|\n| get_version          | Returns the current version |\n| set_version          | Sets the current version in all places where change is required. Doesn't commit changes. |\n| deploy               | Builds all artifacts for the officially supported Beats |\n\n\n\nOther scripts:\n\n\n| File                 | Description |\n|----------------------|-------------|\n| aggregate_coverage.py | Used to create coverage reports that contain both unit and system tests data |\n| merge_pr | Used to make it easier to open a PR that merges one branch into another. |\n\n\nImport / export the dashboards of a single Beat:\n\n| File                  | Description |\n|-----------------------|-------------|\n| export_dashboards.py  | Python script to export the Beat dashboards from Elasticsearch to a local directory|\n\nRunning export_dashboards.py in environment\n----------------------------------------------\n\nIf you are running the python script for the first time, you need to create the\nenvironment by running the following commands in the `beats/dev-tools`\ndirectory:\n\n```\nvirtualenv env\n. env/bin/activate\npip install -r requirements.txt\n```\n\nThis creates the environment that contains all the python packages required to\nrun the `export_dashboards.py` script. Thus, for the next runs you just need\nto enable the environment:\n\n```\n. env/bin/activate\n```\n","dev-tools/packaging/templates/ironbank/filebeat/README.md":"# filebeat\n\n**filebeat** Lightweight shipper for logs\n\nForget using SSH when you have tens, hundreds, or even thousands of servers, virtual machines, and containers generating logs. Filebeat helps you keep the simple things simple by offering a lightweight way to forward and centralize logs and files.\n\nFor more information about filebeat, please visit\nhttps://www.elastic.co/products/beats/filebeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running filebeat on Docker](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [filebeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/filebeat)\n- [filebeat Documentation](https://www.elastic.co/guide/en/beats/filebeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/auditbeat/README.md":"# Auditbeat\n\n**Auditbeat** Lightweight shipper for audit data\n\nCollect your Linux audit framework data and monitor the integrity of your files.\nAuditbeat ships these events in real time to the rest of the Elastic Stack for further analysis.\n\nFor more information about Auditbeat, please visit\nhttps://www.elastic.co/products/beats/auditbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running Auditbeat on Docker](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [Auditbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/auditbeat)\n- [Auditbeat Documentation](https://www.elastic.co/guide/en/beats/auditbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","AGENTS.md":"## Repository Overview\n\nElastic Beats is a Go monorepo containing lightweight data shippers for the Elastic Stack. The module path is `github.com/elastic/beats/v7`. Go version: see `.go-version`.\n\n## Build System\n\nThe primary build tool is **Mage** (Go-based). Makefile wraps mage for some targets. Each beat has its own `magefile.go`; shared build logic lives in `dev-tools/mage/`.\n\n### Per-Beat Commands (run from the beat's directory, e.g. `cd filebeat`)\n\n```bash\nmage build              # Build the beat binary\nmage unitTest           # Run Go unit tests\nmage integTest          # Run integration tests (requires Docker)\nmage goIntegTest        # Go integration tests only\nmage pythonIntegTest    # Python integration tests only\nmage update             # Regenerate fields, configs, dashboards, includes\nmage fields             # Regenerate fields.yml and fields.go\nmage config             # Regenerate config files\nmage check              # Run checks (lint, headers, go mod)\nmage docker:composeUp   # Start integration test containers, wait until healthy\nmage docker:composeDown # Stop integration test containers\nmage crossBuild         # Cross-compile for all platforms\nSNAPSHOT=true DEV=true PLATFORMS=$GOOS/$GOARCH PACKAGES=tar.gz mage package  # Build and package the beat\n```\n\nFor `mage package`, set `PLATFORMS` to match the current OS/architecture. Check with `go env GOOS GOARCH` before running. Common values: `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`. `PACKAGES` sets the format: `tar.gz`, `zip`, `rpm`, `deb`, `docker` (comma-separated).\n\n### Running Tests\n\n**Do not run all unit or integration tests** (e.g. `mage unitTest` from root) unless explicitly requested. They take too long and require too many dependencies. Always run tests scoped to the package you're working on:\n\n```bash\n# Run a single test or package tests\ncd filebeat  # or any beat directory\ngo test -v -race -run TestName ./path/to/package/...\n\n# Stress test to find flaky tests (runs a test repeatedly with x/tools/cmd/stress)\n# It runs FOREVER (stress -timeout is per-run, not total); bound it with an outer `timeout`.\ntimeout 5m script/stresstest.sh [--tags integration] [--race] ./path/to/package ^TestName$ -p 32 [-failfast]\n```\n\n### Integration Tests\n\nIntegration tests may need external dependencies that can be started with mage\nor manually. The Go test binary is built automatically via `TestMain`.\n\n```bash\n# Run integration tests for a specific package\ngo test -v -race -run TestName -tags integration ./path/to/package/...\n```\n\n### Running a Beat\n\n```bash\nDEV=true mage build\n./filebeat -e --strict.perms=false -c filebeat.yml -path.home=<temp_dir>\n```\n\nAlways pass `--strict.perms=false` during development — it disables strict config\nfile permission checks. Set `-path.home` to a temporary directory to avoid\nwriting data/logs into the source tree.\n\n### Pre-Push Check\n\nBefore pushing, run `mage check` from the beat directory — it's a required CI check and catches lint, header, and module issues early.\n\n### Root-Level Commands\n\n```bash\nmage fmt                     # Format code + add license headers\nmake check                   # Full check suite (lint, headers, go mod, python)\n```\n\n### Linting\n\n```bash\n# Running golangci-lint for the whole codebase is slow, prefer running only on changed lines by default.\ngolangci-lint run --max-issues-per-linter 0 --max-same-issues 0 --new-from-merge-base upstream/main\n```\n\n## Architecture\n\n### Beats\n\n| Beat | Description |\n|------|-------------|\n| `filebeat` | Lightweight agent that ships log files and journals |\n| `metricbeat` | Collects metrics from systems and services |\n| `heartbeat` | Monitors availability of services and endpoints, detecting uptime/downtime |\n| `auditbeat` | Gathers audit data from systems to track security events, user activities, and compliance requirements |\n| `packetbeat` | Analyzes network traffic by capturing and inspecting packets for application and network visibility |\n| `winlogbeat` | Collects Windows Event logs for centralized monitoring and troubleshooting of Windows systems |\n| `x-pack/osquerybeat` | Manages and queries Osquery endpoints (Elastic license) |\n| `x-pack/dockerlogbeat` | Ships Docker container logs as a Docker log driver plugin (Elastic license) |\n| `x-pack/otel` | OTel Collector components that wrap beats as receivers, processors, and exporters for the Elastic Distribution of OpenTelemetry (Elastic license) |\n\nEach beat follows the pattern: `cmd/` (CLI entry), `beater/` (implements `beat.Beater` interface from `libbeat/beat/beat.go`), `module/` or `input/` (data collection).\n\n### libbeat (shared framework)\n\nAll beats build on `libbeat/`, which provides:\n- `beat/` — `Beater` interface (Run/Stop), `Beat` struct, `Pipeline`/`Client` for event publishing\n- `outputs/` — Output plugins (Elasticsearch, Logstash, Kafka, Redis, etc.)\n- `processors/` — Event processing pipeline\n- `publisher/` — Internal publishing pipeline\n- `cmd/` — Shared CLI infrastructure and beat instance bootstrapping\n- `autodiscover/` — Dynamic service discovery (Docker, Kubernetes)\n- `management/` — Elastic Agent management integration\n- `statestore/` — Persistent state\n\n### x-pack\n\n`x-pack/` contains Elastic-licensed extensions for each beat and x-pack-only beats. Each `x-pack/{beat}` extends the corresponding OSS beat with additional modules, inputs, or features.\n\n### Licensing Boundary\n\nOSS code (Apache 2.0) **cannot** import from `x-pack/` or `elastic-agent-client`. This is enforced by `depguard` in `.golangci.yml`. X-pack code can import OSS code freely.\n\n## Code Rules\n\n- Logging: accept `*logp.Logger` as a parameter. For tests prefer `logptest`\n- Use `github.com/stretchr/testify` in tests — always add a message explaining the failure. Use `assert` by default, `require` only when you actually need to interrupt the test\n- Use `github.com/gofrs/uuid/v5`\n- Write unit tests for new functionality. Use table-driven tests when appropriate\n- Document exported functions and types\n- Keep comments concise, focused on \"why\" not \"what\"\n- Update documentation when changing behavior\n\n## Documentation\n\nFor changes that affect published documentation or documentation generation, use the `docs-authoring` skill (`.agents/skills/docs-authoring/SKILL.md`).\n\n## Code References\n\nWhen referencing code, always use exact locations and names:\n- Format: `filepath:line_number` or `filepath:start-end`\n- Use specific element names (functions, methods, variables)\n- Quote exact text from code and logs — zero paraphrasing\n\n## Changelog\n\nIf the change is user-visible (not tests, CI, refactoring, or docs), add a changelog fragment: run `go run github.com/elastic/elastic-agent-changelog-tool@latest new` and edit the emitted fragment following the instructions in its comments. Otherwise, add the `skip-changelog` label to the PR.\n\n## Commits and PRs\n\nWhen writing commit messages, explain WHAT changed and WHY — the rationale and motivation, not just a description of the diff. The commit title is used as the squash-merge message. Add a trailer line `Assisted-By: <tool name>` for each AI tool used.\n\nWhen creating PRs, follow the template in `.github/PULL_REQUEST_TEMPLATE.md`\n","dev-tools/kubernetes/README.md":"# Readme\n\nThis folder contains some dev tools that make it easier to develop and deploy filebeat and metricbeat running inside a Kubernetes cluster. This is especially useful when developing the metricbeat module `kubernetes` since it requires metricbeat to run inside a Kubernetes cluster in order to interact with kube-state-metrics and the Kubernetes APIs.\n\nIn details, a combination of Dockerfiles, Kubernetes manifests and Tiltfile make it possible to have features like:\n- hot reloading of code running in Kubernetes, without re-applying the Kubernetes manifest\n- remote debugging (with breakpoints) both metricbeat/filebeat running as a pod in a Kind Kubernetes cluster\n\n[Tilt](https://tilt.dev/) is a dev toolkit for microservices.\n\n\n## Setup\nYou can install Tilt by using the command\n\n```shell\ncurl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash\n```\n\n\n## How to run\nThe Tiltfile that orchestrates everything is located at `dev-tools/kubernetes/Tiltfile`. All the following commands need to be run from `dev-tools/kubernetes`, in the same folder where the Tiltfile is located.\n\nHow to run Tilt\n\n```shell\ntilt up\n```\n\nThis will open a terminal and optionally a web UI where you can interact with Tilt, see container logs and restart resources.\n\nOnce you are done with Tilt, you can simply `CTRL+C` from the open Tilt terminal. The resources that you started in k8s will still be running though.\n\nFor more information on how to configure Tilt to run different scenarios look at the comments in the Tiltfile.\n\nIf you want to remove all the k8s resources that you started with Tilt, you can run\n\n```shell\ntilt down\n```\n\nIf you want to use a remote debugger with Visual Studio code, you need to provide a `.vscode/launch.json` similar to the following file. In order for this to work on your laptop, you need to replace `<absolute_path_to_beats_folder>` with the absolute path of the root folder in this project. This file is currently not under git because it depends on the user configuration, it is only useful for VisualStudio Code and in a folder usually ignored by git.\n\n```json\n{\n    \"version\": \"0.2.0\",\n    \"configurations\": [\n        {\n            \"name\": \"Connect to server\",\n            \"type\": \"go\",\n            \"request\": \"attach\",\n            \"mode\": \"remote\",\n            \"debugAdapter\": \"dlv-dap\",\n            \"port\": 56268,\n            \"host\": \"127.0.0.1\",\n            \"showLog\": true,\n            \"trace\": \"trace\",\n            \"cwd\": \"${workspaceFolder}\",\n            \"substitutePath\": [\n                {\n\t                \"from\": \"${workspaceFolder}\",\n                    \"to\": \"<absolute_path_to_beats_folder>\"\n                }\n            ]\n        }\n\n    ]\n}\n```\n\n\n## Run vs debug mode\nThe behavior of the Tiltfile can be changed by calling the function `beat()` with different parameters:\n- `beat`: `metricbeat` to test Metricbeat, `filebeat` to test Filebeat\n- `mode`: `debug` to start a remote debugger that you can connect to from your IDE with hot reloading enabled, `run` to just run Metricbeat without a debugger but still with hot reloading enabled\n- `arch`: `amd64` to build go binary for amd64 architecture, `arm64` to build go binary for arm64 (aka M1 Apple chip) architecture\n- `k8s_env`: `kind` to run against a Kind cluster with no docker registry, `gcp` to use a docker registry on GCP. More info on docker registry on GCP at https://cloud.google.com/container-registry/docs/advanced-authentication#gcloud-helper.\n- `k8s_cluster`: `single` to use a single node k8s cluster, `multi` to use a k8s with more than 1 node.\n      if running on a multi-node cluster we expect to have at least 2 workers and a control plane node.\n      A Beat in debugger mode will run on a node with a Tain `debugger=yes:NoSchedule`, while 1 Beat per node will run on all the other worker nodes.\n      More info on Taints and Tolerations at https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/.\n      You can add a taint with the following command:\n          `kubectl taint nodes <node_name> debugger=yes:NoSchedule`\n\nYou can modify the Tiltfile while `tilt up` is running in the background. Tilt will try its best to update everything in place but depending what changes you made, you might want to `tilt down` and `tilt up` again just to make sure that everything was updated correctly.\n","dev-tools/packaging/templates/ironbank/heartbeat/README.md":"# heartbeat\n\n**heartbeat** Lightweight shipper for uptime monitoring\n\nMonitor services for their availability with active probing. Given a list of URLs, Heartbeat asks the simple question: Are you alive? Heartbeat ships this information and response time to the rest of the Elastic Stack for further analysis.\n\nFor more information about heartbeat, please visit\nhttps://www.elastic.co/products/beats/heartbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running heartbeat on Docker](https://www.elastic.co/guide/en/beats/heartbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [heartbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/heartbeat)\n- [heartbeat Documentation](https://www.elastic.co/guide/en/beats/heartbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/metricbeat/README.md":"# metricbeat\n\n**metricbeat** Lightweight shipper for metrics\n\nCollect metrics from your systems and services. From CPU to memory, Redis to NGINX, and much more, Metricbeat is a lightweight way to send system and service statistics.\n\nFor more information about metricbeat, please visit\nhttps://www.elastic.co/products/beats/metricbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running metricbeat on Docker](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [metricbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/metricbeat)\n- [metricbeat Documentation](https://www.elastic.co/guide/en/beats/metricbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","dev-tools/packaging/templates/ironbank/packetbeat/README.md":"# packetbeat\n\n**packetbeat** Lightweight shipper for network data\n\nMonitoring your network traffic is critical to gaining observability over your environment — ensuring high levels of performance and security. Packetbeat is a lightweight network packet analyzer that sends data from your hosts and containers to Logstash or Elasticsearch.\n\nFor more information about packetbeat, please visit\nhttps://www.elastic.co/products/beats/packetbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running packetbeat on Docker](https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [packetbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/packetbeat)\n- [packetbeat Documentation](https://www.elastic.co/guide/en/beats/packetbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## Repository Overview\n\nElastic Beats is a Go monorepo containing lightweight data shippers for the Elastic Stack. The module path is `github.com/elastic/beats/v7`. Go version: see `.go-version`.\n\n## Build System\n\nThe primary build tool is **Mage** (Go-based). Makefile wraps mage for some targets. Each beat has its own `magefile.go`; shared build logic lives in `dev-tools/mage/`.\n\n### Per-Beat Commands (run from the beat's directory, e.g. `cd filebeat`)\n\n```bash\nmage build              # Build the beat binary\nmage unitTest           # Run Go unit tests\nmage integTest          # Run integration tests (requires Docker)\nmage goIntegTest        # Go integration tests only\nmage pythonIntegTest    # Python integration tests only\nmage update             # Regenerate fields, configs, dashboards, includes\nmage fields             # Regenerate fields.yml and fields.go\nmage config             # Regenerate config files\nmage check              # Run checks (lint, headers, go mod)\nmage docker:composeUp   # Start integration test containers, wait until healthy\nmage docker:composeDown # Stop integration test containers\nmage crossBuild         # Cross-compile for all platforms\nSNAPSHOT=true DEV=true PLATFORMS=$GOOS/$GOARCH PACKAGES=tar.gz mage package  # Build and package the beat\n```\n\nFor `mage package`, set `PLATFORMS` to match the current OS/architecture. Check with `go env GOOS GOARCH` before running. Common values: `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`. `PACKAGES` sets the format: `tar.gz`, `zip`, `rpm`, `deb`, `docker` (comma-separated).\n\n### Running Tests\n\n**Do not run all unit or integration tests** (e.g. `mage unitTest` from root) unless explicitly requested. They take too long and require too many dependencies. Always run tests scoped to the package you're working on:\n\n```bash\n# Run a single test or package tests\ncd filebeat  # or any beat directory\ngo test -v -race -run TestName ./path/to/package/...\n\n# Stress test to find flaky tests (runs a test repeatedly with x/tools/cmd/stress)\n# It runs FOREVER (stress -timeout is per-run, not total); bound it with an outer `timeout`.\ntimeout 5m script/stresstest.sh [--tags integration] [--race] ./path/to/package ^TestName$ -p 32 [-failfast]\n```\n\n### Integration Tests\n\nIntegration tests may need external dependencies that can be started with mage\nor manually. The Go test binary is built automatically via `TestMain`.\n\n```bash\n# Run integration tests for a specific package\ngo test -v -race -run TestName -tags integration ./path/to/package/...\n```\n\n### Running a Beat\n\n```bash\nDEV=true mage build\n./filebeat -e --strict.perms=false -c filebeat.yml -path.home=<temp_dir>\n```\n\nAlways pass `--strict.perms=false` during development — it disables strict config\nfile permission checks. Set `-path.home` to a temporary directory to avoid\nwriting data/logs into the source tree.\n\n### Pre-Push Check\n\nBefore pushing, run `mage check` from the beat directory — it's a required CI check and catches lint, header, and module issues early.\n\n### Root-Level Commands\n\n```bash\nmage fmt                     # Format code + add license headers\nmake check                   # Full check suite (lint, headers, go mod, python)\n```\n\n### Linting\n\n```bash\n# Running golangci-lint for the whole codebase is slow, prefer running only on changed lines by default.\ngolangci-lint run --max-issues-per-linter 0 --max-same-issues 0 --new-from-merge-base upstream/main\n```\n\n## Architecture\n\n### Beats\n\n| Beat | Description |\n|------|-------------|\n| `filebeat` | Lightweight agent that ships log files and journals |\n| `metricbeat` | Collects metrics from systems and services |\n| `heartbeat` | Monitors availability of services and endpoints, detecting uptime/downtime |\n| `auditbeat` | Gathers audit data from systems to track security events, user activities, and compliance requirements |\n| `packetbeat` | Analyzes network traffic by capturing and inspecting packets for application and network visibility |\n| `winlogbeat` | Collects Windows Event logs for centralized monitoring and troubleshooting of Windows systems |\n| `x-pack/osquerybeat` | Manages and queries Osquery endpoints (Elastic license) |\n| `x-pack/dockerlogbeat` | Ships Docker container logs as a Docker log driver plugin (Elastic license) |\n| `x-pack/otel` | OTel Collector components that wrap beats as receivers, processors, and exporters for the Elastic Distribution of OpenTelemetry (Elastic license) |\n\nEach beat follows the pattern: `cmd/` (CLI entry), `beater/` (implements `beat.Beater` interface from `libbeat/beat/beat.go`), `module/` or `input/` (data collection).\n\n### libbeat (shared framework)\n\nAll beats build on `libbeat/`, which provides:\n- `beat/` — `Beater` interface (Run/Stop), `Beat` struct, `Pipeline`/`Client` for event publishing\n- `outputs/` — Output plugins (Elasticsearch, Logstash, Kafka, Redis, etc.)\n- `processors/` — Event processing pipeline\n- `publisher/` — Internal publishing pipeline\n- `cmd/` — Shared CLI infrastructure and beat instance bootstrapping\n- `autodiscover/` — Dynamic service discovery (Docker, Kubernetes)\n- `management/` — Elastic Agent management integration\n- `statestore/` — Persistent state\n\n### x-pack\n\n`x-pack/` contains Elastic-licensed extensions for each beat and x-pack-only beats. Each `x-pack/{beat}` extends the corresponding OSS beat with additional modules, inputs, or features.\n\n### Licensing Boundary\n\nOSS code (Apache 2.0) **cannot** import from `x-pack/` or `elastic-agent-client`. This is enforced by `depguard` in `.golangci.yml`. X-pack code can import OSS code freely.\n\n## Code Rules\n\n- Logging: accept `*logp.Logger` as a parameter. For tests prefer `logptest`\n- Use `github.com/stretchr/testify` in tests — always add a message explaining the failure. Use `assert` by default, `require` only when you actually need to interrupt the test\n- Use `github.com/gofrs/uuid/v5`\n- Write unit tests for new functionality. Use table-driven tests when appropriate\n- Document exported functions and types\n- Keep comments concise, focused on \"why\" not \"what\"\n- Update documentation when changing behavior\n\n## Documentation\n\nFor changes that affect published documentation or documentation generation, use the `docs-authoring` skill (`.agents/skills/docs-authoring/SKILL.md`).\n\n## Code References\n\nWhen referencing code, always use exact locations and names:\n- Format: `filepath:line_number` or `filepath:start-end`\n- Use specific element names (functions, methods, variables)\n- Quote exact text from code and logs — zero paraphrasing\n\n## Changelog\n\nIf the change is user-visible (not tests, CI, refactoring, or docs), add a changelog fragment: run `go run github.com/elastic/elastic-agent-changelog-tool@latest new` and edit the emitted fragment following the instructions in its comments. Otherwise, add the `skip-changelog` label to the PR.\n\n## Commits and PRs\n\nWhen writing commit messages, explain WHAT changed and WHY — the rationale and motivation, not just a description of the diff. The commit title is used as the squash-merge message. Add a trailer line `Assisted-By: <tool name>` for each AI tool used.\n\nWhen creating PRs, follow the template in `.github/PULL_REQUEST_TEMPLATE.md`\n","isInternal":false,"tokens":1700,"sizeBytes":7219},{"name":"SKILL.md","path":".agents/skills/docs-authoring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/.agents/skills/docs-authoring/SKILL.md","title":"docs-authoring","category":"anthropic-skill","format":"markdown","content":"---\nname: docs-authoring\ndescription: >\n  Write or edit user-facing documentation. Use when a change adds or edits a\n  published doc page, a snippet, navigation, or the source that generates a page.\n  Decides whether a change needs docs, where the content goes, what must be\n  verified against the product, and how to scope it with applies_to. Does not\n  cover changelog fragments or release-note entries.\nmetadata:\n  source: elastic-docs-authoring\n  source_version: \"1.0.0\"\n---\n\n# Documentation\n\nUse `docs/extend/contributing-docs.md` for the repository-specific publishing, placement, and generation instructions.\n\nA page is published as written. Write for the person doing the task, and write it as the final text they will read.\n\nAsk when the change does not tell you who it is for or what they can now do. Never invent a UI label, a default, a limit, a permission, or a behavior, and never generate a screenshot. Name the screenshot that is needed and where it goes.\n\n## Whether to write\n\n| The change | What to do |\n|---|---|\n| Nothing new for the reader to choose, configure, or do | No page change. Say so. |\n| A page already says this | Show where, and narrow or drop the edit |\n| A page states something that is now false | Fix that page |\n| A workflow gained a step or option a reader would otherwise miss | Add it |\n| A page is deliberately general and the request adds specifics | Usually not a gap. Say so |\n| Something the page documents was removed | Keep the content and scope it. Do not delete it |\n\n\"Remove X\" describes the product change, not the edit. The docs are cumulative, and readers on versions that still have the feature still need the page. For a GA or deprecated feature in a versioned product, keep the content and mark it `removed <version>` with `applies_to`. Deleting is reasonable only when the feature was only ever a preview or beta, or only ever existed in a product that has no versions. Say which reading you took.\n\nConcluding that nothing needs documenting is a valid result. Report it and stop.\n\n## Where it goes\n\nStart from the assumption that an existing page should absorb the change. Adding a page is the exception.\n\nSearch before you add. Search the published docs and the `docs/` tree of this repository, including snippets and pages that are not linked yet. A search that did not run is not evidence that nothing covers the topic, so do not report \"nothing covers this yet\" unless you looked.\n\nPropose the lightest change that closes the gap, in this order: a sentence in an existing section, a new section, a new page. Pause when you are about to add a page, or when the change touches several pages.\n\nPut each fact in one place. A caveat that belongs on every page belongs on the one page that owns the concept, with the others linking to it. A sentence, admonition, or requirement repeated at the top of every page in a section is that mistake. A shared snippet is not, when its only job is to say which of two similar systems the page documents: no `applies_to` value can say that, and the wording lives once. Check the nearest `_snippets/` directory before writing prose that more than one page needs.\n\n## Verify, then write\n\nList every concrete claim the page will make: each UI string, field name, setting, default, limit, permission, and behavior. Then verify each one against the product source as it is now, not against the issue or the pull request description. A diff shows one change. The current source shows what the reader will meet.\n\nAnything you cannot verify goes back to the author as a question. It does not go in the page.\n\nBecause the page covers every supported version, a statement that is true only in the latest code is wrong for most readers. Confirm each claim for the versions the page covers, or scope it.\n\nThe product's own lifecycle field outranks the request. A release-note label, a bare version number, and \"on by default\" all mean something shipped. None of them means generally available. A backport label is not a released version, and neither is a merged pull request. Use the minor version in an `applies_to` badge. When a critical difference really is patch-specific, explain the exact patch in prose.\n\n## Versioning\n\nOne page covers every version. Do not copy a page per release. Mark a difference with `applies_to` on the page or on the section that differs.\n\n```yaml\napplies_to:\n  stack: ga 9.1\n  serverless: ga\n```\n\nA feature that exists only in some versions gets `applies_to` on that section. When it is removed from a versioned product, keep the section and add the removal, for example `stack: removed 9.1`. When the page is generated, the repository contributing guide says where the version is set. Do not hand-edit `applies_to` in a generated page.\n\nIf `docs-applies-to-tagging` is installed, let it choose the values and the placement. Collect the version, lifecycle, and deployment answers and hand them over.\n\n## Write the page\n\nWrite what the reader can now do, see, configure, or avoid. The notes you were given describe an implementation. Nothing later will translate them for you, so do it as you draft. Cut anything that does not serve the task, including a detail that is there only because the issue mentioned it.\n\nOrder the page for the task: what it is, then how to do it, then the edge cases. Open a new option or mode on the outcome, not the control. For example, use **View documents as JSON**, then write the sentence that names the control. The labels and defaults you verified are a checklist the page must not contradict. They are not an outline.\n\n- Address the reader as you. Do not call them users or customers.\n- Present tense. Active voice. One idea per sentence.\n- Sentence case for headings. No trailing period on a heading.\n- Name the product, feature, page, or setting on first mention. No internal names: packages, functions, struct fields, ticket numbers, or team names.\n- Backticks for settings, field names, file names, CLI flags, and values the reader types.\n- Quote a UI label only when it would otherwise read as prose. Feature names are capitalized and not quoted.\n- US English.\n\nUse the substitutions the repository defines (`{{kib}}`, `{{es}}`, and the product's own) the way the surrounding page does. Do not spell out a name that page writes as a substitution, and do not introduce one it does not use.\n\n## Links and navigation\n\nA new page goes in the `toc.yml` for its section. Navigation is per docset, and some sections nest their toc, so copy the shape of the section you are adding to rather than inventing one.\n\nUse descriptive link text rather than a bare URL or generic call to action. A link to a page in another Elastic docset uses that docset's form (`docs-content://...`, `integration-docs://...`), not `https://www.elastic.co/docs/...`.\n\nA page you moved, renamed, or deleted needs an entry in `redirects.yml`. If `docs-redirects` is installed, hand it the old path and the new one.\n\nA link to a page being added in another repository cannot resolve until that change publishes. Leave the link, name the change it waits on, and do not point it at a placeholder. Every other unresolved link is a defect.\n\n## Generated pages\n\nIf a page says it is generated, edit the source it names and regenerate. An edit to the generated file is overwritten on the next run. The repository contributing guide names the source and the command.\n\n## Checks\n\nApply these rules while you write, not after. Run the repository's docs build and Vale checks. If the `elastic-docs-skills` plugin is installed, run the individual checks that apply for content type, `applies_to`, style, frontmatter, jargon, syntax, and redirects. `docs-draft-feature-docs` is an end-to-end drafting workflow, not a post-edit checker. Do not copy its companion skills into this repository.\n\nReference: [Elastic style guide](https://www.elastic.co/docs/contribute-docs/style-guide), [cumulative docs](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs), [`applies_to` reference](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs/reference), [content types](https://www.elastic.co/docs/contribute-docs/content-types).\n","frontmatter":{"name":"docs-authoring","description":"Write or edit user-facing documentation. Use when a change adds or edits a published doc page, a snippet, navigation, or the source that generates a page. Decides whether a change needs docs, where the content goes, what must be verified against the product, and how to scope it with applies_to. Does not cover changelog fragments or release-note entries.\n","metadata":{"source":"elastic-docs-authoring","source_version":"1.0.0"}},"isInternal":false,"tokens":1829,"sizeBytes":8160},{"name":"README.md","path":"dev-tools/kubernetes/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/kubernetes/README.md","title":"kubernetes Documentation","category":"plugin-manifest","format":"markdown","content":"# Readme\n\nThis folder contains some dev tools that make it easier to develop and deploy filebeat and metricbeat running inside a Kubernetes cluster. This is especially useful when developing the metricbeat module `kubernetes` since it requires metricbeat to run inside a Kubernetes cluster in order to interact with kube-state-metrics and the Kubernetes APIs.\n\nIn details, a combination of Dockerfiles, Kubernetes manifests and Tiltfile make it possible to have features like:\n- hot reloading of code running in Kubernetes, without re-applying the Kubernetes manifest\n- remote debugging (with breakpoints) both metricbeat/filebeat running as a pod in a Kind Kubernetes cluster\n\n[Tilt](https://tilt.dev/) is a dev toolkit for microservices.\n\n\n## Setup\nYou can install Tilt by using the command\n\n```shell\ncurl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash\n```\n\n\n## How to run\nThe Tiltfile that orchestrates everything is located at `dev-tools/kubernetes/Tiltfile`. All the following commands need to be run from `dev-tools/kubernetes`, in the same folder where the Tiltfile is located.\n\nHow to run Tilt\n\n```shell\ntilt up\n```\n\nThis will open a terminal and optionally a web UI where you can interact with Tilt, see container logs and restart resources.\n\nOnce you are done with Tilt, you can simply `CTRL+C` from the open Tilt terminal. The resources that you started in k8s will still be running though.\n\nFor more information on how to configure Tilt to run different scenarios look at the comments in the Tiltfile.\n\nIf you want to remove all the k8s resources that you started with Tilt, you can run\n\n```shell\ntilt down\n```\n\nIf you want to use a remote debugger with Visual Studio code, you need to provide a `.vscode/launch.json` similar to the following file. In order for this to work on your laptop, you need to replace `<absolute_path_to_beats_folder>` with the absolute path of the root folder in this project. This file is currently not under git because it depends on the user configuration, it is only useful for VisualStudio Code and in a folder usually ignored by git.\n\n```json\n{\n    \"version\": \"0.2.0\",\n    \"configurations\": [\n        {\n            \"name\": \"Connect to server\",\n            \"type\": \"go\",\n            \"request\": \"attach\",\n            \"mode\": \"remote\",\n            \"debugAdapter\": \"dlv-dap\",\n            \"port\": 56268,\n            \"host\": \"127.0.0.1\",\n            \"showLog\": true,\n            \"trace\": \"trace\",\n            \"cwd\": \"${workspaceFolder}\",\n            \"substitutePath\": [\n                {\n\t                \"from\": \"${workspaceFolder}\",\n                    \"to\": \"<absolute_path_to_beats_folder>\"\n                }\n            ]\n        }\n\n    ]\n}\n```\n\n\n## Run vs debug mode\nThe behavior of the Tiltfile can be changed by calling the function `beat()` with different parameters:\n- `beat`: `metricbeat` to test Metricbeat, `filebeat` to test Filebeat\n- `mode`: `debug` to start a remote debugger that you can connect to from your IDE with hot reloading enabled, `run` to just run Metricbeat without a debugger but still with hot reloading enabled\n- `arch`: `amd64` to build go binary for amd64 architecture, `arm64` to build go binary for arm64 (aka M1 Apple chip) architecture\n- `k8s_env`: `kind` to run against a Kind cluster with no docker registry, `gcp` to use a docker registry on GCP. More info on docker registry on GCP at https://cloud.google.com/container-registry/docs/advanced-authentication#gcloud-helper.\n- `k8s_cluster`: `single` to use a single node k8s cluster, `multi` to use a k8s with more than 1 node.\n      if running on a multi-node cluster we expect to have at least 2 workers and a control plane node.\n      A Beat in debugger mode will run on a node with a Tain `debugger=yes:NoSchedule`, while 1 Beat per node will run on all the other worker nodes.\n      More info on Taints and Tolerations at https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/.\n      You can add a taint with the following command:\n          `kubectl taint nodes <node_name> debugger=yes:NoSchedule`\n\nYou can modify the Tiltfile while `tilt up` is running in the background. Tilt will try its best to update everything in place but depending what changes you made, you might want to `tilt down` and `tilt up` again just to make sure that everything was updated correctly.\n","isInternal":false,"tokens":1021,"sizeBytes":4371},{"name":"README.md","path":"dev-tools/packaging/templates/ironbank/auditbeat/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/packaging/templates/ironbank/auditbeat/README.md","title":"auditbeat Documentation","category":"plugin-manifest","format":"markdown","content":"# Auditbeat\n\n**Auditbeat** Lightweight shipper for audit data\n\nCollect your Linux audit framework data and monitor the integrity of your files.\nAuditbeat ships these events in real time to the rest of the Elastic Stack for further analysis.\n\nFor more information about Auditbeat, please visit\nhttps://www.elastic.co/products/beats/auditbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running Auditbeat on Docker](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [Auditbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/auditbeat)\n- [Auditbeat Documentation](https://www.elastic.co/guide/en/beats/auditbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","isInternal":false,"tokens":335,"sizeBytes":1426},{"name":"README.md","path":"dev-tools/packaging/templates/ironbank/filebeat/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/packaging/templates/ironbank/filebeat/README.md","title":"filebeat Documentation","category":"plugin-manifest","format":"markdown","content":"# filebeat\n\n**filebeat** Lightweight shipper for logs\n\nForget using SSH when you have tens, hundreds, or even thousands of servers, virtual machines, and containers generating logs. Filebeat helps you keep the simple things simple by offering a lightweight way to forward and centralize logs and files.\n\nFor more information about filebeat, please visit\nhttps://www.elastic.co/products/beats/filebeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running filebeat on Docker](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [filebeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/filebeat)\n- [filebeat Documentation](https://www.elastic.co/guide/en/beats/filebeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","isInternal":false,"tokens":344,"sizeBytes":1480},{"name":"README.md","path":"dev-tools/packaging/templates/ironbank/heartbeat/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/packaging/templates/ironbank/heartbeat/README.md","title":"heartbeat Documentation","category":"plugin-manifest","format":"markdown","content":"# heartbeat\n\n**heartbeat** Lightweight shipper for uptime monitoring\n\nMonitor services for their availability with active probing. Given a list of URLs, Heartbeat asks the simple question: Are you alive? Heartbeat ships this information and response time to the rest of the Elastic Stack for further analysis.\n\nFor more information about heartbeat, please visit\nhttps://www.elastic.co/products/beats/heartbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running heartbeat on Docker](https://www.elastic.co/guide/en/beats/heartbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [heartbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/heartbeat)\n- [heartbeat Documentation](https://www.elastic.co/guide/en/beats/heartbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","isInternal":false,"tokens":337,"sizeBytes":1495},{"name":"README.md","path":"dev-tools/packaging/templates/ironbank/metricbeat/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/packaging/templates/ironbank/metricbeat/README.md","title":"metricbeat Documentation","category":"plugin-manifest","format":"markdown","content":"# metricbeat\n\n**metricbeat** Lightweight shipper for metrics\n\nCollect metrics from your systems and services. From CPU to memory, Redis to NGINX, and much more, Metricbeat is a lightweight way to send system and service statistics.\n\nFor more information about metricbeat, please visit\nhttps://www.elastic.co/products/beats/metricbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running metricbeat on Docker](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [metricbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/metricbeat)\n- [metricbeat Documentation](https://www.elastic.co/guide/en/beats/metricbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","isInternal":false,"tokens":337,"sizeBytes":1425},{"name":"README.md","path":"dev-tools/packaging/templates/ironbank/packetbeat/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/packaging/templates/ironbank/packetbeat/README.md","title":"packetbeat Documentation","category":"plugin-manifest","format":"markdown","content":"# packetbeat\n\n**packetbeat** Lightweight shipper for network data\n\nMonitoring your network traffic is critical to gaining observability over your environment — ensuring high levels of performance and security. Packetbeat is a lightweight network packet analyzer that sends data from your hosts and containers to Logstash or Elasticsearch.\n\nFor more information about packetbeat, please visit\nhttps://www.elastic.co/products/beats/packetbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running packetbeat on Docker](https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [packetbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/packetbeat)\n- [packetbeat Documentation](https://www.elastic.co/guide/en/beats/packetbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n","isInternal":false,"tokens":346,"sizeBytes":1534},{"name":"README.md","path":"dev-tools/README.md","rawUrl":"https://raw.githubusercontent.com/elastic/beats/HEAD/dev-tools/README.md","title":"dev-tools Documentation","category":"plugin-manifest","format":"markdown","content":"Available scripts\n-----------------\n\n\nThe following scripts are used by the unified release process:\n\n| File                 | Description |\n|----------------------|-------------|\n| get_version          | Returns the current version |\n| set_version          | Sets the current version in all places where change is required. Doesn't commit changes. |\n| deploy               | Builds all artifacts for the officially supported Beats |\n\n\n\nOther scripts:\n\n\n| File                 | Description |\n|----------------------|-------------|\n| aggregate_coverage.py | Used to create coverage reports that contain both unit and system tests data |\n| merge_pr | Used to make it easier to open a PR that merges one branch into another. |\n\n\nImport / export the dashboards of a single Beat:\n\n| File                  | Description |\n|-----------------------|-------------|\n| export_dashboards.py  | Python script to export the Beat dashboards from Elasticsearch to a local directory|\n\nRunning export_dashboards.py in environment\n----------------------------------------------\n\nIf you are running the python script for the first time, you need to create the\nenvironment by running the following commands in the `beats/dev-tools`\ndirectory:\n\n```\nvirtualenv env\n. env/bin/activate\npip install -r requirements.txt\n```\n\nThis creates the environment that contains all the python packages required to\nrun the `export_dashboards.py` script. Thus, for the next runs you just need\nto enable the environment:\n\n```\n. env/bin/activate\n```\n","isInternal":false,"tokens":291,"sizeBytes":1510}],"systemPromptSnippet":"<yakaai_skills repo=\"elastic/beats\">\n<!-- File: AGENTS.md (Tokens: ~1700 | Category: root-instruction) -->\n## Repository Overview\n\nElastic Beats is a Go monorepo containing lightweight data shippers for the Elastic Stack. The module path is `github.com/elastic/beats/v7`. Go version: see `.go-version`.\n\n## Build System\n\nThe primary build tool is **Mage** (Go-based). Makefile wraps mage for some targets. Each beat has its own `magefile.go`; shared build logic lives in `dev-tools/mage/`.\n\n### Per-Beat Commands (run from the beat's directory, e.g. `cd filebeat`)\n\n```bash\nmage build              # Build the beat binary\nmage unitTest           # Run Go unit tests\nmage integTest          # Run integration tests (requires Docker)\nmage goIntegTest        # Go integration tests only\nmage pythonIntegTest    # Python integration tests only\nmage update             # Regenerate fields, configs, dashboards, includes\nmage fields             # Regenerate fields.yml and fields.go\nmage config             # Regenerate config files\nmage check              # Run checks (lint, headers, go mod)\nmage docker:composeUp   # Start integration test containers, wait until healthy\nmage docker:composeDown # Stop integration test containers\nmage crossBuild         # Cross-compile for all platforms\nSNAPSHOT=true DEV=true PLATFORMS=$GOOS/$GOARCH PACKAGES=tar.gz mage package  # Build and package the beat\n```\n\nFor `mage package`, set `PLATFORMS` to match the current OS/architecture. Check with `go env GOOS GOARCH` before running. Common values: `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`. `PACKAGES` sets the format: `tar.gz`, `zip`, `rpm`, `deb`, `docker` (comma-separated).\n\n### Running Tests\n\n**Do not run all unit or integration tests** (e.g. `mage unitTest` from root) unless explicitly requested. They take too long and require too many dependencies. Always run tests scoped to the package you're working on:\n\n```bash\n# Run a single test or package tests\ncd filebeat  # or any beat directory\ngo test -v -race -run TestName ./path/to/package/...\n\n# Stress test to find flaky tests (runs a test repeatedly with x/tools/cmd/stress)\n# It runs FOREVER (stress -timeout is per-run, not total); bound it with an outer `timeout`.\ntimeout 5m script/stresstest.sh [--tags integration] [--race] ./path/to/package ^TestName$ -p 32 [-failfast]\n```\n\n### Integration Tests\n\nIntegration tests may need external dependencies that can be started with mage\nor manually. The Go test binary is built automatically via `TestMain`.\n\n```bash\n# Run integration tests for a specific package\ngo test -v -race -run TestName -tags integration ./path/to/package/...\n```\n\n### Running a Beat\n\n```bash\nDEV=true mage build\n./filebeat -e --strict.perms=false -c filebeat.yml -path.home=<temp_dir>\n```\n\nAlways pass `--strict.perms=false` during development — it disables strict config\nfile permission checks. Set `-path.home` to a temporary directory to avoid\nwriting data/logs into the source tree.\n\n### Pre-Push Check\n\nBefore pushing, run `mage check` from the beat directory — it's a required CI check and catches lint, header, and module issues early.\n\n### Root-Level Commands\n\n```bash\nmage fmt                     # Format code + add license headers\nmake check                   # Full check suite (lint, headers, go mod, python)\n```\n\n### Linting\n\n```bash\n# Running golangci-lint for the whole codebase is slow, prefer running only on changed lines by default.\ngolangci-lint run --max-issues-per-linter 0 --max-same-issues 0 --new-from-merge-base upstream/main\n```\n\n## Architecture\n\n### Beats\n\n| Beat | Description |\n|------|-------------|\n| `filebeat` | Lightweight agent that ships log files and journals |\n| `metricbeat` | Collects metrics from systems and services |\n| `heartbeat` | Monitors availability of services and endpoints, detecting uptime/downtime |\n| `auditbeat` | Gathers audit data from systems to track security events, user activities, and compliance requirements |\n| `packetbeat` | Analyzes network traffic by capturing and inspecting packets for application and network visibility |\n| `winlogbeat` | Collects Windows Event logs for centralized monitoring and troubleshooting of Windows systems |\n| `x-pack/osquerybeat` | Manages and queries Osquery endpoints (Elastic license) |\n| `x-pack/dockerlogbeat` | Ships Docker container logs as a Docker log driver plugin (Elastic license) |\n| `x-pack/otel` | OTel Collector components that wrap beats as receivers, processors, and exporters for the Elastic Distribution of OpenTelemetry (Elastic license) |\n\nEach beat follows the pattern: `cmd/` (CLI entry), `beater/` (implements `beat.Beater` interface from `libbeat/beat/beat.go`), `module/` or `input/` (data collection).\n\n### libbeat (shared framework)\n\nAll beats build on `libbeat/`, which provides:\n- `beat/` — `Beater` interface (Run/Stop), `Beat` struct, `Pipeline`/`Client` for event publishing\n- `outputs/` — Output plugins (Elasticsearch, Logstash, Kafka, Redis, etc.)\n- `processors/` — Event processing pipeline\n- `publisher/` — Internal publishing pipeline\n- `cmd/` — Shared CLI infrastructure and beat instance bootstrapping\n- `autodiscover/` — Dynamic service discovery (Docker, Kubernetes)\n- `management/` — Elastic Agent management integration\n- `statestore/` — Persistent state\n\n### x-pack\n\n`x-pack/` contains Elastic-licensed extensions for each beat and x-pack-only beats. Each `x-pack/{beat}` extends the corresponding OSS beat with additional modules, inputs, or features.\n\n### Licensing Boundary\n\nOSS code (Apache 2.0) **cannot** import from `x-pack/` or `elastic-agent-client`. This is enforced by `depguard` in `.golangci.yml`. X-pack code can import OSS code freely.\n\n## Code Rules\n\n- Logging: accept `*logp.Logger` as a parameter. For tests prefer `logptest`\n- Use `github.com/stretchr/testify` in tests — always add a message explaining the failure. Use `assert` by default, `require` only when you actually need to interrupt the test\n- Use `github.com/gofrs/uuid/v5`\n- Write unit tests for new functionality. Use table-driven tests when appropriate\n- Document exported functions and types\n- Keep comments concise, focused on \"why\" not \"what\"\n- Update documentation when changing behavior\n\n## Documentation\n\nFor changes that affect published documentation or documentation generation, use the `docs-authoring` skill (`.agents/skills/docs-authoring/SKILL.md`).\n\n## Code References\n\nWhen referencing code, always use exact locations and names:\n- Format: `filepath:line_number` or `filepath:start-end`\n- Use specific element names (functions, methods, variables)\n- Quote exact text from code and logs — zero paraphrasing\n\n## Changelog\n\nIf the change is user-visible (not tests, CI, refactoring, or docs), add a changelog fragment: run `go run github.com/elastic/elastic-agent-changelog-tool@latest new` and edit the emitted fragment following the instructions in its comments. Otherwise, add the `skip-changelog` label to the PR.\n\n## Commits and PRs\n\nWhen writing commit messages, explain WHAT changed and WHY — the rationale and motivation, not just a description of the diff. The commit title is used as the squash-merge message. Add a trailer line `Assisted-By: <tool name>` for each AI tool used.\n\nWhen creating PRs, follow the template in `.github/PULL_REQUEST_TEMPLATE.md`\n\n<!-- File: .agents/skills/docs-authoring/SKILL.md (Tokens: ~1829 | Category: anthropic-skill) -->\n---\nname: docs-authoring\ndescription: >\n  Write or edit user-facing documentation. Use when a change adds or edits a\n  published doc page, a snippet, navigation, or the source that generates a page.\n  Decides whether a change needs docs, where the content goes, what must be\n  verified against the product, and how to scope it with applies_to. Does not\n  cover changelog fragments or release-note entries.\nmetadata:\n  source: elastic-docs-authoring\n  source_version: \"1.0.0\"\n---\n\n# Documentation\n\nUse `docs/extend/contributing-docs.md` for the repository-specific publishing, placement, and generation instructions.\n\nA page is published as written. Write for the person doing the task, and write it as the final text they will read.\n\nAsk when the change does not tell you who it is for or what they can now do. Never invent a UI label, a default, a limit, a permission, or a behavior, and never generate a screenshot. Name the screenshot that is needed and where it goes.\n\n## Whether to write\n\n| The change | What to do |\n|---|---|\n| Nothing new for the reader to choose, configure, or do | No page change. Say so. |\n| A page already says this | Show where, and narrow or drop the edit |\n| A page states something that is now false | Fix that page |\n| A workflow gained a step or option a reader would otherwise miss | Add it |\n| A page is deliberately general and the request adds specifics | Usually not a gap. Say so |\n| Something the page documents was removed | Keep the content and scope it. Do not delete it |\n\n\"Remove X\" describes the product change, not the edit. The docs are cumulative, and readers on versions that still have the feature still need the page. For a GA or deprecated feature in a versioned product, keep the content and mark it `removed <version>` with `applies_to`. Deleting is reasonable only when the feature was only ever a preview or beta, or only ever existed in a product that has no versions. Say which reading you took.\n\nConcluding that nothing needs documenting is a valid result. Report it and stop.\n\n## Where it goes\n\nStart from the assumption that an existing page should absorb the change. Adding a page is the exception.\n\nSearch before you add. Search the published docs and the `docs/` tree of this repository, including snippets and pages that are not linked yet. A search that did not run is not evidence that nothing covers the topic, so do not report \"nothing covers this yet\" unless you looked.\n\nPropose the lightest change that closes the gap, in this order: a sentence in an existing section, a new section, a new page. Pause when you are about to add a page, or when the change touches several pages.\n\nPut each fact in one place. A caveat that belongs on every page belongs on the one page that owns the concept, with the others linking to it. A sentence, admonition, or requirement repeated at the top of every page in a section is that mistake. A shared snippet is not, when its only job is to say which of two similar systems the page documents: no `applies_to` value can say that, and the wording lives once. Check the nearest `_snippets/` directory before writing prose that more than one page needs.\n\n## Verify, then write\n\nList every concrete claim the page will make: each UI string, field name, setting, default, limit, permission, and behavior. Then verify each one against the product source as it is now, not against the issue or the pull request description. A diff shows one change. The current source shows what the reader will meet.\n\nAnything you cannot verify goes back to the author as a question. It does not go in the page.\n\nBecause the page covers every supported version, a statement that is true only in the latest code is wrong for most readers. Confirm each claim for the versions the page covers, or scope it.\n\nThe product's own lifecycle field outranks the request. A release-note label, a bare version number, and \"on by default\" all mean something shipped. None of them means generally available. A backport label is not a released version, and neither is a merged pull request. Use the minor version in an `applies_to` badge. When a critical difference really is patch-specific, explain the exact patch in prose.\n\n## Versioning\n\nOne page covers every version. Do not copy a page per release. Mark a difference with `applies_to` on the page or on the section that differs.\n\n```yaml\napplies_to:\n  stack: ga 9.1\n  serverless: ga\n```\n\nA feature that exists only in some versions gets `applies_to` on that section. When it is removed from a versioned product, keep the section and add the removal, for example `stack: removed 9.1`. When the page is generated, the repository contributing guide says where the version is set. Do not hand-edit `applies_to` in a generated page.\n\nIf `docs-applies-to-tagging` is installed, let it choose the values and the placement. Collect the version, lifecycle, and deployment answers and hand them over.\n\n## Write the page\n\nWrite what the reader can now do, see, configure, or avoid. The notes you were given describe an implementation. Nothing later will translate them for you, so do it as you draft. Cut anything that does not serve the task, including a detail that is there only because the issue mentioned it.\n\nOrder the page for the task: what it is, then how to do it, then the edge cases. Open a new option or mode on the outcome, not the control. For example, use **View documents as JSON**, then write the sentence that names the control. The labels and defaults you verified are a checklist the page must not contradict. They are not an outline.\n\n- Address the reader as you. Do not call them users or customers.\n- Present tense. Active voice. One idea per sentence.\n- Sentence case for headings. No trailing period on a heading.\n- Name the product, feature, page, or setting on first mention. No internal names: packages, functions, struct fields, ticket numbers, or team names.\n- Backticks for settings, field names, file names, CLI flags, and values the reader types.\n- Quote a UI label only when it would otherwise read as prose. Feature names are capitalized and not quoted.\n- US English.\n\nUse the substitutions the repository defines (`{{kib}}`, `{{es}}`, and the product's own) the way the surrounding page does. Do not spell out a name that page writes as a substitution, and do not introduce one it does not use.\n\n## Links and navigation\n\nA new page goes in the `toc.yml` for its section. Navigation is per docset, and some sections nest their toc, so copy the shape of the section you are adding to rather than inventing one.\n\nUse descriptive link text rather than a bare URL or generic call to action. A link to a page in another Elastic docset uses that docset's form (`docs-content://...`, `integration-docs://...`), not `https://www.elastic.co/docs/...`.\n\nA page you moved, renamed, or deleted needs an entry in `redirects.yml`. If `docs-redirects` is installed, hand it the old path and the new one.\n\nA link to a page being added in another repository cannot resolve until that change publishes. Leave the link, name the change it waits on, and do not point it at a placeholder. Every other unresolved link is a defect.\n\n## Generated pages\n\nIf a page says it is generated, edit the source it names and regenerate. An edit to the generated file is overwritten on the next run. The repository contributing guide names the source and the command.\n\n## Checks\n\nApply these rules while you write, not after. Run the repository's docs build and Vale checks. If the `elastic-docs-skills` plugin is installed, run the individual checks that apply for content type, `applies_to`, style, frontmatter, jargon, syntax, and redirects. `docs-draft-feature-docs` is an end-to-end drafting workflow, not a post-edit checker. Do not copy its companion skills into this repository.\n\nReference: [Elastic style guide](https://www.elastic.co/docs/contribute-docs/style-guide), [cumulative docs](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs), [`applies_to` reference](https://www.elastic.co/docs/contribute-docs/how-to/cumulative-docs/reference), [content types](https://www.elastic.co/docs/contribute-docs/content-types).\n\n<!-- File: dev-tools/kubernetes/README.md (Tokens: ~1021 | Category: plugin-manifest) -->\n# Readme\n\nThis folder contains some dev tools that make it easier to develop and deploy filebeat and metricbeat running inside a Kubernetes cluster. This is especially useful when developing the metricbeat module `kubernetes` since it requires metricbeat to run inside a Kubernetes cluster in order to interact with kube-state-metrics and the Kubernetes APIs.\n\nIn details, a combination of Dockerfiles, Kubernetes manifests and Tiltfile make it possible to have features like:\n- hot reloading of code running in Kubernetes, without re-applying the Kubernetes manifest\n- remote debugging (with breakpoints) both metricbeat/filebeat running as a pod in a Kind Kubernetes cluster\n\n[Tilt](https://tilt.dev/) is a dev toolkit for microservices.\n\n\n## Setup\nYou can install Tilt by using the command\n\n```shell\ncurl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash\n```\n\n\n## How to run\nThe Tiltfile that orchestrates everything is located at `dev-tools/kubernetes/Tiltfile`. All the following commands need to be run from `dev-tools/kubernetes`, in the same folder where the Tiltfile is located.\n\nHow to run Tilt\n\n```shell\ntilt up\n```\n\nThis will open a terminal and optionally a web UI where you can interact with Tilt, see container logs and restart resources.\n\nOnce you are done with Tilt, you can simply `CTRL+C` from the open Tilt terminal. The resources that you started in k8s will still be running though.\n\nFor more information on how to configure Tilt to run different scenarios look at the comments in the Tiltfile.\n\nIf you want to remove all the k8s resources that you started with Tilt, you can run\n\n```shell\ntilt down\n```\n\nIf you want to use a remote debugger with Visual Studio code, you need to provide a `.vscode/launch.json` similar to the following file. In order for this to work on your laptop, you need to replace `<absolute_path_to_beats_folder>` with the absolute path of the root folder in this project. This file is currently not under git because it depends on the user configuration, it is only useful for VisualStudio Code and in a folder usually ignored by git.\n\n```json\n{\n    \"version\": \"0.2.0\",\n    \"configurations\": [\n        {\n            \"name\": \"Connect to server\",\n            \"type\": \"go\",\n            \"request\": \"attach\",\n            \"mode\": \"remote\",\n            \"debugAdapter\": \"dlv-dap\",\n            \"port\": 56268,\n            \"host\": \"127.0.0.1\",\n            \"showLog\": true,\n            \"trace\": \"trace\",\n            \"cwd\": \"${workspaceFolder}\",\n            \"substitutePath\": [\n                {\n\t                \"from\": \"${workspaceFolder}\",\n                    \"to\": \"<absolute_path_to_beats_folder>\"\n                }\n            ]\n        }\n\n    ]\n}\n```\n\n\n## Run vs debug mode\nThe behavior of the Tiltfile can be changed by calling the function `beat()` with different parameters:\n- `beat`: `metricbeat` to test Metricbeat, `filebeat` to test Filebeat\n- `mode`: `debug` to start a remote debugger that you can connect to from your IDE with hot reloading enabled, `run` to just run Metricbeat without a debugger but still with hot reloading enabled\n- `arch`: `amd64` to build go binary for amd64 architecture, `arm64` to build go binary for arm64 (aka M1 Apple chip) architecture\n- `k8s_env`: `kind` to run against a Kind cluster with no docker registry, `gcp` to use a docker registry on GCP. More info on docker registry on GCP at https://cloud.google.com/container-registry/docs/advanced-authentication#gcloud-helper.\n- `k8s_cluster`: `single` to use a single node k8s cluster, `multi` to use a k8s with more than 1 node.\n      if running on a multi-node cluster we expect to have at least 2 workers and a control plane node.\n      A Beat in debugger mode will run on a node with a Tain `debugger=yes:NoSchedule`, while 1 Beat per node will run on all the other worker nodes.\n      More info on Taints and Tolerations at https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/.\n      You can add a taint with the following command:\n          `kubectl taint nodes <node_name> debugger=yes:NoSchedule`\n\nYou can modify the Tiltfile while `tilt up` is running in the background. Tilt will try its best to update everything in place but depending what changes you made, you might want to `tilt down` and `tilt up` again just to make sure that everything was updated correctly.\n\n<!-- File: dev-tools/packaging/templates/ironbank/auditbeat/README.md (Tokens: ~335 | Category: plugin-manifest) -->\n# Auditbeat\n\n**Auditbeat** Lightweight shipper for audit data\n\nCollect your Linux audit framework data and monitor the integrity of your files.\nAuditbeat ships these events in real time to the rest of the Elastic Stack for further analysis.\n\nFor more information about Auditbeat, please visit\nhttps://www.elastic.co/products/beats/auditbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running Auditbeat on Docker](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [Auditbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/auditbeat)\n- [Auditbeat Documentation](https://www.elastic.co/guide/en/beats/auditbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n\n<!-- File: dev-tools/packaging/templates/ironbank/filebeat/README.md (Tokens: ~344 | Category: plugin-manifest) -->\n# filebeat\n\n**filebeat** Lightweight shipper for logs\n\nForget using SSH when you have tens, hundreds, or even thousands of servers, virtual machines, and containers generating logs. Filebeat helps you keep the simple things simple by offering a lightweight way to forward and centralize logs and files.\n\nFor more information about filebeat, please visit\nhttps://www.elastic.co/products/beats/filebeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running filebeat on Docker](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [filebeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/filebeat)\n- [filebeat Documentation](https://www.elastic.co/guide/en/beats/filebeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n\n<!-- File: dev-tools/packaging/templates/ironbank/heartbeat/README.md (Tokens: ~337 | Category: plugin-manifest) -->\n# heartbeat\n\n**heartbeat** Lightweight shipper for uptime monitoring\n\nMonitor services for their availability with active probing. Given a list of URLs, Heartbeat asks the simple question: Are you alive? Heartbeat ships this information and response time to the rest of the Elastic Stack for further analysis.\n\nFor more information about heartbeat, please visit\nhttps://www.elastic.co/products/beats/heartbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running heartbeat on Docker](https://www.elastic.co/guide/en/beats/heartbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [heartbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/heartbeat)\n- [heartbeat Documentation](https://www.elastic.co/guide/en/beats/heartbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n\n<!-- File: dev-tools/packaging/templates/ironbank/metricbeat/README.md (Tokens: ~337 | Category: plugin-manifest) -->\n# metricbeat\n\n**metricbeat** Lightweight shipper for metrics\n\nCollect metrics from your systems and services. From CPU to memory, Redis to NGINX, and much more, Metricbeat is a lightweight way to send system and service statistics.\n\nFor more information about metricbeat, please visit\nhttps://www.elastic.co/products/beats/metricbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running metricbeat on Docker](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [metricbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/metricbeat)\n- [metricbeat Documentation](https://www.elastic.co/guide/en/beats/metricbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n\n<!-- File: dev-tools/packaging/templates/ironbank/packetbeat/README.md (Tokens: ~346 | Category: plugin-manifest) -->\n# packetbeat\n\n**packetbeat** Lightweight shipper for network data\n\nMonitoring your network traffic is critical to gaining observability over your environment — ensuring high levels of performance and security. Packetbeat is a lightweight network packet analyzer that sends data from your hosts and containers to Logstash or Elasticsearch.\n\nFor more information about packetbeat, please visit\nhttps://www.elastic.co/products/beats/packetbeat.\n\n### Installation instructions\n\nPlease follow the documentation on [running packetbeat on Docker](https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html).\n\n### Where to file issues and PRs\n\n- [Issues](https://github.com/elastic/beats/issues)\n- [PRs](https://github.com/elastic/beats/pulls)\n\n### DoD Restrictions\n\n### Where to get help\n\n- [packetbeat Discuss Forums](https://discuss.elastic.co/tags/c/elastic-stack/beats/28/packetbeat)\n- [packetbeat Documentation](https://www.elastic.co/guide/en/beats/packetbeat/current/index.html)\n\n### Still need help?\n\nYou can learn more about the Elastic Community and also understand how to get more help\nvisiting [Elastic Community](https://www.elastic.co/community).\n\nThis software is governed by the [Elastic\nLicense](https://github.com/elastic/beats/blob/{{ .MajorMinor }}/licenses/ELASTIC-LICENSE.txt),\nand includes the full set of [free\nfeatures](https://www.elastic.co/subscriptions).\n\nView the detailed release notes\n[here](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-{{ beat_version }}.html).\n\n<!-- File: dev-tools/README.md (Tokens: ~291 | Category: plugin-manifest) -->\nAvailable scripts\n-----------------\n\n\nThe following scripts are used by the unified release process:\n\n| File                 | Description |\n|----------------------|-------------|\n| get_version          | Returns the current version |\n| set_version          | Sets the current version in all places where change is required. Doesn't commit changes. |\n| deploy               | Builds all artifacts for the officially supported Beats |\n\n\n\nOther scripts:\n\n\n| File                 | Description |\n|----------------------|-------------|\n| aggregate_coverage.py | Used to create coverage reports that contain both unit and system tests data |\n| merge_pr | Used to make it easier to open a PR that merges one branch into another. |\n\n\nImport / export the dashboards of a single Beat:\n\n| File                  | Description |\n|-----------------------|-------------|\n| export_dashboards.py  | Python script to export the Beat dashboards from Elasticsearch to a local directory|\n\nRunning export_dashboards.py in environment\n----------------------------------------------\n\nIf you are running the python script for the first time, you need to create the\nenvironment by running the following commands in the `beats/dev-tools`\ndirectory:\n\n```\nvirtualenv env\n. env/bin/activate\npip install -r requirements.txt\n```\n\nThis creates the environment that contains all the python packages required to\nrun the `export_dashboards.py` script. Thus, for the next runs you just need\nto enable the environment:\n\n```\n. env/bin/activate\n```\n</yakaai_skills>"}