Merge branch 'dev' into main

docs/configuration.md

@@ -17,8 +17,7 @@ The following are common parameters which it is possible to specify in the confi
 |logging.useUTC| If set to true, logs will be reported in UTC time. Is set to false or missing, the timezone of the machine will be used. This parameter affects only the timestamp reported at the beginning of each log entry, it doesn't affect the time reported in the data/alerts which is always in UTC.  | A boolean | true | No |
 |checkForUpdatesAtBoot| Indicates if at each booth the application should check for updates. If an update is available, a notification will be sent to the default group. If you restart the process often (e.g., debugging, experimenting etc.) set this to false to avoid notifications. Anyway, BGPalerter checks for updates every 10 days.| A boolean | true | Yes |
 |processMonitors| A list of modules allowing various ways to check for the status of BGPalerter (e.g., API, heartbeat). See [here](process-monitors.md) for more information. | | | No | 
-|httpProxy| Defines the HTTP/HTTPS proxy server to be used by BGPalerter and its submodules (reporters/connectors/monitors). See [here](http-proxy.md) for more information. | A string | http://usr:psw@ prxy.org:8080 | No | 
-|volume| Defines a directory that will contain the data that needs persistence. For example, configuration files and logs will be created in such directory (default to "./"). | A string | /home/bgpalerter/ | No | 
+|httpProxy| Defines the HTTP/HTTPS proxy server to be used by BGPalerter and its submodules (reporters/connectors/monitors). See [here](http-proxy.md) for more information. | A string | http://usr:psw@ prxy.org:8080 | No |
 |persistStatus| If set to true, when BGPalerter is restarted the list of alerts already sent is recovered. This avoids duplicated alerts. The process must be able to write on disc inside `.cache/`. | A boolean | true | No |
 |generatePrefixListEveryDays| This parameter allows to automatically re-generate the prefix list after the specified amount of days. Set to 0 to disable it. It works only if you have one prefix list file and if you have used BGPalerter to automatically generate the file (and not if you edited prefixes.yml manually). | An integer | 0 | No |
 |rpki| A dictionary containing the RPKI configuration (see [here](rpki.md) for more details). |  |  | Yes |
@@ -38,6 +37,7 @@ The following are advanced parameters, please don't touch them if you are not do
 |multiProcess| If set to true, the processing of the BGP messages will be distributed on two processes. This may be useful for research measurements on the entire address space. It is discouraged to set this to true for normal production monitoring. | A boolean | false | No | 
 |fadeOffSeconds| If an alert is generated but cannot be yet squashed (e.g., not reached yet the `thresholdMinPeers`), it is inserted in a temporary list which is garbage collected after the amount of seconds expressed in `fadeOffSeconds`. Due to BGP propagation times, values below 5 minutes can result in false negatives.| An integer | 360 | No | 
 |checkFadeOffGroupsSeconds| Amount of seconds after which the process checks for fading off alerts. | An integer | 30 | No | 
