- Metricbeat Reference: other versions:
- Overview
- 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
- HTTP Endpoint
- metricbeat.reference.yml
- Beats central management
- Modules
- Aerospike module
- Apache module
- Ceph module
- Couchbase module
- Docker module
- Dropwizard module
- Elasticsearch module
- Elasticsearch ccr metricset
- Elasticsearch cluster_stats metricset
- Elasticsearch index metricset
- Elasticsearch index_recovery metricset
- Elasticsearch index_summary metricset
- Elasticsearch ml_job metricset
- elasticsearch ml_job MetricSet
- Elasticsearch node metricset
- Elasticsearch node_stats metricset
- Elasticsearch pending_tasks metricset
- elasticsearch pending_tasks MetricSet
- Elasticsearch shard metricset
- envoyproxy module
- Etcd module
- Golang module
- Graphite module
- HAProxy module
- HTTP module
- Jolokia module
- Kafka module
- Kibana module
- Kubernetes module
- Kubernetes apiserver metricset
- 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 state_statefulset metricset
- Kubernetes system metricset
- Kubernetes volume metricset
- kvm module
- Logstash module
- Memcached module
- MongoDB module
- Munin 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 socket metricset
- System socket_summary metricset
- System uptime metricset
- traefik 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
- envoyproxy fields
- Etcd fields
- Golang fields
- Graphite fields
- HAProxy fields
- Host fields
- HTTP fields
- Jolokia fields
- Kafka fields
- Kibana fields
- Kubernetes fields
- Kubernetes fields
- kvm fields
- Logstash fields
- Memcached fields
- MongoDB fields
- Munin fields
- MySQL fields
- Nginx fields
- PHP_FPM fields
- PostgreSQL fields
- Prometheus fields
- RabbitMQ fields
- Redis fields
- System fields
- traefik fields
- uwsgi fields
- vSphere fields
- Windows fields
- ZooKeeper fields
- Monitoring Metricbeat
- Securing Metricbeat
- Troubleshooting
- Contributing to Beats
Autodiscover
editAutodiscover
editWhen you run applications on containers, they become moving targets to the monitoring system. Autodiscover allows you to track them and adapt settings as changes happen. By defining configuration templates, the autodiscover subsystem can monitor services as they start running.
You define autodiscover settings in the metricbeat.autodiscover
section of the metricbeat.yml
config file. To enable autodiscover, you specify a list of providers.
Providers
editAutodiscover providers work by watching for events on the system and translating those events into internal autodiscover events with a common format. When you configure the provider, you can use fields from the autodiscover event to set conditions that, when met, launch specific configurations.
On start, Metricbeat will scan existing containers and launch the proper configs for them. Then it will watch for new start/stop events. This ensures you don’t need to worry about state, but only define your desired configs.
Docker
editThe Docker autodiscover provider watches for Docker containers to start and stop. These are the available fields on every event:
- host
- port
- docker.container.id
- docker.container.image
- docker.container.name
- docker.container.labels
For example:
{ "host": "10.4.15.9", "port": 6379, "docker": { "container": { "id": "382184ecdb385cfd5d1f1a65f78911054c8511ae009635300ac28b4fc357ce51" "name": "redis", "image": "redis:3.2.11", "labels": { "io.kubernetes.pod.namespace": "default" ... } } } }
You can define a set of configuration templates to be applied when the condition matches an event. Templates define a condition to match on autodiscover events, together with the list of configurations to launch when this condition happens.
Conditions match events from the provider. Providers use the same format for Conditions that processors use.
Configuration templates can contain variables from the autodiscover event. They can be accessed under the data
namespace.
For example, with the example event, "${data.port}
" resolves to 6379
.
Metricbeat supports templates for modules:
metricbeat.autodiscover: providers: - type: docker templates: - condition: contains: docker.container.image: redis config: - module: redis metricsets: ["info", "keyspace"] hosts: "${data.host}:6379"
This configuration launches a redis
module for all containers running an image with redis
in the name.
Kubernetes
editThe Kubernetes autodiscover provider watches for Kubernetes pods to start, update, and stop. These are the available fields on every event:
- host
- port (if exposed)
- kubernetes.container.id
- kubernetes.container.image
- kubernetes.container.name
- kubernetes.labels
- kubernetes.namespace
- kubernetes.node.name
- kubernetes.pod.name
If the include_annotations
config is added to the provider config, then the list of annotations present in the config
are added to the event.
For example:
{ "host": "172.17.0.21", "port": 9090, "kubernetes": { "container": { "id": "bb3a50625c01b16a88aa224779c39262a9ad14264c3034669a50cd9a90af1527", "image": "prom/prometheus", "name": "prometheus" }, "labels": { "project": "prometheus", ... }, "namespace": "default", "node": { "name": "minikube" }, "pod": { "name": "prometheus-2657348378-k1pnh" } }, }
The configuration of templates and conditions is similar to that of the Docker provider. Configuration templates can contain variables from the autodiscover event. They can be accessed under data namespace.
The kubernetes
autodiscover provider has the following configuration settings:
-
in_cluster
-
(Optional) Use in cluster settings for Kubernetes client,
true
by default. -
host
- (Optional) Identify the node where metricbeat is running in case it cannot be accurately detected, as when running metricbeat in host network mode.
-
namespace
- (Optional) Select the namespace from which to collect the metadata. If it is not set, the processor collects metadata from all namespaces. It is unset by default.
-
kube_config
- (Optional) Use given config file as configuration for Kubernetes client.
Metricbeat supports templates for modules:
metricbeat.autodiscover: providers: - type: kubernetes include_annotations: ["prometheus.io.scrape"] templates: - condition: contains: kubernetes.annotations.prometheus.io.scrape: "true" config: - module: prometheus metricsets: ["collector"] hosts: "${data.host}:{data.port}"
This configuration launches a prometheus
module for all containers of pods annotated prometheus.io.scrape=true
.
Manually Defining Ports with Kubernetes
editDeclare exposed ports in your pod spec if possible. Otherwise, you will need to use
multiple templates with complex filtering rules. The {port} variable will not be
present, and you will need to hardcode ports. Example: {data.host}:1234
When ports are not declared, Autodiscover generates a config using your provided template once per pod, and once per container. These generated configs are de-duplicated after they are generated. If the generated configs for multiple containers are identical, they will be merged into one config.
Pods share an identical host. If only the {data.host}
variable is interpolated,
then one config will be generated per host. The configs will be identical.
After they are de-duplicated, only one will be used.
Jolokia (experimental)
editThe Jolokia autodiscover provider uses Jolokia Discovery to find agents running in your host or your network.
Jolokia Discovery mechanism is supported by any Jolokia agent since version 1.2.0, it is enabled by default when Jolokia is included in the application as a JVM agent, but disabled in other cases as the OSGI or WAR (Java EE) agents. In any case, this feature is controlled with two properties:
-
discoveryEnabled
, to enable the feature -
discoveryAgentUrl
, if set, this is the URL announced by the agent when being discovered, setting this parameter implicitly enables the feature
There are multiple ways of setting these properties, and they can vary from application to application, please refer to the documentation of your application to find the more suitable way to set them in your case.
Jolokia Discovery is based on UDP multicast requests. Agents join the multicast group 239.192.48.84, port 24884, and discovery is done by sending queries to this group. You have to take into account that UDP traffic between Metricbeat and the Jolokia agents has to be allowed. Also notice that this multicast address is in the 239.0.0.0/8 range, that is reserved for private use within an organization, so it can only be used in private networks.
These are the available fields on every event:
- jolokia.agent.id
- jolokia.agent.version
- jolokia.secured
- jolokia.server.product
- jolokia.server.vendor
- jolokia.server.version
- jolokia.url
The configuration of this provider consists in a set of network interfaces, as well as a set of templates as in other providers. The network interfaces will be the ones used for discovery probes, they have these settings:
-
name
-
the name of the interface (e.g.
br0
), it can contain a wildcard as suffix to apply the same settings to multiple network interfaces of the same type (e.g.br*
). -
interval
- time between probes (defaults to 10s)
-
grace_period
- time since the last reply to consider an instance stopped (defaults to 30s)
-
probe_timeout
- max time to wait for responses since a probe is sent (defaults to 1s)
Metricbeat supports templates for modules:
metricbeat.autodiscover: providers: - type: jolokia interfaces: - name: br* interval: 5s grace_period: 10s - name: en* templates: - condition: contains: jolokia.server.product: "tomcat" config: - module: jolokia metricsets: ["jmx"] hosts: "${data.jolokia.url}" namespace: test jmx.mappings: - mbean: "java.lang:type=Runtime" attributes: - attr: Uptime field: uptime
This configuration starts a jolokia module that collects the uptime of each
tomcat
instance discovered. Discovery probes are sent using all interfaces
starting with br
and en
, for the br
interfaces the interval
and
grace_period
is reduced to 5 and 10 seconds respectively.