Improve metrics to be more analytics friendly

@oscarotero and team, I have these suggestions for improving metrics:

1. Increase granularity
2. Allow “baggage” (in open telemetry terms) to be contributed by pages

Increasing granularity. Right now we have the following in metrics.json where the “name” has event details that need to parsed in order to be consumable for analytics:

{
    "name": "Load: /support/generate-static-build.sh",
    "entryType": "measure",
    "startTime": 1009.5581999999999,
    "duration": 0.1815000000000282,
    "detail": null
  }

Instead, I suggest something like this:

{
    "name": "Load: /home", // human-friendly, not useful for analytics
    "nature": { category: "load" }, // analytics-friendly, nature can be like a URL with depth /load/X, /preprocess, /render/Z, etc. and can be merged with metrics contributed by pages being rendered
    "target": { url: "/page/url", ...anything else we know about target... }, // analytics-friendly
    "entryType": "measure", // "measure" is the only entry I see here -- is there anything else?
    "startTime": 1007.8624, // analytics-friendly, 
    "duration": 2187.5929, // suggest removing "duration" and only including analytics-friendly "endTime"
    "detail": null // suggest renaming to "baggage" using OpenTelemetry terminology; and allow this to be contributed/merged from generated pages (through filter.metrics({ nature: {  }, baggage: {... anything ...}})
}

Allow metrics “contribution” by pages. Many of my pages run database calls or other expensive calls and I’d like to add my own metrics for those expensive items.

export default async function ( // for Lume
  page: lumeAide.RenderablePage,
  filters: lumeAide.Filters,
) {
  // do something expensive
  filter.metrics({ nature: {  }, baggage: {... anything ...}}); // I can call my own metrics?
}

[oscarotero]

I think this is already implemented, so I’m closing it.

[oscarotero]

What you’re proposing is that, instead of returning a function, returns an Instrument object with a measure function? I mean:

// This is your proposal (the not type-safe option)
const observe = this.metrics.typicalInstrument("Copy (all files)");
for (const [from, to] of this.source.staticFiles) {
  await this.#copyStatic(from, to);
}
observe.measure();


// And this is my proposal
const end = this.metrics.start("Copy (all files)");
for (const [from, to] of this.source.staticFiles) {
  await this.#copyStatic(from, to);
}
end();

I see both are almost the same, but maybe I’m missing something. Maybe you’re planning to expand the observe object with more functionalities?

My idea to make this extensible is that you could create your own class extending Metrics:

class DbMetrics extends Metrics {
    measureDatabase() {
        return this.start("Database");
    }
}

I guess what you’re proposing is creating an interface that you can use without extending the base class, right?

class MyMetrics implements InstumentationSupplier {

Anyway, I’ll release a new version in next days, but if you want to test it right now, just run lume upgrade --dev and this will install the last commit version.

btw, feel free to create a pull request if you want to work on this.