Title: Logs API options for programmatic access
Location: https://fly.io/docs/monitoring/logs-api-options/
Source: https://github.com/superfly/docs/blob/main/monitoring/logs-api-options.html.md
Describe the issue
You are characterizing NATS access as unofficial, experimental, even dusty. But then, you recommend to use fly-log-shipper for export which in fact just uses the very NATS interface as a data source. This somehow feels inconsistent. Also, even though you can update fly-log-shipper to whatever infrastructure you might move to out of the "dust", this would still mean that people would have to redeploy their exporters to adapt, so maybe a bit easier but in the end similarly experimental as the underlying infrastructure.
Am I missing something?