Any plans in stabilizing (and listing) logging messages for crowdsec?

Questions
1

Your question

Are there going to be changes to the log messages for failed authentications for example? How likely are changes going to happen to the log messages?

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This gives the identifier system’s design but doesn’t state stability guarantees explicitly. Let me check the tracing/log docs for any statement about stability policy.

There is no explicit commitment in the docs about the stability of log message wording. What’s documented is that Stalwart’s telemetry system uses stable, versioned event identifiers (e.g. auth.failed for a failed login) rather than free-form log text, and each event has a documented default level and structured key/value fields.

Key points from the Events reference:

  • Every loggable event has an identifier like auth.failed (Authentication failed) formatted as <subsystem>.<name>, plus a documented default level and structured keys (e.g. remoteIp, login, etc.) attached to the entry rather than baked into free text.
  • These identifiers are the stable thing to key off of for tools like Crowdsec/fail2ban, not the human-readable “long” description text, which is explicitly described as informational/operational context.

So the identifier and key/value structure is the intended stable interface for external tooling; the prose descriptions are documentation aids and could be reworded without that being considered a breaking change. I don’t see any changelog or policy statement promising the identifiers themselves will never change, so I can’t say definitively “never” — but architecturally they’re designed to be the stable machine-readable anchor for log filtering/alerting, which is what a Crowdsec parser should match against instead of literal message text.

Reference: Events | Stalwart and Events | Stalwart for the key/value schema.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Match on the event id, not the wording. Every line carries it in parentheses, like (auth.failed) or (security.authentication-ban), followed by key = value pairs such as remoteIp. The ids are what we document at Events | Stalwart and they haven’t changed since they were introduced in 0.9, through the 0.16 rework. The description text in front of the id is what I wouldn’t build a parser on. Turn off ANSI colors and multiline entries on the tracer so each event lands on one line.

auth.failed is a debug-level event by default, so an info-level log file never contains it. Raise that event to info (Events | Stalwart), or add a second tracer at debug that includes only the auth and security events. If you’d rather skip text parsing, a webhook sends the same events as JSON with the id in type.

I don’t know of a crowdsec collection for Stalwart. For banning on a single host, the built-in auto-ban already counts failed logins, scans and abuse per IP: Auto-banning | Stalwart