Metrics::Any(3pm)

✨ Metrics::Any 💅

okay bestie, so this is the Metrics::Any page from the User Contributed Perl Documentation — it's the whole vibe guide for this module, and yes we're doing the full tour, no skimming, periodt.

---

🌸 NAME 🌸

Metrics::Any — the abstract collection of monitoring metrics, iykyk 🎀

---

✨ SYNOPSIS ✨

okay so in a module, you'd do this:

use Metrics::Any '$metrics',
   strict => 0,
   name_prefix => [ 'my_module_name' ];

sub do_thing {
   $metrics->inc_counter( 'things_done' );
}

and then in a program, or a top-level program-like module, you do:

use Metrics::Any::Adapter 'Prometheus';

that's literally it, the whole flex 💅

---

🦋 DESCRIPTION 🦋

so what even is this. it gives modules one central place to report monitoring metrics — stuff like counters of how many times interesting events have happened — and then programs can collect all those metrics up and send them off to monitoring services. main character energy, honestly.

inspired by Log::Any, this module splits the whole problem into two sides, which is the smart part:

• Modules that wanna provide metrics for monitoring can use the use Metrics::Any statement to get themselves a collector to report metric events into. and here's the cute bit — by default this collector doesn't actually do anything, so modules can just use it without dragging in extra specific dependencies for specific reporting. obsessed. 🙈
• A program using one or more of those modules can apply a different policy and request a particular adapter implementation, so the metrics actually get reported to some external system. that's the use Metrics::Any::Adapter statement.

this separation of concerns thing means module authors get to write code that reports metrics without needing to care about the exact mechanism of that reporting — and also without their code depending on the code required to do that reporting. it's giving ✨ boundaries ✨ and we love that for them.

🌈 Future Direction 🌈

ngl, at present this interface is in an early state of experimentation. the API is fairly specifically-shaped for Net::Prometheus right now, but the hope is that with more adapter implementations (like for statsd or OpenTelemetry) the API shapes can be expanded and made more generic, so it can support a wider variety of reporting mechanisms. growth mindset 💖

so as a result: any API details for now should be considered experimental and subject to change in later versions. don't be shocked if things shift, bestie. it's not a bug, it's a vibe-in-progress. 💀

---

🎀 USE STATEMENT 🎀

for a module to use this facility, the use statement that imports it should give the name of a variable (as a plain string) to store the collector for that package.

use Metrics::Any '$metrics';

this variable gets created in the calling package and populated with an instance of Metrics::Any::Collector. then the module can use the collector API to declare new metrics, and eventually report values into them. slay.

heads up though — the variable is created at the package level. any other packages within the same file won't see it, and will have to declare their own. no sharing, no sneaking, fr fr.

---

👑 SEE ALSO 👑

• The name and overall concept of this module is heavily influenced by a similar module for logging, Log::Any. 🫶
• For reporting metrics to one specific target collector, there are specific modules for systems like statsd (Net::Statsd, Net::Async::Statsd) or prometheus (Prometheus::Tiny, Net::Prometheus).
• There is also a similar concept in Measure::Everything.

---

💜 AUTHOR 💜

Paul Evans <leonerd@leonerd.org.uk>

---

and that's the whole page, bestie — no cap. 🧚

cute lil sign-off: this page is from perl v5.36.0, dated 2023-09-29, and it's Metrics::Any(3pm). go forth and report those metrics, you absolute icon. ⭐🍓🔥