I am currently having an OS which does support logging mechanisms like syslog. However, it is tedious when it comes to debug a process ie to find out what events or messages have a particular process exchanged with other processes in the system.
Can any one suggest me a better mechanism to do the same ?
I would recommend wrapping your message passing mechanism with some sort of abstraction. Then you can place diagnostics in the message passing layer. I'd imagine that this is a design pattern of some sort. Create an abstraction that includes connectors between processes and messages sent across the connectors. If your message abstraction includes an identifier (e.g., GUID), then you can log the messages that flow through the connectors and follow them through the system easily. Take a look at the C2 architectural style for some ideas.
Part of our switch application uses 20+ single threaded process to handle transactions, each process handles a small part of the transaction processing then sends a request to the next process. Eventually the last process replies and the reply messages are sent back in reverse order.
Our applications all write their trace to their own log files, and this is not very useful for diagnosing problems. So the trace layer also sends all trace to a debug server process, also when ever a process sends or receives a message this info is sent to the debug server with a unique id for the message. This enabled the debug server to join all the messages together an enables us to get a system view for each transaction.
Obviously this is very resource intensive, so by default is off on a busy system, but it can be turned on and the trace level set at runtime to diagnose issues both on site and in development.