I am considering installing ntop on our range of production servers. Is it unwise to do so? It gives some interesting information.

I am looking for experiences with ntop.

• Is it good for network troubleshooting?
• What do you use ntop for mostly?
• What is the thing you like most of ntop?

ntop is a very good product when it's working, but I don't find it stable enough for a production environment. Additionally it's has (had?) annoying limitations such as not saving any data at all across a service restart, again significantly imparing it's production suitability.

What do you actually want to get out of ntop? If it's not the netflow / ipfix style data then there are probably better products. If you only have a few machines, I'd suggest you have a look at netflow analyzer by manageengine, which gives a free netflow server for 5 machines. you can than run a simpler netflow client on each box, ntop comes with one actually, and send the data in to a more robust and usable server. Or run it on each server if you want to. Same time, you can still run ntop in a central location as well...

I am currently use the following tools to monitor Java servlets:

• Analyze stack (kill -3 & Thread Dump Analyzer)
• Analyze memory dump (jmap & Memory Analyzer)
• Analyze cpu usage, memory usage, garbage collection, number of threads running/waiting (YourKit Profiler)

I am still looking for ways to monitor:

• Network issues which may cause problems with threads taking 300 seconds on particular times. We have no clue what causes the threads to be so slow sometimes. (happens once of twice a week, the entire web cluster is slow at these moments)
• Databases issues which may cause threads to be so slow, same as above.

I thought ntop might be useful for discovering problems for the Network File System, isn't it?

hmm, not really. I mean it could assist in some ways, but not that directly. for something like an oracle connection issue you'll be able to see summary tabular data showing the volume of oracle transactions between each client and the server for periods of time during the day. If you want to retrospectively see what was happening on a given DB connection, i.e. what the network traffic looked like during the point of failure, it won't be able to. Instead if you can justify the disk space, i'd set up a tcpdump / tshark ring buffer to keep a given volume of network traffic on each server so you can go an see the raw traffic, or possibly just the tcp/ip headers to save on space, at any given point within your window.