Re: [hono-dev] Metric names/tags

[Jens Reimann <jreimann@xxxxxxxxxx>]

I think it can be quite possible to keep the protocol as is:

For example with the Kura adapter, although the (transport) protocol is MQTT, the actual protocol is "Kura MQTT", and IIRC the protocol name is "kura".

The generic "http" and "mqtt" protocol adapters maybe could be better tagged with "protocol=vanilla-http" or "protocol=hono-http", as they are the default HTTP dialect for Hono. But I think simply naming them e.g. "http" is fine.

And the same for "coap", "lora", …

So when it comes to e.g. PPMP, why not simply say the protocol is "ppmp"? Yes, the transport is still HTTP, but the whole protocol stack could be called "ppmp".

On Tue, Jan 8, 2019 at 4:48 PM Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote:

Hi list,

after the discussion we had around the names and tags of the metrics we want to
use for tracking the frequency and payload size of telemetry, event and command
messages, I have reviewed the tags that we have defined in the Metrics API [1].

I have some concerns regrading the "protocol" tag. For the time being we only
have a single protocol adapter for each of the transport protocols and thus the
value of the "protocol" tag also indicates the specific type of protocol adapter
that has reported the value. However, assuming that there will be multiple
(custom) protocol adapters that make use of e.g. HTTP as the transport protocol,
my feeling is that the "protocol" tag is not really appropriate to determine the
specific protocol adapter.

Instead, I propose that we use "component-name" to contain the name of the
protocol adapter or service reporting the value.

I would therefore like to propose the following changes:

Common Tags

- rename "component" to "component-type": values are ["service", "adapter"]
- add "component-name": value is the name of the component, e.g. "http",
                        "LoRa", "mqtt", "PPMP" etc.

Adapter Tags

- remove "protocol" tag

This way, we could still drill down along component type as well as along the
specific adapter type but would prevent the ambiguity regarding the transport
protocol name(s).

WDYT?


[1] https://www.eclipse.org/hono/api/metrics/
--
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
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

--

Jens Reimann
Principal Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill