Name conventions for our core metrics?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Name conventions for our core metrics?

Bertrand Delacretaz
Hi,

As mentioned earlier I'll be coaching a small student project in
March, to start adding metrics to our core as per SLING-5410

We need to define conventions for the metrics names, currently
/system/console/slingmetrics shows Oak metrics with names like
oak:SOME_METRIC

Do we want to follow that convention or a similar one?

If similar I suggest hierarchical names like sling:engine.requests.count , WDYT?

-Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: Name conventions for our core metrics?

Felix Meschberger-3
Hi

I like hierarchical names for name spacing. But can we do as most people do today and just use dots  (thus remove the colon) ?

Not sure whether we should stiplute a relation to the bundle or package name they are defined in because that might have negative consequences in case of refactorings.

Regards
Felix

> Am 26.01.2017 um 12:13 schrieb Bertrand Delacretaz <[hidden email]>:
>
> Hi,
>
> As mentioned earlier I'll be coaching a small student project in
> March, to start adding metrics to our core as per SLING-5410
>
> We need to define conventions for the metrics names, currently
> /system/console/slingmetrics shows Oak metrics with names like
> oak:SOME_METRIC
>
> Do we want to follow that convention or a similar one?
>
> If similar I suggest hierarchical names like sling:engine.requests.count , WDYT?
>
> -Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Name conventions for our core metrics?

Bertrand Delacretaz
On Thu, Jan 26, 2017 at 2:12 PM, Felix Meschberger <[hidden email]> wrote:
> I like hierarchical names for name spacing. But can we do as most people do
> today and just use dots  (thus remove the colon) ?...

You're right, sling.engine.requests.count is more inline with our
logging categories for example.

> ...Not sure whether we should stiplute a relation to the bundle or package name they
> are defined in because that might have negative consequences in case of
> refactorings...

I don't think we should necessarily have a 1:1 mapping to bundle
names, I'd rather use logical names like engine, resourceresolver,
servlets, scripts, etc. which in many cases will map to existing
bundles, but not always.

-Bertrand