Forum Discussion
Jeremy_Bridges_
Nimbostratus
NimbostratusCustom TCP Monitor
I am looking to do some custom TCP monitoring with a custom application that we need to monitor with the F5. Essentially, the application's thread handling logic will hang unless a specific set of send and receive steps are performed:
1. TCP handshake is established
2. Client sends a custom string.
3. Server sends a char in acknowledgement.
4. Client sends message header.
5. Client sends message body.
6. Server sends response header.
7. Server sends response body.
8. TCP close occurs.
The custom TCP monitors I can make on the F5 don't allow me to follow this kind of send and recieve logic. Is there a way to perform these steps with some kind of custom monitor?
26 Replies
hoolioCirrostratus
Hi again,
I am actually running into this issue myself now where I'd like to be able to use a null character in the send and/or receive string for a TCP monitor. Do you mind sharing your case number so I can pass it along to F5 Support as a reference for my case? Mine is C569837.
You might want to add the PID checking to ensure only one instance of the monitor per pool member is running at a time. It's more of a best practice than a functional requirement though.Formulate the PID filename based on the script name, pool member IP and port PIDFILE="/var/run/`basename ${0}`.${NODE}_${PORT}.pid" If the PID file already exists, it means the last instance of this monitor is probably hung. if [ -f $PIDFILE ] then Stop the current process kill -9 `cat $PIDFILE` > /dev/null 2>&1 fi Create a new PID file echo "$$" > $PIDFILE
And then at the end of the script:Remove the PID file rm -f $PIDFILE
Thanks,
Aaron- hoolioThe bigd CR is CR41708 for allowing null characters in the send/receive strings. It's not supported now as the monitoring daemon uses nulls to terminate lines.
Aaron 
Jeremy_Bridges_Sorry for the delay. My case number is C565983.
Wouldn't the script you suggest incur a file I/O performance penalty? Since there is already a pretty significant performance penalty with external monitors, wouldn't I want to avoid any other potential performance problems?- hoolioThe issue the PID file solves is killing a script that hangs. I think the extra overhead of the file I/O justifies the functionality. I'd guess it's not much relative to the overall resource usage of the external script and monitoring.
Aaron - Jeremy_Bridges_Ok, sounds good. I will add it.
Another question for you: what is the best way to assess the performance impact of using this external monitor? Specifically, what performance stats should I look at as we monitor more pools in this way to know for sure that our BIG-IP can handle the extra overhead of external monitoring? - hoolioI'd check the top and ps output. You could try to gauge the CPU/memory usage while there is no traffic and then increase the number of pool members the monitor checks. You could then extrapolate from a few data points on what CPU/memory the external monitor uses for a varying number of pool members.
If I do anything in this area, I'll let you know. And if you try some checks, let me know how it goes.
Thanks,
Aaron
