This article is a continuation of the article " Beats: Installing and Configuring Metricbeat (1) - 8.x ". You can read the previous article before continuing to read this article. We continue our previous discussion in this article.

Use fingerprint instead of certificate

In actual use, we need to copy the certificate from the Elasticsearch installation directory to configure metricbeat. This sometimes feels inconvenient. Instead, we can directly use fingerprint to configure the metricbeat certificate. We can refer to the article " Beats: Using fingerprint to connect Beats/Logstash and Elasticsearch ". We modify metricbeat.yml as follows:

/etc/metricbeat/metricbeat.yml

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.0.3:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  #api_key: "id:api_key"
  username: "${ES_USER}"
  password: "${ES_PASSWORD}"
  # ssl.certificate_authorities: ["/etc/metricbeat/http_ca.crt"]
  ssl.ca_trusted_fingerprint: "633bf7f6e4bf264e6a05d488af3c686b858fa63592dc83999a0d77f7e9fe5940"

Above, we use the ssl.ca_trusted_fingerprint configuration instead of the ssl.certificate_authorities configuration. Obviously this is more convenient, because we don't need to copy the certificate, and the configuration does not need to contain the certificate path.

After modifying the above configuration, we re-run the following command to test whether the output has been successful:

metricbeat test output

oot@ubuntu2004:/etc/metricbeat# metricbeat test output
elasticsearch: https://192.168.0.3:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.0.3
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.9.0

From the output, it is possible that our certificate configuration is successful.

Use API key instead of username and password

In many cases, we don't want to use the elastic superuser to configure Beats. We can use API key for configuration. The advantage of using API is that it can define the usage time limit of API key, such as 1 month. Of course it can also define corresponding permissions. Below we show how to create an API key:

We copy the API key above and configure it in metricbeat.yml:

/etc/metricbeat/metricbeat.yml

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.0.3:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  #api_key: "id:api_key"
  # username: "${ES_USER}"
  # password: "${ES_PASSWORD}"
  api_key: sFizXYoBxPLM4LwrKywe:NMOjRbUvT7ykunWDsVG4uQ
 
  # ssl.certificate_authorities: ["/etc/metricbeat/http_ca.crt"]
  ssl.ca_trusted_fingerprint: "633bf7f6e4bf264e6a05d488af3c686b858fa63592dc83999a0d77f7e9fe5940"

Above, we use api_key instead of username/password configuration. We use the following command to test whether the configuration is successful:

metricbeat test output

root@ubuntu2004:/etc/metricbeat# metricbeat test output
elasticsearch: https://192.168.0.3:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.0.3
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.9.0

The above shows that our configuration was successful.

Create a new user and use the new user information for configuration

Above, we have explained that using the elastic super user is a very bad habit, because once the information of the elastic super user is leaked, it may cause disastrous consequences. In actual use, we try to avoid using the super user elastic. We can refer to the previous article " Beats: Best Practices " to create a user for Beats data collection. This user has fewer privileges. Even a leak may not cause particularly large losses. For more information, please refer to the official document Grant privileges and roles needed for publishing | Filebeat Reference [8.9] | Elastic

We refer to the previous article " Elasticsearch: User Security Settings " to create users and roles.

We next create the user:

As shown above, I created a user called user, and its password is password.

Next, we use the following command to create an API key belonging to the mertic user:

POST _security/api_key/grant
{
  "grant_type": "password",
  "username": "metric",
  "password": "password",
  "api_key": {
    "name": "mertic"
  }
}

We can use the following methods to configure Metricbeat:

api_key: "id:api_key"

/etc/metricbeat/metricbeat.yml

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.0.3:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  api_key: "s1jWXYoBxPLM4LwrZSzu:rL-6POdnQDSAjWWHao9Ybw"
  # username: "${ES_USER}"
  # password: "${ES_PASSWORD}"
 
  # ssl.certificate_authorities: ["/etc/metricbeat/http_ca.crt"]
  ssl.ca_trusted_fingerprint: "633bf7f6e4bf264e6a05d488af3c686b858fa63592dc83999a0d77f7e9fe5940"

After the configuration is complete, we perform the following tests:

metricbeat test output

root@ubuntu2004:/etc/metricbeat# metricbeat test output
elasticsearch: https://192.168.0.3:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.0.3
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.9.0

Obviously our configuration was successful. We can use the keystore described in the previous article " Beats: Install and configure Metricbeat (1) - 8.x " to save this information.

/etc/mertricbeat/metrcibeat.yml

# ---------------------------- Elasticsearch Output ----------------------------
output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.0.3:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  api_key: "${ES_API_KEY}"
  # username: "${ES_USER}"
  # password: "${ES_PASSWORD}"

  # ssl.certificate_authorities: ["/etc/metricbeat/http_ca.crt"]
  ssl.ca_trusted_fingerprint: "633bf7f6e4bf264e6a05d488af3c686b858fa63592dc83999a0d77f7e9fe5940"

metricbeat keystore add ES_API_KEY

root@ubuntu2004:/etc/metricbeat# metricbeat keystore add ES_API_KEY
Enter value for ES_API_KEY: 
Successfully updated the keystore

Above, we use s1jWXYoBxPLM4LwrZSzu:rL-6POdnQDSAjWWHao9Ybw as input. It is the combination of id:api_key. We run the following command again to check whether the configuration is successful:

root@ubuntu2004:/etc/metricbeat# metricbeat test output
elasticsearch: https://192.168.0.3:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.0.3
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 8.9.0

Of course, for some users who like to use username and password to configure instead of API key, you can also use the following configuration:

/etc/metricbeat/metricbeat.yml

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.0.3:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  # api_key: "${ES_API_KEY}"
  username: "metric"
  password: "password"

  # ssl.certificate_authorities: ["/etc/metricbeat/http_ca.crt"]
  ssl.ca_trusted_fingerprint: "633bf7f6e4bf264e6a05d488af3c686b858fa63592dc83999a0d77f7e9fe5940"

In this way, we have completed the display of this part. In the next article, I will introduce how to use Alerts to notify Metricbeat.

Beats: Install and configure Metricbeat (2) - 8.x

Use fingerprint instead of certificate

Use API key instead of username and password

Create a new user and use the new user information for configuration

Guess you like