fix missing codeblocks

simplexalerts/index.md

@@ -28,10 +28,10 @@ Simple threshold-based alert are reactive by nature, but their automated monitor
 - Threshold-based: a [SMARTCTL](https://en.wikipedia.org/wiki/Smartctl) alert creating a notification when any hard drive within your infrastructure crosses a pre-failure threshold
 
 ~~~
-    smartctl_device_attribute{attribute_flags_long=\~".*prefailure.*", attribute_value_type="value"} 
+    smartctl_device_attribute{attribute_flags_long=~".*prefailure.*", attribute_value_type="value"} 
     <= 
     on (device, attribute_id, instance, attribute_name) 
-    smartctl_device_attribute{attribute_flags_long=\~".*prefailure.*", attribute_value_type="thresh"}
+    smartctl_device_attribute{attribute_flags_long=~".*prefailure.*", attribute_value_type="thresh"}
 ~~~
 
 - Statistical (anomaly detection): CPU spike or under-use
@@ -110,18 +110,24 @@ When devising a monitoring plan you must take the following into account:
 
 - insider threat: track successful logins and session durations (Loki)
 
+~~~
     {unit="systemd-logind.service", instance="$hostname"} |= `session` | regexp `.* session (?P<session>[0-9]+).*user (?P<user>[^\.]+)` | label_format session="{{.session}}", user="{{.user}}" | session != ""
+~~~
 
 
 - If the endpoint used to connect remotely over ssh gets discovered by the attacker and becomes the target of a bruteforce attacks (Loki data source):
 
 
+~~~
     count_over_time({unit="sshd.service", instance="myserver"} |~ `.*invalid (user|password)`[24h]) > 0
+~~~
 
 
 - If you have deployed fail2ban and an appropriate telemetry exporter to monitor it (prometheus data source) this query can give you a heads up when  you are under attack
 
+~~~
     sum by (instance) (rate(f2b_jail_banned_current[5m]))
+~~~
 
 
 Season with statistical threshold detection depending on how likely your administrators are to fat-finger their username
@@ -130,7 +136,9 @@ Season with statistical threshold detection depending on how likely your adminis
 - Appsec Monitoring (Tempo datasource for traces): if your service collects distributed tracing data you can create alerts based on specific function durations to discover if an attacker has, for example, dropped a webshell in a traced function
 
 
+~~~
     {duration>=10s && .service.name="my-interactive-website"}
+~~~
 
 Do note that Pyroscope for continuous profiling should also be used, but this is highly application-specific (eg: monitor critical functions for execution duration variation). You will want to create recording rules that will build prometheus metrics from your continuous profiling infrastructure so you can alert against those. Creation of recording rules is out of scope for this tutorial but they use the same language and tooling as alerting rules.