| Re: [hono-dev] Metrics for processing command responses |
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