configuring-metricbeat.asciidoc 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190
  1. [role="xpack"]
  2. [testenv="gold"]
  3. [[configuring-metricbeat]]
  4. == Collecting {es} monitoring data with {metricbeat}
  5. [subs="attributes"]
  6. ++++
  7. <titleabbrev>Collecting monitoring data with {metricbeat}</titleabbrev>
  8. ++++
  9. In 6.5 and later, you can use {metricbeat} to collect data about {es}
  10. and ship it to the monitoring cluster, rather than routing it through exporters
  11. as described in <<collecting-monitoring-data>>.
  12. image::monitoring/images/metricbeat.png[Example monitoring architecture]
  13. . Enable the collection of monitoring data.
  14. +
  15. --
  16. // tag::enable-collection[]
  17. Set `xpack.monitoring.collection.enabled` to `true` on the
  18. production cluster. By default, it is is disabled (`false`).
  19. You can use the following APIs to review and change this setting:
  20. [source,console]
  21. ----------------------------------
  22. GET _cluster/settings
  23. PUT _cluster/settings
  24. {
  25. "persistent": {
  26. "xpack.monitoring.collection.enabled": true
  27. }
  28. }
  29. ----------------------------------
  30. If {es} {security-features} are enabled, you must have `monitor` cluster privileges to
  31. view the cluster settings and `manage` cluster privileges to change them.
  32. // end::enable-collection[]
  33. For more information, see <<monitoring-settings>> and <<cluster-update-settings>>.
  34. --
  35. . {metricbeat-ref}/metricbeat-installation-configuration.html[Install {metricbeat}] on each
  36. {es} node in the production cluster.
  37. . Enable the {es} {xpack} module in {metricbeat} on each {es} node.
  38. +
  39. --
  40. For example, to enable the default configuration in the `modules.d` directory,
  41. run the following command:
  42. ["source","sh",subs="attributes,callouts"]
  43. ----------------------------------------------------------------------
  44. metricbeat modules enable elasticsearch-xpack
  45. ----------------------------------------------------------------------
  46. Alternatively, you can use the {es} module, as described in the
  47. {metricbeat-ref}/metricbeat-module-elasticsearch.html[{es} module usage for {stack} monitoring].
  48. --
  49. . Configure the {es} {xpack} module in {metricbeat} on each {es} node.
  50. +
  51. --
  52. The `modules.d/elasticsearch-xpack.yml` file contains the following settings:
  53. [source,yaml]
  54. ----------------------------------
  55. - module: elasticsearch
  56. xpack.enabled: true
  57. period: 10s
  58. hosts: ["http://localhost:9200"] <1>
  59. #scope: node <2>
  60. #username: "user"
  61. #password: "secret"
  62. ----------------------------------
  63. <1> By default, the module collects {es} monitoring metrics from
  64. `http://localhost:9200`. If that host and port number are not correct, you must
  65. update the `hosts` setting. If you configured {es} to use encrypted
  66. communications, you must access it via HTTPS. For example, use a `hosts` setting
  67. like `https://localhost:9200`.
  68. <2> By default, `scope` is set to `node` and each entry in the `hosts` list
  69. indicates a distinct node in an {es} cluster. If you set `scope` to `cluster`,
  70. each entry in the `hosts` list indicates a single endpoint for a distinct {es}
  71. cluster (for example, a load-balancing proxy fronting the cluster).
  72. If Elastic {security-features} are enabled, you must also provide a user ID
  73. and password so that {metricbeat} can collect metrics successfully:
  74. .. Create a user on the production cluster that has the
  75. <<built-in-roles,`remote_monitoring_collector` built-in role>>.
  76. Alternatively, use the
  77. <<built-in-users,`remote_monitoring_user` built-in user>>.
  78. .. Add the `username` and `password` settings to the {es} module configuration
  79. file.
  80. --
  81. . Optional: Disable the system module in {metricbeat}.
  82. +
  83. --
  84. By default, the {metricbeat-ref}/metricbeat-module-system.html[system module] is
  85. enabled. The information it collects, however, is not shown on the *Monitoring*
  86. page in {kib}. Unless you want to use that information for other purposes, run
  87. the following command:
  88. ["source","sh",subs="attributes,callouts"]
  89. ----------------------------------------------------------------------
  90. metricbeat modules disable system
  91. ----------------------------------------------------------------------
  92. --
  93. . Identify where to send the monitoring data.
  94. +
  95. --
  96. TIP: In production environments, we strongly recommend using a separate cluster
  97. (referred to as the _monitoring cluster_) to store the data. Using a separate
  98. monitoring cluster prevents production cluster outages from impacting your
  99. ability to access your monitoring data. It also prevents monitoring activities
  100. from impacting the performance of your production cluster.
  101. For example, specify the {es} output information in the {metricbeat}
  102. configuration file (`metricbeat.yml`):
  103. [source,yaml]
  104. ----------------------------------
  105. output.elasticsearch:
  106. # Array of hosts to connect to.
  107. hosts: ["http://es-mon-1:9200", "http://es-mon2:9200"] <1>
  108. # Optional protocol and basic auth credentials.
  109. #protocol: "https"
  110. #username: "elastic"
  111. #password: "changeme"
  112. ----------------------------------
  113. <1> In this example, the data is stored on a monitoring cluster with nodes
  114. `es-mon-1` and `es-mon-2`.
  115. If you configured the monitoring cluster to use encrypted communications, you
  116. must access it via HTTPS. For example, use a `hosts` setting like
  117. `https://es-mon-1:9200`.
  118. IMPORTANT: The {es} {monitor-features} use ingest pipelines, therefore the
  119. cluster that stores the monitoring data must have at least one
  120. <<ingest,ingest node>>.
  121. If {es} {security-features} are enabled on the monitoring cluster, you must
  122. provide a valid user ID and password so that {metricbeat} can send metrics
  123. successfully:
  124. .. Create a user on the monitoring cluster that has the
  125. <<built-in-roles,`remote_monitoring_agent` built-in role>>.
  126. Alternatively, use the
  127. <<built-in-users,`remote_monitoring_user` built-in user>>.
  128. .. Add the `username` and `password` settings to the {es} output information in
  129. the {metricbeat} configuration file.
  130. For more information about these configuration options, see
  131. {metricbeat-ref}/elasticsearch-output.html[Configure the {es} output].
  132. --
  133. . {metricbeat-ref}/metricbeat-starting.html[Start {metricbeat}] on each node.
  134. . Disable the default collection of {es} monitoring metrics.
  135. +
  136. --
  137. Set `xpack.monitoring.elasticsearch.collection.enabled` to `false` on the
  138. production cluster.
  139. You can use the following API to change this setting:
  140. [source,console]
  141. ----------------------------------
  142. PUT _cluster/settings
  143. {
  144. "persistent": {
  145. "xpack.monitoring.elasticsearch.collection.enabled": false
  146. }
  147. }
  148. ----------------------------------
  149. If {es} {security-features} are enabled, you must have `monitor` cluster
  150. privileges to view the cluster settings and `manage` cluster privileges
  151. to change them.
  152. --
  153. . {kibana-ref}/monitoring-data.html[View the monitoring data in {kib}].