consider adding adding non-lambda example?

[AlJohri]

It would be great to add a simple non-lambda example, perhaps using the axum webserver? I've been looking for an out of the box tower middleware or tracing subscriber that can emit # requests and request latency (per http status code, per route?) for a tower http service via EMF and it seemed like this crate was the closest I could find to making something like that possible.

Related Links

• https://github.com/tower-rs/tower-http/blob/master/examples/axum-key-value-store/src/main.rs
• https://github.com/tokio-rs/axum/blob/main/examples/tracing-aka-logging/src/main.rs
• https://github.com/tokio-rs/tracing/blob/master/examples/examples/fmt-json.rs

[BMorinDrifter]

Hey Al, thanks for the interest.

I'd like to understand more about your use case.

How are you getting data into Cloudwatch?
Why a wrapper instead of using the metric API in each route?

Finally, were you able to find any other crates or Rust open source that writes EMF?

The core stuff for collecting + flushing metrics in EMF is in there to reuse or fork. Serializing from serde worked out really well and probably isn't that far off the runtime of concatenating a mess of strings as I've done in the past.

A timer based flush wrapper for axium/warp/rocket/etc. makes a lot of sense to build. Also an async flush would be nice (are the interfaces here going to change when async traits hit stable?)

[AlJohri]

How are you getting data into Cloudwatch?

Cloudwatch Logs supports directly sending EMF to Cloudwatch Metrics. I believe at some point in the past, it required a specific EMF header, but now that is not the case. Also see: "Any EMF logs that can reach CloudWatch Logs will now be parsed and metrics can be generated from them.".

I want to create a Fargate ECS Task with the docker awslogs Cloudwatch Logs Driver to send stdout (EMF) to Cloudwatch Logs. Cloudwatch Logs should then parse and propagate the EMF to Cloudwatch Metrics.

Why a wrapper instead of using the metric API in each route?

My thought was that there should be an out of the box way to instrument a simple http service with commonly looked at metrics (error rate via status codes, latency, etc.). I would love if the out of the box solution not only instrumented the code (like tower-metrics), but also was able to propagate the metrics to a destination like Cloudwatch Metrics. I'm hoping EMF can be the simple solution here as opposed to setting up an OpenTelemetry sidecar which currently requires a lot more setup.

Being relatively new to async rust, I am not quite sure what's the right abstraction here. I am imagining an experience like tower_http::trace where instead of outputting JSON via tracing_subscriber::fmt::format::Json, it is able to output EMF directly? And users can emit tracing::event::Event via tracing::info to emit metrics? Let me know if I'm completely off-base here 😅

Finally, were you able to find any other crates or Rust open source that writes EMF?

Shockingly, I didn't find anything open source. There is one internally at Amazon that integrates with tracing but I am hoping to use/improve something open source.

The core stuff for collecting + flushing metrics in EMF is in there to reuse or fork. Serializing from serde worked out really well and probably isn't that far off the runtime of concatenating a mess of strings as I've done in the past.

Makes sense! I thought given the tight lambda integration with the MetricsService tower middleware, we might consider doing something like that for non-lambda as well here.

[BMorinDrifter]

I'm working on an Axum project now. Once I have that sucker up to MVP status, going to look into how to fit this crate in and what (if anything) to add.