configuring-metricbeat.asciidoc 6.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
  1. [role="xpack"]
  2. [[configuring-metricbeat]]
  3. == Collecting {es} monitoring data with {metricbeat}
  4. [subs="attributes"]
  5. ++++
  6. <titleabbrev>Collecting monitoring data with {metricbeat}</titleabbrev>
  7. ++++
  8. In 6.5 and later, you can use {metricbeat} to collect data about {es}
  9. and ship it to the monitoring cluster, rather than routing it through exporters
  10. as described in <<collecting-monitoring-data>>.
  11. Want to use {agent} instead? Refer to <<configuring-elastic-agent>>.
  12. image::monitoring/images/metricbeat.png[Example monitoring architecture]
  13. . {metricbeat-ref}/metricbeat-installation-configuration.html[Install
  14. {metricbeat}]. Ideally install a single {metricbeat} instance configured with
  15. `scope: cluster` and configure `hosts` to point to an endpoint (e.g. a
  16. load-balancing proxy) which directs requests to the master-ineligible nodes in
  17. the cluster. If this is not possible then install one {metricbeat} instance for
  18. each {es} node in the production cluster and use the default `scope: node`.
  19. When {metricbeat} is monitoring {es} with `scope: node` then you must install a
  20. {metricbeat} instance for each {es} node. If you don't, some metrics will not
  21. be collected. {metricbeat} with `scope: node` collects most of the metrics from
  22. the elected master of the cluster, so you must scale up all your
  23. master-eligible nodes to account for this extra load and you should not use
  24. this mode if you have dedicated master nodes.
  25. . Enable the {es} module in {metricbeat} on each {es} node.
  26. +
  27. --
  28. For example, to enable the default configuration for the {stack-monitor-features}
  29. in the `modules.d` directory, run the following command:
  30. ["source","sh",subs="attributes,callouts"]
  31. ----------------------------------------------------------------------
  32. metricbeat modules enable elasticsearch-xpack
  33. ----------------------------------------------------------------------
  34. For more information, refer to
  35. {metricbeat-ref}/metricbeat-module-elasticsearch.html[{es} module].
  36. --
  37. . Configure the {es} module in {metricbeat} on each {es} node.
  38. +
  39. --
  40. The `modules.d/elasticsearch-xpack.yml` file contains the following settings:
  41. [source,yaml]
  42. ----------------------------------
  43. - module: elasticsearch
  44. xpack.enabled: true
  45. period: 10s
  46. hosts: ["http://localhost:9200"] <1>
  47. #scope: node <2>
  48. #username: "user"
  49. #password: "secret"
  50. #ssl.enabled: true
  51. #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
  52. #ssl.certificate: "/etc/pki/client/cert.pem"
  53. #ssl.key: "/etc/pki/client/cert.key"
  54. #ssl.verification_mode: "full"
  55. ----------------------------------
  56. <1> By default, the module collects {es} monitoring metrics from
  57. `http://localhost:9200`. If that host and port number are not correct, you must
  58. update the `hosts` setting. If you configured {es} to use encrypted
  59. communications, you must access it via HTTPS. For example, use a `hosts` setting
  60. like `https://localhost:9200`.
  61. <2> By default, `scope` is set to `node` and each entry in the `hosts` list
  62. indicates a distinct node in an {es} cluster. If you set `scope` to `cluster`
  63. then each entry in the `hosts` list indicates a single endpoint for a distinct
  64. {es} cluster (for example, a load-balancing proxy fronting the cluster). You
  65. should use `scope: cluster` if the cluster has dedicated master nodes, and
  66. configure the endpoint in the `hosts` list not to direct requests to the
  67. dedicated master nodes.
  68. If Elastic {security-features} are enabled, you must also provide a user ID
  69. and password so that {metricbeat} can collect metrics successfully:
  70. .. Create a user on the production cluster that has the
  71. <<built-in-roles,`remote_monitoring_collector` built-in role>>.
  72. Alternatively, use the
  73. <<built-in-users,`remote_monitoring_user` built-in user>>.
  74. .. Add the `username` and `password` settings to the {es} module configuration
  75. file.
  76. .. If TLS is enabled on the HTTP layer of your {es} cluster, you must either use https as the URL scheme in the `hosts` setting or add the `ssl.enabled: true` setting. Depending on the TLS configuration of your {es} cluster, you might also need to specify {metricbeat-ref}/configuration-ssl.html[additional ssl.*] settings.
  77. --
  78. . Optional: Disable the system module in {metricbeat}.
  79. +
  80. --
  81. By default, the {metricbeat-ref}/metricbeat-module-system.html[system module] is
  82. enabled. The information it collects, however, is not shown on the *Monitoring*
  83. page in {kib}. Unless you want to use that information for other purposes, run
  84. the following command:
  85. ["source","sh",subs="attributes,callouts"]
  86. ----------------------------------------------------------------------
  87. metricbeat modules disable system
  88. ----------------------------------------------------------------------
  89. --
  90. . Identify where to send the monitoring data.
  91. +
  92. --
  93. TIP: In production environments, we strongly recommend using a separate cluster
  94. (referred to as the _monitoring cluster_) to store the data. Using a separate
  95. monitoring cluster prevents production cluster outages from impacting your
  96. ability to access your monitoring data. It also prevents monitoring activities
  97. from impacting the performance of your production cluster.
  98. For example, specify the {es} output information in the {metricbeat}
  99. configuration file (`metricbeat.yml`):
  100. [source,yaml]
  101. ----------------------------------
  102. output.elasticsearch:
  103. # Array of hosts to connect to.
  104. hosts: ["http://es-mon-1:9200", "http://es-mon-2:9200"] <1>
  105. # Optional protocol and basic auth credentials.
  106. #protocol: "https"
  107. #username: "elastic"
  108. #password: "changeme"
  109. ----------------------------------
  110. <1> In this example, the data is stored on a monitoring cluster with nodes
  111. `es-mon-1` and `es-mon-2`.
  112. If you configured the monitoring cluster to use encrypted communications, you
  113. must access it via HTTPS. For example, use a `hosts` setting like
  114. `https://es-mon-1:9200`.
  115. IMPORTANT: The {es} {monitor-features} use ingest pipelines, therefore the
  116. cluster that stores the monitoring data must have at least one
  117. <<ingest,ingest node>>.
  118. If {es} {security-features} are enabled on the monitoring cluster, you must
  119. provide a valid user ID and password so that {metricbeat} can send metrics
  120. successfully:
  121. .. Create a user on the monitoring cluster that has the
  122. <<built-in-roles,`remote_monitoring_agent` built-in role>>.
  123. Alternatively, use the
  124. <<built-in-users,`remote_monitoring_user` built-in user>>.
  125. .. Add the `username` and `password` settings to the {es} output information in
  126. the {metricbeat} configuration file.
  127. For more information about these configuration options, see
  128. {metricbeat-ref}/elasticsearch-output.html[Configure the {es} output].
  129. --
  130. . {metricbeat-ref}/metricbeat-starting.html[Start {metricbeat}] on each node.
  131. . {kibana-ref}/monitoring-data.html[View the monitoring data in {kib}].