Not flush events on agent destruct about elastic-apm-php-agent HOT 6 CLOSED

@tsantos84 Are you trying to work on something similar to this? https://packagist.org/packages/goksagun/elastic-apm-bundle

When I was trying to set it up, I found it a bit inflexible for my needs, but it could be useful for you.

from elastic-apm-php-agent.

Yes, it's a bit inflexible and I decided to write a new bundle for my company purposes (fit php versions, new spans and etc). After this experience, I'm planning to write a public bundle or contribute with goksagun/elastic-apm-bundle.

Anyway, the question here is about flushing the agent automatically. I think it'd be an optional process given the problems I've mentioned on the initial thread.

from elastic-apm-php-agent.

Perhaps what you need is something where if it is running in the symfony console, set the active config to false? That could be done in your symfony config, and not require a change in the agent code.

from elastic-apm-php-agent.

I've thought about this approach, but didn't saw an easy way to do that. And thinking better, unit testing could cause the same side effect depending how they were written. In a bundle, it's better to let it flush the events instead of on __destruct. There is another side effect on it. If some error happens (e.g request failure), we can't see the error on __destruct.

from elastic-apm-php-agent.

You may be able to do it through native php functions, so if you had a php config file, it could override the active config for the agent on runtime.

https://electrictoolbox.com/determine-php-run-via-http-or-cli/
https://www.php.net/manual/en/function.php-sapi-name.php

I will say, there is a lot of power in using php configuration files, but they are only documented in some circumstances.

from elastic-apm-php-agent.

If the apm server is not running or there is some network issue, then destruct function would throw an uncaught exception, would it be better to add a try catch here?

from elastic-apm-php-agent.