Troubleshooting in Ruby

Ruby developers and programmers develop applications that experience problems that require solutions and troubleshooting. Processes to diagnose the issues are set up to avoid project failure and to have a successful and effective application. There are specific tools to help resolve difficult to solve Ruby application problems that the typical Ruby structure is unable to clear up.

With the tools available to troubleshoot Ruby issues, there is a need to use Ruby standard development solutions instead of inspecting objects and raising exceptions, adding a log message, and launching an irb. Many times the Ruby standard development solutions fail and there is a need for a deep system level to handle the problems. There are various non-standard tools to diagnose Ruby and resolve issues such as:

lsof

Lsof (LiSt Open Files) is a powerful tool used as a UNIX command that helps to troubleshoot Ruby development applications.
Ways in which lsof is used; first invoke the command without using another specific command such as:

1
2
#List the output consisting of (Command, PID, USER, FD, TYPE, DEVICE, SIZE and NODE NAME)
sudo lsof #The command will troubleshoot of system activities

From the command you will see similar output as shown in the image below:

Using lsof to execute on Ruby files
To investigate the Ruby files we leverage the lsof by adding the following command:

1
2
#View the Ruby files using the lsof command
sudo lsof - c ruby

Using lsof to execute on Ruby Internet connections and processes
The command helps to inspect the Ruby processes over the internet.

1
2
#Inspect the internet connections
sudo lsof - i - a - c ruby

Using lsof to execute on Mongrel Ruby status

1
2
#To check on specific listening PORTS
sudo lsof - Pni: 5000 - 5009

Using lsof to check on Ruby application database

1
2
#Check on Ruby databases by leverage lsof command
sudo lsof - Pni - a - c mongrel

NB: The importance of using lsof commands on Ruby: easy to track the issues on the terminal/command line, the output displayed on the terminal is human readable.

Strace

Strace helps to detect system signals and calls for both inputs and outputs in the terminal/kernel. The below command helps to trace the log files as below:

1
2
3
4
5
#strace redirects to a log file in strace
strace - o strace.log ruby. / script / test - e test

#trace the system calls with specific PID
strace - o starce.log - p(PID) #PID is the number on the process

NB: Strace also helps to find the Ruby Mongrel files in clusters. Strace helps to quickly identify the library in which the directories were loaded.

GDB

GDB is a free, open-source debugging software for all UNIX platforms. It can be used for Ruby tracing by attaching the process of the program as displayed below:

1
2
3
4
5
#Attach ruby processes to diagnose using the process PID number
gdb / usr / bin / ruby(PID)

#Use high privileges to launch the Ruby processes
sudo gdb / usr / bin / ruby(PID)

There are many use cases for GDB such as getting commands to inspect Ruby as shown below:

1
2
3
4
#There in -build gdb commands such as help guide(gdb) help user - defined #All user commands will be defined

#One can print the local variables and values
  (gdb) help rb_locals

Why is GDB important?

• GDB helps to reproduce hard problems/issues and diagnose in an inspection environment of GDB.

• Provides an appropriate way to access Ruby trace to inspect the critical and frozen process.

• Able to troubleshoot issues that were unseen for both the system and the Ruby code.

• GDB is able to switch between threads and tracepoints and modify variables and breakpoints.
  NOTE: Developers need to utilize the UNIX platform while using diagnosing tools such as strace, lsof, GDB, and netstat, especially while on Linux, Solaris, BSD, and Mac OS.

• Mongrel is the server for Ruby development and the fastest HTTP library.

• PID is the Process Identification Number and is unique to defining the system process in the kernel.

Configuration and Troubleshooting Basics of Ruby Framework

There are various basic configurations and requirements to help in troubleshooting Ruby development such as:

1. Confirmation of the reported data working through the troubleshooting Ruby framework

2. Correct environment to test or develop on Ruby framework.

3. Diagnostic CLI runs on Ruby development in collecting data and validation, in which developers can do the following:

   • Required Ruby version

   • The minimum requirements of the OS are met

   • Newrelic_rpm in Gemfile/Gemfile.lock existence on Ruby development

   • Newrelic.yml file presence on the Ruby agent installation.

   • The license key and Ruby application name configuration is valid.

   • Ruby development agent logs existence in the default path

   • Agent availability to connect to the Relic collector

   • Check and verify the logs on the reporting line

   • Account and settings for the application should match

