Examples
Here are a few simple examples of CREs detecting real problems.
Kafka
Apache Kafka is an open-source distributed event streaming platform primarily used for building real-time data pipelines and streaming applications. It was originally developed by LinkedIn and is now maintained by the Apache Software Foundation.
Problem CRE-2025-0025
When the configured replication factor for a Kafka topic is greater than the actual number of brokers in the cluster, Kafka repeatedly fails to assign partitions and logs replication-related errors. This results in persistent warnings or an InvalidReplicationFactorException when the broker tries to create internal or user-defined topics.
Run the following Docker commands to download the latest version of Kafka, reproduce this failure, and detect it with preq.
tip
If you don't have Docker installed, you can view this demo on the playground.
Example:
docker run -d --name cre-2025-0025 apache/kafka:latest; \
docker logs cre-2025-0025 > /dev/null; \
docker exec cre-2025-0025 /opt/kafka/bin/kafka-topics.sh \
--create \
--topic test-topic-rf3 \
--replication-factor 3 \
--partitions 1 \
--bootstrap-server localhost:9092 |& preq -o -
Example output:
Parsing rules done! [4 rules in 1ms; 2.23K rules/s]
Problems detected done! [1 in 2ms; 552/s]
Reading stdin done! [1.51KB in 0s; 2.76MB/s]
CRE-2025-0025 medium [1 hits @ 2025-04-12T13:18:28.252-05:00]
Matching lines done! [6 lines in 0s; 10.99K lines/s]
[
{
"cre": {
"id": "CRE-2025-0025",
"severity": 2,
"title": "Kafka broker replication mismatch",
"category": "message-queue-problems",
"tags": [
"kafka",
"known-problem"
],
"author": "Prequel",
"description": "When the configured replication factor for a Kafka topic is greater than the actual number of brokers in the cluster, Kafka repeatedly fails to assign partitions and logs replication-related errors. This results in persistent warnings or an `InvalidReplicationFactorException` when the broker tries to create internal or user-defined topics.\n",
"impact": "Exceeding the available brokers with a higher replication factor can lead to failed topic creations, continuous log errors, and possible service disruption if critical internal topics (like consumer offsets or transaction state) cannot be replicated.\n",
"cause": "There are not enough brokers to fulfill the specified replication factor, preventing valid partition assignments.\n",
"mitigation": "- Match or lower the replication factor to the actual broker count, or scale up the Kafka cluster to accommodate the higher replication factor.\n",
"references": [
"https://strimzi.io/docs/operators/latest/deploying#proc-changing-topic-replicas-str",
"https://github.com/strimzi/proposals/blob/main/066-topic-replication-factor-change.md",
"https://github.com/strimzi/strimzi-kafka-operator/issues/990"
],
"applications": [
{
"name": "Kafka",
"version": "3.x"
},
{
"name": "Kafka",
"version": "4.x"
}
]
},
"hits": [
{
"timestamp": "2025-04-12T13:27:15.864-05:00",
"entry": "[2025-04-12 18:27:15,864] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: Unable to replicate the partition 3 time(s): The target replication factor of 3 cannot be reached because only 1 broker(s) are registered. (org.apache.kafka.tools.TopicCommand)"
}
],
"id": "CRE-2025-0025",
"rule_hash": "2qs85BkqaiEiHwdz7EASvJxMdRo2cKwBmXvyjYM6Kfty",
"rule_id": "LikPvDPTX5kEKiR3EoBEM7",
"timestamp": "2025-04-12T13:27:15.864-05:00"
}
]
Clean up:
docker rm -f cre-2025-0025
nginx
nginx is a high-performance web server that also functions as a reverse proxy, load balancer, and HTTP cache.
Problem CRE-2024-0043
When an upstream server becomes unreachable or its DNS entry is unavailable, nginx requests will fail.
tip
If you don't have Docker installed, you can view this demo on the playground.
Example:
docker network create test-net && \
docker run -d --name fake-backend --network test-net python:3.9-slim python -m http.server 80 && \
sleep 1 && \
printf "events {}\nhttp {\n resolver 127.0.0.11 valid=1s ipv6=off;\n resolver_timeout 1s;\n upstream my_upstream {\n zone my_upstream 64k;\n server fake-backend:80 resolve;\n }\n server {\n listen 80;\n location / {\n proxy_pass http://my_upstream;\n }\n }\n}\n" > nginx.conf && \
docker run -d --name test-nginx --network test-net -p 8080:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro nginx:alpine && \
sleep 5 && \
curl -s --retry 5 --retry-delay 2 --retry-connrefused -I http://localhost:8080 > /dev/null && \
docker rm -f fake-backend && \
sleep 5 && \
curl -I -s http://localhost:8080 --max-time 1 2> /dev/null || true && \
docker logs test-nginx |& preq -o -
Example output:
Parsing rules done! [5 rules in 2ms; 2.20K rules/s]
Problems detected done! [1 in 2ms; 435/s]
Reading stdin done! [1.47KB in 0s; 2.29MB/s]
Matching lines done! [6 lines in 0s; 9.19K lines/s]
CRE-2024-0043 medium [5 hits @ 2025-04-12T15:59:18-05:00]
[
{
"cre": {
"id": "CRE-2024-0043",
"severity": 2,
"title": "NGINX Upstream DNS Failure",
"category": "proxy-problems",
"tags": [
"kafka",
"known-problem"
],
"author": "Prequel",
"description": "When a NGINX upstream becomes unreachable or its DNS entry disappears, NGINX requests begin to fail.\n",
"impact": "Clients experience partial or total service interruptions until the upstream is restored or reconfigured.\n",
"cause": "The upstream host or container is removed, invalidating its DNS resolution and causing requests to break.\n",
"mitigation": "- Provide a stable or redundant upstream configuration so NGINX can gracefully handle DNS resolution failures.\n",
"references": [
"https://stackoverflow.com/questions/32845674/nginx-how-to-not-exit-if-host-not-found-in-upstream"
],
"applications": [
{
"name": "NGINX"
}
]
},
"hits": [
{
"timestamp": "2025-04-12T15:59:18-05:00",
"entry": "2025/04/12 20:59:18 [error] 30#30: fake-backend could not be resolved (2: Server failure)"
},
{
"timestamp": "2025-04-12T15:59:19-05:00",
"entry": "2025/04/12 20:59:19 [error] 30#30: fake-backend could not be resolved (2: Server failure)"
},
{
"timestamp": "2025-04-12T15:59:20-05:00",
"entry": "2025/04/12 20:59:20 [error] 30#30: fake-backend could not be resolved (2: Server failure)"
},
{
"timestamp": "2025-04-12T15:59:21-05:00",
"entry": "2025/04/12 20:59:21 [error] 30#30: fake-backend could not be resolved (2: Server failure)"
},
{
"timestamp": "2025-04-12T15:59:22-05:00",
"entry": "2025/04/12 20:59:22 [error] 30#30: fake-backend could not be resolved (2: Server failure)192.168.224.1 - - [12/Apr/2025:20:59:22 +0000] \"HEAD / HTTP/1.1\" 499 0 \"-\" \"curl/8.5.0\""
}
],
"id": "CRE-2024-0043",
"rule_hash": "8JzQx86iR3KJU7iC58ct5qMB1p1yV9d3vNr7cmYGJCAc",
"rule_id": "oN49VMfoAw8rUre2bEhheP",
"timestamp": "2025-04-12T15:59:18-05:00"
}
]
Clean up commands:
docker rm -f test-nginx && \
docker rm -f fake-backend && \
rm -f nginx.conf && \
docker network rm test-net