http-export.asciidoc 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106
  1. [role="xpack"]
  2. [testenv="basic"]
  3. [[http-exporter]]
  4. === HTTP exporters
  5. [IMPORTANT]
  6. =========================
  7. {metricbeat} is the recommended method for collecting and shipping monitoring
  8. data to a monitoring cluster.
  9. If you have previously configured internal collection, you should migrate to
  10. using {metricbeat} collection. Use either {metricbeat} collection or
  11. internal collection; do not use both.
  12. Learn more about <<configuring-metricbeat>>.
  13. =========================
  14. The `http` exporter is the preferred exporter in the {es} {monitor-features}
  15. because it enables the use of a separate monitoring cluster. As a secondary
  16. benefit, it avoids using a production cluster node as a coordinating node for
  17. indexing monitoring data because all requests are HTTP requests to the
  18. monitoring cluster.
  19. The `http` exporter uses the low-level {es} REST Client, which enables it to
  20. send its data to any {es} cluster it can access through the network. Its requests
  21. make use of the <<common-options-response-filtering,`filter_path`>> parameter to
  22. reduce bandwidth whenever possible, which helps to ensure that communications
  23. between the production and monitoring clusters are as lightweight as possible.
  24. The `http` exporter supports a number of settings that control how it
  25. communicates over HTTP to remote clusters. In most cases, it is not
  26. necessary to explicitly configure these settings. For detailed
  27. descriptions, see <<monitoring-settings>>.
  28. [source,yaml]
  29. ----------------------------------
  30. xpack.monitoring.exporters:
  31. my_local: <1>
  32. type: local
  33. my_remote: <2>
  34. type: http
  35. host: [ "10.1.2.3:9200", ... ] <3>
  36. auth: <4>
  37. username: my_username
  38. # "xpack.monitoring.exporters.my_remote.auth.secure_password" must be set in the keystore
  39. connection:
  40. timeout: 6s
  41. read_timeout: 60s
  42. ssl: ... <5>
  43. proxy:
  44. base_path: /some/base/path <6>
  45. headers: <7>
  46. My-Proxy-Header: abc123
  47. My-Other-Thing: [ def456, ... ]
  48. index.name.time_format: YYYY-MM <8>
  49. ----------------------------------
  50. <1> A `local` exporter defined explicitly whose arbitrary name is `my_local`.
  51. <2> An `http` exporter defined whose arbitrary name is `my_remote`. This name
  52. uniquely defines the exporter but is otherwise unused.
  53. <3> `host` is a required setting for `http` exporters. It must specify the HTTP
  54. port rather than the transport port. The default port value is `9200`.
  55. <4> User authentication for those using {stack} {security-features} or some other
  56. form of user authentication protecting the cluster.
  57. <5> See <<http-exporter-settings>> for all TLS/SSL settings. If not supplied,
  58. the default node-level TLS/SSL settings are used.
  59. <6> Optional base path to prefix any outgoing request with in order to
  60. work with proxies.
  61. <7> Arbitrary key/value pairs to define as headers to send with every request.
  62. The array-based key/value format sends one header per value.
  63. <8> A mechanism for changing the date suffix used by default.
  64. NOTE: The `http` exporter accepts an array of `hosts` and it will round robin
  65. through the list. It is a good idea to take advantage of that feature when the
  66. monitoring cluster contains more than one node.
  67. Unlike the `local` exporter, _every_ node that uses the `http` exporter attempts
  68. to check and create the resources that it needs. The `http` exporter avoids
  69. re-checking the resources unless something triggers it to perform the checks
  70. again. These triggers include:
  71. * The production cluster's node restarts.
  72. * A connection failure to the monitoring cluster.
  73. * The license on the production cluster changes.
  74. * The `http` exporter is dynamically updated (and it is therefore replaced).
  75. The easiest way to trigger a check is to disable, then re-enable the exporter.
  76. WARNING: This resource management behavior can create a hole for users that
  77. delete monitoring resources. Since the `http` exporter does not re-check its
  78. resources unless one of the triggers occurs, this can result in malformed index
  79. mappings.
  80. Unlike the `local` exporter, the `http` exporter is inherently routing requests
  81. outside of the cluster. This situation means that the exporter must provide a
  82. username and password when the monitoring cluster requires one (or other
  83. appropriate security configurations, such as TLS/SSL settings).
  84. IMPORTANT: When discussing security relative to the `http` exporter, it is
  85. critical to remember that all users are managed on the monitoring cluster. This
  86. is particularly important to remember when you move from development
  87. environments to production environments, where you often have dedicated
  88. monitoring clusters.
  89. For more information about the configuration options for the `http` exporter,
  90. see <<http-exporter-settings>>.