+|volume| Defines a directory that will contain all the files used by BGPalerter. See [here](installation.md#volume) before modifying this. | A string | /home/bgpalerter/ | No | 
 
 
 
@@ -85,7 +85,7 @@ Each monitor declaration is composed of:
 
 | Attribute | Description |
 |---|---|
-| file | Name of the file containing the monitor implementation. Monitor implementations are in the `moniors` directory. |
+| file | Name of the file containing the monitor implementation. Monitor implementations are in the `monitors` directory. |
 | channel | The name of the channel that will be used by the monitor to dispatch messages. If the inserted name doesn't correspond to an already existent channel, a new channel is created.|
 |name| The name associated to the monitor. Multiple monitors with the same implementation can be loaded with different names. This name will be used to annotate messages in order track from where they are coming from.|
 |params| A dictionary of parameters that can be useful for the functioning of the monitor. Different monitors with the same implementation can be initialized with different parameters. |
@@ -299,7 +299,7 @@ This monitor will listen for all announcements produced by the monitored Autonom
 involving any of the monitored prefixes (independently of who is announcing them), and it will trigger an alert if any of the announcements is RPKI invalid or not covered by ROAs (optional).
 
 This monitor is particularly useful when:
-* Before RPKI deployment, since it will let you test what announcements will be invalid after singing the ROAs.
+* Before RPKI deployment, since it will let you test what announcements will be invalid after creating the ROAs.
 * During RPKI deployment, since it will let you know if any of your announcements are invalid.
 * After you deployed RPKI, in order to be sure all future BGP configurations will be covered by ROAs.
 

docs/friends.md

@@ -32,4 +32,6 @@ Please, let me know so I can add your company name here.
 * TelcoSwitch Limited (AS45033)
 * Ziron Limited (AS49344)
 * Elite Limited (AS29611)
+* Scaleway (AS12876)
+* NTS workspace (AS15576)
 * Axera S.P.A. (AS34758)

docs/http-proxy.md

@@ -11,7 +11,7 @@ This will enable the proxy globally on all HTTP/HTTPS/WebSocket traffic generate
 
 While the global configuration will send all requests to the proxy, you can specify which modules are able to bypass the proxy.
 This is useful for example if you want to not proxy requests to internal apps or networks. 
-This can be set per module (i.e reporter/connector/monitor) by adding the `noProxy: true` parameter to the desired module(s) in `config.yml`.
+This can be set per module (i.e., reporter/connector/monitor) by adding the `noProxy: true` parameter to the desired module(s) in `config.yml`.
 For instance, the configuration below allows you to bypass your proxy server for your traffic towards an Alerta dashboard.
 
 

docs/installation.md

@@ -128,7 +128,10 @@ The execution of BGPalerter supports some parameters
 | -v | Show version number |
 | -h | Show help |
 | -c | To specify the config file to load (default `./config.yml`) |
-| -d | To specify a directory where configuration and data is persisted (see [volume](configuration.md)). |
+| -d | To specify a directory that will contain all the files used by BGPalerter. See [here](installation.md#volume) before modifying this.|
 | -t | To test the configuration by generating fake BGP updates. This will start sending alerts on all the reports listening the `hijack` channel. |
 
 You can also use the same parameters with npm (if you are running the source code), in the following format `npm run serve -- --h` (replace `h` with the parameter you need).
+
+### Volume
+BGPalerter writes/reads some files on disk (e.g., logs). The positions of these files is set in `config.yml`, where both absolute and relative paths can be used. However, the `volume` parameter can be used to modify this behavior and confine BGPalerter to a specific directory. This is mostly useful in two occasions: (1) when you want to create "virtual environments", e.g., you want to have a single installation of BGPalerter running multiple instances each operating confined in a different directory; or (2) when you are using docker and you want to create a persistent volume (see above).

docs/release-process.md

@@ -36,15 +36,15 @@ The availability of a new release is notified.
 ### Release number
 The release number is composed of 3 digis `x.x.x`:
 
-* The first number identifies a breaking release. The first number is incremented only when the breaking change cannot be addressed with a deprecation warning.
-* The second number identifies a major release. The second number is incremented if new functionalities are introduced.
-* The third number identifies a minor release. The third number is incremented when there are changes which don't introduce any new functionality but improve the available ones.
+* The first number identifies a major release. The first number is incremented only when there are breaking changes which cannot be addressed with deprecation warnings and sensible defaults.
+* The second number identifies a minor release. The second number is incremented if new functionalities are introduced.
+* The third number identifies a patch. The third number is incremented when there are changes which don't introduce any new functionality but improve/repair the available ones.
 
 ### Patching
-In the event a serious bug (e.g., affecting one of the core functionalities) is discovered in a released version, we will not follow the timing described above and release as soon as possible a minor release.
-Minor releases are anyway tested and deployed for the monitoring of our network.
+In the event a serious bug (e.g., affecting one of the core functionalities) is discovered in a released version, we will not follow the timing described above and release as soon as possible a patch.
+Patches are anyway tested and deployed for the monitoring of our network.
 
-A minor release can also be released as a part of the normal release cycle in case there are no new features to justify a major release. 
+A patch can also be released as a part of the normal release cycle in case there are improvements which don't justify a new minor release. 
 
 ### Dependencies
 We use [Dependabot](https://dependabot.com/) to automatically check for newer version of the dependencies used by BGPalerter.

docs/report-http.md

@@ -138,3 +138,74 @@ reports:
 ```
 
 Thanks [arpanet-creeper](https://github.com/nttgin/BGPalerter/pull/412) for the help.
+
+
+## OpsGenie
+
+OpsGenie is an alert management tool by Atlassian. It's also a good example of how to use HTTP headers with reportHTTP.
+
+```yaml
+reports:
+  - file: reportHTTP
+    channels:
+      - hijack
+      - newprefix
+      - visibility
+      - path
+      - misconfiguration
+      - rpki
+    params:
+      templates:
+        default: '
+            {
+                "message": "BGPalerter ${channel} ${description}",
+                "description": "${summary}",
+                "details":
+                    {
+                        "prefix": "${prefix}",
+                        "bgplay": "${bgplay}",
+                        "earliest": "${earliest}",
+                        "latest": "${latest}",
+                        "channel": "${channel}",
+                        "type": "${type}",
+                        "asn": "${asn}",
+                        "paths": "${paths}",
+                        "peers": "${peers}"
+                    }
+            }'
+      headers:
+        'Content-Type': 'application/json'
+        'Authorization': 'GenieKey 00000000-1111-2222-3333-444444444444'
+      isTemplateJSON: true
+      showPaths: 5
+      hooks:
+        default: https://api.opsgenie.com/v2/alerts
+```
+
+
+## RocketChat
+
+[RocketChat](https://rocket.chat/) is an open source messaging platform.
+
+```yaml
+- file: reportHTTP
+   channels:
+     - hijack
+     - newprefix
+     - visibility
+     - path
+     - misconfiguration
+     - rpki
+   params:
+     templates:
+       default: '{"username": "BGPalerter", "channel": "_CHANNEL_NAME_", "text": "${channel}: ${summary}"}'
+     headers:
+     isTemplateJSON: true
+     showPaths: 0
+     hooks:
+       default: https://_RC_URL/hooks/_YOUR_KEY_
+```
+
+> Configure the "_CHANNEL_NAME_" in the template. Start with @ for user or # for channel. Eg: @john or #general
+
+Thanks to [cadirol](https://github.com/nttgin/BGPalerter/pull/704).

docs/ris-disconnections.md

@@ -6,6 +6,7 @@ The following causes are possible:
 
 1) **Network issues.** The machine where BGPalerter is running loses connectivity (maybe just for a few seconds).
 2) **You are monitoring something that produces too many BGP updates** (e.g., your prefixes are not stable or constantly re-announced). In such cases you may be too slow in consuming the data and the server disconnects you to flush the buffer.
+3) **Process termination.** This happens when BGPalerter was killed or crashed for some reason, this is not related to RIPE RIS.
 
 Anyway, unfortunately sometimes this happens without an explanation due to RIPE RIS instabilities.
 This has been reported to the RIPE RIS team.