docs/reference/serverless/beats.md
{{beats}} are lightweight data shippers that send operational data to {{es}}. Elastic provides separate {{beats}} for different types of data, such as logs, metrics, and uptime. Depending on what data you want to collect, you might need to install multiple shippers on a single host.
{{beats}} are not hosted by Elastic. You deploy and manage them on your own infrastructure, such as on-premises servers, virtual machines, or containers. {{beats}} work with all {{es-serverless}} project types, including Elasticsearch, Observability, and Security projects.
::::{tip} If you're looking for a hosted data collection option that doesn't require managing infrastructure, consider agentless integrations, which run on Elastic's infrastructure and require no agent deployment or maintenance. ::::
| Data | {{beats}} |
|---|---|
| Audit data | Auditbeat |
| Log files and journals | Filebeat |
| Availability | Heartbeat |
| Metrics | Metricbeat |
| Network traffic | Packetbeat |
| Windows event logs | Winlogbeat |
{{beats}} can send data to {{es}} directly or through {{ls}}, where you can further process and enhance the data before visualizing it in {{kib}}.
To send data to an {{es-serverless}} project, configure your Beat to connect using the project's {{es}} endpoint URL and an API key.
In your Beat configuration file (for example, filebeat.yml), set the output.elasticsearch section with your endpoint URL and API key:
output.elasticsearch:
hosts: ["ELASTICSEARCH_ENDPOINT_URL"]
api_key: "YOUR_API_KEY"
::::{note}
Do not use cloud.id or cloud.auth for {{es-serverless}} projects. Those settings are for {{ech}} deployments only.
::::
Follow the quick start guide for the Beat you want to use:
When you reach the connection setup step, use the {{es-serverless}} configuration from Configure the output instead of the cloud.id or hosts examples shown for other deployment types.
When using {{beats}} with {{es-serverless}}, keep the following differences in mind:
cloud.id, and cloud.auth are not supported.