I have setup logstash, kibana, elasticsearch in logstash-server and logstash-forwarder in client-servers. I have setup five client-servers where logstash-forwarder is installed. It was working fine when there was two and three client-servers but after adding more servers I was unable to see the log in kibana. Is this because client-servers sending too much data? I am using port 5000 for sending and receiving the logs. Because there was no log I use command netstat -an to see what is happening. From the command I see results as follows:
xxx.xx.xxx.xx => logstash-server,
yyy.yy.yyy.yy => client-server
tcp 0 0 ::ffff:xxx.xx.xxx.xx:5000 ::ffff:yyy.yy.yyy.yy:44693 TIME_WAIT
tcp 0 0 ::ffff:xxx.xx.xxx.xx:5000 ::ffff:xxx.xx.xxx.xx:9300 TIME_WAIT
tcp 0 0 ::ffff:xxx.xx.xxx.xx:5000 ::ffff:yyy.yy.yyy.yy:48026 TIME_WAIT
tcp 0 0 ::ffff:xxx.xx.xxx.xx:5000 ::ffff:yyy.yy.yyy.yy:9300 TIME_WAIT
tcp 0 0 ::ffff:xxx.xx.xxx.xx:5000 ::ffff:yyy.yy.yyy.yy:49719 TIME_WAIT
I have already Google it and didn't find any solution till now. My question is how do I remove this TIME_WAIT or kill these and restart accepting the logs from the server. Is there anyway so that I can optimize it?
Well I am running logstash-1.4.2 and elasticsearch-1.2.1, I am debugging the problem, I ran following command in client-server /opt/logstash-forwarder/bin/logstash-forwarder.sh -config /etc/logstash-forwarder (it may be different for you). The problem I see till now is that the ssl certificate has expired. I again regenerated the ssl key and configured the logstash again and see problems like
Failure connecting to xxx.xxx.xxx.xxx: dial tcp xx.xxx.xxx.xxx:5000: i/o timeout,
and
Read error looking for ack: EOF
This may be additional question, why I am getting it. May be a bug.
Related
I know there are lots of resources on this topic, but I think I've done everything correctly and I still can't connect to my server.
I've started a simple node.js server on port 80.
sudo netstat -tnlp | grep 80
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 3657/node
curl localhost:80
Welcome Node.js
I've configured the Security group for this instance as well as the VPC to allow traffic.
I've made sure there is no local firewall and that the VPC ACL is not blocking traffic (not that I expected it, since this is a completely new instance.)
service iptables status
Redirecting to /bin/systemctl status iptables.service
Unit iptables.service could not be found.
The output when I try to connect from my local machine:
curl 3.xxx.xxx.xxx
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
curl: (7) Failed to connect to 3.xxx.xxx.xxx port 80: Connection refused
Are there any other ideas on what to check next?
The answer to my problem was https://stackoverflow.com/a/14045163/2369000. The boilerplate code that I copied used a method to only listen to requests that originated from localhost. This could have been detected from the netstat output, which said 127.0.0.1:80 for the listening address. The answer was to use .listen(80, "0.0.0.0") or just .listen(80) since the default behavior is to listen for requests from any IP address.
Node Exporter is always running on my local machine on localhost:9100 even if I don't execute it with terminal following this error message:
FATA[0000] listen tcp :9100: bind: address already in use source="node_exporter.go:172"
By which I can understand that this port number is already being used by another application but the thing is I don't have anything hosted there.
This is what netstat | grep 9100 gives:
tcp 0 0 localhost:60232 localhost:9100 ESTABLISHED
tcp6 0 0 localhost:9100 localhost:60232 ESTABLISHED
All I had to do was to "kill" the 9100 port in which Node Exporter was running by using fuser -k 9100/tcp as this was shown on How to kill a process running on particular port in Linux?.
I am setting up a Nexus OSS on an Azure VM.
I have set it up on a Ubuntu 16.04 LTS.
When I connect to the webapp via an SSH tunnel, I can access the Nexus repository manager. When I try to open it directly, I cannot get it to work.
As per the Azure docs and several Stackoverflow responses, I have updated the NSG and added port 8081 to be allowed but with no success. I also check the UFW (Ubuntu Firewall) and it is not even activated.
EDIT :
netstat -plant | grep 8081
tcp 0 0 127.0.0.1:33519 0.0.0.0:* LISTEN 18081/java
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 18081/java
tcp 0 0 127.0.0.1:8081 127.0.0.1:60242 TIME_WAIT -
tcp 0 0 127.0.0.1:8081 127.0.0.1:60366 TIME_WAIT -
tcp 0 0 127.0.0.1:8081 127.0.0.1:60244 TIME_WAIT -
EDIT2 :
admin#nexus-vm:~$ sudo iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
Does anyone have any idea what could be wrong?
Thanks in advance!
Regards
The problem was the firewall of my company. Tested it over 4G and it works.
I have an application running on Windows machine. the application related alerts are to be e-mailed to administrator,for which an e-mail needs to be sent by Java program. The SMTP server is configured on a remote Linux machine in network.
The Java Mail program works fine and sends out an email, when run on the Linux machine. However if the same program is run on Windows it fails to connect to the SMTP server.
Note:
Ping to the Linux Machine (having SMTP server) is successful from Remote windows server.
Telnet < SMTP server hostname > 25 fails from remote machine as well from the machine where SMTP is running
Telnet localhost 25 is sucessful from SMTP server (Linux server).
The email by Java program is sucessfull, if run on SMTP server when hostname is specified as localhost.It fails if you give actual hostname.
/etc/hosts file on SMTP server lists 127.0.0.1 localhost.
How can i use the SMTP server to send an email from remote Windows machine?
I can paste the errors coming up on windows machine but the problem is not with the program; its the way the SMTP server is configured. I am new to SMTP so feel free to correct me if i am wrong.
The objective is to send a java e-mail from remote windows machine using the SMTP server on the Linux machine.
Adding the Output of netstat -ant|grep :25 as requested in the comment below:
[root#XXXXXXXXXXX]# netstat -ant | grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 ::1:25 :::* LISTEN
tcp 0 0 ::ffff:10.207.70.71:1521 ::ffff:10.207.70.71:25481 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25481 ::ffff:10.207.70.71:1521 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25202 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:25127 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:25289 ::ffff:10.207.70.71:3001 ESTABLISHED
tcp 0 0 ::1:51432 ::1:25580 ESTABLISHED
tcp 0 0 ::1:25580 ::1:51432 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25233 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:3001 ::ffff:10.207.70.71:25289 ESTABLISHED
[root#XXXXXXXXXXX]#
Postfix: Accepting SMTP connections on ALL IP interrfaces
Your SMTP server (postfix) accepts incoming SMTP connection only on loopback interface(s)
[IPv4=127.0.0.1 and IPv6=::1].
Make your postfix listen on all available IP interfaces -> in main.cf configuration file restore default setting inet_interfaces = all
http://www.postfix.org/postconf.5.html#inet_interfaces
Why "loopback only" configuration is used?
Limiting SMTP server to accept only local SMTP connections is pretty common default configuration on "workstations". It allows sending emails (e.g. system warnings/notifications) without accepting any incoming spam.
Proto Recv-Q Send-Q Local Address Foreign Address State PID
tcp 0 0 ip:11080 0.0:* LISTEN -
tcp 0 0 ip:5070 0.0:* LISTEN -
tcp 0 0 ip:5071 0.0:* LISTEN -
tcp 0 0 **127.0.0.1:5072** 0.0:* LISTEN -
tcp 0 0 ip:11443 0.0:* LISTEN -
tcp 0 0 **127.0.0.1:11444** 0.0:* LISTEN -
Not able to access port (11444 & 5072) externally.
Only working on Local Host not remotely.
We are using Ubuntu on Google Compute Engine.
Firewall rules Added
Just checking - have you also configured the firewall? By default, the ports may be blocked by the firewall. You can configure it to enable ports via either the Developer Console, or with the gcloud command line tool.
Some extra information about firewall's on Google Compute Engine can be found at:
https://cloud.google.com/compute/docs/networking?hl=en#firewalls
As the netstat output shows, your services listening on port 11444 and 5072 are bound to localhost (127.0.0.1) which means they only accept connections on the local loop interface. Change the binding IP address on your service configuration to 0.0.0.0.