The whole wide events thing is Honeycomb’s marketing pitch. It’s essentially offering developer velocity, ie you don’t have to think about what should be a metric in advance. They have an open source project called Refinery which is a smart sampling proxy that samples successful requests but always forwards errors, slow queries, etc.
You can do anything you like with any approach but if they are mostly about ad hoc queries, dumping everything into BigQuery as a wide event can be the most economical. However if you want to run alerting, SLOs, etc with frequent queries over aggregated metrics, the best bet is using OTel Collector and metrics store of your choice like Prometheus or Mimir.
Most companies could save a bundle on observability if they were to move to a hybrid that includes both of those approaches instead of cloud provider logging, log-based metrics, and alerting.
You can do anything you like with any approach but if they are mostly about ad hoc queries, dumping everything into BigQuery as a wide event can be the most economical. However if you want to run alerting, SLOs, etc with frequent queries over aggregated metrics, the best bet is using OTel Collector and metrics store of your choice like Prometheus or Mimir.
Most companies could save a bundle on observability if they were to move to a hybrid that includes both of those approaches instead of cloud provider logging, log-based metrics, and alerting.