The usual way for viewing remote CQ logs seem pretty barbaric and kludgy to me.  Cat, tail, VI, less, and a partridge in a pear tree.  They all require way too many steps, especially if I am in the heat of the development cycle.  If I am leisurely browsing through the park one day trying to look at my logs, and I'm not in a hurry, they will do.  But I like the solution below because of its lower "just in time" overhead for getting at those log files.  Plus there is also the issue of dealing with the huge amount of white noise in the logfile that it deals with as well.

What this is

We are configuring ssh on the remote Unix side to allow us to automatically log into that server using Putty.  We are also configuring putty to automatically execute 2 commands to: cat the error.log and then tail it for the changes.  We are also configuring putty to log all printable output to a local file.  On our local system we will use a file tail-ing application to monitor the logfile created by Putty.  The application we are using will also allow us to use regexes to match against the logfile to identify and highlight matching text.

The Ingredients

  1. Putty - Download Link - Look in Synaptic for the Debian based version
  2. PuttyGen
  3. BaretailPro (buy the pro version - it's worth the money - besides as a professional you can afford the 35 bucks)
  4. WINE (if your local development system is a Linux-based Unix environment)
  5. Sweat of your brow

Some comments
Obviously all of these applications run on a Windows system.  "Come now", you query, "Surely you jest!  What about us Linux folk?"  I assure you that all of these applications run on Ubuntu.  Putty has a Unix version, BaretailPro and PuttyGen both run on Ubuntu using WINE.  I have been using them both for 3+ years.  If you are on a Mac, you will have to extrapolate the solution here for your environment.

The Solution

PuttyGen Configuration

  1. Fire up PuttyGen and click on the radio button "SSH-2 DSA" at the bottom of the window
  2. Click the "Generate" button and follow the instructions below the menubar at the top of the window
  3. Click the "Save private key" button at the bottom of the window.  You will need this later.  I did not use a passphrase when saving my private key.  This negated the automation I was looking for.  If I wanted to type a password in, I would never have used PuttyGen to generate the keys to auto-log me in.
  4. Copy the text within the "Public key for pasting into OpenSSH authorized_keys file:" textarea, paste it into a text editor and save it somewhere.  You will need this later.
  5. Login to your remote Unix server
  6. Create the directory .ssh if it does not already exist, and change your working directory to here
  7. Create the file authorized_keys if it does not already exist
  8. Execute this command only if you had to create the authorized_keys file: chmod 755 authorized_keys
  9. Edit the authorized_keys file with VI and paste the contents of the file from Step 4 above and save your changes

Putty Configuration

  1. Create a new profile, specifying the hostname and Saved Session name
  2. Click on "Logging" beneath "Session"
  3. Select the "Printable output" radio button
  4. Select a filename and location - I store my on my desktop for convenience
  5. Select the "Always overwrite it" radio button
  6. Select "Data" beneath "Connection" and fill in your remote Unix username in "Auto-login username"
  7. Select "SSH" and fill in the "Remote command" textbox with: cat <path-to-cq-logs>/error.log ; tail -F <path-to-cq-logs>/error.log - I will explain this below
  8. Select "Auth" and in the "Authentication parameters" section, browse and select the Private key file from the "PuttyGen Configuration - Step 3"
  9. Scroll back to the top and select "Session" then click "Save" - don't forget to do this or you will lose all of your configurations up to this point.

In Step 7 we are cat-ing the error log and then tail-ing it.  This way we will have the entire logfile plus any subsequent chages.  This might seem a bit lazy to have 20 or so lines duplicated.  But in the years of using this solution it has never interefered with my ability to troubleshoot.  There seemed to me to be a diminishing return for trying to get the logfile"exactly" right - so I never bothered under the premise that perfection was not needed.

The "-F" not only follows the end of the file, but if the logfile rolls to a new file, tail will continue to follow the end of the new file.  You can use "-f" but when the logfile rolls, you will stop getting updates.

OK - so fire up your new putty configuration and "Open" it.  This will create your local logfile, which you can now start mining with BaretailPro.  Open the logfile in BaretailPro and start using those mind-numbing white-noise expressions to track down those buried messages of yours!  keep in mind there are some features that are only available with the full version - but like I said, its worth the money IMHO.

Hope this saves you time in your development cycles.