When you say it's working, do you mean that you tested it on real inputs and confirmed that it does what it's supposed to do? Or do you just mean that it compiles and runs without crashes or error messages?

A few odd things that I wouldn't normally do:

• Why put GetOptions inside an eval block? You can just check its return value (true means command line was ok, false means a bad arg).
• Why have @meth as an array when you only assign a single scalar value to it, and only use $meth[0] when checking its contents?
• Your "usage" message implies that a bunch of options can be used together (i.e. the first line shows "-c", "-d" and "-i" all being used in combination), but your option handling will only operate on one option.
• Your "san_check_arg" function does not check whether the args for "-c", "-d" or "-i" consist of just digits, and then you pass these unchecked strings from the command line directly into a subshell. This means you are asking for trouble. It's not so much a "security risk", but you are opening the door for simple typos to cause all sorts of havoc, because of what the subshell might do with "unexpected" characters in the unchecked user input.

If you could figure out a way to do what is needed without runnin those ssh commands in backticks, it would be a lot nicer. How big are the files that you need to grep over? Would it make sense to coy them from the remove servers and do the grep locally (with the perl script)? Or you could do something like this in your "proc_it()" sub:

my $remote_file = $proc . 'cc.[12]/' . ( $proc eq 'sip' ? 'sipcalls' :
+ 'paccalls';
for my $server ( @servers ) {
    open( REMOTE, "-|", "ssh $server cat /process/home/$remote_file" )
        or die "ssh $server failed: $!";
    while (<REMOTE>) {
        next unless /whatever/;
        ...
    }
    close REMOTE;
}
[download]

As long as you make sure that $proc has a proper value ("h323" or "sip"), that ssh command will be safe -- it contains no other "tainted" variables. But if the files are so big that you don't want all the data coming in over the remote connection, you should still try eliminate (or at least be more careful about) the use of quoted strings and user-supplied args in the command line being sent to a remote shell.