fix: broken links after lapi/lp merge (#703)

LaurenceJJones · web-flow · commit 822424a89b91 · 2024-12-26T13:15:43.000Z
diff --git a/crowdsec-docs/docs/appsec/configuration.md b/crowdsec-docs/docs/appsec/configuration.md
@@ -9,7 +9,7 @@ sidebar_position: 6
 Configuring the AppSec Component usually requires the use of multiple files:
 
  - [AppSec rules](/appsec/rules_syntax.md) allow you to write a signature to detect and/or block malevolent requests. [You can find more information about the syntax here](/appsec/rules_syntax.md)
- - [acquisition configuration](/data_sources/appsec.md) indicates which port is the AppSec Component listening on, and which AppSec configuration it will use.
+ - [acquisition configuration](/log_processor/data_sources/appsec.md) indicates which port is the AppSec Component listening on, and which AppSec configuration it will use.
  - AppSec configuration tells which rules are loaded in in-band (blocking) and out-of-band (non-blocking)
   phases. [it as well allows you to tweak the behavior of the component via the powerful expr bindings](/appsec/rules_syntax.md)
 
diff --git a/crowdsec-docs/docs/appsec/create_rules.md b/crowdsec-docs/docs/appsec/create_rules.md
@@ -168,7 +168,7 @@ Let's get over the relevant parts:
 
 - `name` is how the alert will appear to users (in `cscli` or [the console](http://app.crowdsec.net))
 - `description` is how your scenario will appear in [the hub](https://hub.crowdsec.net)
-- `labels` section is used both in [the hub](https://hub.crowdsec.net) and [the console](https://app.crowdsec.net). [It must follow rules described here](/scenarios/format.md#labels)
+- `labels` section is used both in [the hub](https://hub.crowdsec.net) and [the console](https://app.crowdsec.net). [It must follow rules described here](/log_processor/scenarios/format.md#labels)
 - `rules` describe what we want to match:
   - a [`METHOD`](/appsec/rules_syntax.md#target) [equal to `POST`](/appsec/rules_syntax.md#match)
   - the presence of a header ([`HEADERS_NAME`](/appsec/rules_syntax.md#target)) with a name that once transformed to `lowercase`, is `x-foobar-bypass`
diff --git a/crowdsec-docs/docs/appsec/quickstart/nginxopenresty.mdx b/crowdsec-docs/docs/appsec/quickstart/nginxopenresty.mdx
@@ -23,7 +23,7 @@ Additionally, we'll show how to monitor these alerts through the [console](https
 1. If you're new to the [AppSec Component](/appsec/intro.md#introduction) or **W**eb **A**pplication **F**irewalls, start with the [Introduction](/appsec/intro.md#introduction) for a better understanding.
 
 2. It's assumed that you have already installed:
-   - **CrowdSec [Security Engine](intro.mdx)**: for installation, refer to the [QuickStart guide](/u/getting_started/installation/linux). The AppSec Component, which analyzes HTTP requests, is included within the security engine as a [Acquisition](data_sources/appsec.md).
+   - **CrowdSec [Security Engine](intro.mdx)**: for installation, refer to the [QuickStart guide](/u/getting_started/installation/linux). The AppSec Component, which analyzes HTTP requests, is included within the security engine as a [Acquisition](/log_processor/data_sources/appsec.md).
    - One of the supported web servers for this guide:
         - Nginx **[Remediation Component](/u/bouncers/intro)**: installation instructions are available in the [QuickStart guide](/u/bouncers/nginx).
         - OpenResty **[Remediation Component](/u/bouncers/intro)**: installation instructions are available in the [QuickStart guide](/u/bouncers/openresty).
@@ -89,7 +89,7 @@ We do not recommend exposing the AppSec Component to the internet. It should onl
 ::: 
 
 :::info
-You can find more about the [supported options for the acquisition here](/data_sources/appsec.md)
+You can find more about the [supported options for the acquisition here](/log_processor/data_sources/appsec.md)
 :::
 
 You can now restart CrowdSec:
diff --git a/crowdsec-docs/docs/appsec/quickstart/traefik.mdx b/crowdsec-docs/docs/appsec/quickstart/traefik.mdx
@@ -20,7 +20,7 @@ Additionally, we'll show how to monitor these alerts through the [console](https
 1. If you're new to the [AppSec Component](/appsec/intro.md#introduction) or **W**eb **A**pplication **F**irewalls, start with the [Introduction](/appsec/intro.md#introduction) for a better understanding.
 
 2. It's assumed that you have already installed:
-   - **CrowdSec [Security Engine](intro.mdx)**: for installation, refer to the [QuickStart guide](/u/getting_started/installation/linux). The AppSec Component, which analyzes HTTP requests, is included within the security engine as a [Acquisition](data_sources/appsec.md).
+   - **CrowdSec [Security Engine](intro.mdx)**: for installation, refer to the [QuickStart guide](/u/getting_started/installation/linux). The AppSec Component, which analyzes HTTP requests, is included within the security engine as a [Acquisition](/log_processor/data_sources/appsec.md).
    -  Traefik Plugin **[Remediation Component](/u/bouncers/intro)**: Thanks to [maxlerebourg](https://github.com/maxlerebourg) and team they created a [Traefik Plugin](https://plugins.traefik.io/plugins/6335346ca4caa9ddeffda116/crowdsec-bouncer-traefik-plugin) that allows you to block requests directly from Traefik.
 
 :::info
diff --git a/crowdsec-docs/docs/configuration/crowdsec_configuration.md b/crowdsec-docs/docs/configuration/crowdsec_configuration.md
@@ -97,7 +97,7 @@ always replaced.
 - `bouncers/crowdsec-blocklist-mirror.yaml`
 
 In the case of `profiles.yaml`, the files are read as a whole (as if they were
-attached) instead of merged. See [profiles - introduction](/profiles/intro.md).
+attached) instead of merged. See [profiles - introduction](/local_api/profiles/intro.md).
 
 
 ## Configuration directives
diff --git a/crowdsec-docs/docs/contributing/hub.md b/crowdsec-docs/docs/contributing/hub.md
@@ -41,7 +41,7 @@ In other cases, having a parser for `SpecificWebServer` access logs would justif
 
 ### Scenarios
 
-When you create a scenario, you must fill some fields in the [`labels`](/scenarios/format.md#labels), else the CI won't accept the contribution.
+When you create a scenario, you must fill some fields in the [`labels`](/log_processor/scenarios/format.md#labels), else the CI won't accept the contribution.
 Those `labels` are:
  - `classification`: this array contains the CVE ID and the [Mitre Techniques](https://attack.mitre.org/techniques/enterprise/) related to the scenario (when applicable)
  - `spoofable`: between 0 and 3, is the chance that the attacker behind the attack can spoof its origin
@@ -50,7 +50,7 @@ Those `labels` are:
  - `label` : a human readable name for the scenario
  - `cti` : (optional) true or false, used to specify that a scenario is mainly used for audit rather than detecting a threat 
 
-[Here](/scenarios/format.md#labels) is the `labels` documentation for more information.
+[Here](/log_processor/scenarios/format.md#labels) is the `labels` documentation for more information.
 
 Here is an example:
 
diff --git a/crowdsec-docs/docs/expr/file_helpers.md b/crowdsec-docs/docs/expr/file_helpers.md
@@ -5,7 +5,7 @@ sidebar_position: 3
 ---
 
 :::info
-File helpers do not load the file into memory, but rather use a cache on initial startup to avoid loading the same file multiple times. Please see [the data property](/scenarios/format.md#data) on how to configure the Security Engine to load the file.
+File helpers do not load the file into memory, but rather use a cache on initial startup to avoid loading the same file multiple times. Please see [the data property](/log_processor/scenarios/format.md#data) on how to configure the Security Engine to load the file.
 :::
 
 ### `File(FileName) []string`
diff --git a/crowdsec-docs/docs/expr/intro.md b/crowdsec-docs/docs/expr/intro.md
@@ -8,17 +8,17 @@ sidebar_position: 1
 
 Several places of CrowdSec's configuration use [expr](https://github.com/antonmedv/expr), notably :
 
- - [Filters](/parsers/format.md#filter) that are used to determine events eligibility in parsers, scenarios and profiles
- - [Statics](/parsers/format.md#statics) use expr in the `expression` directive, to compute complex values
- - [Whitelists](/whitelist/introduction.md) rely on `expression` directive to allow more complex whitelists filters
- - [Profiles](/profiles/intro.md) rely on `filters` directives to find matching profiles 
+ - [Filters](/log_processor/parsers/format.md#filter) that are used to determine events eligibility in parsers, scenarios and profiles
+ - [Statics](/log_processor/parsers/format.md#statics) use expr in the `expression` directive, to compute complex values
+ - [Whitelists](/log_processor/whitelist/introduction.md) rely on `expression` directive to allow more complex whitelists filters
+ - [Profiles](/local_api/profiles/intro.md) rely on `filters` directives to find matching profiles 
 
 To learn more about [expr](https://github.com/antonmedv/expr), [check the github page of the project](https://github.com/antonmedv/expr/blob/master/docs/Language-Definition.md).
 
 
 When CrowdSec relies on `expr`, a context is provided to let the expression access relevant objects :
 
  - `evt.` is the representation of the current event and is the most relevant object
- - in [profiles](/profiles/intro.md), alert is accessible via the `Alert` object
+ - in [profiles](/local_api/profiles/intro.md), alert is accessible via the `Alert` object
 
 If the `debug` is enabled (in the scenario or parser where expr is used), additional debug will be displayed regarding evaluated expressions.
diff --git a/crowdsec-docs/docs/expr/other_helpers.md b/crowdsec-docs/docs/expr/other_helpers.md
@@ -25,7 +25,7 @@ Parses unix timestamp string and returns RFC3339 formatted time
 ### `GetFromStash(cache string, key string)`
 
 `GetFromStash` retrieves the value for `key` in the named `cache`.
-The cache are usually populated by [parser's stash section](/parsers/format.md#stash).
+The cache are usually populated by [parser's stash section](/log_processor/parsers/format.md#stash).
 An empty string if the key doesn't exist (or has been evicted), and error is raised if the `cache` doesn't exist.
 
 ## Others
diff --git a/crowdsec-docs/docs/local_api/notification_plugins/intro.md b/crowdsec-docs/docs/local_api/notification_plugins/intro.md
@@ -13,7 +13,7 @@ Plugins are defined and used at the LAPI level, so if you are running a multi-se
 
 By default all plugins are shipped with CrowdSec are within the install package, and can trivially be enabled without further need to install additional packages.
 
-Refer directly to each plugin's dedicated documentation and keep in mind that plugins needs to be enabled/dispatched at the [profile](/profiles/intro.md) level via the dedicated `notifications` section (defaults to `/etc/crowdsec/profiles.yaml`.md).
+Refer directly to each plugin's dedicated documentation and keep in mind that plugins needs to be enabled/dispatched at the [profile](/local_api/profiles/intro.md) level via the dedicated `notifications` section (defaults to `/etc/crowdsec/profiles.yaml`.md).
 
 Plugin binaries are present in `config_paths.plugin_dir` (defaults to `/var/lib/crowdsec/plugins/`), and their individual configuration are present in `config_paths.notification_dir` (defaults to `/etc/crowdsec/notifications/`)
 
diff --git a/crowdsec-docs/docs/local_api/notification_plugins/writing_your_own_plugin.md b/crowdsec-docs/docs/local_api/notification_plugins/writing_your_own_plugin.md
@@ -7,7 +7,7 @@ In this guide we will implement a plugin in Go, which dispatches an email with s
 
 Full code for this plugin can be found in [crowdsec repo](https://github.com/crowdsecurity/crowdsec/tree/master/plugins/notifications/email)
 
-Before we begin, make sure you read [intro](/notification_plugins/intro.md)
+Before we begin, make sure you read [intro](/local_api/notification_plugins/intro.md)
 
 Let's start by creating a new go project in a fresh directory:
 
diff --git a/crowdsec-docs/docs/local_api/profiles/format.md b/crowdsec-docs/docs/local_api/profiles/format.md
@@ -158,4 +158,4 @@ notifications:
   - notification_plugin2
 ```
 
-The [list of notification plugins](/notification_plugins/intro.md) to which the alert should be fed.
+The [list of notification plugins](/local_api/notification_plugins/intro.md) to which the alert should be fed.
diff --git a/crowdsec-docs/docs/log_processor/alert_context/intro.md b/crowdsec-docs/docs/log_processor/alert_context/intro.md
@@ -5,13 +5,13 @@ title: Alert Context
 
 ## Introduction
 
-As the [Log Processor](log_processor/intro.mdx) processes logs, it will detect patterns of interest known as [Scenarios](log_processor/scenarios/introduction.mdx). When a scenario is detected, an alert is generated and sent to the [Local API](local_api/intro.md) (LAPI) for evaluation.
+As the [Log Processor](log_processor/intro.mdx) processes logs, it will detect patterns of interest known as [Scenarios](/log_processor/scenarios/introduction.mdx). When a scenario is detected, an alert is generated and sent to the [Local API](local_api/intro.md) (LAPI) for evaluation.
 
 When the alert is generated you can define additional Alert Context that can be sent along with the alert to give you context about the alert. This can be useful when you host multiple applications on the same server and you want to know which application generated the alert.
 
 ### Format
 
-The format of Alert Context are key value pairs that are sent along with the alert. When you install some [Collections](log_processor/collections/intro.md) you will see that they come with Alert Context pre-configured.
+The format of Alert Context are key value pairs that are sent along with the alert. When you install some [Collections](/log_processor/collections/introduction.md) you will see that they come with Alert Context pre-configured.
 
 For example if you install the `crowdsecurity/nginx` collection you will see that the `http_base` context is added:
 
diff --git a/crowdsec-docs/docs/log_processor/data_sources/cloudwatch.md b/crowdsec-docs/docs/log_processor/data_sources/cloudwatch.md
@@ -7,7 +7,7 @@ This module allows the `Security Engine` to acquire logs from AWS's cloudwatch s
 
 :::info
 
-Instead of using this datasource, we recommend setting up a log subscription filter in your AWS account to push the logs to a kinesis stream, and use the [kinesis datasource](/data_sources/kinesis.md) to read them.
+Instead of using this datasource, we recommend setting up a log subscription filter in your AWS account to push the logs to a kinesis stream, and use the [kinesis datasource](/log_processor/data_sources/kinesis.md) to read them.
 
 :::
 
diff --git a/crowdsec-docs/docs/log_processor/parsers/create.md b/crowdsec-docs/docs/log_processor/parsers/create.md
@@ -119,10 +119,10 @@ statics:
     value: yes
 ```
 
- - a [filter](/parsers/format.md#filter) : if the expression is `true`, the event will enter the parser, otherwise, it won't
- - a [onsuccess](/parsers/format.md#onsuccess) : defines what happens when the event was successfully parsed : shall we continue ? shall we move to next stage ? etc.
+ - a [filter](/log_processor/parsers/format.md#filter) : if the expression is `true`, the event will enter the parser, otherwise, it won't
+ - a [onsuccess](/log_processor/parsers/format.md#onsuccess) : defines what happens when the event was successfully parsed : shall we continue ? shall we move to next stage ? etc.
  - a `name` & a `description`
- - some [statics](/parsers/format.md#statics) that will modify the event
+ - some [statics](/log_processor/parsers/format.md#statics) that will modify the event
  - a `debug` flag that allows to enable local debugging information
  - a `grok` pattern to capture some data in logs
 
@@ -230,7 +230,7 @@ Various changes have been made here :
  - We created to patterns to capture the two relevant type of log lines, Using an [online grok debugger](https://grokdebug.herokuapp.com/) or an [online regex debugger](https://www.debuggex.com/) [2]
 )
  - We keep track of the username and the source_ip (Please note that setting the source_ip in `evt.Meta.source_ip` and `evt.Parsed.source_ip` is important [1])
- - We setup various [statics](/parsers/format.md#statics) information to classify the log type [3]
+ - We setup various [statics](/log_processor/parsers/format.md#statics) information to classify the log type [3]
 
 
 
@@ -299,7 +299,7 @@ __note: we can see that our log line `accepted connection for user 'toto' from '
 We have now a fully functional parser for myservice logs !
 We can either deploy it to our production systems to do stuff, or even better, contribute to the hub !
 
-If you want to know more about directives and possibilities, take a look at [the parser reference documentation](/parsers/format.md) !
+If you want to know more about directives and possibilities, take a look at [the parser reference documentation](/log_processor/parsers/format.md) !
 
 See as well [this blog article](https://crowdsec.net/blog/how-to-write-crowdsec-parsers-and-scenarios) on the topic.
 
diff --git a/crowdsec-docs/docs/log_processor/parsers/enricher.md b/crowdsec-docs/docs/log_processor/parsers/enricher.md
@@ -7,7 +7,7 @@ sidebar_position: 4
 
 # Enrichers
 
-Enrichers are [parsers](/parsers/introduction.mdx) that can rely on external methods to provide extra contextual information to the event. The enrichers are usually in the `s02-enrich`  [stage](/parsers/introduction.mdx#stages) (after most of the parsing happened).
+Enrichers are [parsers](/log_processor/parsers/introduction.mdx) that can rely on external methods to provide extra contextual information to the event. The enrichers are usually in the `s02-enrich`  [stage](/log_processor/parsers/introduction.mdx#stages) (after most of the parsing happened).
 
 Enrichers functions should all accept a string as a parameter, and return an associative string array, that will be automatically merged into the `Enriched` map of the [`Event`](/expr/event.md).
 
diff --git a/crowdsec-docs/docs/log_processor/parsers/format.md b/crowdsec-docs/docs/log_processor/parsers/format.md
@@ -28,7 +28,7 @@ statics:
     expression: "evt.Parsed.src_ip"
 ```
 
-The parser nodes are processed sequentially based on the alphabetical order of [stages](/parsers/introduction.mdx#stages) and subsequent files.
+The parser nodes are processed sequentially based on the alphabetical order of [stages](/log_processor/parsers/introduction.mdx#stages) and subsequent files.
 If the node is considered successful (grok is present and returned data or no grok is present) and "onsuccess" equals to `next_stage`, then the event is moved to the next stage.
 
 ## Parser trees
@@ -511,4 +511,4 @@ A parser is considered "successful" if :
   
 ### Patterns documentation
 
-You can find [exhaustive patterns documentation here](/parsers/patterns-documentation.md).
+You can find [exhaustive patterns documentation here](/log_processor/parsers/patterns-documentation.md).
diff --git a/crowdsec-docs/docs/log_processor/scenarios/create.md b/crowdsec-docs/docs/log_processor/scenarios/create.md
@@ -126,16 +126,16 @@ We filter on `evt.Meta.log_type == 'myservice_failed_auth'` because in the parse
 
 We have the following fields:
 
-- a [type](/scenarios/format.md#type): the type of bucket to use (trigger or leaky).
-- a [name](/scenarios/format.md#name)
-- a [description](/scenarios/format.md#description)
-- a [filter](/scenarios/format.md#type): the filter to apply on events to be filled in this bucket.
-- a [leakspeed](/scenarios/format.md#leakspeed)
-- a [capacity](/scenarios/format.md#capacity): the number of events in the bucket before it overflows.
-- a [groupby](/scenarios/format.md#groupby): a field from the event to partition the bucket. It is often the `source_ip` of the event.
-- a [blackhole](/scenarios/format.md#blackhole): the number of minute to not retrigger this scenario for the same `groupby` field.
-- a [reprocess](/scenarios/format.md#reprocess): ingest the alert in crowdsec for further processing.
-- some [labels](/scenarios/format.md#labels): Some labels are mandatory and the scenario will not be validated by the Hub if they are missing. Don't forget to set `remediation: true` if you want the IP to be blocked by bouncers.
+- a [type](/log_processor/scenarios/format.md#type): the type of bucket to use (trigger or leaky).
+- a [name](/log_processor/scenarios/format.md#name)
+- a [description](/log_processor/scenarios/format.md#description)
+- a [filter](/log_processor/scenarios/format.md#type): the filter to apply on events to be filled in this bucket.
+- a [leakspeed](/log_processor/scenarios/format.md#leakspeed)
+- a [capacity](/log_processor/scenarios/format.md#capacity): the number of events in the bucket before it overflows.
+- a [groupby](/log_processor/scenarios/format.md#groupby): a field from the event to partition the bucket. It is often the `source_ip` of the event.
+- a [blackhole](/log_processor/scenarios/format.md#blackhole): the number of minute to not retrigger this scenario for the same `groupby` field.
+- a [reprocess](/log_processor/scenarios/format.md#reprocess): ingest the alert in crowdsec for further processing.
+- some [labels](/log_processor/scenarios/format.md#labels): Some labels are mandatory and the scenario will not be validated by the Hub if they are missing. Don't forget to set `remediation: true` if you want the IP to be blocked by bouncers.
 
 We can then "test" our scenario like this :
 
@@ -252,7 +252,7 @@ line: Dec  8 06:28:43 mymachine myservice[2806]: bad password for user 'admin' f
 We have now a fully functional scenario for myservice to detect brute forces!
 We can either deploy it to our production systems to do stuff, or even better, contribute to the hub !
 
-If you want to know more about directives and possibilities, take a look at [the scenario reference documentation](/scenarios/format.md) !
+If you want to know more about directives and possibilities, take a look at [the scenario reference documentation](/log_processor/scenarios/format.md) !
 
 See as well [this blog article](https://crowdsec.net/blog/how-to-write-crowdsec-parsers-and-scenarios) on the topic.
 
diff --git a/crowdsec-docs/docs/log_processor/scenarios/introduction.mdx b/crowdsec-docs/docs/log_processor/scenarios/introduction.mdx
diff --git a/crowdsec-docs/docs/log_processor/whitelist/expr_based_whitelist.md b/crowdsec-docs/docs/log_processor/whitelist/expr_based_whitelist.md
diff --git a/crowdsec-docs/docs/log_processor/whitelist/fqdn_based_whitelist.md b/crowdsec-docs/docs/log_processor/whitelist/fqdn_based_whitelist.md
diff --git a/crowdsec-docs/docs/log_processor/whitelist/ip_based_whitelist.md b/crowdsec-docs/docs/log_processor/whitelist/ip_based_whitelist.md
diff --git a/crowdsec-docs/docs/log_processor/whitelist/postoverflow_based_whitelist.md b/crowdsec-docs/docs/log_processor/whitelist/postoverflow_based_whitelist.md
diff --git a/crowdsec-docs/docs/observability/usage_metrics.md b/crowdsec-docs/docs/observability/usage_metrics.md
