This approach will also introduce the same issues we have in our current integrations, like the agent on containers not being able to send the data before exiting the container itself.

Is the overhead or delay so much we should consider implementing this already?

@tombruijn

This approach will also introduce the same issues we have in our current integrations, like the agent on containers not being able to send the data before exiting the container itself.

True! Though, unlike in the integrations, here we could have a --wait flag to ask the process to wait for the data to be sent.

Is the overhead or delay so much we should consider implementing this already?

Probably not, at least not on my local tests -- though, at the end of the day, it depends on the public API's response time and the amount of data to send.

Making it non-blocking would improve certain use-cases. You might want to call the wrapper in a for loop, for example:

for file in *.log; do
  appsignal-wrap -- grep 'ERROR' file
done

(this is a contrived example, as you could appsignal-wrap -- grep 'ERROR' *.log instead, but you see the point)

I'd be okay with having a bit of delay. That's the cost of instrumentation. I wouldn't expect it to take up to 30 seconds like it does in our current agent setup. We can start testing without, so the project is a bit simpler, and see if it becomes an issue in the future.