Ok, can  you open the issue to store the input parameters or do you want me
to open it?

On Tue, Apr 23, 2024 at 1:22 PM Enrique Gonzalez Martinez <
elguard...@gmail.com> wrote:

> Wdym ? The component is working. The inputs are not being stored yet but
> want to keep certain things yet because it is not clear the extra data of a
> node
>
> El mar, 23 abr 2024, 13:20, Francisco Javier Tirado Sarti <
> ftira...@redhat.com> escribió:
>
> > Yes, I agree. which is the status of the audit component?
> >
> > On Tue, Apr 23, 2024 at 1:18 PM Enrique Gonzalez Martinez <
> > egonza...@apache.org> wrote:
> >
> > > Mining data audit from my point of view. We have extra data for nodes.
> We
> > > can include those inputs if needed
> > >
> > > El mar, 23 abr 2024, 13:11, Francisco Javier Tirado Sarti <
> > > ftira...@redhat.com> escribió:
> > >
> > > > And now a pretty questionable metric that was requested and that  I
> > feel
> > > it
> > > > belongs to the audit domain, but let's discuss it ;)
> > > > There is a user that wants to know the number of times a certain
> > > parameter
> > > > has been passed with a certain value to a workflow type (a process
> id).
> > > > Since we do not really have the concept of parameter as is (it is
> just
> > a
> > > > field in a POJO for BPMN and a propert in a JSON for SWF), I was
> > thinking
> > > > on providing a custom module to cope with that request to not change
> > the
> > > > default ones, but maybe we can think of a way to adding that metric
> in
> > a
> > > > general way.
> > > > One idea might be to add a counter with three tags (process-id,
> > parameter
> > > > name and parameter value). The issue here is what we understood as a
> > > > parameter.
> > > > Any idea is welcome (even to rule out the possibility and defer to
> > custom
> > > > metrics extensions)
> > > >
> > > >
> > > > On Tue, Apr 23, 2024 at 12:59 PM Francisco Javier Tirado Sarti <
> > > > ftira...@redhat.com> wrote:
> > > >
> > > > > Yes, I was thinking something like that.
> > > > > In the parser, add a metadata key ("Metric"?) to the node you want
> to
> > > > > record duration for.
> > > > > In the monitoring addon, check for that metadata key and if there,
> > add
> > > > the
> > > > > duration of that node to the metric.
> > > > >
> > > > > On Tue, Apr 23, 2024 at 12:54 PM Enrique Gonzalez Martinez <
> > > > > egonza...@apache.org> wrote:
> > > > >
> > > > >> I would say is not bad idea but I would restrict per node. Usually
> > you
> > > > >> dont
> > > > >> want to store information about a script or a transformation....
> > > Maybe a
> > > > >> rest call or a service to keep taps on them. I would something
> like.
> > > > >>
> > > > >> Metadata on the node for signaling you want to meassure time
> > > > >> Metrics per process id - node maybe min, max, average ?
> > > > >>
> > > > >> Wdyt ?
> > > > >>
> > > > >>
> > > > >> El mar, 23 abr 2024, 11:17, Francisco Javier Tirado Sarti <
> > > > >> ftira...@redhat.com> escribió:
> > > > >>
> > > > >> > Hi Enrique, I was wondering if we should go further (using a
> > > different
> > > > >> > issue) and add an additional DistributionSummary  "
> > > > >> > kogito_node_instance_duration_seconds" to track node execution
> > > > duration,
> > > > >> > similar  to already existing
> > > > "kogito_process_instance_duration_seconds"
> > > > >> and
> > > > >> > "kogito_work_item_duration_seconds", wdyt?
> > > > >> > I think such a summary should only be enabled explicitly through
> > > > >> > configuration, because the number of records is potentially too
> > > high.
> > > > >> >
> > > > >> > On Mon, Apr 22, 2024 at 4:47 PM Enrique Gonzalez Martinez <
> > > > >> > egonza...@apache.org> wrote:
> > > > >> >
> > > > >> > > The proposal is sensible as it will fit more what the user has
> > in
> > > > the
> > > > >> > > data index/audit... so we won't have problems regarding data
> > that
> > > > does
> > > > >> > > not fit among sources.
> > > > >> > > +1 to me.
> > > > >> > >
> > > > >> > > One of the things that we should be aware of is related to
> > > > >> > > clustering... one process can start in one node.... and can be
> > > > >> > > completed in other. This should be kept in mind.
> > > > >> > >
> > > > >> > > El lun, 22 abr 2024 a las 14:56, Francisco Javier Tirado Sarti
> > > > >> > > (<ftira...@redhat.com>) escribió:
> > > > >> > > >
> > > > >> > > > While implementing the proposal, I faced an issue that
> forced
> > me
> > > > to
> > > > >> > amend
> > > > >> > > > it
> https://github.com/apache/incubator-kie-issues/issues/1101
> > > to
> > > > >> keep
> > > > >> > it
> > > > >> > > > aligned with the existing monitoring collection approach.
> > > > >> > > >
> > > > >> > > > On Mon, Apr 22, 2024 at 9:53 AM Fabrizio Antonangeli <
> > > > >> > > > fantonang...@apache.org> wrote:
> > > > >> > > >
> > > > >> > > > > +1
> > > > >> > > > >
> > > > >> > > > > On Fri, Apr 19, 2024 at 8:46 PM ricardo zanini fernandes <
> > > > >> > > > > ricardozan...@gmail.com> wrote:
> > > > >> > > > >
> > > > >> > > > > > +1
> > > > >> > > > > >
> > > > >> > > > > > On Fri, Apr 19, 2024 at 2:56 PM Pere Fernandez <
> > > > >> > > pere.fernan...@gmail.com
> > > > >> > > > > >
> > > > >> > > > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > +1
> > > > >> > > > > > >
> > > > >> > > > > > > El dv., 19 d’abr. 2024, 18:06, Francisco Javier Tirado
> > > > Sarti <
> > > > >> > > > > > > ftira...@redhat.com> va escriure:
> > > > >> > > > > > >
> > > > >> > > > > > > > Hi all,
> > > > >> > > > > > > > Let me know if there is any problem with the
> proposal
> > in
> > > > >> this
> > > > >> > > issue
> > > > >> > > > > > > > <
> > > > https://github.com/apache/incubator-kie-issues/issues/1101
> > > > >> >
> > > > >> > > > > > > description.
> > > > >> > > > > > > > Thanks
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > >
> > > > >> > >
> > > > ---------------------------------------------------------------------
> > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org
> > > > >> > > For additional commands, e-mail: dev-h...@kie.apache.org
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Reply via email to