sdd commented on issue #482: URL: https://github.com/apache/iceberg-rust/issues/482#issuecomment-3090352063
Hi All - I've been distracted with other things for a while but I've recently found time to pick this back up and have good progress so far. See the description on https://github.com/apache/iceberg-rust/pull/1502 for some details. Some open questions / tasks: * Feedback on the granularity of the traces I've implemented at different log levels appreciated. I've been using similar levels of tracing in production now on my iceberg fork for a few months and it has proved very useful, and I've taken the lessons I've learned from that process to feed in to this greenfield implementation. * A documented naming scheme for trace spans would be good to have. Ideally one that aligns with cross-language iceberg implementations * Ditto for naming tracing events * Ditto for metrics for Prometheus etc * Documented guidelines / policy for what / where to instrument with spans / logs / metrics and at what level (ie info/debug/trace) * My PR contains changes necessary to the integration test setup as well as the instrumentation itself. I'd appreciate feedback / critique on the approach. It might make sense to split that part out if there is any controversy * Where is a good location to add documentation / examples for consumers of the library for how to integrate iceberg traces/metrics with common observability stacks One final observation. There's a trade-off to be had - at one end of the spectrum, the tracing / metrics instrumentation is as light-touch on the codebase as possible, with the implementation prioritising simplicity and clarity of the primary business logic at the expense of less cohesive / coherent traces within the observability tooling. At the other end of this spectrum, the control flow and readability of the core logic is completely disregarded in order to generate the most accurate and readable traces. I've trodden a path closer towards the latter with this PR. It is not easy in Rust to get traces that are the most useable to consumers when you are working with streams of streams with multiple async stages. Getting the traces to look right was my goal with this PR and the cost of that is some loss of readability. My rationale is that I'd estimate that many more people will look at traces than will read the codebase. But as ever this is a discussion point. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