4. Verify and check the raised errors in the application console.

5. Debug log collection and checking the error messages in the log file name or the log file path.

6. The required settings for the newrelic.yml are correctly configured.

7. Have the alternative methods of Ruby configuration well structured on the server-side and on the environment variables.

Ruby Troubleshooting Techniques

There are specific keywords and techniques that are used to troubleshoot Ruby development such as raise, puts, and debug(). One of the most familiar ways to troubleshoot unexpected issues on Ruby is to include the following:

1
2
3
4
5
#Using raise to investigate the unexpected issues
raise some_object.inspect

#Using puts to investigate the unexpected issues
puts some_objects.inspect

The above statement codes help to rerun tests and develop problem cases.

There are other ways to investigate the Ruby development such as irb and script/console which helps to track bugs, investigate the Ruby development code, inspect an API on the application, verify the Ruby object models and syntaxes, and verify the environmental variables and settings.

Steps to consider while writing a test to troubleshoot a Ruby Development app

Writing tests helps to inspect bugs, isolate the issue in the code and figure out the main problem and possible solutions. The following are steps to adhere to:

Log Files

Log files should be present to help easily find the problems and pop-up issues on the Ruby application. You can start the Mongrel debug mode by running the following on the console:

1
Mongrel_rails start - B

The above command helps to log information with the following files: rails.log (contains request parameters), access.log (all access details), objects.log (object types for the application memory usage), files.log (after and before request files are opened), and threads.log (tracking threads).

Dispatch signals

Trigger diagnostic issues are well captured in UNIX processes to provide solutions as system signals. Send signals to the Ruby Mongrel server to help toggle the debugger on/off using the signal command such as USR1 as follows:

1
2
# PID - is the mongrel pid active number
kill - USR1(PID)

Breakpointer and code debugger

The breakpointer helps to investigate and troubleshoot issues by finding the bugs and listing the possible solutions from previously solved problems.

Ruby errors and logs through centralizing

There are tools available to track errors and collect important data such as Retrace software, which was developed to track and log issues with Ruby on Rails, and helps to set alerts to get notifications. Additionally, unforeseen errors are reported. On the Retrace dashboard one can view all Ruby application errors/issues in one place.
NB: A debugger is needed to inspect issues on the Ruby controller to give error messages and handling exceptions.

Rails on ByeBug

ByeBug, which is a gem, works with Rails identically on Ruby applications and it is installed by default on the Rails 5 project.
A sample gemfile to help us debug:

1
2
3
4
5
6
7
8
9
10
11
#Gemfile on Byebug with Rails
group: dev,: new move
gem‘ byebug’, platforms: [: mingw,: x64_mingw,: mri]
end

#Run the Byebug debugger code as shown below
def show
byebug
logger.debug“ The debugger mode: ”+@debug.inspect
json_respond(@debug)
end

Next, start a ByeBug session by running the Rails server with the command as follows:

1
2
#Run the Rails server
rails s

When the request is done and the server starts, ByeBug automatically takes over.

Displaying exception data handler using ByeBug

Rails helps the Ruby application to report the exception errors as displayed below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
(byebug) error exception # Undefined json method

  (byebug) instance_variables # The following are the variables([: @_requests,: @_action_name, @_params, @_routes, @_lookup_context])

#Start the system process and kill the ongoing session
  (byebug) kill
kill ? (y / n) y
Killed: 10

# Step into the next stack trace using“ step”
  (byebug) step #all the contents on the next program will be listed

#Identify the current stack trace using“ where”
  (byebug) where

IMPORTANT REQUIREMENTS FOR RUBY TO WORK WELL:

1. Ruby installation versions are supported by agents which are as follows:
   a. JRuby
   b. MRI

2. Web servers that are supported by the Ruby development agents include:
   a. Puma
   b. Passenger
   c. Rainbows
   d. Thin
   e. Unicorn
   f. Webrick

3. Web frameworks that support the Ruby development agent include:
   a. Padrino
   b. Grape
   c. Rack
   d. Sinatra
   e. Rails

4. Databases that support the Ruby development agent include:
   a. Mongo
   b. ActiveRecord
   c. DataMapper
   d. Redis
   e. Sequel