/v1/input/<api_key> for datadog compatibility

[poundifdef]

In order to be compatible with DataDog for log ingest, we should support a /v1/input endpoint. We should also investigate DataDog's v2 endpoint schema.

[tanmaymunjal]

Hey @poundifdef, looking at the documentation for Datadog(https://docs.datadoghq.com/api/latest/logs/?code-lang=go), it seems that the main difference between /v1/input and /v2/logs is that the v2 version takes in extra parameters in the body as hostname, service, and source while the v1 version only takes as input ddtags and message.

I think it makes sense to add both to the API to allow for compatibility with Datadog API clients. What do you think about it?
Would love to work on it, could you please assign me the issue?

[poundifdef]

Thanks for taking an interest in this issue. Please feel free to make a PR. One thing to consider is how to namespace the endpoint. Ideally there would be a url prefix such as /datadog/v1 or something, but many exporters only let you specify a base url. Should there be a configuration option to enable this?

…

On Mon, Oct 23, 2023 at 9:08 PM Tanmay Munjal ***@***.***> wrote: Hey @poundifdef <https://github.com/poundifdef>, looking at the documentation for Datadog( https://docs.datadoghq.com/api/latest/logs/?code-lang=go), it seems that the main difference between /v1/input and /v2/logs is that the v2 version takes in extra parameters in the body as hostname, service, and source while the v1 version only takes as input ddtags and message. I think it makes sense to add both to the API to allow for compatibility with Datadog API clients. What do you think about it? Would love to work on it, could you please assign me the issue? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXNTHRKYUML4MCGTEU6J3YA4IKLAVCNFSM6AAAAAA3WZKVTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGI4TQMBUGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tanmaymunjal]

Hmmm, we could set a configuration option that sets the endpoint for this perhaps. Not sure if it's the best route though. Will look into this a bit more.