GitBook: [master] 9 pages and 7 assets modified

Author: agup006

.gitbook/assets/image (3) (2) (2) (4) (4) (3) (7).png

@@ -6,7 +6,7 @@ description: Convert Unstructured to Structured messages
 
 Dealing with raw strings or unstructured messages is a constant pain; having a structure is highly desired. Ideally we want to set a structure to the incoming data by the Input Plugins as soon as they are collected:
 
-![](../../.gitbook/assets/logging_pipeline_parser%20%281%29%20%281%29%20%281%29%20%281%29%20%282%29%20%282%29%20%282%29%20%283%29%20%283%29%20%283%29%20%282%29.png)
+![](../../.gitbook/assets/logging_pipeline_parser%20%281%29%20%281%29%20%281%29%20%281%29%20%282%29%20%282%29%20%282%29%20%283%29%20%283%29%20%283%29%20%283%29%20%282%29.png)
 
 The Parser allows you to convert from unstructured to structured data. As a demonstrative example consider the following Apache \(HTTP Server\) log entry:
 

… (1) (1) (2) (2) (2) (3) (3) (3) (1).png … (1) (2) (2) (2) (3) (3) (3) (3) (1).png.gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (1).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (1).png .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (1).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (1).png

@@ -76,3 +76,4 @@ Alpine Linux uses Musl C library instead of Glibc. Musl is not fully compatible
 Our Docker containers images are deployed thousands of times per day, we take security and stability very seriously.
 
 The _latest_ tag _most of the time_ points to the latest stable image. When we release a major update to Fluent Bit like for example from v1.3.x to v1.4.0, we don't move _latest_ tag until 2 weeks after the release. That give us extra time to verify with our community that everything works as expected.
+

… (1) (1) (2) (2) (2) (3) (3) (3) (2).png … (1) (2) (2) (2) (3) (3) (3) (3) (2).png.gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (2).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (2).png .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (2).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (2).png

@@ -2,9 +2,9 @@
 
 ## Stable
 
-For production systems, we strongly suggest that you always get the latest stable release from our web site, you can get the official tarballs \(.tar.gz\) from the following link:
+For production systems, we strongly suggest that you always get the latest stable release from our web site, you can get the official tarballs \(.tar.gz\) from using the following link pattern:
 
-[https://fluentbit.io/download/](https://fluentbit.io/download/)
+https://fluentbit.io/release/1.7/fluent-bit-<release version>. For example for version 1.7.4 the link is the following: [https://fluentbit.io/releases/1.7/fluent-bit-1.7.4.tar.gz](https://fluentbit.io/releases/1.7/fluent-bit-1.7.4.tar.gz)
 
 ## Development
 

… (1) (1) (1) (2) (2) (2) (3) (3) (3).png … (1) (2) (2) (2) (3) (3) (3) (3) (3).png.gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (3).png .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3).png renamed to .gitbook/assets/logging_pipeline_parser (1) (1) (1) (1) (2) (2) (2) (3) (3) (3) (3) (3).png

@@ -192,3 +192,4 @@ To create a ZIP package, call `cpack` as follows:
 ```text
 % cpack -G ZIP
 ```
+

concepts/data-pipeline/parser.md

@@ -14,3 +14,4 @@ It's strongly recommended to always use the stable release of Fluent Bit recipe
 ## Fluent Bit and other architectures
 
 Fluent Bit >= v1.1.x fully supports x86\_64, x86, arm32v7 and arm64v8.
+

installation/docker.md

@@ -24,7 +24,7 @@ The plugin supports the following configuration parameters:
 | DB | Specify the database file to keep track of monitored files and offsets. |  |
 | DB.sync | Set a default synchronization \(I/O\) method. Values: Extra, Full, Normal, Off. This flag affects how the internal SQLite engine do synchronization to disk, for more details about each option please refer to [this section](https://www.sqlite.org/pragma.html#pragma_synchronous). Most of workload scenarios will be fine with `normal` mode, but if you really need full synchronization after every write operation you should set `full` mode. Note that `full` has a high I/O performance cost. | normal |
 | DB.locking | Specify that the database will be accessed only by Fluent Bit. Enabling this feature helps to increase performance when accessing the database but it restrict any external tool to query the content. | false |
-| DB.journal_mode | sets the journal mode for databases \(WAL\). Enabling WAL provides higher performance. Note that WAL is not compatible with shared network file systems. | WAL |
+| DB.journal\_mode | sets the journal mode for databases \(WAL\). Enabling WAL provides higher performance. Note that WAL is not compatible with shared network file systems. | WAL |
 | Mem\_Buf\_Limit | Set a limit of memory that Tail plugin can use when appending data to the Engine. If the limit is reach, it will be paused; when the data is flushed it resumes. |  |
 | exit\_on\_eof | When reading a file will exit as soon as it reach the end of the file. Useful for bulk load and tests | false |
 | Parser | Specify the name of a parser to interpret the entry as a structured message. |  |
@@ -198,12 +198,11 @@ Those two files aims to support the `WAL` mechanism that helps to improve perfor
 
 ### WAL and Memory Usage
 
-The `WAL` mechanism give us higher performance but also might increase the memory usage by Fluent Bit. Most of this usage comes from the memory mapped and cached pages. In some cases you might see that memory usage keeps a bit high giving the impression of a memory leak, but actually is not relevant unless you want your memory metrics back to normal.
-Starting from Fluent Bit v1.7.3 we introduced the new option ```db.journal_mode``` mode that sets the journal mode for databases, by default it will be ```WAL (Write-Ahead Logging)```, currently allowed configurations for ```db.journal_mode``` are ```DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF``` .
-
+The `WAL` mechanism give us higher performance but also might increase the memory usage by Fluent Bit. Most of this usage comes from the memory mapped and cached pages. In some cases you might see that memory usage keeps a bit high giving the impression of a memory leak, but actually is not relevant unless you want your memory metrics back to normal. Starting from Fluent Bit v1.7.3 we introduced the new option `db.journal_mode` mode that sets the journal mode for databases, by default it will be `WAL (Write-Ahead Logging)`, currently allowed configurations for `db.journal_mode` are `DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF` .
 
 ## File Rotation
 
 File rotation is properly handled, including logrotate's _copytruncate_ mode.
 
 Note that the `Path` patterns **cannot** match the rotated files. Otherwise, the rotated file would be read again and lead to duplicate records.
+