GGraziadei commented on issue #9016: URL: https://github.com/apache/storm/issues/9016#issuecomment-5706039647
Hi Davide, I see your point. I think the difference between us is the one between monitoring and observability. The first line of this issue talks about observability. A sampled trace, though, is a stochastic estimate: it gives full detail for the tuples it keeps and nothing for the others. That is closer to monitoring than to full observability, and the timeout case shows it, since a decision taken at the spout cannot guarantee the trace of the tuples that will fail. I am open to both, but we need to decide what to implement. If you consider sampled traces good enough for your use case, go ahead with them. I did something similar when I built the control loop for upstream feedback, and I am happy to help. Path labelling can go in a separate issue. The points you raised, multiple anchors and table size, have answers that come from MPLS itself, label merging at fan-in nodes and per-component tables bounded by the linear segments, and I will write them up there. For the design document, please include an evaluation of two trade-offs: - the performance cost of producing and exporting spans, on the hot path and towards the backend, measured with tracing off, at a low rate and at 100%; - the sampling factor, and what it means for the tuples that fail or time out. If required I am open for a meeting on Sunday afternoon CEST. -- 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]
