You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2022/03/01 01:59:40 UTC

[GitHub] [apisix] shuaijinchao commented on a change in pull request #6415: docs: refactor the docs associated with Logger

shuaijinchao commented on a change in pull request #6415:
URL: https://github.com/apache/apisix/pull/6415#discussion_r816391395



##########
File path: docs/en/latest/plugins/http-logger.md
##########
@@ -44,16 +46,26 @@ This will provide the ability to send Log data requests as JSON objects to Monit
 | auth_header      | string  | optional    | ""            |         | Any authorization headers.                                                               |
 | timeout          | integer | optional    | 3             | [1,...] | Time to keep the connection alive after sending a request.                               |
 | name             | string  | optional    | "http logger" |         | A unique identifier to identity the logger.                                              |
-| batch_max_size   | integer | optional    | 1000          | [1,...] | Set the maximum number of logs sent in each batch. When the number of logs reaches the set maximum, all logs will be automatically pushed to the `HTTP/HTTPS` service. |
-| inactive_timeout | integer | optional    | 5             | [1,...] | The maximum time to refresh the buffer (in seconds). When the maximum refresh time is reached, all logs will be automatically pushed to the `HTTP/HTTPS` service regardless of whether the number of logs in the buffer reaches the maximum number set. |
-| buffer_duration  | integer | optional    | 60            | [1,...] | Maximum age in seconds of the oldest entry in a batch before the batch must be processed.|
-| max_retry_count  | integer | optional    | 0             | [0,...] | Maximum number of retries before removing from the processing pipe line.                 |
-| retry_delay      | integer | optional    | 1             | [0,...] | Number of seconds the process execution should be delayed if the execution fails.        |
-| include_req_body | boolean | optional    | false         | [false, true] | Whether to include the request body. false: indicates that the requested body is not included; true: indicates that the requested body is included. Note: if the request body is too big to be kept in the memory, it can't be logged due to Nginx's limitation. |
+|  include_req_body | boolean | optional    | false         | [false, true] | Whether to include the request body. false: indicates that the requested body is not included; true: indicates that the requested body is included. Note: if the request body is too big to be kept in the memory, it can't be logged due to Nginx's limitation. |
 | include_resp_body| boolean | optional    | false         | [false, true] | Whether to include the response body. The response body is included if and only if it is `true`. |
 | include_resp_body_expr  | array  | optional    |          |         | When `include_resp_body` is true, control the behavior based on the result of the [lua-resty-expr](https://github.com/api7/lua-resty-expr) expression. If present, only log the response body when the result is true. |
 | concat_method    | string  | optional    | "json"        | ["json", "new_line"] | Enum type: `json` and `new_line`. **json**: use `json.encode` for all pending logs. **new_line**: use `json.encode` for each pending log and concat them with "\n" line. |
 
+The plugin also has some common parameters that are handled by the batch processor(a component of APISIX ). The batch processor can be used to aggregate entries(logs/any data) and process them in a batch.
+This helps in reducing the number of requests that are being sent from the plugin per time frame to improve performance.
+Of course the batch processors provide an out-of-the-box configuration, so you don't have to worry about it.
+A brief overview of the parameters is provided here to help you choose.
+
+| Parameters       | Descriptions                                                                                                    |   |   |   |
+|------------------|----------------------------------------------------------------------------------------------------------------|---|---|---|
+| batch_max_size   | When the value is set to 0, the processor executes immediately. When the value is set to greater than or equal to 1, entries are aggregated until the maximum value or timeout is reached. |   |   |   |
+| inactive_timeout | This parameter indicates the maximum age in seconds that the buffer will be flushed without plugin activity information.                                     |   |   |   |
+| buffer_duration  | This parameter indicates the maximum age in seconds that the oldest entries in the batch must first be processed.                                               |   |   |   |
+| max_retry_count  | This parameter indicates the maximum number of retries before removal from the processing pipeline.                                                             |   |   |   |
+| retry_delay      | This parameter indicates the number of seconds the process should be delayed if it fails.                                                           |   |   |   |
+
+If you want to learn more about batch processors, please refer to [Batch-Processor](../batch-processor.md#配置) configuration section.

Review comment:
       The purpose of splitting is to unify management and reduce maintenance costs. I don't think the current method has changed compared to the previous method.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org