getsentry / arroyo

A library to build streaming applications that consume from and produce to Kafka.
https://getsentry.github.io/arroyo/
Apache License 2.0
39 stars 6 forks source link

Enhance metric definitions #360

Open mj0nez opened 1 month ago

mj0nez commented 1 month ago

Hi,

Thank you for arroyo! I'm currently adopting it and to integrate the exposed metrics with our Prometheus setup, I had to redefine the metrics in metric_def.py. It would be nice if we could use some simple structure like the following to give each metric a description and type that may be evaluated by downstream consumers/other backends.

from enum import Enum, auto
from typing import NamedTuple

class MetricType(Enum):
    GAUGE = auto()
    TIMER = auto()
    COUNTER = auto()

class Metric(NamedTuple):
    name: str
    type_: MetricType
    description: str

ARROYO_METRICS = [
    Metric("gauge.a", MetricType.GAUGE, "goes up and down"),
    Metric("counter.b", MetricType.COUNTER, "goes up!"),
]

AFAIK it's not possible to generate a Literal like the current MetricName dynamically, so this is something to consider. But if you accept this request, I would be happy to contribute. :)

untitaker commented 1 month ago

basically we had two requirements for metrics: 1) should be type-safe 2) should create usable docs

Literal was just the easiest way to get there without impacting ergonomics of internal code too much. if it can be done in some other way, i'm open to it. I'm not entirely sure I understand your requirements though, and why you need it to change.

mj0nez commented 1 month ago

To create a metric with the prometheus client library I have to provide a name and description, set aside the type of the metric. Name and type I can cover with a defaultdict but the description is currently only in comments. So, I extracted the descriptions manually, but was unsure if this would be sustainable for the future, when new metrics would be added, or existing ones modified.

To be honest, I don’t see a solution which does not involve duplicating at least the metric names while keeping the current behavior. But I wanted to see if anybody had an idea... Feel free to close the issue and thanks for your reply! :)

untitaker commented 1 month ago

I think we can check in some code into arroyo CI that extracts metric definitions from sourcecode and publishes a machine-readable file alongside docs.