Ex. 1 — Parsing program logs for analysis (12 Points)

It is often necessary to parse the output produced by various specialized software systems to extract/generate data that is of specific interest to us. In this assignment, we will use the advanced Unix utilities that we covered in class to analyze the log files of a distributed software system.

The log files that we will be using for this assignment is available under the directory hierarchy of

/home/2013/jdsilv2/206/mini3/logset1. Please note that this directory may not be accessible through FileZilla, etc. It is primarily meant to be accessed from the Unix command line in mimi.

The description of the software system is provided towards the end of the assignment under the section logs of the distributed system, to help you understand how the log files are generated, the meaning of various descriptions, etc. It is important to read it thoroughly to understand some of the techniques you will have to use to analyze the

log files to generate the required output before continuing with the rest of the questions.

You will be writing a shell script logparser .bash that would process these log files.

1. (0.5 Points) The shell script is expected to be given the name of a directory as its argument, under which we will look for log files whose names are of the form host .port .log. Where host is made up of alpha-numeric

characters and - (like our SOCS servers).  port is basically an integer. Do not hard code the directory name in your script. Each of these are log files of processes with identifiers host:port.

If the script is not invoked with the correct number of arguments, it should throw an usage message and terminate with a code of 1.

2. (0.5 Points)

If the passed argument is not a valid directory name, it should throw an error message and terminate with code 2.  For this particular situation (and only here), the error message must be send to the standard error and not the standard output.

You do not have to explicitly check if you have the permissions to access the directory or the log files.

3. (6 Points)

The script should parse all the log files and produce a comma separated output file (CSV) called logdata .csv of the following format (truncated for brevity), in the current directory (i.e., where you are currently in the shell when the script was invoked).

In the above example, the first field refers to the process that initiated the broadcast, teach-node-05:40190, the second field is the message id (13), unique only to the broadcaster process, the third field is a process that recevied that broadcast message (so basically if you have 6 processes in the group, you will have a maximum of 6 entries in the CSV file per broadcast message - one per receiver).  The fourth, fifth and sixth fields are broadcast time (available only in the sender’s log), receive time and delivery time (the last two being available in the receveing process’s log), respectively.  So as you can see, the broadcast time is the same for all the 6 entries but the other fields could vary.

Please note that since the group communication  (GC) messaging system is not very reliable, a broadcast message may not get to the other process (receive), or in some cases may not get actually delivered.  This means that the entries for receive and/or delivery might be missing from the log files.  In which case you leave those entries empty.   You do not have to worry about duplicate delivery of the same message from a broadcaster.   The output log CSV must be ordered based on the broadcast process identifier,  message identifier, and receiver process identifier.

4. (3 Points) Using logdata .csv, the script must generate another CSV file (in the same directory), stats .csv which would contain a summary of the efficiency of the group communication system. (Truncated for brevity). Below example is only a sample format, the data may not be accurate.

This is basically one row per processes’ that do broadcasts, a corresponding column that shows how many messages were broadcasted by each of the process and a column per each receiver, indicating the percentage of messages that were delivered by the broadcaster at that receiver (as in there is an entry for delivery time in the receiver’s log file for the said messages). Do not include processes that do not perform any broadcasts in the rows.  The file should also have a header to name the columns, as given in the above example.  Rows should follow the order of broadcast process identifiers and columns with in a row (left to right) should follow the order of the process identifers.

5. (2 Points) Next we will use the stats .csv file to generate an HTML file by the name stats .html (also in the same directory). This can be easily accomplished by replacing comma ( ,) with appropriate HTML tags. (Vi the sample file given to you to understand the format). Below example is only a sample format, the data may not be accurate.