Open olsavmic opened 2 years ago
Hello @olsavmic thank you for opening the issue and for bringing up those two points. Let me answer separately.
Remove specific spans
We currently do not offer this possibility but I see your point. I am bringing this up to our product managers and hopefully we will be able to get back to you with a plan soon. Some tracers offer span post-processors, that let you drop a span, but it can have performance implications. We might decide instead just to offer a block_list of span names that you want to block.
Custom instrumentation
I assume that at this point your idea would be to disable the PDO integration and write your own. We plan to release in the next few months the final manual instrumentation api and I will bring up your suggestion about ObjectKVStore
. About Integration::toString
, why do you need it? In order to set tags? Because in this case I can provide a more thoughtful answer.
@labbati Great news, thank you!
Offering a block_list of span names sounds like a good enough solution for most use-cases.
Regarding the Integration::toString, yes, we're using it to set tags similarly to how it's done in other integrations. It's just convenient to keep the output format of (for example) method params consistent with DDTrace integrations. It's not needed for the PDOIntegration in particular as the important parameters are plain strings.
If there is a better way, I'm happy to learn :)
We have the same:
I would like to adjust the LaravelIntegration
to our needs but see no way or documentation on how to overwrite/adjust an Integration.
Hey @joelharkes,
To disable the built-in integration set datadog.trace.laravel_enabled=0
in your INI. Then you should to be able to copy most code from https://github.com/DataDog/dd-trace-php/blob/master/src/Integrations/Integrations/Laravel/LaravelIntegration.php and just adapt it as you need.
Could adding a config parameter not be good enough as the PDO.prepare is equally useless to us. I'm assuming that there may be other people whom feel the same way. e.g. if `DD_TRACE_PDO_PREPARE_ENABLED' then run the relevant trace_method code: https://github.com/DataDog/dd-trace-php/blob/master/src/Integrations/Integrations/PDO/PDOIntegration.php#L108-L120
Hey @grigi, to be sure what you mean, you want to disable creating spans for PDO.prepare, is that right?
Hey @grigi, to be sure what you mean, you want to disable creating spans for PDO.prepare, is that right?
Yes, if one could disable generating a span for PDO.prepare
via a config option (easiest for me would be an environment variable) it could save us on about ⅓ of our generated spans, and lose no real benefit in the tracing.
Hi @bwoebi
Is the ability to exclude PDO.prepare
in the pipeline? Has there been any progress?
Hi @bwoebi
Is the ability to exclude PDO.prepare
in the pipeline? Has there been any progress?
:wave: I work on profiling and don't know the answer about that, @grigi . However, you should be able to drop the span with something like this:
DDTrace\trace_method(PDO::class, 'prepare', fn () => false);
I confirmed it works for at least this basic example:
<?php
if (extension_loaded('ddtrace')) {
var_dump(DDTrace\trace_method(PDO::class, 'prepare', fn () => false));
}
$pdo = new PDO('sqlite:/tmp/mydb.sq3');
$result = $pdo->prepare('SELECT "hello"'); // no span here
$result->execute();
$hello = $result->fetch(PDO::FETCH_NUM);
var_export($hello); echo PHP_EOL;
Oh, that's interesting. I will try that. Thanks for the feedback!
Thanks it seems to work as expected :+1:
This is a great thread thank you all. I'm having a similar issue but I don't want to drop the prepare span rather customize it some. Right now, Datadog shows the span equivalent to the PDO.execute span in that they are both treated as a real query within the Trace -> SQL Queries tab. I was hoping to measure the average duration of just Prepare spans, but cant find a way to separate them.
Is custom instrumentation the way to do this? [Docs]
With the recent APM trace ingestion pricing change, we're trying to cut down our usage by removing traces that provide no value to us, mainly
PDO::prepare
(which makes approximately 30% of our total ingestion and is completely irrelevant for us).Customizing the integration is not as simple as it seemed, mainly due to the fact that the DDTrace\Integrations namespace is not part of the defined PSR-4 autoloading (only /api part of DDTrace namespace is).
It's not really the integration itself that we're missing but rather utilities like
ObjectKVStore
orIntegration::toString
.Would you consider providing these and potentially other utilities helping with custom integration development as a part of API?