# EPF Cohort 6 – Week 18 Update ## PR Summary: Merged into **grandinetech** submodule `eth2_libp2p`: - **PR** - **[eth2_libp2p migration to Tokio Tracing #21 ](https://github.com/grandinetech/eth2_libp2p/pull/21)** --- Awaiting clippy lints fix on grandinetech side (before merge): - **PR** - **[Full Repository Migration to Tokio Tracing & Dynamic Runtime Log Control #422](https://github.com/grandinetech/grandine/pull/422)** --- New PR opened (awaiting review): - **PR: [Enable critical logging for developers (suspicious/malicious behavior detection #432)](https://github.com/grandinetech/grandine/pull/432)** --- ## Progress this week This week I opened the official **PR** - **[Full Repository Migration to Tokio Tracing & Dynamic Runtime Log Control #422](https://github.com/grandinetech/grandine/pull/422)** I received some feedback from Tumas, addressed all the comments, and aligned my implementation with the team’s expectations. --- However, one of the [feedback](https://github.com/grandinetech/grandine/pull/422#discussion_r2432657902) required a deeper change, so I created a separate PR to handle that changes. **PR: [Enable critical logging for developers (suspicious/malicious behavior detection) #432](https://github.com/grandinetech/grandine/pull/432)** - In this PR, I implemented **developer-controlled crit!** logging across **all log levels**. - It now works seamlessly in both debug and production modes, without requiring a separate log file. Developers can enable crit! logging on demand. `crit!` visibility can now be controlled through: - **Environment variables**: `GRANDINE_LOG` or `RUST_LOG` - A reloadable tracing layer / **API**: `POST /eth/v2/debug/tracing/log_level` - allowing log levels to be updated **dynamically** after startup - No dedicated log file is needed - logs are filtered through the crit target --- I started that PR **by writing tests** ([issue27](https://github.com/sntntn/grandine/issues/27), [issue26](https://github.com/sntntn/grandine/issues/26)) to capture the **current** tracing **behavior** and crit behavior **across different log levels**. That process helped me experiment with multiple approaches and eventually find the most practical solution. >Some approaches were quite challenging — every new layer added to the subscriber increased the overall type complexity. When combined with the reload layer (which enables runtime log-level changes), the tracing handle type became even more complex. Working with Rust’s generics to simplify these deeply nested types was particularly tricky. > >Useful links: > - [per-layer-filtering](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#per-layer-filtering) - when we need *"one Layer to record a particular subset of spans and events, while a different subset of spans and events are recorded by other Layers"*, > - [trait.Filter](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/trait.Filter.html) - filter that determines whether a span or event is enabled for an individual layer, > - [Module layer](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html). > - [Layers and Filters](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/#layers-and-filters) & [Composing Layers](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#composing-layers) & [Runtime Configuration With Layers](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#runtime-configuration-with-layers) > >Combining it with the reload layer wasn’t straightforward, but I found a simple and stable solution that keeps full developer visibility without requiring an external log file. In discusion with Saulious we clarify that these **crit!** logs **are not “critical errors”** in the traditional sense. They represent **suspicious**, **malicious**, or **unusual** behaviors intended **mainly for developers**, rather than end users running the Grandine client. >This feature is exposed via the **target directive**, which can be configured using **environment variables** or dynamically via **API during runtime**. I believe this represents the ultimate solution for developer-side monitoring and diagnostics. An example of how the new crit! target works with environment variables can be found here: [example issue](https://github.com/sntntn/grandine/issues/31) . After completing that work, I also handled a missing piece in the implementation related to cross-platform builds. I created the issue [Make CLI build pass on all supported OS (Ubuntu, Windows, macOS) ](https://github.com/sntntn/grandine/issues/32) and fixed the build so that the CLI now compiles successfully on all operating systems. > Previously, I hadn’t noticed this issue because I usually build and run the software on Ubuntu, and the Windows-specific code paths weren’t triggered in my environment. Now the build works correctly across **Ubuntu**, **Windows**, and **macOS**. ![image](https://hackmd.io/_uploads/HJqLpnmCle.png) ## Next Once the Grandine team resolves the remaining Clippy lints on their side - likely after introducing the [Update rust-kzg to latest version]( https://github.com/grandinetech/grandine/commit/a0af36ce44d18fb1dbc81ac6aada6e79b982a23f) commit - everything should be ready for merge PR: [Full Repository Migration to Tokio Tracing & Dynamic Runtime Log Control #422](https://github.com/grandinetech/grandine/pull/422). The latest PR — [Enable critical logging for developers (suspicious/malicious behavior detection) #432](https://github.com/grandinetech/grandine/pull/432) — awaits review. ## Resources - **[Grandinetech](https://github.com/grandinetech)** - **PR** - **[Full Repository Migration to Tokio Tracing & Dynamic Runtime Log Control #422](https://github.com/grandinetech/grandine/pull/422)** - **PR** - **[eth2_libp2p migration to Tokio Tracing #21 ](https://github.com/grandinetech/eth2_libp2p/pull/21)** - **PR: [Enable critical logging for developers (suspicious/malicious behavior detection #432)](https://github.com/grandinetech/grandine/pull/432)** - [per-layer-filtering](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#per-layer-filtering) - [trait.Filter](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/trait.Filter.html) - [Module layer](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html) - [Layers and Filters](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/#layers-and-filters) & [Composing Layers](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#composing-layers) & [Runtime Configuration With Layers](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/index.html#runtime-configuration-with-layers)