TL;DR: For a marketplace rolling out a pricing rule behind a flag, the useful question is not which logging service has the longest feature list. It is whether the service preserves four signals together: the rule decision, the request outcome, the latency, and the change version. Keep those fields structured, attach a correlation identifier, and measure noise before choosing retention or search features.

A pricing experiment can look healthy while quietly charging the wrong fee to a narrow slice of listings. Raw request logs will not explain that. A single log event that records the evaluated flag, the rule revision, the seller or listing scope, and the final decision gives the on-call engineer something testable. The trade-off is straightforward: emit fewer, more meaningful events, then keep the detailed evidence only around decisions that need investigation.

What should a pricing log answer?

The log pipeline starts at the application, not at the logging vendor.…