Feconn of one server jump from 174 to 1001 suddenly

Help!
1

Help!
In my haproxy log,i saw the feconn of one backend server jump form 174 to 1001 suddenly,but there is not other connection log between these two logs. why?
the log is following:

Nov 5 05:31:55 localhost haproxy[11863]: 10.86.21.43:37484 [05/Nov/2024:05:11:55.599] master_litellm_sit master_litellm_sit/litellm2 1/2/1199996 3967 -- 1175/174/173/173/0 0/0
Nov 5 05:36:12 localhost haproxy[11863]: 10.87.8.16:59536  [05/Nov/2024:05:35:12.422] master_litellm master 
master_litellm_sit/<NOSRV>     60004/-1/60003 0   sQ 1176/1001/1000/0/0 0/1

the config of haproxy is

global
    log         127.0.0.1 local2
    chroot      /data/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     5000
    user        root
    group       root
    daemon

defaults
    mode tcp
    log  global
    option     tcplog
    option     dontlognull
    option     redispatch
    retries    3
    maxconn    5000
    timeout queue           1m
    timeout connect         10s
    timeout client          240h
    timeout server          10m
    timeout check           5s

listen status
    bind *:1080
    mode http
    log global
    stats enable
    stats refresh 30s
    stats uri /
    stats realm Private lands
    stats auth admin:admin

listen master
    bind *:17006
    mode tcp
    option tcplog
    balance roundrobin
    option httpchk OPTIONS /master
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server server1 server1:7006 maxconn 1000 check port 8009 inter 5000 rise 2 fall 2
    server server2 server2:7006 maxconn 1000 check port 8009 inter 5000 rise 2 fall 2
    server server3 server3:7006 maxconn 1000 check port 8009 inter 5000 rise 2 fall 2
2

It is very possible that multiple requests were processed in parallel. By default haproxy only produces a log when the transaction is completed (when the response was sent back to the client).

Thus it could be possible that when the log was emitted, other requests were already being processed (but not yet finished), which could explain why the fe_conn counter suddenly jumps in your logs. Note that in this case: you should see a lot of logs entries right after the fe_conn “jump” though (it should match the difference between the previous fe_conn and the new one)