Closed gregms closed 8 years ago
liquidat
commented
8 years ago Yes, this behavior might occur: the test works by opening a connection to the openvpn server. If the server logs all connection attempts the log will fill up.
If this is a concern for you please add log rotation or a logging filter.
gregms
commented
8 years ago We already had log rotate enabled, but even with, 67 MB daily logs were already showing up on reports of relatively large unexpected file changes.
A few options I changed within openvpn config: mute 5 (suppresses repeated messages) but still produces a lot of entries ever minute verb 0 (change verbosity from 4 to 0).
While muting does help, it still produces a lot of entries every minute. I decided changing verbosity was the best of my options, it isn't my preferred method but 0 is the only thing to prevent them from filling up.
Since this is a UDP connection, seems like my testing options are limited.
If you have any other solutions or recommendations, I would be open to it. No matter what, just having this as a monitoring option is much better than what I had before (which was nothing and complaints when discovered it wasn't working).
liquidat
commented
8 years ago The problem seems to me to be by design: the check actually opens a connection, thus you will have a logging action of the OpenVPN server. There is little the plugin can do here. Alternatives are:
However, if you need to test the availability every two seconds (!) please consider to route all OpenVPN logs through a log daemon as rsyslog, and add filter lines to drop all lines which contain the IP address of your monitoring server.
Hope that helps...
When I tail my /var/log/openvpn/int.log file, every two seconds it adds the following entry: Thu Oct 15 08:07:24 2015 us=130000 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Is this happening on yours as well? Wasn't sure if there was a better work around to prevent this. The check currently happens every minute and it takes a full minute for the connection refused to stop so it essentially never ends.
Here is the full text (10.1.1.1 in this example would be my Nagios server): Thu Oct 15 08:15:21 2015 us=396443 MULTI: multi_create_instance called Thu Oct 15 08:15:21 2015 us=396513 10.1.1.1:54134 Re-using SSL/TLS context Thu Oct 15 08:15:21 2015 us=396534 10.1.1.1:54134 LZO compression initialized Thu Oct 15 08:15:21 2015 us=396601 10.1.1.1:54134 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Thu Oct 15 08:15:21 2015 us=396613 10.1.1.1:54134 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Thu Oct 15 08:15:21 2015 us=396642 10.1.1.1:54134 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' Thu Oct 15 08:15:21 2015 us=396650 10.1.1.1:54134 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' Thu Oct 15 08:15:21 2015 us=396665 10.1.1.1:54134 Local Options hash (VER=V4): '530fdded' Thu Oct 15 08:15:21 2015 us=396676 10.1.1.1:54134 Expected Remote Options hash (VER=V4): '41690919' Thu Oct 15 08:15:21 2015 us=396705 10.1.1.1:54134 TLS: Initial packet from 10.1.1.1:54134, sid=01000000 00000000 Thu Oct 15 08:15:21 2015 us=396715 10.1.1.1:54134 TLS Error: reading acknowledgement record from packet Thu Oct 15 08:15:24 2015 us=199771 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) Thu Oct 15 08:15:26 2015 us=609427 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) Thu Oct 15 08:15:29 2015 us=200170 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)