I don't know about other_latency, but I'd monitor both. You can have a high storage latency(volume) that won't show up in lun:avg_latency and that could be a memory leak, and you could have low volume latency and high lun:avg_latency. When that happens in our environment, that's from a host saturating its FC links(or some other host-side stuff but usually link saturation is the reason) without bogging down the filer.
other_latency means a latency for operation other than read or write, and usually should be ignored. You should monitor read_latency and write_latency for both lun and volume. As far as I know there are subtle difference between volume and lun latency. Lun latency includes network latency, whereas volume latency is just how long it takes for the storage system to process the request.
Just saying what I heard from a guru. Not a performance expert myself. I believe it has something to do with the single large LUN operation being split into several network IO exchanges, and LUN latency being the latency for the whole IO operation. Anyway, it's common that lun latency is much higher than the volume latency.
What is the environment..VMware? OnCommand Balance has a really nice complete view of all components. Other latency and IOPs can be an issue especially in environments with a lot of getattrs...usually edge cases but don't overlook a system being overloaded with these types of operations. If lun latency is low that is good but would be better to monitor proactively.