Minor doc updates. (#14409)

Co-authored-by: Victoria Lim <vtlim@users.noreply.github.com>

docs/configuration/index.md

@@ -855,7 +855,7 @@ These Coordinator static configurations can be defined in the `coordinator/runti
 |`druid.coordinator.kill.period`|How often to send kill tasks to the indexing service. Value must be greater than `druid.coordinator.period.indexingPeriod`. Only applies if kill is turned on.|P1D (1 Day)|
 |`druid.coordinator.kill.durationToRetain`|Only applies if you set `druid.coordinator.kill.on` to `true`. This value is ignored if `druid.coordinator.kill.ignoreDurationToRetain` is `true`. Valid configurations must be a ISO8601 period. Druid will not kill unused segments whose interval end date is beyond `now - durationToRetain`. `durationToRetain` can be a negative ISO8601 period, which would result in `now - durationToRetain` to be in the future.<br /><br />Note that the `durationToRetain` parameter applies to the segment interval, not the time that the segment was last marked unused. For example, if `durationToRetain` is set to `P90D`, then a segment for a time chunk 90 days in the past is eligible for permanent deletion immediately after being marked unused.|`P90D`|
 |`druid.coordinator.kill.ignoreDurationToRetain`|A way to override `druid.coordinator.kill.durationToRetain` and tell the coordinator that you do not care about the end date of unused segment intervals when it comes to killing them. If true, the coordinator considers all unused segments as eligible to be killed.|false|
-|`druid.coordinator.kill.maxSegments`|Kill at most n unused segments per kill task submission, must be greater than 0. Only applies and MUST be specified if kill is turned on.|100|
+|`druid.coordinator.kill.maxSegments`|The number of unused segments to kill per kill task. This number must be greater than 0. This only applies when `druid.coordinator.kill.on=true`.|100|
 |`druid.coordinator.balancer.strategy`|Specify the type of balancing strategy for the coordinator to use to distribute segments among the historicals. `cachingCost` is logically equivalent to `cost` but is more CPU-efficient on large clusters. `diskNormalized` weights the costs according to the servers' disk usage ratios - there are known issues with this strategy distributing segments unevenly across the cluster. `random` distributes segments among services randomly.|`cost`|
 |`druid.coordinator.balancer.cachingCost.awaitInitialization`|Whether to wait for segment view initialization before creating the `cachingCost` balancing strategy. This property is enabled only when `druid.coordinator.balancer.strategy` is `cachingCost`. If set to 'true', the Coordinator will not start to assign segments, until the segment view is initialized. If set to 'false', the Coordinator will fallback to use the `cost` balancing strategy only if the segment view is not initialized yet. Notes, it may take much time to wait for the initialization since the `cachingCost` balancing strategy involves much computing to build itself.|false|
 |`druid.coordinator.loadqueuepeon.repeatDelay`|The start and repeat delay for the loadqueuepeon, which manages the load and drop of segments.|PT0.050S (50 ms)|

docs/operations/clean-metadata-store.md

@@ -163,7 +163,7 @@ For more detail, see [Task logging](../configuration/index.md#task-logging).
 Druid automatically cleans up metadata records, excluding compaction configuration records and indexer task logs.
 To disable automated metadata cleanup, set the following properties in the `coordinator/runtime.properties` file:
 
-```
+```properties
 # Keep unused segments
 druid.coordinator.kill.on=false
 
@@ -185,7 +185,7 @@ druid.coordinator.kill.datasource.on=false
 
 Consider a scenario where you have scripts to create and delete hundreds of datasources and related entities a day. You do not want to fill your metadata store with leftover records. The datasources and related entities tend to persist for only one or two days. Therefore, you want to run a cleanup job that identifies and removes leftover records that are at least four days old. The exception is for audit logs, which you need to retain for 30 days:
 
-```
+```properties
 ...
 # Schedule the metadata management store task for every hour:
 druid.coordinator.period.metadataStoreManagementPeriod=P1H
@@ -197,7 +197,7 @@ druid.coordinator.period.metadataStoreManagementPeriod=P1H
 # Required also for automated cleanup of rules and compaction configuration.
 
 druid.coordinator.kill.on=true
-druid.coordinator.kill.period=P1D 
+druid.coordinator.kill.period=P1D
 druid.coordinator.kill.durationToRetain=P4D
 druid.coordinator.kill.maxSegments=1000
 

docs/operations/rule-configuration.md

@@ -195,7 +195,7 @@ Forever drop rules have type `dropForever`:
 
 ```json
 {
-  "type": "dropForever",
+  "type": "dropForever"
 }
 ```
 
@@ -209,7 +209,7 @@ Period drop rules have type `dropByPeriod` and the following JSON structure:
 {
   "type": "dropByPeriod",
   "period": "P1M",
-  "includeFuture": true,
+  "includeFuture": true
 }
 ```
 
@@ -271,7 +271,7 @@ Forever broadcast rules have type `broadcastForever`:
 
 ```json
 {
-  "type": "broadcastForever",
+  "type": "broadcastForever"
 }
 ```
 
@@ -285,7 +285,7 @@ Period broadcast rules have type `broadcastByPeriod` and the following JSON stru
 {
   "type": "broadcastByPeriod",
   "period": "P1M",
-  "includeFuture": true,
+  "includeFuture": true
 }
 ```
 

extensions-contrib/opentelemetry-emitter/README.md

@@ -39,7 +39,7 @@ To enable the OpenTelemetry emitter, add the extension and enable the emitter in
 
 Load the plugin:
 
-```
+```properties
 druid.extensions.loadList=[..., "opentelemetry-emitter"]
 ```
 
@@ -47,13 +47,13 @@ Then there are 2 options:
 
 * You want to use only `opentelemetry-emitter`
 
-```
+```properties
 druid.emitter=opentelemetry
 ```
 
 * You want to use `opentelemetry-emitter` with other emitters
 
-```
+```properties
 druid.emitter=composing
 druid.emitter.composing.emitters=[..., "opentelemetry"]
 ```
@@ -66,7 +66,7 @@ _*More about Druid configuration [here](https://druid.apache.org/docs/latest/con
 
 Create `docker-compose.yaml` in your working dir:
 
-```
+```yaml
 version: "2"
 services:
 
@@ -86,7 +86,7 @@ services:
 
 Create `config.yaml` file with configuration for otel-collector:
 
-```
+```yaml
 version: "2"
 receivers:
 receivers:
@@ -116,7 +116,7 @@ service:
 
 Run otel-collector and zipkin.
 
-```
+```bash
 docker-compose up
 ```
 
@@ -124,7 +124,7 @@ docker-compose up
 
 Build Druid:
 
-```
+```bash
 mvn clean install -Pdist
 tar -C /tmp -xf distribution/target/apache-druid-0.21.0-bin.tar.gz
 cd /tmp/apache-druid-0.21.0
@@ -148,7 +148,7 @@ Load sample data - [example](https://druid.apache.org/docs/latest/tutorials/inde
 
 Create `query.json`:
 
-```
+```json
 {
    "query":"SELECT COUNT(*) as total FROM wiki WHERE countryName IS NOT NULL",
    "context":{
@@ -159,7 +159,7 @@ Create `query.json`:
 
 Send query:
 
-```
+```bash
 curl -XPOST -H'Content-Type: application/json' http://localhost:8888/druid/v2/sql/ -d @query.json
 ```
 

integration-tests/README.md

@@ -315,7 +315,7 @@ To run tests on any druid cluster that is already running, create a configuratio
     }
 
 Set the environment variable `CONFIG_FILE` to the name of the configuration file:
-```
+```bash
 export CONFIG_FILE=<config file name>
 ```