[nanomsg] Re: Monitoring, another approach

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sat, 14 Sep 2013 07:52:37 +0200

Hi Paul.

I *really* want to keep user interface and administrative interface separated. As seen with ZeroMQ, if you publish monitoring data about connections via user API, users will immediately start using it to find out about internal connects/disconnects and implement their own, not well though out, reliability logic.

I believe the monitoring should be done via IPC. The library would connect to a well knows IPC address (/tmp/nn-monitor.ipc or similar) and send the state there.

Martin

On 13/09/13 22:05, Paul Colomiets wrote:
Hi,

Let's try another API for statistics:

uint64_t stat[NN_STAT_NUM];
nn_getsockopt(sock, NN_SOL_SOCKET, NN_STATISTICS,  &stat, sizeof(stat));
printf("stat: %d\n", stat[NN_STAT_MSGCOUNTER]);

Note: we have nn_symbol to iterate over symbols, that may be used to
enumerate NN_STAT_* constants.

To be able to find out a reason for asynchronous errors, we should
provide an option similar to SO_ERROR in posix:

int err;
nn_getsockopt(sock, NN_SOL_SOCKET, NN_ERROR,  &err, sizeof(err));

Pros:

1. Keping nanomsg simpler

2. No need to agree on socket names, it's left up to the application

Cons:

1. More work to integrate in each app

2. Everybody will use it's own version

3. Statistics may be accessed from separate thread, so options should
be lock-free (shouldn't be a problem looking at the code).

(Note: first two cons may be addressed by reference implementation
outside of nanomsg itself)

Thoughts?



Other related posts: