Ajuste de rendimiento

La mayoría de los despliegues funcionan bien con los valores por defecto. Ajusta estas opciones cuando la reconciliación de arranque gestione listas CAPI grandes, un router lento agote los tiempos de espera o necesites ventanas de reinicio predecibles.

Pool de conexiones

mikrotik.pool_size controla cuántas sesiones de la API de RouterOS puede usar el bouncer para trabajo en paralelo, como las eliminaciones de la reconciliación.

mikrotik:
  pool_size: 4

Recomendaciones:

Clase de router	Valor sugerido
Router doméstico pequeño	1-2
RouterOS 7 de gama media	4
Despliegues CAPI grandes	6-8

El valor configurado debe estar entre 1 y 20. En el arranque, el bouncer consulta max-sessions de la API de RouterOS y limita el pool efectivo a max-sessions - 2, garantizando que al menos dos sesiones queden disponibles para otras operaciones de RouterOS.

Comprueba o aumenta el límite de RouterOS:

/ip/service/print where name=api
/ip/service/set api max-sessions=1000

Comportamiento de adición masiva

Durante la reconciliación, las adiciones usan scripts temporales de RouterOS en lugar de una llamada a la API por cada IP. Cada script lleva hasta 100 direcciones.

Ese tamaño de bloque no tiene que ver con el tamaño del mensaje — la API de RouterOS admite palabras mucho mayores que estos scripts, y un bloque de 1.000 entradas se transfiere sin protestar. Es el compromiso entre amortizar los cuatro viajes de ida y vuelta que cuesta cada bloque (buscar, añadir, ejecutar, eliminar) y cuánto tiempo retiene al router una única ejecución de script no interrumpible.

Barriéndolo contra un RB5009 — cinco rondas intercaladas de 4.000 entradas con 50/100/250/500/1000 — las medianas caen entre 4,36 s y 5,78 s en todo ese rango de 20×. El resultado útil es que el barrido no puede resolver un ganador: dentro de un mismo tamaño el rango intercuartílico llega a 2,55 s, mayor que los 1,43 s que separan al mejor tamaño del peor, y qué tamaño parece mejor depende del estimador que uses (mediana y mínimo eligen 1.000; la media elige 100).

Lo que sí es estable es la forma: insertar una fila cuesta ~1,2–1,3 ms y domina todo lo demás, así que importar 22.000 entradas gasta unos 27 s insertando frente a entre 0,2 s y 2,3 s de andamiaje de bloques. No hay motivo para cambiar este valor, ni ninguna medición aquí que te diga a qué cambiarlo.

Si un script masivo falla, el bouncer registra un aviso y recurre a adiciones individuales para ese bloque. Las entradas duplicadas se omiten o se refrescan sin reconectar la sesión de la API.

Tiempos de espera

Aumenta mikrotik.command_timeout si RouterOS es lento durante operaciones con listas grandes:

mikrotik:
  command_timeout: "60s"

Aumenta mikrotik.connection_timeout solo cuando el propio login inicial TCP/API sea lento:

mikrotik:
  connection_timeout: "20s"

Intervalo de reconciliación

La reconciliación de arranque se ejecuta siempre. La reconciliación periódica repara la deriva después del arranque.

crowdsec:
  reconciliation_interval: "15m"

Usa 0 para desactivar la reconciliación periódica, o un valor de 1m o superior para activarla. Los valores entre 0 y 1m se rechazan en el arranque.

Los intervalos cortos reparan la deriva más rápido, pero leen la address-list entera de RouterOS más a menudo. Lo que eso cuesta es medible: en un RB5009 con 22.332 entradas, una pasada sin deriva tarda 1,86 s, de los cuales las dos lecturas de lista son el 98,5%. Con el valor por defecto de 15m eso es un ciclo de trabajo del 0,2%; con 1m, del 3,1%.

El coste escala con cuántas entradas guarda el router, no con cuánta deriva haya que reparar — una pasada que no encuentra nada cuesta prácticamente lo mismo que una que arregla algo. Así que merece la pena alargar el intervalo con una lista grande y un router modesto, y poco se gana acortándolo por debajo de lo que realmente exija tu tolerancia a deriva sin detectar.

Métricas de tráfico procesado

metrics.track_processed crea reglas de conteo de tipo passthrough para que el bouncer pueda informar del tráfico total evaluado, no solo del tráfico descartado.

metrics:
  track_processed: true

Ponlo a false para evitar esas reglas de conteo adicionales:

metrics:
  track_processed: false

Ejemplo de referencia

crowdsec:
  origins: ["crowdsec", "cscli"]
  reconciliation_interval: "30m"

mikrotik:
  command_timeout: "60s"
  pool_size: 6

metrics:
  enabled: true
  routeros_poll_interval: "30s"
  track_processed: true

Para routers pequeños, prefiere el modo solo local, pool_size: 1 o 2, y evita el CAPI completo hasta que hayas medido el tiempo de reconciliación.