Define LogRecord batching processor defaults

[alanwest]

Fixes #2954

Defines default configuration values for the LogRecord batching processor.

The same default values have been adopted from the span batching processor with the exception of scheduleDelayMillis. A default value of 1000 milliseconds has been chosen for log rather than the 5000 milliseconds for spans. See #3002 (comment) for discussion.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[tedsuo]

So, it's clear that our current defaults – both for the SDK and the Collector – are not great, and we should consider revisiting them. For example, some defaults presume that the SDK is talking to a local collector. Some defaults presume the collector is aggregating data from multiple services. This is due to us adding defaults one at a time, where each default might be reasonable on its own, but making different assumptions from the other defaults.

My request is that the logging defaults be coherent with the tracing defaults. New users will definitely be confused if they start receiving logs immediately, but don't see their traces for five seconds. So I'm worried about creating a different set of defaults for logging, even if the assumptions behind those new defaults are reasonable on their own.

This is my suggested course of action:

• Please describe the "default deployment" we are actually trying to target.
• I strongly suggest that by default, we assume an SDK is talking to a local collector. This is our suggested deployment pattern for production, and it also works well for new users going through the installation process.
• Pick a set of logging defaults that work well for this scenario, but are not too aggressive or over-optimized.
• Bring the tracing defaults into alignment with the new logging defaults.

If the above course of action is too much work for the logging group to tackle at this time, my request is to match the tracing defaults for now, and defer improving our defaults to a later date. Please do not release a version of the spec where tracing and logging defaults are incoherent with each other.

[tigrannajaryan]

This is my suggested course of action:

• Please describe the "default deployment" we are actually trying to target.
• I strongly suggest that by default, we assume an SDK is talking to a local collector. This is our suggested deployment pattern for production, and it also works well for new users going through the installation process.
• Pick a set of logging defaults that work well for this scenario, but are not too aggressive or over-optimized.
• Bring the tracing defaults into alignment with the new logging defaults.

If the above course of action is too much work for the logging group to tackle at this time, my request is to match the tracing defaults for now, and defer improving our defaults to a later date. Please do not release a version of the spec where tracing and logging defaults are incoherent with each other.

I like this plan. I think we should go for lower batch delay for both logs and traces (somewhere around 200-1000ms) and use the same value for both. I am personally fine with lowering defaults for the traces and I do not think it is a breaking change, I think it should be allowed.

[alanwest]

Please describe the "default deployment" we are actually trying to target.

This seems worthy of a separate issue. That is, the "default deployment" described should be more of a top-level thing in the spec making it clear that it provides a guide for the decisions we make across the entire specification.

Regarding @tedsuo's recommendation as it relates to the specific issue of settling on batch processor defaults, the question I have is the order of operations. For example, say we agree that 1000ms is a more satisfying default. Can we do things in this order?

1. Land this PR with a 1000ms default
2. Open a separate PR to change span batch processor also to 1000ms
3. Open a separate issue/PR to describe the "default deployment"

I'd prefer that we are able to continue progress on log stabilization in parallel with furthering the discussion of codifying a notion of a "default deployment".

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.