Hi Aleksandr, Thanks for putting this FLIP together. This looks like a great set of practical improvements for the OTel exporter, and I'm supportive of the direction.
I had one clarifying question about the attribute truncation. The proposal mentions logging a warning on collisions during metric registration. I was wondering what the functional behavior would be in that case? For example, if a user's config truncates two different task_name attributes (e.g., task_name.operator-A-long-name and task_name.operator-B-long-name) to the identical string, what happens? 1. Do both metrics get registered and end up reporting under that same, single truncated name (effectively merging their data)? 2. Or, would the registration for the second metric fail? Just wanted to clarify, as the first behavior could be a bit confusing for users trying to debug their jobs. Thanks, Kartikey. On Thu, Oct 16, 2025 at 8:29 PM Aleksandr Iushmanov <[email protected]> wrote: > Hi All, > > I would like to start a discussion about FLIP 553: Robust OTel gRPC metric > exporter [1] > > Existing gRPC metric exporter is not sufficiently configurable to handle > export of jobs with complex job graphs. Complicated jobs often result in > significant request payload size and there could be more flexibility to > control it on the flink side. > > Looking forward to your feedback and suggestions. > > [1] > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-553%3A+Robust+OTel+gRPC+metric+exporter > > Kind regards, > Aleksandr Iushmanov >
