Moves figures to local directories because they weren't displayed in …

…production

content/chapter-concepts/concepts-logging-with-syslog-ng/concepts-route-of-a-message/_index.md

@@ -9,7 +9,7 @@ weight:  100
 
 The following procedure illustrates the route of a log message from its source on the {{% param "product.abbrev" %}} client to its final destination on the central {{% param "product.abbrev" %}} server.
 
-![The route of a log message](/images/figures/fig-syslog-ng-logging-01.png)
+![The route of a log message](fig-syslog-ng-logging-01.png)
 
 ## Steps:
 

content/chapter-concepts/concepts-modes-of-operation/concepts-client-mode/_index.md

@@ -4,6 +4,6 @@ weight:  100
 ---
 <!-- DISCLAIMER: This file is based on the syslog-ng Open Source Edition documentation https://github.com/balabit/syslog-ng-ose-guides/commit/2f4a52ee61d1ea9ad27cb4f3168b95408fddfdf2 and is used under the terms of The syslog-ng Open Source Edition Documentation License. The file has been modified by Axoflow. -->
 
-![Processing logs in client mode](/images/figures/fig-client_mode01.png)
+![Processing logs in client mode](fig-client_mode01.png)
 
 In client mode, {{% param "product.abbrev" %}} collects the local logs generated by the host and forwards them through a network connection to the central {{% param "product.abbrev" %}} server or to a relay. Clients often also log the messages locally into files.

content/chapter-concepts/concepts-modes-of-operation/concepts-relay-mode/_index.md

@@ -4,7 +4,7 @@ weight:  300
 ---
 <!-- DISCLAIMER: This file is based on the syslog-ng Open Source Edition documentation https://github.com/balabit/syslog-ng-ose-guides/commit/2f4a52ee61d1ea9ad27cb4f3168b95408fddfdf2 and is used under the terms of The syslog-ng Open Source Edition Documentation License. The file has been modified by Axoflow. -->
 
-![Processing logs in relay mode](/images/figures/fig-relay_mode01.png)
+![Processing logs in relay mode](fig-relay_mode01.png)
 
 In relay mode, {{% param "product.abbrev" %}} receives logs through the network from {{% param "product.abbrev" %}} clients and forwards them to the central {{% param "product.abbrev" %}} server using a network connection. Relays also log the messages from the relay host into a local file, or forward these messages to the central {{% param "product.abbrev" %}} server.
 

content/chapter-concepts/concepts-modes-of-operation/concepts-server-mode/_index.md

@@ -4,7 +4,7 @@ weight:  500
 ---
 <!-- DISCLAIMER: This file is based on the syslog-ng Open Source Edition documentation https://github.com/balabit/syslog-ng-ose-guides/commit/2f4a52ee61d1ea9ad27cb4f3168b95408fddfdf2 and is used under the terms of The syslog-ng Open Source Edition Documentation License. The file has been modified by Axoflow. -->
 
-![Processing logs in server mode](/images/figures/fig-server_mode01.png)
+![Processing logs in server mode](fig-server_mode01.png)
 
 In server mode, {{% param "product.abbrev" %}} acts as a central log-collecting server. It receives messages from {{% param "product.abbrev" %}} clients and relays over the network, and stores them locally in files, or passes them to other applications, for example, log analyzers.
 

content/chapter-correlating-log-messages/grouping-by-parser/_index.md

@@ -11,7 +11,7 @@ The {{% param "product.abbrev" %}} application can correlate log messages that m
 
 ## How the grouping-by() parser works
 
-![How the grouping-by() parser works](/images/figures/fig-grouping-by-parser-works.png)
+![How the grouping-by() parser works](fig-grouping-by-parser-works.png)
 
 The `grouping-by()` parser has three options that determine if a message is added to a context: `scope()`, `key()`, and `where()`.
 

content/chapter-destinations/configuring-destinations-kafka-c/_index.md

@@ -12,4 +12,4 @@ As of {{% param "product.abbrev" %}} version 3.21, the new C implementation of t
 
 <span id="how-it-works"></span>
 
-![How the C implementation of the kafka destination works with {{% param "product.abbrev" %}}](/images/figures/fig-kafka-c-implementation.png)
+![How the C implementation of the kafka destination works with {{% param "product.abbrev" %}}](fig-kafka-c-implementation.png)

content/chapter-encrypted-transport-tls/concepts-tls/_index.md

@@ -14,7 +14,7 @@ This chapter describes how to use TLS encryption when using the standard syslog
 
 TLS uses certificates to authenticate and encrypt the communication, as illustrated on the following figure:
 
-![Authenticating and encrypting the communication with TLS](/images/figures/fig-certificate-based-authentication01.png)
+![Authenticating and encrypting the communication with TLS](fig-certificate-based-authentication01.png)
 
 The client authenticates the server by requesting its certificate and public key. Optionally, the server can also request a certificate from the client, thus mutual authentication is also possible.
 

content/chapter-examples/example-chroot/_index.md

@@ -8,7 +8,7 @@ weight: 600
 
 To collect logs from a chroot using an AxoSyslog client running on the host, complete the following steps:
 
-![Collecting logs from chroot](/images/figures/fig-chroot01.png)
+![Collecting logs from chroot](fig-chroot01.png)
 
 ## Steps:
 

