[Feature] Error Tracking via logs

[TheLevti]

Describe the feature you'd like

Basically we are currently integrating error tracking via RUM, APM and LOGS. Because of APM being heavily sampled, we want to rely more on log error tracking.

Unfortunately the documentation is lacking support for error tracking via php https://docs.datadoghq.com/logs/error_tracking/backend/?tab=serilog#php

It would be really nice if the php-dd-trace extension is also able to support error tracking via logs. e.g. when using monolog and the errors/critical context has a Throwable object, make sure it gets picked up properly by the error tracking feature.

Is your feature request related to a problem?

No response

Describe alternatives you've considered

I have also attempted to provide a custom formatter to set the specified generic fields error.stack, error.message and error.kind, but it seems like datadog does not convert/does not pick up those logs into the error tracking component.

Is there a non sdk specific documentation about what is the bare minimum that needs to be provided in the logs to be considered to be picked up in the error tracking component?

Additional context

No response

[PROFeNoM]

Hi @TheLevti :wave:

Thanks for opening this feature request!

On my sandbox, I've tried the following:

1. Sending a sample exception

try {
    // ...
} catch (\Exception $e) {
    Log::error('An error occurred', [
        'error.message' => $e->getMessage(),
        'error.kind' => get_class($e),
        'error.stack' => $e->getTraceAsString(),
    ]);
}

Nota Bene: Monolog with JSON formatting

2. Adding the necessary remapping pipelines

The above currently adds the error information under the context array; hence, the pipeline would need to be enhanced with three remappers, remapping each of these context.error.X to error.X

Result

With the two above steps being done, I can get my errors in error tracking, as shown by the screenshots below:

---

To ensure that Error Tracking can capture errors in your PHP code, we can add three remappers to the default PHP pipeline. However, while we work on implementing this, you may add these remappers to your pipeline on your end as well. This will prevent you from waiting for us to add them to our backend.

Please let me know if this aligns with your requirements or if I have misunderstood your request.

Thank you for your collaboration!

[TheLevti]

Great! I was attempting something similar, instead I added a datadog processor that would populate those fields in the extras array to not pollute the given context from the application (if context.exception is provided of course).

What I did not do is adding remapping settings, but instead added my own custom JsonFormatter that would move the error array out of extras into the root. So it should have also worked, or?

I will try to do how you did it.

Would be nice if the default php remappers can check both, the extras and context array. Thank you for the hints, will let you know if it worked.

[adam-marchewicz-tg]

Are there any plans to support default monolog behaviour (context.*) so remappers won't be needed ?

[TheLevti]

Are there any plans to support default monolog behaviour (context.*) so remappers won't be needed ?

Context should not be polluted with meta data. Thats what the extra collection is for. Context must be strictly related to the logged message.

[adam-marchewicz-tg]

Right, but even using extra, remapping is still required to make it work with dd error tracking. Alternatively, moving it from extra to the root with a custom JsonFormatter (as you described) would probably work but it seems like a lot of manual work.