chore: Clarify configuration via env var.

README.md

@@ -40,7 +40,7 @@ You may notice an increase of your Lambda function's reported duration (`aws.lam
 
 By default, the Extension flushes data back to Datadog at the end of each invocation (for example, cold starts always trigger flushing). This avoids delays of data arrival for sporadic invocations from low-traffic applications, cron jobs, and manual tests. Once the Extension detects a steady and frequent invocation pattern (more than once per minute), it batches data from multiple invocations and flushes periodically at the beginning of the invocation when it's due. This means that *the busier your function is, the lower the average duration overhead per invocation*. In other words, for low-traffic applications, the duration overhead would be noticeable while the associated cost overhead is typically negligible; for high-traffic applications, the duration overhead would be barely noticeable. To understand the duration overhead that is used by the Datadog extension to flush data, use the metric `aws.lambda.post_runtime_extensions_duration` or `aws.lambda.enhanced.post_runtime_duration`. 
 
-For Lambda functions deployed in a region that is far from the Datadog site, for example, a Lambda function deployed in eu-west-1 reporting data to the US1 Datadog site, can observe a higher duration (and therefore, cost) overhead due to the network latency. To reduce the overhead, configure the extension to flush data less often, such as every minute `DD_SERVERLESS_FLUSH_STRATEGY=periodically,60000`.
+For Lambda functions deployed in a region that is far from the Datadog site, for example, a Lambda function deployed in eu-west-1 reporting data to the US1 Datadog site, can observe a higher duration (and therefore, cost) overhead due to the network latency. To reduce the overhead, configure the extension to flush data less often, such as every minute by setting the environment variable `DD_SERVERLESS_FLUSH_STRATEGY=periodically,60000` on your Lambda function. For more info, see https://docs.datadoghq.com/serverless/guide/agent_configuration/#basic-configuration.
 
 In some rare cases where a very short timeout is configured (the definition of what is _short_ depends on the runtime), it is possible to notice that the Lambda handler code may not get run on subsequent invocations. This is a possibility when the first invocation times out, requiring the `INIT` [phase](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html#runtimes-extensions-api-lifecycle) to be started again in the next invocation. In the subsequent invocation, should the function time out before the `INIT` phase is completed, the function is terminated by Lambda and the handler code is not run. You can identify these failures using `INIT_REPORT` [logs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle-init-errors). Datadog recommends increasing the timeout for a Lambda function where this has been identified.