content/chapter-parsers/chapter-patterndb/concepts-pattern-databases/syslog-ng-patterndb-operation/_index.md

@@ -4,7 +4,7 @@ weight:  300
 ---
 <!-- DISCLAIMER: This file is based on the syslog-ng Open Source Edition documentation https://github.com/balabit/syslog-ng-ose-guides/commit/2f4a52ee61d1ea9ad27cb4f3168b95408fddfdf2 and is used under the terms of The syslog-ng Open Source Edition Documentation License. The file has been modified by Axoflow. -->
 
-![How pattern matching works](/images/figures/fig-patterndb-pattern.png)
+![How pattern matching works](fig-patterndb-pattern.png)
 
 The followings describe how patterns work. This information applies to program patterns and message patterns alike, even though message patterns are used to illustrate the procedure.
 

content/chapter-parsers/chapter-patterndb/concepts-pattern-databases/syslog-ng-patterndb-structure/_index.md

@@ -6,7 +6,7 @@ weight:  100
 
 The pattern database is organized as follows:
 
-![Pattern database structure](/images/figures/fig-patterndb-structure.png)
+![Pattern database structure](fig-patterndb-structure.png)
 
   - The pattern database consists of rulesets. A ruleset consists of a Program Pattern and a set of rules: the rules of a ruleset are applied to log messages if the name of the application that sent the message matches the Program Pattern of the ruleset. The name of the application (the content of the `${PROGRAM}` macro) is compared to the Program Patterns of the available rulesets, and then the rules of the matching rulesets are applied to the message. (If the content of the `${PROGRAM}` macro is not the proper name of the application, you can use the `program-template()` option to specify it.)
 

content/chapter-routing-filters/concepts-diskbuffer/_index.md

@@ -25,7 +25,7 @@ The {{% param "product.abbrev" %}} application supports two types of disk buffer
 
 When you use disk-based buffering, and the `reliable()` option is set to `no`, {{% param "product.abbrev" %}} handles outgoing messages the following way:
 
-![Disk buffering](/images/figures/disk-buffer-diagram-normal.png)
+![Disk buffering](disk-buffer-diagram-normal.png)
 
   - *Output queue*: In-memory queue. If there is space left in it, {{% param "product.abbrev" %}} puts the message into this queue first . Messages stored here are processed faster, because {{% param "product.abbrev" %}} can skip writing to, and reading from the disk, as well as serializing or deserializing the message, saving I/O and processor time as a result. The contents of the in-memory output queue are persisted to the disk-buffer file during {{% param "product.abbrev" %}} reload, restart or stop, but they cannot be persisted if in the event of power failures, or if {{% param "product.abbrev" %}} crashes. By default, the output queue can hold 1000 messages (you can adjust this number using the `quot-size()` option).
 
@@ -57,7 +57,7 @@ The `flow-control-window-bytes()` option determines when flow-control is trigger
 
 If the control window is full, the flow-control completely stops reading incoming messages from the source. (As a result, `flow-control-window-bytes()` must be at least as large as `log-iw-size()` times the average message size.)
 
-![Reliable disk buffering](/images/figures/disk-buffer-diagram-reliable.png)
+![Reliable disk buffering](disk-buffer-diagram-reliable.png)
 
   - *Output queue*: In-memory and disk queue. If there is space left in it, {{% param "product.abbrev" %}} puts the message into this queue first. In case of reliable disk-buffer, in addition to storing the message in memory, it is stored directly in the disk-buffer file as well for safety reasons (see the next point). Messages stored here are processed faster, because {{% param "product.abbrev" %}} can skip reading from the disk, and deserializing the message, saving I/O and processor time. By default, the output queue can hold 1000 messages (you can adjust it using the `quot-size()` option).
 

content/chapter-routing-filters/concepts-flow-control/_index.md

@@ -10,11 +10,11 @@ The AxoSyslog application monitors (polls) the sources defined in its configurat
 
 In large-traffic environments many messages can arrive during a single poll loop, therefore AxoSyslog reads only a fixed number of messages from each source. The `log-fetch-limit()` option specifies the number of messages read during a poll loop from a single source.
 
-![Reading messages](/images/figures/fig-syslog-ng-io-01.png)
+![Reading messages](fig-syslog-ng-io-01.png)
 
 TCP and unix-stream sources can receive the logs from several incoming connections (for example, many different clients or applications). For such sources, AxoSyslog reads messages from every connection, thus the `log-fetch-limit()` parameter applies individually to every connection of the source.
 
-![Reading messages from a stream](/images/figures/fig-syslog-ng-io-02.png)
+![Reading messages from a stream](fig-syslog-ng-io-02.png)
 
 ## Log paths without flow-control
 
@@ -121,7 +121,7 @@ Hazard of data loss! For destinations other than file, soft flow-control is not
 
 The AxoSyslog application handles outgoing messages the following way:
 
-![Disk buffering](/images/figures/disk-buffer-diagram-normal.png)
+![Disk buffering](/chapter-routing-filters/concepts-diskbuffer/disk-buffer-diagram-normal.png)
 
   - *Output queue*: Messages from the output queue are sent to the target AxoSyslog server. The AxoSyslog application puts the outgoing messages directly into the output queue, unless the output queue is full. The output queue can hold 64 messages, this is a fixed value and cannot be modified.