Info-logs despite LEVEL_INFO not being set

[ManiMatter]

What happened?

I am running crowdsec with the following docker-compose. In the logs, I see plenty of entries of verbosity level "info".

According to the reference doc, info logs should only be surfaced if LEVEL_INFO is true. Additionally, if LEVEL_INFO is not set, it should default to false.

In my case, I have not set LEVEL_INFO, for which it should be false, and thus no info logs should be displayed.
Is this a bug, or am I misunderstanding the reference documents?

docker-compose:

 crowdsec:
   <<: *common-keys-core
   image: crowdsecurity/crowdsec:latest
   container_name: crowdsec
   environment:
     <<: *default-tz-puid-pgid   
     COLLECTIONS: "crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/whitelist-good-actors crowdsecurity/iptables crowdsecurity/linux crowdsecurity/nginx crowdsecurity/sshd"
     GID: "${GID-1000}"
     CUSTOM_HOSTNAME: dSHB
     DO_HUB_UPGRADE: true
   volumes:
     - /var/log:/var/log:ro
     - $DOCKERDIR/appdata/crowdsec/data:/var/lib/crowdsec/data
     - $DOCKERDIR/appdata/crowdsec/config:/etc/crowdsec

Example of observed info-logs:

time= 2024-06-08T11:50:30+02:00 level= info msg= 127.0.0.1 - [Sat, 08 Jun 2024 11:50:30 CEST] "GET /v1/heartbeat HTTP/1.1 200 6.874968ms "crowdsec/v1.6.2-16bfab86-docker" "
time= 2024-06-08T11:51:30+02:00 level= info msg= 127.0.0.1 - [Sat, 08 Jun 2024 11:51:30 CEST] "GET /v1/heartbeat HTTP/1.1 200 6.386463ms "crowdsec/v1.6.2-16bfab86-docker" "
time= 2024-06-08T11:52:30+02:00 level= info msg= 127.0.0.1 - [Sat, 08 Jun 2024 11:52:30 CEST] "GET /v1/heartbeat HTTP/1.1 200 6.250875ms "crowdsec/v1.6.2-16bfab86-docker" "

What did you expect to happen?

To not see info logs when LEVEL_INFO is not set.

How can we reproduce it (as minimally and precisely as possible)?

Check logs of crowdsec when LEVEL_INFO is not set

Anything else we need to know?

No response

Crowdsec version

version: v1.6.2-16bfab86
Codename: alphaga
BuildDate: 2024-06-05_14:25:55
GoVersion: 1.22.3
Platform: docker
libre2: C++
User-Agent: crowdsec/v1.6.2-16bfab86-docker
Constraint_parser: >= 1.0, <= 3.0
Constraint_scenario: >= 1.0, <= 3.0
Constraint_api: v1
Constraint_acquis: >= 1.0, < 2.0

[github-actions]

@ManiMatter: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[LaurenceJJones]

Is this a bug, or am I misunderstanding the reference documents?

Not really, more just an undocumented default behaviour. By default we provide this config.yaml which already defaults the log level to INFO. The description of the environment variables is to FORCE the container to that level and since INFO is the default not providing the env var does nothing.

[ManiMatter]

Many thanks, @LaurenceJJones

Is there a way I can change the log level for my docker container to "warn"? I do not care about all these info logs; but because there are so many info logs, I will not see when eventually there is a "warn" or "error" log.

[LaurenceJJones]

Many thanks, @LaurenceJJones

Is there a way I can change the log level for my docker container to "warn"? I do not care about all these info logs; but because there are so many info logs, I will not see when eventually there is a "warn" or "error" log.

Since you are persisting the /etc/crowdsec/ directory you can edit the config.yaml directly within that folder and make it that level. Bare in mind that we log decisions and general information on INFO so you may miss some information.

You can always use grep to filter the output

docker logs <container> 2>&1 | grep -E "level=(error|fatal|warn)"

[ManiMatter]

Thank you. I was hoping I could set it via a docker variable, as I do with most other containers. Guess there is no way to achieve that?

[LaurenceJJones]

Thank you. I was hoping I could set it via a docker variable, as I do with most other containers. Guess there is no way to achieve that?

Not currently, we only have the ones documented, however, it should be easy to expand and add warn and error levels

[ManiMatter]

Many thanks, @LaurenceJJones

[ManiMatter]

@LaurenceJJones

Hi,
I just tested v1.6.3, which to my understanding should contain your changes.

However, I still see the info-level logs, despite LEVEL_WARN: true in docker-compose settings:

{
"time": "2024-09-28T13:47:09+02:00",
"level": "info",
"msg": "127.0.0.1 - [Sat, 28 Sep 2024 13:47:09 CEST] \"GET /v1/heartbeat HTTP/1.1 200 5.968705ms \"crowdsec/v1.6.3-4851945a-docker\" \""
}

 crowdsec:
   <<: *common-keys-core
   image: crowdsecurity/crowdsec:latest
   container_name: crowdsec
   environment:
     <<: *default-tz-puid-pgid   
     COLLECTIONS: "crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/whitelist-good-actors crowdsecurity/iptables crowdsecurity/linux crowdsecurity/nginx crowdsecurity/sshd"
     GID: "${GID-1000}"
     CUSTOM_HOSTNAME: dSHB
     DO_HUB_UPGRADE: true
     LEVEL_WARN: true
   volumes:
     - /var/log:/var/log:ro
     - $DOCKERDIR/appdata/crowdsec/data:/var/lib/crowdsec/data
     - $DOCKERDIR/appdata/crowdsec/config:/etc/crowdsec

[LaurenceJJones]

@LaurenceJJones

Hi, I just tested v1.6.3, which to my understanding should contain your changes.

However, I still see the info-level logs, despite LEVEL_WARN: true in docker-compose settings:

{
"time": "2024-09-28T13:47:09+02:00",
"level": "info",
"msg": "127.0.0.1 - [Sat, 28 Sep 2024 13:47:09 CEST] "GET /v1/heartbeat HTTP/1.1 200 5.968705ms "crowdsec/v1.6.3-4851945a-docker" ""
}

 crowdsec:
   <<: *common-keys-core
   image: crowdsecurity/crowdsec:latest
   container_name: crowdsec
   environment:
     <<: *default-tz-puid-pgid   
     COLLECTIONS: "crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/whitelist-good-actors crowdsecurity/iptables crowdsecurity/linux crowdsecurity/nginx crowdsecurity/sshd"
     GID: "${GID-1000}"
     CUSTOM_HOSTNAME: dSHB
     DO_HUB_UPGRADE: true
     LEVEL_WARN: true
   volumes:
     - /var/log:/var/log:ro
     - $DOCKERDIR/appdata/crowdsec/data:/var/lib/crowdsec/data
     - $DOCKERDIR/appdata/crowdsec/config:/etc/crowdsec

Most likely the flag passed to CrowdSec isnt being handled correctly when the log handler is created for the ApiServer will create a new issue to investigate this.