Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
+1 (non-binding) On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote: > Dear devs, > > I'd like to open a vote on FLIP-179: Expose Standardized Operator Metrics > [1] which was discussed in this thread [2]. > The vote will be open for at least 72 hours unless there is an objection > or not enough votes. > > The proposal excludes the implementation for the currentFetchEventTimeLag > metric, which caused a bit of discussion without a clear convergence. We > will implement that metric in a generic way at a later point and encourage > sources to implement it themselves in the meantime. > > Best, > > Arvid > > [1] > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > [2] > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
+1 (binding). Thanks for driving the efforts, Arvid. Cheers, Jiangjie (Becket) Qin On Sat, Jul 31, 2021 at 12:08 PM Steven Wu wrote: > +1 (non-binding) > > On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote: > > > Dear devs, > > > > I'd like to open a vote on FLIP-179: Expose Standardized Operator Metrics > > [1] which was discussed in this thread [2]. > > The vote will be open for at least 72 hours unless there is an objection > > or not enough votes. > > > > The proposal excludes the implementation for the currentFetchEventTimeLag > > metric, which caused a bit of discussion without a clear convergence. We > > will implement that metric in a generic way at a later point and > encourage > > sources to implement it themselves in the meantime. > > > > Best, > > > > Arvid > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > > [2] > > > > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
+1 (binding) Although I still think all the set* methods should accept a Supplier instead of a Gauge. On 02/08/2021 12:36, Becket Qin wrote: +1 (binding). Thanks for driving the efforts, Arvid. Cheers, Jiangjie (Becket) Qin On Sat, Jul 31, 2021 at 12:08 PM Steven Wu wrote: +1 (non-binding) On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote: Dear devs, I'd like to open a vote on FLIP-179: Expose Standardized Operator Metrics [1] which was discussed in this thread [2]. The vote will be open for at least 72 hours unless there is an objection or not enough votes. The proposal excludes the implementation for the currentFetchEventTimeLag metric, which caused a bit of discussion without a clear convergence. We will implement that metric in a generic way at a later point and encourage sources to implement it themselves in the meantime. Best, Arvid [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics [2] https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
+1 (binding) On Tue, Aug 3, 2021 at 12:58 AM Chesnay Schepler wrote: > +1 (binding) > > Although I still think all the set* methods should accept a Supplier > instead of a Gauge. > > On 02/08/2021 12:36, Becket Qin wrote: > > +1 (binding). > > > > Thanks for driving the efforts, Arvid. > > > > Cheers, > > > > Jiangjie (Becket) Qin > > > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu wrote: > > > >> +1 (non-binding) > >> > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote: > >> > >>> Dear devs, > >>> > >>> I'd like to open a vote on FLIP-179: Expose Standardized Operator > Metrics > >>> [1] which was discussed in this thread [2]. > >>> The vote will be open for at least 72 hours unless there is an > objection > >>> or not enough votes. > >>> > >>> The proposal excludes the implementation for the > currentFetchEventTimeLag > >>> metric, which caused a bit of discussion without a clear convergence. > We > >>> will implement that metric in a generic way at a later point and > >> encourage > >>> sources to implement it themselves in the meantime. > >>> > >>> Best, > >>> > >>> Arvid > >>> > >>> [1] > >>> > >>> > >> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > >>> [2] > >>> > >>> > >> > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
@Becket Qin @Thomas Weise would you also agree to @Chesnay Schepler 's proposal? I think the main intention is to only use a Gauge when the exact metric is exposed. For any partial value that may be used in an internal/predefined metric, we would only use a supplier instead of a Gauge. So a connector developer can immediately distinguish the cases: if it's a metric class he would see the exact metric corresponding to the setter. If it's some Supplier, the developer would expect that the value is used in a differently named metric, which we would describe in the JavaDoc. Could that also be a solution to the currentEventFetchTimeLag metric? On Tue, Aug 3, 2021 at 12:54 PM Thomas Weise wrote: > +1 (binding) > > On Tue, Aug 3, 2021 at 12:58 AM Chesnay Schepler > wrote: > > > +1 (binding) > > > > Although I still think all the set* methods should accept a Supplier > > instead of a Gauge. > > > > On 02/08/2021 12:36, Becket Qin wrote: > > > +1 (binding). > > > > > > Thanks for driving the efforts, Arvid. > > > > > > Cheers, > > > > > > Jiangjie (Becket) Qin > > > > > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu > wrote: > > > > > >> +1 (non-binding) > > >> > > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise wrote: > > >> > > >>> Dear devs, > > >>> > > >>> I'd like to open a vote on FLIP-179: Expose Standardized Operator > > Metrics > > >>> [1] which was discussed in this thread [2]. > > >>> The vote will be open for at least 72 hours unless there is an > > objection > > >>> or not enough votes. > > >>> > > >>> The proposal excludes the implementation for the > > currentFetchEventTimeLag > > >>> metric, which caused a bit of discussion without a clear convergence. > > We > > >>> will implement that metric in a generic way at a later point and > > >> encourage > > >>> sources to implement it themselves in the meantime. > > >>> > > >>> Best, > > >>> > > >>> Arvid > > >>> > > >>> [1] > > >>> > > >>> > > >> > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > > >>> [2] > > >>> > > >>> > > >> > > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > > > > > >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
Personally speaking, it is intuitive for me to set a gauge in MetricGroup. So I am fine with set*Gauge pattern as long as the method is in *MetricGroup class. Thanks, Jiangjie (Becket) Qin On Tue, Aug 3, 2021 at 7:24 PM Arvid Heise wrote: > @Becket Qin @Thomas Weise would > you > also agree to @Chesnay Schepler 's proposal? > > I think the main intention is to only use a Gauge when the exact metric is > exposed. For any partial value that may be used in an internal/predefined > metric, we would only use a supplier instead of a Gauge. > > So a connector developer can immediately distinguish the cases: if it's a > metric class he would see the exact metric corresponding to the setter. If > it's some Supplier, the developer would expect that the value is used in a > differently named metric, which we would describe in the JavaDoc. > Could that also be a solution to the currentEventFetchTimeLag metric? > > On Tue, Aug 3, 2021 at 12:54 PM Thomas Weise wrote: > > > +1 (binding) > > > > On Tue, Aug 3, 2021 at 12:58 AM Chesnay Schepler > > wrote: > > > > > +1 (binding) > > > > > > Although I still think all the set* methods should accept a Supplier > > > instead of a Gauge. > > > > > > On 02/08/2021 12:36, Becket Qin wrote: > > > > +1 (binding). > > > > > > > > Thanks for driving the efforts, Arvid. > > > > > > > > Cheers, > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu > > wrote: > > > > > > > >> +1 (non-binding) > > > >> > > > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise > wrote: > > > >> > > > >>> Dear devs, > > > >>> > > > >>> I'd like to open a vote on FLIP-179: Expose Standardized Operator > > > Metrics > > > >>> [1] which was discussed in this thread [2]. > > > >>> The vote will be open for at least 72 hours unless there is an > > > objection > > > >>> or not enough votes. > > > >>> > > > >>> The proposal excludes the implementation for the > > > currentFetchEventTimeLag > > > >>> metric, which caused a bit of discussion without a clear > convergence. > > > We > > > >>> will implement that metric in a generic way at a later point and > > > >> encourage > > > >>> sources to implement it themselves in the meantime. > > > >>> > > > >>> Best, > > > >>> > > > >>> Arvid > > > >>> > > > >>> [1] > > > >>> > > > >>> > > > >> > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > > > >>> [2] > > > >>> > > > >>> > > > >> > > > > > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > > > > > > > > > > >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
I agree with Becket. Although I find the use of gauge to pass contextual information less intuitive, it is acceptable within the metric group interface (plus javadoc). Thanks, Thomas On Tue, Aug 3, 2021 at 10:06 PM Becket Qin wrote: > Personally speaking, it is intuitive for me to set a gauge in MetricGroup. > So I am fine with set*Gauge pattern as long as the method is in > *MetricGroup class. > > Thanks, > > Jiangjie (Becket) Qin > > On Tue, Aug 3, 2021 at 7:24 PM Arvid Heise wrote: > > > @Becket Qin @Thomas Weise would > > you > > also agree to @Chesnay Schepler 's proposal? > > > > I think the main intention is to only use a Gauge when the exact metric > is > > exposed. For any partial value that may be used in an internal/predefined > > metric, we would only use a supplier instead of a Gauge. > > > > So a connector developer can immediately distinguish the cases: if it's a > > metric class he would see the exact metric corresponding to the setter. > If > > it's some Supplier, the developer would expect that the value is used in > a > > differently named metric, which we would describe in the JavaDoc. > > Could that also be a solution to the currentEventFetchTimeLag metric? > > > > On Tue, Aug 3, 2021 at 12:54 PM Thomas Weise wrote: > > > > > +1 (binding) > > > > > > On Tue, Aug 3, 2021 at 12:58 AM Chesnay Schepler > > > wrote: > > > > > > > +1 (binding) > > > > > > > > Although I still think all the set* methods should accept a Supplier > > > > instead of a Gauge. > > > > > > > > On 02/08/2021 12:36, Becket Qin wrote: > > > > > +1 (binding). > > > > > > > > > > Thanks for driving the efforts, Arvid. > > > > > > > > > > Cheers, > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu > > > wrote: > > > > > > > > > >> +1 (non-binding) > > > > >> > > > > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise > > wrote: > > > > >> > > > > >>> Dear devs, > > > > >>> > > > > >>> I'd like to open a vote on FLIP-179: Expose Standardized Operator > > > > Metrics > > > > >>> [1] which was discussed in this thread [2]. > > > > >>> The vote will be open for at least 72 hours unless there is an > > > > objection > > > > >>> or not enough votes. > > > > >>> > > > > >>> The proposal excludes the implementation for the > > > > currentFetchEventTimeLag > > > > >>> metric, which caused a bit of discussion without a clear > > convergence. > > > > We > > > > >>> will implement that metric in a generic way at a later point and > > > > >> encourage > > > > >>> sources to implement it themselves in the meantime. > > > > >>> > > > > >>> Best, > > > > >>> > > > > >>> Arvid > > > > >>> > > > > >>> [1] > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > > > > >>> [2] > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > > > > > > > > > > > > > > > > >
Re: [VOTE] FLIP-179: Expose Standardized Operator Metrics
I am with Thomas on the contextual usage of metrics as well. That is the "global" variable usage I was trying to explain in the discussion thread. Thanks, Jiangjie (Becket) Qin On Thu, Aug 5, 2021 at 1:59 AM Thomas Weise wrote: > I agree with Becket. Although I find the use of gauge to pass contextual > information less intuitive, it is acceptable within the metric group > interface (plus javadoc). > > Thanks, > Thomas > > On Tue, Aug 3, 2021 at 10:06 PM Becket Qin wrote: > > > Personally speaking, it is intuitive for me to set a gauge in > MetricGroup. > > So I am fine with set*Gauge pattern as long as the method is in > > *MetricGroup class. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Tue, Aug 3, 2021 at 7:24 PM Arvid Heise wrote: > > > > > @Becket Qin @Thomas Weise > would > > > you > > > also agree to @Chesnay Schepler 's proposal? > > > > > > I think the main intention is to only use a Gauge when the exact metric > > is > > > exposed. For any partial value that may be used in an > internal/predefined > > > metric, we would only use a supplier instead of a Gauge. > > > > > > So a connector developer can immediately distinguish the cases: if > it's a > > > metric class he would see the exact metric corresponding to the setter. > > If > > > it's some Supplier, the developer would expect that the value is used > in > > a > > > differently named metric, which we would describe in the JavaDoc. > > > Could that also be a solution to the currentEventFetchTimeLag metric? > > > > > > On Tue, Aug 3, 2021 at 12:54 PM Thomas Weise wrote: > > > > > > > +1 (binding) > > > > > > > > On Tue, Aug 3, 2021 at 12:58 AM Chesnay Schepler > > > > > wrote: > > > > > > > > > +1 (binding) > > > > > > > > > > Although I still think all the set* methods should accept a > Supplier > > > > > instead of a Gauge. > > > > > > > > > > On 02/08/2021 12:36, Becket Qin wrote: > > > > > > +1 (binding). > > > > > > > > > > > > Thanks for driving the efforts, Arvid. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > On Sat, Jul 31, 2021 at 12:08 PM Steven Wu > > > > > wrote: > > > > > > > > > > > >> +1 (non-binding) > > > > > >> > > > > > >> On Fri, Jul 30, 2021 at 3:55 AM Arvid Heise > > > wrote: > > > > > >> > > > > > >>> Dear devs, > > > > > >>> > > > > > >>> I'd like to open a vote on FLIP-179: Expose Standardized > Operator > > > > > Metrics > > > > > >>> [1] which was discussed in this thread [2]. > > > > > >>> The vote will be open for at least 72 hours unless there is an > > > > > objection > > > > > >>> or not enough votes. > > > > > >>> > > > > > >>> The proposal excludes the implementation for the > > > > > currentFetchEventTimeLag > > > > > >>> metric, which caused a bit of discussion without a clear > > > convergence. > > > > > We > > > > > >>> will implement that metric in a generic way at a later point > and > > > > > >> encourage > > > > > >>> sources to implement it themselves in the meantime. > > > > > >>> > > > > > >>> Best, > > > > > >>> > > > > > >>> Arvid > > > > > >>> > > > > > >>> [1] > > > > > >>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-179%3A+Expose+Standardized+Operator+Metrics > > > > > >>> [2] > > > > > >>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/r856920cbfe6a262b521109c5bdb9e904e00a9b3f1825901759c24d85%40%3Cdev.flink.apache.org%3E > > > > > > > > > > > > > > > > > > > > > > > > >
