diff --git a/metricbeat/docs/developer-guide/create-metricset.asciidoc b/metricbeat/docs/developer-guide/create-metricset.asciidoc index e395a880bae9..068b536c8a93 100644 --- a/metricbeat/docs/developer-guide/create-metricset.asciidoc +++ b/metricbeat/docs/developer-guide/create-metricset.asciidoc @@ -186,15 +186,15 @@ The only difference between this and the previous example is that the second exa Metricbeat will add the same timestamp to all the events in the list to make it possible to correlate the events. [float] -==== Parsing and normalizing fields +==== Parsing and Normalizing Fields -In Metricbeat we aim to normalize the metric names from all Metricsets to +In Metricbeat we aim to normalize the metric names from all metricsets to respect a common {libbeat}/event-conventions.html[set of conventions]. This makes it easy for users to find and interpret metrics. To simplify parsing, converting, renaming, and restructuring of the object read from the monitored system to the Metricbeat format, we have created the https://godoc.org/github.com/elastic/beats/metricbeat/schema[schema] package -that allows to declaratively define transformations. +that allows you to declaratively define transformations. For example, assuming this input object: @@ -251,7 +251,7 @@ func eventMapping(input map[string]interface{}) common.MapStr { ---- In the above example, note that it is possible to create the schema object once -but to apply to all events. +and apply it to all events. [float] === Configuration File diff --git a/metricbeat/docs/metricbeat-in-a-container.asciidoc b/metricbeat/docs/metricbeat-in-a-container.asciidoc index 222fc21e9a8f..173291b3bef9 100644 --- a/metricbeat/docs/metricbeat-in-a-container.asciidoc +++ b/metricbeat/docs/metricbeat-in-a-container.asciidoc @@ -4,8 +4,8 @@ Elastic does not provide any official container images for Metricbeat. The examples on this page assume you are using your own Metricbeat container image. -Metricbeat can be executed in a container and when doing so there are some -important things to be aware of if you want to monitor the host machine or other +When executing Metricbeat in a container, there are some important +things to be aware of if you want to monitor the host machine or other containers. Let's walk-through some examples using Docker as our container orchestration tool. @@ -13,7 +13,7 @@ orchestration tool. [[monitoring-host]] === Monitoring the Host Machine -This first example highlights the changes required to make the system module +This example highlights the changes required to make the system module work properly inside of a container. This enables Metricbeat to monitor the host machine from within the container. @@ -27,24 +27,24 @@ sudo docker run \ my/metricbeat:latest -system.hostfs=/hostfs --- -<1> Metricbeat's system module collects much of its data through the Linux proc -filesystem which is normally located at `/proc`. Due to the fact that containers +<1> Metricbeat's <> collects much of its data through the Linux proc +filesystem, which is normally located at `/proc`. Because containers are isolated as much as possible from the host, the data inside of the -containers `/proc` is different than the host's `/proc`. To account for this you +container's `/proc` is different than the host's `/proc`. To account for this, you can mount the host's `/proc` filesystem inside of the container and tell Metricbeat to look inside the `/hostfs` directory when looking for `/proc` by using the `-system.hostfs=/hostfs` CLI flag. <2> If you have enabled cgroup reporting (an experimental feature) from the -system process metricset then you need to mount the host's cgroup mountpoints +<>, then you need to mount the host's cgroup mountpoints within the container. They need to be mounted inside the directory specified by the `-system.hostfs` CLI flag. -<3> If you want to be able to monitor filesystems from the host using the -system filesystem metricset then those filesystems need to be mounted inside +<3> If you want to be able to monitor filesystems from the host by using the +<>, then those filesystems need to be mounted inside of the container. They can be mounted at any location. -<4> The system network metricset uses data from `/proc/net/dev`, or -`/hostfs/proc/net/dev` when using `-system.hostfs=/hostfs`, and the only way +<4> The <> uses data from `/proc/net/dev`, or +`/hostfs/proc/net/dev` when using `-system.hostfs=/hostfs`. The only way to make this file contain the host's network devices is to use the `--net=host` -flag. This is due to Linux namespacing, simply bind mounting the host's `/proc` +flag. This is due to Linux namespacing; simply bind mounting the host's `/proc` to `/hostfs/proc` is not sufficient. [float] @@ -63,10 +63,10 @@ sudo docker run \ --- <1> Linking the containers enables Metricbeat access the exposed ports of the -mysql container and it makes the hostname `mysql` resolvable to Metricbeat. +mysql container, and it makes the hostname `mysql` resolvable to Metricbeat. <2> If you do not want to hardcode certain values into your Metricbeat -configuration then you can pass them into the container either as environment -variables or as command line flags to Metricbeat (see the `-E` CLI flag). +configuration, then you can pass them into the container either as environment +variables or as command line flags to Metricbeat (see the `-E` CLI flag in <>). The mysql module configuration would look like this: @@ -81,6 +81,6 @@ metricbeat.modules: --- <1> The `mysql` hostname will resolve to the `some-mysql` container's address. -<2> The `MYSQL_PASSWORD` variable will be evaluated at startup. If a variable -is not set this will lead to an error at startup. +<2> The `MYSQL_PASSWORD` variable will be evaluated at startup. If the variable +is not set, this will lead to an error at startup.