Usage Metrics

info

Usage metrics require at least CrowdSec v1.6.3

Support on Remediation Components are rolling out progressively. Please check the relevant documentation to see if your Remediation Component has support.

Logs processors and Remediation Components can provide detailed usage data to the Local API (LAPI), allowing for a unified view of their behavior and better insights.

Remediation Components

Remediation Components can send detailed information about themselves and what decisions they are acting on.

The specific metrics sent vary depending on the type of Remediation Component used.

For example, the firewall Remediation Component can report metrics on dropped bytes or packets, while the OpenResty Remediation Component can report metrics on dropped HTTP requests.

The same applies to interpreting the metrics: when blocking at the firewall level, most bots or attackers stop once they realize they can't connect to the target server. Therefore, the dropped packets or bytes should be seen as relative indicators of effectiveness between different blocking sources, not as the exact number of packets that would have been transmitted if the IP weren't blocked.

In contrast, HTTP-based Remediation Components typically count each handled request, as attackers are less likely to stop after receiving a 403 response or a Captcha challenge.

Whenever possible, the Remediation Components will break down the remediated traffic by the source of the decision.

Currently, CrowdSec supports the following origins:

• crowdsec: an automated decision based on behavioral analysis of your logs
• CAPI: a decision coming from the Community Blocklist
• cscli: a manual decision added with cscli decisions add
• cscli-import: decisions that were imported with cscli decisions import
• appsec: the request was blocked by an appsec rule
• console: a manual decision added from the console
• lists:XXX: a decision coming from a blocklist subscribed in the console. XXX is the name of the blocklist.

You can view the metrics locally using cscli metrics show bouncers:

The Remediation Components will send the number of decisions that are actually enforced.

These numbers may differ from what is shown by cscli decisions list for several reasons:

• Filters are applied when querying LAPI (such as scope, scenarios, etc.).
• LAPI deduplicates decisions before sending. If an IP is listed in multiple sources, only the decision with the longest remaining time is sent (useful for assessing blocklist overlap).

Remediation components will also send the version of the OS they are running on. You can see this information with cscli bouncers inspect XXX:

Log Processors

info

Log Processors are the underlying component within the Security Engine that processes logs and sends Alerts to the LAPI. If you are running a multi-server setup, you will have multiple Log Processors.

Logs processors can also send more information about themselves to LAPI:

• Operating system information (version, distribution/platform)
• Number of datasources configured per type
• Enabled features flags
• Installed Hub files (including custom / tainted files):
  • AppSec-Config
  • AppSec-Rules
  • Collections
  • Contexts
  • Parsers
  • Scenarios

You can show this data by using cscli machines inspect XXX:

By default, only the collections are shown in order to keep the output readable.

If you want to see the entire hub state of a given Log Processor, you can use cscli machines inspect --hub XXX.