clean up and precisions of a few pages still wip

Author: jdv

crowdsec-docs/unversioned/troubleshooting/issue_engine_no_alerts.md

@@ -13,106 +13,159 @@ The **Engine No Alerts** issue appears when your Security Engine has been runnin
 
 ## Common Root Causes
 
-- **No logs being read**: The acquisition configuration may be missing, disabled, or pointing to empty log sources.
-- **No logs being parsed**: Logs are being read but parsers can't process them due to format mismatches or missing collections.
 - **Scenarios in simulation mode**: Detection scenarios are installed but set to simulation mode, preventing actual alerts.
-- **Legitimate low-activity environment**: In some cases, truly clean environments with no malicious activity may not trigger alerts.
+- **Are appropriate collections installed**: make sure you have the detection scenarios and/or appsec rules covering your services needs
+- **Low/no-traffic environment**: If your service handles very few request or is not open to the internet it's usually to observe low/no malicious activity.
+- **Legitimate low-activity environment**: Your defenses preceding your service might be good enough that you don't detect additional malicious behaviors (CrowdSec blocklists or other protections may already deflect most malicious activity)
+
+<a name="otherIssues"></a>  
+
+**Other Issues**
+- 🔗 **[No logs being read](/u/troubleshooting/issue_lp_no_logs_read)**: The acquisition configuration may be missing, disabled, or pointing to empty log sources. 
+- 🔗 **[No logs being parsed](/u/troubleshooting/issue_lp_no_logs_parsed)**: Logs are being read but parsers can't process them due to format mismatches or missing collections.
 
 ## How to Diagnose
 
-### Check metrics to identify the issue
+If it's not due to [other issues](#otherIssues), here are the diagnosis and resolutions for other root causes.
+
+### Check if scenarios are in simulation mode
 
-Run the metrics command to see the full pipeline:
+Verify whether your scenarios are set to simulation mode, which prevents them from generating alerts:
 
 ```bash
 # On host
-sudo cscli metrics show acquisition parsers scenarios
+sudo cscli simulation status
 
 # Docker
-docker exec crowdsec cscli metrics show acquisition parsers scenarios
+docker exec crowdsec cscli simulation status
 
 # Kubernetes
-kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show acquisition parsers scenarios
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation status
 ```
 
-Look for:
-- **Acquisition Metrics**: Are log lines being read? (non-zero "Lines read")
-- **Parser Metrics**: Are logs being parsed successfully? (non-zero "Lines parsed")
-- **Scenario Metrics**: Are scenarios evaluating events? (check "Current count" or "Overflow")
+If scenarios are listed, they're in simulation mode and won't be sent to CrowdSec console (they should however still appear in `cscli alerts list`).
+
+### Check if appropriate collections are installed
 
-### Check recent alerts
+Verify you have collections matching your protected services:
 
 ```bash
 # On host
-sudo cscli alerts list
+sudo cscli collections list
 
 # Docker
-docker exec crowdsec cscli alerts list
+docker exec crowdsec cscli collections list
 
 # Kubernetes
-kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli alerts list
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections list
 ```
 
-If the list is empty, proceed with the resolution steps below.
+Compare your installed collections against your actual services (nginx, apache, ssh, etc.). Missing collections means no detection rules for those services.
 
-## How to Resolve
+### Evaluate your service activity level
 
-### If no logs are being read
+Check how much traffic your service is processing:
 
-This is the most common cause. Follow the [LP No Logs Read troubleshooting guide](/u/troubleshooting/lp_no_logs_read) for detailed steps.
-
-**Quick checks:**
-- Verify acquisition configuration exists (`/etc/crowdsec/acquis.yaml` or `acquis.d/`)
-- Ensure log files exist and are accessible
-- Check file permissions allow CrowdSec to read logs
+```bash
+# On host
+sudo cscli metrics show acquisition parsers
 
-### If logs are read but not parsed
+# Docker
+docker exec crowdsec cscli metrics show acquisition parsers
 
-Follow the [LP No Logs Parsed troubleshooting guide](/u/troubleshooting/lp_no_logs_parsed) for detailed steps.
+# Kubernetes
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show acquisition parsers
+```
 
