Metrics collection for Services

[yazaddaruvala]

I know this will not be looked at for a while, and this might get moved to a different repo, but I wanted to get my thoughts written down.

I'd love to get more thoughts on two things:

• We need a trait for Metrics, that a service(via middleware) can then use.

pub trait Metric {
    /// Name of service
    fn service_name(&self) -> &str;

    /// Name of api
    fn api_name(&self) -> &str;

    /// Request Id
    fn request_id(&self) -> &str; // Or `usize` or `T`

    /// Start time for the call; To calculate latency
    fn start(&self) -> Instant;

    /// End time for the call; To calculate latency
    fn end(&self) -> Instant;

    // There are some more here we can discuss later: [children_calls, error_type, or some generic "other_info"]
}

• How would we end up returning such an object from the Future?

Future<(Response, Metrics), (Error, Metrics)>

This feels really awkward, and it breaks the fluency of Futures with .map and such. What other options do we have? Given the nature of Futures (i.e. long tasks), and the importance of metrics, it could make sense to bake in Metrics into the Future trait, but that may not be possible in a zero-cost way. Does it make sense for Tokio-Service to implement its own Future which has Metrics built-in?

[lunemec]

I suggest implementing prometheus metrics which are used by most companies for production server monitoring.

[yazaddaruvala]

@lunemec I can see why you brought that point up in this thread. However, I didn't intend for this thread to be about log formats. Ideally, if we get the in memory model/code interface for Metrics correct, any application should be able to format those objects to the logs in any way they need.

To be more explicit:
Off topic: Log formats, Loggers, Log Processing/Analytics

• How do we end up getting the metrics into the log files?
• What do the log files look like?

On topic: The model/interface/implementation of Metrics.

• What does a struct Metrics { ... } look like?
• How does Metrics get created/populated in an async environment?
  • Can this be done without allocations?
• Can we collect/expose metrics for sub-tasks, in the primary-task?

[lunemec]

Oh, sorry you are right, this is about a way to collect all these metrics (generally) ...
thank you for the clarification.

[posix4e]

I had always hoped this day would come https://github.com/posix4e/rust-metrics. The library is really fine grained. You only need Prometheus if you want them. I'm also happy to donate this code or adapt it as people wish.

[posix4e]

Hello everyone @durch is happy to help do this...

[carllerche]

Closing this due to inactivity. I would say that this behavior can probably be implemented in a standalone crate and mature separately.

[posix4e]

Great!

On Wed, Oct 25, 2017 at 12:28 PM Carl Lerche ***@***.***> wrote: Closing this due to inactivity. I would say that this behavior can probably be implemented in a standalone crate and mature separately. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxN2y1tR7S301ZXbKw9kIxR5VFL_v-1ks5sv4vugaJpZM4KbmMx> .

-- Sent from a chromebook 4045076749 Alex Newman