The troubleshooting overview in Brooklyn gives information for how to find more information about errors.
If that doesn't give enough information to diagnose, fix or workaround the problem, then it can be required to login to the machine, to investigate further. This guide applies to entities that are types of "SoftwareProcess" in Brooklyn, or that follows those conventions.
VM connection details
The ssh connection details for an entity is published to a sensor
host.sshAddress. The login
credentials will depend on the Brooklyn configuration. The default is to use the
~/.ssh/id_dsa on the Brooklyn host (uploading the associated
~/.ssh/id_rsa.pub to the machine's
authorised_keys). However, this can be overridden (e.g. with specific passwords etc) in the
For Windows, there is a similar sensor with the name
Install and Run Directories
For ssh-based software processes, the install directory and the run directory are published as sensors
For some entities, files are unpacked into the install dir; configuration files are written to the run dir along with log files. For some other entities, these directories may be mostly empty - e.g. if installing RPMs, and that software writes its logs to a different standard location.
Most entities have a sensor
log.location. It is generally worth checking this, along with other files
in the run directory (such as console output).
Process and OS Health
It is worth checking that the process is running, e.g. using
ps aux to look for the desired process.
Some entities also write the pid of the process to
pid.txt in the run directory.
It is also worth checking if the required port is accessible. This is discussed in the troubleshooting guide
including listing the ports in use:
netstat -antp (or on OS X
netstat -antp TCP) to list the TCP ports in use (or use
-anup for UDP).
It is also worth checking the disk space on the server, e.g. using
df -m, to check that there
is sufficient space on each of the required partitions.