kfaraz commented on PR #14453: URL: https://github.com/apache/druid/pull/14453#issuecomment-1600004733
> In general, what is the pattern of naming metrics in druid? We don't really have any guidelines in place yet. But if you look at [the docs](https://druid.apache.org/docs/latest/operations/metrics.html), metrics typically fall into one of these buckets: - `segment/` : related to segment data or metadata, something that can be tracked at the segment level - `task/`: task management - `ingest/`: ingestion stats, row counts, etc - `query/`: query execution - `sys/`, `jvm/`, `jetty/`: non-Druid system-related metrics There are some which could have probably been fit into the above, so I wouldn't advocate them. But these are: - `interval/`, `compact/`: these are all compaction metrics and could have been under `ingest/` - `taskSlot/`, `worker/`, `compactTask/`: could have been grouped into `task/` - `tier/`: probably better named as `cluster/` The service name need not be a part of the metric (i.e. `broker/` prefix is not required) as the `service` dimension is already emitted with all metrics. (The only metric with service name is `coordinator/time` and it is an ambiguous name at best). I suggested `segment/metadatacache/` because it relates to _segment_ metadata, and because we already allude to `SegmentMetadataCache` class as `metadatacache` in another metric (`init/metadatacache/time`). --- The above are my opinions to reduce complexity for a user. You can choose some other nomenclature if you can reason about it. -- 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]