-**Quick checks:**
-- Verify collections are installed: `cscli collections list`
-- Check log format matches parser expectations
-- Use `cscli explain --log "<sample log line>" --type <type>` to test parsing
+Look at "Lines parsed" - if this number is very low (dozens or hundreds per day), you may simply have insufficient traffic volume for malicious activity to appear.
 
-### If scenarios are in simulation mode
+### Check if proactive defenses are blocking threats upstream
 
-Check if scenarios are in simulation:
+If you have CrowdSec blocklists or other protection layers active, they may be blocking malicious traffic before it reaches your scenarios:
 
 ```bash
-sudo cscli simulation status
+# On host
+sudo cscli decisions list
+sudo cscli metrics show bouncers
+
+# Docker
+docker exec crowdsec cscli decisions list
+docker exec crowdsec cscli metrics show bouncers
+
+# Kubernetes
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli decisions list
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show bouncers
 ```
 
-If scenarios are in simulation mode, they will be listed. To disable simulation for all scenarios:
+High numbers of active decisions or bouncer blocks indicate your proactive defenses are working - malicious actors never reach your log-based detection.
+
+## How to Resolve
+
+### If scenarios are in simulation mode
+
+Disable simulation mode to allow alerts to be generated:
 
 ```bash
+# On host
 sudo cscli simulation disable --all
 sudo systemctl reload crowdsec
+
+# Docker
+docker exec crowdsec cscli simulation disable --all
+docker restart crowdsec
+
+# Kubernetes
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation disable --all
+kubectl rollout restart deployment/crowdsec -n crowdsec
 ```
 
-Or for specific scenarios:
+You can also disable simulation for specific scenarios only:
 
 ```bash
 sudo cscli simulation disable crowdsecurity/ssh-bf
 sudo systemctl reload crowdsec
 ```
 
-### If this is a low-activity environment
+### If appropriate collections are missing
+
+Install collections matching your protected services. Visit the [CrowdSec Hub](https://hub.crowdsec.net/) to find collections for your stack:
+
+- **Web servers**: `crowdsecurity/nginx`, `crowdsecurity/apache2`, `crowdsecurity/caddy`
+- **SSH**: `crowdsecurity/sshd`
+- **Linux base**: `crowdsecurity/linux`
+- **AppSec/WAF**: `crowdsecurity/appsec-*` collections for application-level protection
+
+Install collections using:
+
+```bash
+# On host
+sudo cscli collections install crowdsecurity/nginx
+sudo systemctl reload crowdsec
+
+# Docker
+docker exec crowdsec cscli collections install crowdsecurity/nginx
+docker restart crowdsec
+
+# Kubernetes
+kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections install crowdsecurity/nginx
+kubectl rollout restart deployment/crowdsec -n crowdsec
+```
+
+### If this is a low-traffic environment
 
-In genuinely clean environments, you can:
+For services with minimal traffic or limited internet exposure:
 
-1. **Test with dummy scenarios** using the [Health Check guide](/u/getting_started/health_check) to verify detection works
-2. **Subscribe to Community Blocklist** decisions in the Console to add proactive blocking
-3. **Monitor metrics regularly** to ensure the pipeline stays healthy
+1. **Verify detection is working** by triggering test scenarios as described in the [Health Check guide](/u/getting_started/health_check/#trigger-crowdsecs-test-scenarios)
+2. **Consider this normal** - If your detection is properly working, low traffic may means fewer threats to detect and you can ignore the issue for now.
 
-## Verify Resolution
+### If proactive defenses are already handling threats
 
-After making changes:
+This is actually a **positive outcome** - your blocklists and bouncers are preventing malicious traffic from reaching your services:
 
-1. Restart CrowdSec: `sudo systemctl restart crowdsec`
-2. Wait a few minutes for log processing
-3. Check metrics again: `sudo cscli metrics show scenarios`
-4. Trigger a test alert using the [Health Check detection tests](/u/getting_started/health_check#-detection-checks)
+1. **Verify your setup is working** by running the [Health Check detection tests](/u/getting_started/health_check#-detection-checks) to confirm scenarios can still trigger when needed
+2. **Monitor bouncer metrics** to see how many threats are being blocked: `sudo cscli metrics show bouncers`
+3. **Review active decisions** to understand what threats are being prevented: `sudo cscli decisions list`
+4. **Keep the Console enrolled** to maintain visibility into your protection posture even if local alerts are minimal
 
 ## Related Issues