add defaultMetrics for logging emitter

[sarangv]

Fixes 19021.

Description

LoggingEmitter can restrict which metrics are written to the log. When this behavior is turned on, only ServiceMetricEvent metrics that appear in a configured permitted set are emitted; alerts and other non-metric events are never dropped. When the feature is off, the emitter behaves as before (all events logged).

Runtime properties

• druid.emitter.logging.shouldFilterMetrics (default false): If true, logging is limited to metrics named in the permitted set. If false, every event is logged.
• druid.emitter.logging.allowedMetricsPath (optional): File path for the permitted-metrics definition. Omitted or empty → the in-JAR resource defaultMetrics.json is used. If a path is given but the file does not exist, a warning is logged and the in-JAR resource is used instead (startup continues; operators can spot the warning).

Permitted-metrics file shape

The file must be a JSON object whose keys are metric names; values are placeholders (e.g. []), e.g. {"query/time": [], "query/bytes": []}. This shape matches other emitter default configs (e.g. Prometheus) and leaves room for per-metric metadata later. On invalid content, operators see: "Allowed metrics file must be a JSON object with metric names as keys".

Rationale

• DruidException: Errors use DruidException.forPersona(Persona.OPERATOR) with NOT_FOUND (default resource absent) and RUNTIME_FAILURE (parse/read failure), matching the project’s guidance for operator-facing failures.
• Missing custom file: Rather than failing startup, the code logs a WARN and uses the in-JAR default so a wrong path does not prevent the process from starting; the log still exposes the mistake.
• Object format: A key-value object was chosen over a JSON array so the schema can later carry extra fields per metric without a breaking change.
• Emitters.java: The two new keys are written into the legacy logging map only when the matching property exists, preserving Java defaults and avoiding odd empty-string behavior.
• No set when off: With filtering disabled, allowedMetrics stays null; no extra collection is created. Contains checks stay O(1).

Release note

Operators can limit which metrics the logging emitter writes by setting druid.emitter.logging.shouldFilterMetrics=true and, if desired, druid.emitter.logging.allowedMetricsPath to a JSON object file (keys = metric names). A missing custom file results in a warning and use of the bundled defaultMetrics.json. Alerts and other non-metric events are always logged.

---

Key changed/added classes in this PR

• LoggingEmitter – load permitted set (classpath or file; use default if file missing), apply in emit(), DruidException on bad/missing config
• LoggingEmitterConfig – shouldFilterMetrics, allowedMetricsPath plus Javadoc
• Emitters – map the new keys from legacy properties only when set
• processing/src/main/resources/defaultMetrics.json – in-JAR permitted set (object form)
• processing/src/test/resources/defaultMetrics.json – test resource
• LoggingEmitterTest – seven cases: feature off, default resource, custom file, missing file uses default, non-metrics pass through, empty set, path ignored when off; @After tearDown for close
• LoggingEmitterConfigTest – new config fields covered for defaults and legacy mapping

---

This PR has:

• been self-reviewed.
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[abhishekrb19]

Thanks for the contribution, @sarangv! There's also #19026
from @nozjkoitop, which has a similar implementation. Would you both be open to collaborating on the reviews and aligning on any implementation differences? 🙂

I see this PR has a bit more test coverage and the defaultMetrics file schema is a bit more extensible if we want to add additional dimensions in the future similar to other emitter types.

[abhishekrb19]

If a path is set but the file is missing, a warning is logged and the emitter falls back to the default classpath resource.

IMO, in this case, we should fail fast by throwing an exception instead of falling back in the event of a misconfiguration, since an operator would be intentionally opting in to enable metric filtering and provide a custom path

[nozjkoitop]

Sure thing! I updated #19026 to match the deltas noted here (more test coverage and extensible default-metrics schema). @sarangv could you take a quick look at the updated #19026 and leave any review notes there? I’d prefer we keep review in a single PR to avoid duplicating effort