Solved the major socket bug ... and it was a layer 8 problem

I’d like to offer an excuse. But I can’t. It was one single missing newline. Just one. Missing. Newline. I changed my config file to use port 10000. I set up an nc listener on the remote host.

nc -k -l a.b.c.d 10000

Then I invoked the code. And the data showed up. Without a ()&(&%&$%*&(^ newline. That couldn’t possibly be it. Could it? No. Its way to freaking simple. I went so far as to swap out using Socket::Class rather than IO::Network::Socket. Ok, admittedly, that was not a hard changeover. Very easy in fact. But it gave me the same results. Then I got the idea of putting up the nc listener as above. And no freaking newline. It couldn’t be that this was the difference … could it? This is just too bloody simple. Really, no way on earth it could be that. The bug is subtle, damn it, not simple!!! So, to demonstrate that I am not a blithering moron, I put the newline in the send method. And it started working. /sigh I am a blithering moron. The other code (accidentally) included a newline in the value. And thats why it worked. This one, I happily removed the newline. And then things fell over. Newline is like a semicolon at the end of the line for a programming language, some APIs require it and assume it. The socket API does not assume it, and will happily send whatever buffer you hand it. This is the correct behavior. The data collector API assumes that received data is terminated by a newline, so it can start its parsing. Its the details that are killers. Ok, it works now. Onto more parallel monitor debugging. Making sure it gets into the InfluxDB correctly. Once we have this done, a major issue in monitoring/metrics I’ve been itching to solve correctly is done. I’ll put the code up for this as well. The monitoring code will work on *nix, MacOSX, and Windows, no matter if it is in VMs, containers, physical servers. This is why its so important for us, we can monitor near anything with it.