120 million events/hour translates into roughly 33,333 events per second.  You should not need 30 shards to accomplish that.  I think you'd probably be okay with 9:1, so that each node has 1 primary or 1 replica, which maximizes the I/O on each node, i.e. each node is only writing to one shard at a time.  It may take time to get to that balance, since you have a larger number of shards than can be equally balanced on nodes right now, but in the end it will be worth it.

You should also have 3 master nodes, because with 2, if even one goes down, your entire cluster goes offline.

That high of a shard count will also have dramatic repercussions in terms of cluster management and performance if you plan on keeping more than 1000 shards per node, total (and that, only if you have 30g heap on each data nodeā€”the max number of shards per node before hitting those consequences falls off if the heap is smaller than 30g).

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB