[
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 15:10 +0000, Kalidass Kartheeswaran (INST/ECS4) wrote:
> -----Original Message-----
> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of
> Hudalla Kai (INST/ECS4)
> Sent: Montag, 10. Dezember 2018 13:11
> To: hono-dev@xxxxxxxxxxx
> Subject: Re: [hono-dev] Metrics for processing command responses
>
> On Mon, 2018-12-10 at 12:03 +0000, Kalidass Kartheeswaran (INST/ECS4) wrote:
> > -----Original Message-----
> > From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On
> > Behalf Of Hudalla Kai (INST/ECS4)
> > Sent: Montag, 10. Dezember 2018 11:59
> > To: hono-dev@xxxxxxxxxxx
> > Subject: 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:
> >
> > +1. It sounds good.
> >
> > > * 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
> >
> > For me both sounds good and I see only a slight difference. IMHO I
> > would prefer with type="command" and command="request/response". The
> > "type=command" here clearly denotes only the type of messages as for
> > telemetry and event messages.
> > More information such as response or request can be defined with
> > another tag "command=request/response".
> >
>
> In that case I would, however, prefer to call the other (qualifying) tag
> "direction" or "dir" instead of "command", which IMHO would be very confusing.
>
> I would also propose to use tag for distinguishing between one-way commands and
> command request messages.
>
> So, we would end up with
>
> one-way command: type = "command"
>
> command request message: type = "command", dir = "request"
>
> command response message: type = "command", dir = "response"
>
> WDYT?
>
> It sounds even better, as now we are able to report the metrics of one-way
> commands too. Personally for me "direction" is clearer than "dir.
> In the above case, querying with type="command" retrieves all the command
> messages. In order to retrieve only one-way commands metrics, I think, it would
> appear as type="command",direction="". For me it would be very clear if the
> query looks like type="command",direction="one-way".
>
That would work for me as well:
one-way command: type = "command", direction = "one-way"
command request message: type = "command", direction = "request"
command response message: type = "command", direction = "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
> > _______________________________________________
> > 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
