- 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 data by using ingest node
- Set up project paths
- Set up the Kibana endpoint
- Load the Kibana dashboards
- Load the Elasticsearch index template
- Configure logging
- Use environment variables in the configuration
- Autodiscover
- 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
- Etcd module
- Golang module
- Graphite 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
- Logstash module
- Memcached module
- MongoDB module
- MySQL module
- Nginx module
- PHP_FPM module
- PostgreSQL module
- Prometheus module
- RabbitMQ module
- Redis module
- System module
- System core metricset
- System cpu metricset
- System diskio metricset
- System filesystem metricset
- System fsstat metricset
- System load metricset
- System memory metricset
- System network metricset
- System process metricset
- System process_summary metricset
- System raid metricset
- system raid MetricSet
- System socket metricset
- System uptime metricset
- uwsgi module
- uwsgi 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
- Etcd fields
- Golang fields
- Graphite fields
- HAProxy fields
- HTTP fields
- Jolokia fields
- Kafka fields
- Kibana fields
- Kubernetes fields
- Kubernetes fields
- Logstash fields
- Memcached fields
- MongoDB fields
- MySQL fields
- Nginx fields
- PHP_FPM fields
- PostgreSQL fields
- Prometheus fields
- RabbitMQ fields
- Redis fields
- System fields
- uwsgi fields
- vSphere fields
- Windows fields
- ZooKeeper fields
- Monitoring Metricbeat
- Securing Metricbeat
- Troubleshooting
WARNING: Version 6.2 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. |
To obfuscate passwords and other sensitive settings, use the secrets keystore.
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).