[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Metrics for processing command responses
|
On Mon, 2018-12-10 at 09:09 +0100, Jens Reimann wrote:
> Why not always name it "hono.messages.processed" and then:
>
> * either tag both request and response with "type=command" and
> "command=request"/"command="response"
> * or tag with "type=request", "type=response"
>
what about using tags
type = command
type = command-response
> That would make more sense to me than to create new metrics.
>
> On Fri, Dec 7, 2018 at 5:01 PM Kalidass Kartheeswaran (INST/ECS4) <
> Kartheeswaran.Kalidass@xxxxxxxxxxxx> wrote:
> > Hi Kai,
> >
> > Thank you for the response. I tried to group based on the direction of the
> > messages (downstream/upstream). If it has been already deliberately decided
> > to group based on request/response, which is another logical way of grouping,
> > then it makes sense to me to track command request messages with metric
> > "hono.messages.processed" with type "command". Also the payload size can be
> > tracked using "hono.messages.processed.payload", which is not available
> > currently for commands. The existing separate metric could be used to track
> > command responses. The naming of "hono.commands.response.delivered" doesn't
> > seem to be in consistence with that of requests. IMHO something like
> > "hono.responses.processed" with type "command" seems be more consistent. And
> > so the command responses payload with "hono.responses.processed.payload".
> >
> > Best regards,
> > Kartheeswaran Kalidass
> >
> >
> >
> > -----Original Message-----
> > From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf
> > Of Hudalla Kai (INST/ECS4)
> > Sent: Freitag, 7. Dezember 2018 10:43
> > To: hono-dev@xxxxxxxxxxx
> > Subject: Re: [hono-dev] Metrics for processing command responses
> >
> > On Thu, 2018-12-06 at 14:21 +0000, Kalidass Kartheeswaran (INST/ECS4) wrote:
> > > Dear Hono community,
> > >
> > > Currently I work on the implementation of metrics for the AMQP adapter
> > > and thanks Kai for bringing to notice about the metric
> > > "hono.commands.response.delivered". This metric is currently being
> > > used only to track the number of command responses processed by the
> > > protocol adapters. There is an already existing metric
> > > "hono.messages.processed", which tracks the number of successfully
> > > processed messages by the protocol adapters. The telemetry messages
> > > are tracked with type as "telemetry" and so the events. This metric
> > > "hono.messages.processed" with type "command" is better suited also to
> > track the number of command responses.
> >
> > I am not sure if hono.messages.processed would actually be better suited in
> > this case. For telemetry and events we are using the metric for request
> > messages, not reponses. Using it for keeping track of command responses seems
> > a little odd. I know that from a technical perspective it seems similar
> > because all three (telemetry, event, command response) are sent from the
> > device to the adapter and so could be handled similarly. However, using the
> > same metric for tracking telemetry and event request messages but on the
> > other hand command responses seems a little odd to me.
> >
> > > FMPOV, in addition to the count, the payload size of command responses
> > > can also be tracked by using the metric
> > > "hono.messages.processed.payload". Currently no metrics keep track of the
> > payload size of command responses.
> > >
> > > Hence I would propose the below:
> > > 1. use the metric "hono.messages.processed" (with type "command") to
> > > track the number of successfully processed command responses and drop
> > > the metric "hono.commands.response.delivered" from Hono.
> > > 2. use the metric "hono.messages.processed.payload" (with type
> > > "command") to track the payload size of the successfully processed command
> > responses.
> > >
> > > WDYT?
> > >
> >
> > IIRC we deliberately chose to use a different metric for tracking commands
> > and their responses because they are different from telemetry and events in
> > that they can be request/response. However, for consistency reasons we might
> > want to actually start using hono.messages.processed also for command
> > _request_ messages (incl. one-way commands) and just use a separate metric
> > for keeping track of command responses. I think that also would make the
> > implementation of dashboards on top of these metrics easier to implement ...
> >
> >
> > >
> > >
> > > Mit freundlichen Grüßen / Best regards
> > >
> > > Kartheeswaran Kalidass
> > >
> > > Engineering Cloud Services 4 Bosch IoT Hub (INST/ECS4) Bosch Software
> > > Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY
> > > | www.bosch-si.com Kartheeswaran.Kalidass@xxxxxxxxxxxx
> > >
> > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> > > B
> > > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
> > > Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
> > >
> > >
> > >
> > > _______________________________________________
> > > hono-dev mailing list
> > > hono-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or
> > > unsubscribe from this list, visit
> > > https://www.eclipse.org/mailman/listinfo/hono-dev
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from
> > this list, visit https://www.eclipse.org/mailman/listinfo/hono-dev
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from
> > this list, visit
> > https://www.eclipse.org/mailman/listinfo/hono-dev
>
>
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/hono-dev
