hi
I use the heavyforwarder forward to indexer,but ...
01-17-2014 10:49:26.162 +0800 WARN TcpOutputFd - Connect to 192.168.1.66:9998 failed. Connection refused
01-17-2014 10:49:26.162 +0800 ERROR TcpOutputFd - Connection to host=192.168.1.66:9998 failed
01-17-2014 10:49:56.845 +0800 WARN TcpOutputProc - Connected to idx=192.168.1.66:9998. Not using ACK.
01-17-2014 10:50:26.996 +0800 WARN TcpOutputProc - Connected to idx=192.168.1.66:9998. Not using ACK.
01-17-2014 10:50:57.135 +0800 WARN TcpOutputProc - Connected to idx=192.168.1.66:9998. Not using ACK.
01-17-2014 10:51:26.808 +0800 WARN TcpOutputProc - Connected to idx=192.168.1.66:9998. Not using ACK.
01-17-2014 10:51:56.890 +0800 WARN TcpOutputProc - Connected to idx=192.168.1.66:9998. Not using ACK.
who can give some suggest to me?
Did you check for the firewall at the indexer,or check the outbound port from you localhost? Perform a
telnet 192.168.1.66 9998
Check if you are able to connect.. If you are having any antivirus software try disabling them.
I am looking at a similar problem. What I have observed is that when the heavy forwarder is unable to deliver to the upstream indexers ( Splunk Cloud in my case) due to network congestion, indexer unavailability, or network outage, then the heavy forwarder will refuse downstream connections, causing these errors. Once the buffer is full, it refuses any further connections. I think it is designed that way to force loadbalancing. Normally this is transient, as per your logs. In my case if the heavy forwarder goes into rejecting mode, it does not recover until it is restarted.
Did you check for the firewall at the indexer,or check the outbound port from you localhost? Perform a
telnet 192.168.1.66 9998
Check if you are able to connect.. If you are having any antivirus software try disabling them.