jtuglu1 commented on code in PR #18855: URL: https://github.com/apache/druid/pull/18855#discussion_r2634334601
########## docs/operations/metrics.md: ########## @@ -270,7 +270,7 @@ batch ingestion emit the following metrics. These metrics are deltas for each em |`ingest/events/processed`|Number of events processed per emission period.|`dataSource`, `taskId`, `taskType`, `groupId`, `tags`|Equal to the number of events per emission period.| |`ingest/events/processedWithError`|Number of events processed with some partial errors per emission period. Events processed with partial errors are counted towards both this metric and `ingest/events/processed`.|`dataSource`, `taskId`, `taskType`, `groupId`, `tags`|0| |`ingest/events/unparseable`|Number of events rejected because the events are unparseable.|`dataSource`, `taskId`, `taskType`, `groupId`, `tags`|0| -|`ingest/events/thrownAway`|Number of events rejected because they are null, or filtered by `transformSpec`, or outside one of `lateMessageRejectionPeriod`, `earlyMessageRejectionPeriod`.|`dataSource`, `taskId`, `taskType`, `groupId`, `tags`|0| +|`ingest/events/thrownAway`|Number of events rejected because they are null, or filtered by `transformSpec`, or outside one of `lateMessageRejectionPeriod`, `earlyMessageRejectionPeriod`. The `reason` dimension indicates why the event was thrown away.|`dataSource`, `taskId`, `taskType`, `groupId`, `tags`, `reason`|0| Review Comment: I considered this, but ultimately chose against it in the spirit of https://netflix.github.io/atlas-docs/concepts/naming/#summary. I feel like `description` ends up being a "kitchen sink" string which you need to regex matching on to do any kind of programmatic alerting; I'd actually like to move away from using this excessively. IMO `description` should be used if we're not 100% sure what the value is (e.g. an exception is thrown). In our case, we have a fixed set of possible cases that we can assign proper values. This makes things like building alerts, etc. much easier. Thoughts? -- 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]
