Log Processor No Logs Parsed

The Log Processor No Logs Parsed issue indicates that logs are being read by the Log Processor, but none are being parsed correctly in the last 48 hours.
This means the acquisition is working, but parsers can't interpret the log format.

What Triggers This Issue

• Trigger condition: Logs read but no successful parsing for 48 hours
• Criticality: 🔥 Critical
• Impact: No events generated means no detection or alerts possible

Common Root Causes

• Missing collection or parsers: The required parser collection for your log format isn't installed.
• Custom or unexpected log format: Logs don't match the format expected by the parser (custom format, version mismatch, etc.).

Diagnosis & Resolution

Missing Collection or Parsers

🔎 Check parsing metrics and installed collections

sudo cscli metrics show acquisition parsers

Run this command for Docker or Kubernetes

docker exec crowdsec cscli metrics show acquisition parsers

kubectl exec -n crowdsec -it <agent-pod> -- cscli metrics show acquisition parsers

What to look for:

• Acquisition: "Lines read" should be > 0 (confirms logs are being read)
• Parsers: "Lines parsed" should be > 0 (currently 0 means parsing is failing)
• Unparsed lines: Check if there's a high "unparsed" count

Check installed collections and parsers:

sudo cscli collections list

sudo cscli parsers list

🛠️ Install required collections for your log formats

Most services have a collection that includes parsers and scenarios.

• Search the CrowdSec Hub ↗️ for a collection with the name of the service you want to protect.
• Or a specific log parser ↗️ if you do not find a collection
• Get help from the community to understand what collections you need.

Acquisition Type/Program Mismatch

The log type defined in acquisition is linked to parsing. A mismatch can prevent the correct parser from being selected.

💡 If you are reading a program log file directly, the type usually matches the program name.
If you are reading logs from a stream (for example, syslog), parsing usually starts by identifying the syslog format, so the acquisition type is syslog.

💡 If you use default logging systems, this is usually not the root cause.

🔎 Check acquisition labels match parser filters

# Check your acquisition configuration
sudo cat /etc/crowdsec/acquis.yaml
sudo cat /etc/crowdsec/acquis.d/*.yaml

Compare the type: (or program: in Kubernetes) with installed parser names.

🛠️ Fix acquisition labels to match parser FILTER

The acquisition label must match a parser's FILTER:

On Host or Docker:

Check your acquis.yaml:

filenames:
  - /var/log/nginx/access.log
labels:
  type: nginx  # This must match a parser FILTER

Common types:

• nginx - for NGINX logs
• apache2 - for Apache logs
• syslog - for syslog-formatted logs (SSH, etc.)
• mysql - for MySQL logs
• postgres - for PostgreSQL logs
• 💡 for the exact type you can look at the filter in the parser yaml files

Kubernetes:

In Kubernetes, use program: instead of type::

agent:
  acquisition:
    - namespace: production
      podName: nginx-*
      program: nginx  # This must match parser FILTER

After changing configuration:

sudo systemctl restart crowdsec
# or docker restart crowdsec
# or helm upgrade (for Kubernetes)

Parser FILTER Not Matching

🔎 Inspect parser FILTER requirements

If a parser is installed but not matching, check its FILTER:

# View parser details
sudo cscli parsers inspect crowdsecurity/nginx-logs

# Look for the "filter" field
# Example: filter: "evt.Parsed.program == 'nginx'"

The FILTER must match your acquisition label. If your label is type: nginx, the parser FILTER should check evt.Line.Labels.type == "nginx" or evt.Parsed.program == "nginx".

🛠️ Update acquisition configuration to match FILTER

Ensure your acquisition configuration uses labels that match the parser's FILTER. Refer to the "Acquisition Type/Program Mismatch" section above for examples.

Common Parser FILTER Values

Service	Acquisition Label	Parser FILTER
NGINX	type: nginx	evt.Line.Labels.type == "nginx"
Apache	type: apache2	evt.Line.Labels.type == "apache2"
SSH (syslog)	type: syslog	evt.Line.Labels.type == "syslog"
Traefik	program: traefik	evt.Parsed.program == "traefik"
MySQL	type: mysql	evt.Line.Labels.type == "mysql"

Related Issues

• Log Processor No Logs Read - If logs aren't being read at all
• Log Processor No Alerts - If logs are parsed but scenarios don't trigger
• Engine No Alerts - Similar issue at the Security Engine level

Getting Help

If parsing still fails:

• Test your logs in CrowdSec Playground
• Share your log samples and acquisition config on Discourse
• Ask on Discord with cscli collections list and cscli parsers list output
• Check parser documentation on the Hub