Check out the new USENIX Web site. next up previous
Next: Security Problems Up: Reliability and Monitoring Previous: HTTP/TCP Heartbeat

Aggregate Information


Each CoDeeN proxy stores its local monitoring state as well as its peer summary to disk every 30 seconds, allowing offline behavior analysis as well as anomaly detection. The summary is also published and updated automatically on the CoDeeN central status page [16] every five minutes. These logs provide the raw data that we use in our analysis in Section 5. A sample log entry, truncated to fit in the column, is shown in Figure 2.

Figure: Sample monitoring log entry
\begin{figure}
\scriptsize\begin{verbatim}FdTstHst: 0x0
ProxUptm: 36707
Node...
...0 00111 101t0 11121\vert
\normalfont\vspace{-.125in}\vspace{-.15in}\end{figure}

Most of the fields are the measurements that have been mentioned earlier, and the columns in the tabular output represent data about the other nodes in CoDeeN. Values in these lines are usually the counts in base-32 format, where 'w' represents 32. The exception is SysMxCPU, which is the percentage value divided by 10 and rounded up. Based on collected information through UDP heartbeat and HTTP tests, each redirector decides the ``Liveness'' for each CoDeeN node, indicating whether the local node considers that peer node to be viable.

In this particular example, this node is avoiding six of its peers, mostly because they have missed several UDP ACKs. The eighth node, highlighted in boldface, is being avoided because it has a WgetTarg count of 3, indicating that it has failed the HTTP fetch test (with itself as the target) three times out of the past 32. More analysis on the statistics for node avoidance is presented in Section 5.



next up previous
Next: Security Problems Up: Reliability and Monitoring Previous: HTTP/TCP Heartbeat
Vivek Pai
2004-05-04