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 < [email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 < >> > [email protected]> 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 >> > > (<[email protected]>) 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 < >> > > > [email protected]> wrote: >> > > > >> > > > > +1 >> > > > > >> > > > > On Fri, Apr 19, 2024 at 8:46 PM ricardo zanini fernandes < >> > > > > [email protected]> wrote: >> > > > > >> > > > > > +1 >> > > > > > >> > > > > > On Fri, Apr 19, 2024 at 2:56 PM Pere Fernandez < >> > > [email protected] >> > > > > > >> > > > > > wrote: >> > > > > > >> > > > > > > +1 >> > > > > > > >> > > > > > > El dv., 19 d’abr. 2024, 18:06, Francisco Javier Tirado Sarti < >> > > > > > > [email protected]> 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: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > > >> > >> >
