abhishekrb19 commented on code in PR #18103: URL: https://github.com/apache/druid/pull/18103#discussion_r2155346944
########## docs/configuration/index.md: ########## @@ -2031,6 +1893,155 @@ See [cache configuration](#cache-configuration) for how to configure cache setti |`druid.broker.segment.watchRealtimeTasks`|Boolean|The Broker watches segment announcements from processes that serve segments to build a cache to relate each process to the segments it serves. When `watchRealtimeTasks` is true, the Broker watches for segment announcements from both Historicals and realtime processes. To configure a broker to exclude segments served by realtime processes, set `watchRealtimeTasks` to false. |true| |`druid.broker.segment.awaitInitializationOnStart`|Boolean|Whether the Broker will wait for its view of segments to fully initialize before starting up. If set to 'true', the Broker's HTTP server will not start up, and the Broker will not announce itself as available, until the server view is initialized. See also `druid.sql.planner.awaitInitializationOnStart`, a related setting.|true| +## Metrics monitors + +You can configure Druid services to emit [metrics](../operations/metrics.md) regularly from a number of [monitors](#metrics-monitors-for-each-service) via [emitters](#metrics-emitters). The following table lists general configurations for metrics: + +|Property|Description|Default| +|--------|-----------|-------| +|`druid.monitoring.emissionPeriod`| Frequency that Druid emits metrics.|`PT1M`| +|[`druid.monitoring.monitors`](#metrics-monitors-for-each-service)|Sets list of Druid monitors used by a service.|none (no monitors)| +|[`druid.emitter`](#metrics-emitters)|Setting this value initializes one of the emitter modules.|`noop` (metric emission disabled by default)| + +### Metrics monitors for each service + +:::caution + +Because each monitor is meant for a specific service or services, make sure you configure them for the correct service unless it is meant for any service. For example, if a monitor is meant for the Historical service, configure it in `historical/runtime.properties` rather than `_common/common.runtime.properties`. Review Comment: Nice, thanks for adding this! Could we explicitly call out that any monitors added in `common/runtime.properties` will be overridden by service-specific monitor configurations? Given this behavior, I’m wondering if we should even recommend adding monitors to `common/runtime.properties` at all. Since monitors aren’t additive and it’s very likely that users have service-specific monitors defined per cluster, this could lead to monitors not being added. Even for monitors marked as "Any" in the table below, IMO users would still need to add them to each relevant service runtime properties individually for them rather than in `common/runtime.properties`. @kfaraz have you seen any clusters where monitors were actually added via `common/runtime.properties`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
