- Metricbeat Reference: other versions:
- Overview
- Contributing to Beats
- Getting started with Metricbeat
- Setting up and running Metricbeat
- Upgrading Metricbeat
- How Metricbeat works
- Configuring Metricbeat
- Specify which modules to run
- Specify general settings
- Load external configuration files
- Configure the internal queue
- Configure the output
- Specify SSL settings
- Filter and enhance the exported data
- Parse logs by using ingest node
- Set up project paths
- Set up the Kibana endpoint
- Load the Kibana dashboards
- Load the Elasticsearch index template
- Set up logging
- Use environment variables in the configuration
- YAML tips and gotchas
- Regular expression support
- metricbeat.reference.yml
- Modules
- Aerospike module
- Apache module
- Ceph module
- Couchbase module
- Docker module
- Dropwizard module
- Elasticsearch module
- Golang module
- HAProxy module
- HTTP module
- Jolokia module
- Kafka module
- Kibana module
- Kubernetes module
- Kubernetes container metricset
- Kubernetes event metricset
- Kubernetes node metricset
- Kubernetes pod metricset
- Kubernetes state_container metricset
- Kubernetes state_deployment metricset
- Kubernetes state_node metricset
- Kubernetes state_pod metricset
- Kubernetes state_replicaset metricset
- Kubernetes system metricset
- Kubernetes volume metricset
- Memcached module
- MongoDB module
- MySQL module
- Nginx module
- PHP-FPM module
- PostgreSQL Module
- Prometheus module
- RabbitMQ module
- Redis module
- System module
- vSphere module
- Windows module
- ZooKeeper module
- Exported Fields
- Aerospike Fields
- Apache Fields
- Beat Fields
- Ceph Fields
- Cloud Provider Metadata Fields
- Common Fields
- Couchbase Fields
- docker Fields
- Docker Fields
- Dropwizard Fields
- Elasticsearch Fields
- Golang Fields
- HAProxy Fields
- HTTP Fields
- Jolokia Fields
- Kafka Fields
- Kibana Fields
- kubernetes Fields
- Kubernetes Fields
- Memcached Fields
- MongoDB Fields
- MySQL Fields
- Nginx Fields
- PHP-FPM Fields
- PostgreSQL Fields
- Prometheus Fields
- RabbitMQ Fields
- Redis Fields
- System Fields
- vSphere Fields
- Windows Fields
- ZooKeeper Fields
- Securing Metricbeat
- Troubleshooting
WARNING: Version 6.0 of Metricbeat has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Secure communication with Elasticsearch
editSecure communication with Elasticsearch
editTo secure the communication between Metricbeat and Elasticsearch, you can use HTTPS and basic authentication. Here is a sample configuration:
output.elasticsearch: username: metricbeat password: verysecret protocol: https hosts: ["elasticsearch.example.com:9200"]
The username to use for authenticating to Elasticsearch. |
|
The password to use for authenticating to Elasticsearch. |
|
This setting enables the HTTPS protocol. |
|
The IP and port of the Elasticsearch nodes. |
Elasticsearch doesn’t have built-in basic authentication, but you can achieve it either by using a web proxy or by using X-Pack to secure Elasticsearch. For more information, see the X-Pack documentation about securing Elasticsearch and Metricbeat and X-Pack Security.
Metricbeat verifies the validity of the server certificates and only accepts trusted certificates. Creating a correct SSL/TLS infrastructure is outside the scope of this document.
By default Metricbeat uses the list of trusted certificate authorities from the operating system where Metricbeat is running. You can configure Metricbeat to use a specific list of CA certificates instead of the list from the OS. You can also configure it to use client authentication by specifying the certificate and key to use when the server requires the Beat to authenticate. Here is an example configuration:
output.elasticsearch: username: metricbeat password: verysecret protocol: https hosts: ["elasticsearch.example.com:9200"] ssl.certificate_authorities: - /etc/pki/my_root_ca.pem - /etc/pki/my_other_ca.pem ssl.certificate: "/etc/pki/client.pem" ssl.key: "/etc/pki/key.pem"
The list of CA certificates to trust |
|
The path to the certificate for SSL client authentication |
|
The client certificate key |
For any given connection, the SSL/TLS certificates must have a subject
that matches the value specified for hosts
, or the SSL handshake fails.
For example, if you specify hosts: ["foobar:9200"]
, the certificate MUST
include foobar
in the subject (CN=foobar
) or as a subject alternative name
(SAN). Make sure the hostname resolves to the correct IP address. If no DNS is available, then
you can associate the IP address with your hostname in /etc/hosts
(on Unix) or C:\Windows\System32\drivers\etc\hosts
(on Windows).