Add scarf pixels (#1418)

lecaros · web-flow · commit 5590b18b5970 · 2024-08-09T11:41:04.000-04:00
* pipeline: processors: metrics-selector: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* pipeline: processors: content-modifier: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-configuring-fluent-bit: multiline-parsing: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* pipeline: filters: type-converter: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* processors: sql: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* filters: log-to-metrics: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* filters: lua: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: monitoring: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: monitoring: grafana-dashboards-and-alerts add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: buffering-and-storage: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: backpressure: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: scheduling-and-retries: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: memory-management: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: troubleshooting: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* installation: getting-started-with-fluent-bit: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-fluent-bit: classic-mode: configuration-file: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-fluent-bit: yaml: configuration-file: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-fluent-bit: classic-mode: variables: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* inputs: process: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* pipeline: processors: labels: add scarf pixel

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-fluent-bit: classic-mode: configuration-file: move scarf pixel location for consistency

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

* administration: configuring-fluent-bit: classic-mode: variables: move scarf pixel location for consistency

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;

---------

Signed-off-by: lecaros &lt;lecaros@calyptia.com&gt;
diff --git a/administration/backpressure.md b/administration/backpressure.md
@@ -1,5 +1,7 @@
 # Backpressure
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=63e37cfe-9ce3-4a18-933a-76b9198958c1" />
+
 Under certain scenarios it is possible for logs or data to be ingested or created faster than the ability to flush it to some destinations. One such common scenario is when reading from big log files, especially with a large backlog, and dispatching the logs to a backend over the network, which takes time to respond. This generates backpressure leading to high memory consumption in the service.
 
 In order to avoid backpressure, Fluent Bit implements a mechanism in the engine that restricts the amount of data that an input plugin can ingest, this is done through the configuration parameters **Mem\_Buf\_Limit** and **storage.Max\_Chunks\_Up**.
diff --git a/administration/buffering-and-storage.md b/administration/buffering-and-storage.md
@@ -1,5 +1,7 @@
 # Buffering & Storage
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=cde12327-09ed-409c-ac02-7c0afa5eff51" />
+
 The end-goal of [Fluent Bit](https://fluentbit.io) is to collect, parse, filter and ship logs to a central place. In this workflow there are many phases and one of the critical pieces is the ability to do _buffering_ : a mechanism to place processed data into a temporary location until is ready to be shipped.
 
 By default when Fluent Bit processes data, it uses Memory as a primary and temporary place to store the records, but there are certain scenarios where it would be ideal to have a persistent buffering mechanism based in the filesystem to provide aggregation and data safety capabilities.
diff --git a/administration/configuring-fluent-bit/classic-mode/configuration-file.md b/administration/configuring-fluent-bit/classic-mode/configuration-file.md
@@ -4,6 +4,8 @@ description: This page describes the main configuration file used by Fluent Bit
 
 # Configuration File
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=5e67142e-3887-4b56-b940-18494bcc23a7" />
+
 One of the ways to configure Fluent Bit is using a main configuration file. Fluent Bit allows to use one configuration file which works at a global scope and uses the [Format and Schema](format-schema.md) defined previously.
 
 The main configuration file supports four types of sections:
diff --git a/administration/configuring-fluent-bit/classic-mode/variables.md b/administration/configuring-fluent-bit/classic-mode/variables.md
@@ -1,5 +1,7 @@
 # Variables
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=1731c7b5-34c6-424f-bfc6-88c2aa71e81f" />
+
 Fluent Bit supports the usage of environment variables in any value associated to a key when using a configuration file.
 
 The variables are case sensitive and can be used in the following format:
diff --git a/administration/configuring-fluent-bit/multiline-parsing.md b/administration/configuring-fluent-bit/multiline-parsing.md
@@ -2,6 +2,8 @@
 
 In an ideal world, applications might log their messages within a single line, but in reality applications generate multiple log messages that sometimes belong to the same context. But when is time to process such information it gets really complex. Consider application stack traces which always have multiple log lines.
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=e19a4c14-a9e4-4163-8f3a-52196eb9a585" />
+
 Starting from Fluent Bit v1.8, we have implemented a unified Multiline core functionality to solve all the user corner cases. In this section, you will learn about the features and configuration options available.
 
 ## Concepts
diff --git a/administration/configuring-fluent-bit/yaml/configuration-file.md b/administration/configuring-fluent-bit/yaml/configuration-file.md
@@ -2,6 +2,8 @@
 description: This page describes the yaml configuration file used by Fluent Bit
 ---
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=864c6f0e-8977-4838-8772-84416943548e" />
+
 # YAML Configuration File
 
 One of the ways to configure Fluent Bit is using a YAML configuration file that works at a global scope.
diff --git a/administration/memory-management.md b/administration/memory-management.md
@@ -1,5 +1,7 @@
 # Memory Management
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=5cc3ce54-e910-4ebf-85f5-f02530b3e11b" />
+
 In certain scenarios it would be ideal to estimate how much memory Fluent Bit could be using, this is very useful for containerized environments where memory limits are a must.
 
 In order to that we will assume that the input plugins have set the **Mem\_Buf\_Limit** option \(you can learn more about it in the [Backpressure](backpressure.md) section\).
diff --git a/administration/monitoring.md b/administration/monitoring.md
@@ -2,6 +2,8 @@
 description: Learn how to monitor your Fluent Bit data pipelines
 ---
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=e9ca51eb-7faf-491d-a62e-618a21c94506" />
+
 # Monitoring
 
 Fluent Bit comes with built-it features to allow you to monitor the internals of your pipeline, connect to Prometheus and Grafana, Health checks  and also connectors to use external services for such purposes:
@@ -308,6 +310,8 @@ Now when querying the metrics we get the aliases in place instead of the plugin
 
 ## Grafana Dashboard and Alerts
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=0b83cb05-4f52-4853-83cc-f4539b64044d" />
+
 Fluent Bit's exposed [prometheus style metrics](https://docs.fluentbit.io/manual/administration/monitoring) can be leveraged to create dashboards and alerts.
 
 The provided [example dashboard](https://github.com/fluent/fluent-bit-docs/tree/8172a24d278539a1420036a9434e9f56d987a040/monitoring/dashboard.json) is heavily inspired by [Banzai Cloud](https://banzaicloud.com)'s [logging operator dashboard](https://grafana.com/grafana/dashboards/7752) but with a few key differences such as the use of the `instance` label (see [why here](https://www.robustperception.io/controlling-the-instance-label)), stacked graphs and a focus on Fluent Bit metrics.
diff --git a/administration/scheduling-and-retries.md b/administration/scheduling-and-retries.md
@@ -1,5 +1,7 @@
 # Scheduling and Retries
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=a70a6008-106f-43c8-8930-243806371482" />
+
 [Fluent Bit](https://fluentbit.io) has an Engine that helps to coordinate the data ingestion from input plugins and calls the _Scheduler_ to decide when it is time to flush the data through one or multiple output plugins. The Scheduler flushes new data at a fixed time of seconds and the _Scheduler_ retries when asked.
 
 Once an output plugin gets called to flush some data, after processing that data it can notify the Engine three possible return statuses:
diff --git a/administration/troubleshooting.md b/administration/troubleshooting.md
@@ -1,5 +1,7 @@
 # Troubleshooting
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=759ddb3d-b363-4ee6-91fa-21025259767a" />
+
 * [Tap Functionality: generate events or records](troubleshooting.md#tap-functionality)
 * [Dump Internals Signal](troubleshooting#dump-internals-signal)
 
diff --git a/installation/getting-started-with-fluent-bit.md b/installation/getting-started-with-fluent-bit.md
@@ -2,6 +2,8 @@
 description: The following serves as a guide on how to install/deploy/upgrade Fluent Bit
 ---
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=e9732f9c-44a4-46d3-ab87-86138455c698" />
+
 # Getting Started with Fluent Bit
 
 ## Container Deployment
diff --git a/pipeline/filters/log_to_metrics.md b/pipeline/filters/log_to_metrics.md
@@ -2,6 +2,8 @@
 description: Generate metrics from logs
 ---
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=768830f6-8d2d-4231-9e5e-259ce6797ba5" />
+
 # Log To Metrics
 
 The _Log To Metrics Filter_ plugin allows you to generate log-derived metrics. It currently supports modes to count records, provide a gauge for field values or create a histogram. You can also match or exclude specific records based on regular expression patterns for values or nested values. This filter plugin does not actually act as a record filter and does not change or drop records. All records will pass this filter untouched and generated metrics will be emitted into a seperate metric pipeline.
diff --git a/pipeline/filters/lua.md b/pipeline/filters/lua.md
@@ -2,6 +2,8 @@
 
 The **Lua** filter allows you to modify the incoming records (even split one record into multiple records) using custom [Lua](https://www.lua.org/) scripts.
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=f519378e-536c-4b25-8949-ee6ed8d8d6c1" />
+
 Due to the necessity to have a flexible filtering mechanism, it is now possible to extend Fluent Bit capabilities by writing custom filters using Lua programming language. A Lua-based filter takes two steps:
 
 1. Configure the Filter in the main configuration
diff --git a/pipeline/filters/type-converter.md b/pipeline/filters/type-converter.md
@@ -2,6 +2,8 @@
 
 The _Type Converter Filter_ plugin allows to convert data type and append new key value pair.
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=8984f540-d95a-462b-8a08-09f72f5fab63" />
+
 This plugin is useful in combination with plugins which expect incoming string value.
 e.g. [filter_grep](grep.md), [filter_modify](modify.md)
 
diff --git a/pipeline/inputs/process.md b/pipeline/inputs/process.md
@@ -1,4 +1,5 @@
 # Process Metrics
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=91b97a84-1cd9-41fb-9189-a4f3b30b6bce" />
 
 _Process_ input plugin allows you to check how healthy a process is. It does so by performing a service check at every certain interval of time specified by the user.
 
diff --git a/pipeline/processors/content-modifier.md b/pipeline/processors/content-modifier.md
@@ -2,6 +2,8 @@
 
 The **content_modifier** processor allows you to manipulate the messages, metadata/attributes and content of Logs and Traces.
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=ee1ad690-a3e9-434f-9635-3e53c670e96c" />
+
 Similar to the functionality exposed by filters, this processor presents a unified mechanism to perform such operations for data manipulation. The most significant difference is that processors perform better than filters, and when chaining them, there are no encoding/decoding performance penalties.
 
 Note that processors and this specific component can only be enabled using the new YAML configuration format. Classic mode configuration format doesn't support processors.
diff --git a/pipeline/processors/labels.md b/pipeline/processors/labels.md
@@ -1,4 +1,5 @@
 # Labels
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=1e9a2474-00c3-4d8d-b170-79996be7af79" />
 
 The **labels** processor lets you manipulate the labels of metrics.
 
diff --git a/pipeline/processors/metrics-selector.md b/pipeline/processors/metrics-selector.md
@@ -2,6 +2,8 @@
 
 The **metric_selector** processor allows you to select metrics to include or exclude (similar to the `grep` filter for logs).
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=326269f3-cfea-472d-9169-1de32c142b90" />
+
 ## Configuration Parameters <a id="config"></a>
 
 The native processor plugin supports the following configuration parameters:
diff --git a/pipeline/processors/sql.md b/pipeline/processors/sql.md
@@ -2,6 +2,8 @@
 
 The **sql** processor provides a simple interface to select content from Logs by also supporting conditional expressions.
 
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=6bd80893-c66f-4950-9e6d-c21358e9e8c9" />
+
 Our SQL processor does not depend on a database or indexing; it runs everything on the fly (this is good). We don't have the concept of tables but you run the query on the STREAM.
 
 Note that this processor differs from the "stream processor interface" that runs after the filters; this one can only be used in the processor's section of the input plugins when using YAML configuration mode.
