The other day I found myself trying to tune a Ruby on Rails app I had written as a side project. (The app lets me keep track of my favorite eateries and pubs. It’s searchable, includes multiple images, and has stored locations.) On past projects, I relied on SolarWinds^® Papertrail^™, path testing, a lot of trial and error, and a general feel to try to improve performance. This time I thought I would give SolarWinds AppOptics^™ Dev Edition a try.

I’ve never done much with application performance management (APM) tools. I heard they were hard to deploy and configure and pricey. With the announcement of AppOptics Dev Edition, which is designed to be quick to set up, integrated with Papertrail, and free for small pre-production environments, I thought I should give it a shot.

Design applications to be modular. It’s a software design best practice. Modular programming is writing multiple independent programs that perform a single function but work together to achieve an overarching outcome. The benefit to this design is the smaller parts can be easily created and tested. New functionality can be slipped into the larger whole without interfering with other functions.

Modular programming is the approach of dividing up a program into smaller parts, called functions. Developing a function in modular programming is a sub-program that performs a clear task within a program. These tasks are narrow in scope and can be reused over and over again throughout the entire application. Functions need to be clear and simple to reduce complexity and increase readability.

Now With More Log Room

If you’ve visited the SolarWinds^® Papertrail^™ event viewer this week, you may have noticed it’s roomier. There’s less scrolling needed and more of the log line appears on the screen. You may be wondering what changed.

Based on suggestions from user feedback, we streamlined the navigation and tucked it into the top bar. This change lets the logs message fill the entire screen width and lets you see more of the log message, with less scrolling. Now you can sit back and enjoy more screen real estate for log searching fun.

At SolarWinds^® Papertrail^™, we know that when you’re combing through lines and lines of long event messages, every pixel matters. That’s why in the new Papertrail event viewer, we introduced the ability to hide the application chrome.

Hiding the application chrome, or ‘presentation mode,’ removes the header and navigation menus and maximizes your screen real estate.

So far the feedback on this new option has been great. Papertrail fans all over have let us know how much they like this new option. Hiding the application chrome lets them see more of the log message, reduces scrolling, and simplifies troubleshooting.

If you’ve been in the new Papertrail event viewer lately (if not, you should soon!), you might have noticed we made a small change to the way you can hide and display the application chrome. We have now included this option at the bottom of the display options menu.

This change groups all the display preferences in one place and makes it easier to find. This should also make it easier to toggle “hide application chrome” on and off.

Try out the new event viewer and all the new display options, and let us know what you think.

The feedback on the new SolarWinds^® Papertrail^™ event viewer has been overwhelmingly positive. We’ve heard that the new event viewer is “awesome,” “sleek” and “easy to use.”   

We also heard, from some long-time Papertrail fans, that moving the context menu to the right side of the log lines might not have been the best choice. 

The idea behind moving the context menu and event actions to the right side was that it would help prevent fat-fingering mistakes. But we discovered, in moving access to these features to the right edge of the log line, they became easy to miss. 

While our engineering team was hard at work improving the performance of the new event viewer, our design team got to work rejuvenating the user experience. We’re excited to offer some serious upgrades and customization options.

We organized our interface elements, cleaned up the mobile experience, and adopted a new header and navigation to provide a smoother transition when switching between other SolarWinds^® APM products. And of course, we updated the look and feel.

Because the event viewer is the core of SolarWinds Papertrail^™, we wanted to make sure any visual changes we made wouldn’t distract you from your work. We wanted you to continue viewing your logs in the same style you’ve grown accustomed to over the past several years.

The event viewer is the heart of SolarWinds^® Papertrail^™, where you tail logs, save searches, and create alerts. For most Papertrail users, this is where they spend the majority of their time in Papertrail. 

We’ve wanted to update and modernize the event viewer for a while. But knowing that any change to the event viewer can have a large impact on how users find and troubleshoot issues, we wanted to make sure we got it right. 

After more than six months of extensive beta tests and with tons of feedback from our beta users (thank you!), we’re finally ready to unveil the new event viewer.  

Today we announced an integration between SolarWinds^® AppOptics^™ and SolarWinds Papertrail^™ to allow you to quickly move from service-level metrics, down to a trace, and then down to the logs specific to that trace.

The integration between AppOptics and Papertrail provides the ability to group the log messages from a traced transaction and add trace context to your logs in Papertrail. Connecting the dots between the distributed trace and the related logs makes your life easier when troubleshooting application issues—especially in complex environments.

Serverless architectures such as AWS Lambda have created new challenges in debugging code. Without a solid logging framework in place, you could waste hours, or even days, tracking down simple defects in your functions. A strategic logging framework can be a powerful way to track down and resolve bugs.

Let’s walk through how to get the most out of logging Lambda functions. We’ll set up and troubleshoot code to find the root cause of a defect, look at some best practices for logging Lambda functions, and explore setting up alerts.

Working with concurrent code can be a real pain, because it can be difficult to track execution in multiple parts of the code base. Even the trusty debugger can get difficult to use with this kind of code. I’ll show you how logs make it easy to see the application behavior and identify problems. This is especially true when your code is running in the wild on a remote server and you are trying to diagnose problems.

Logging is one of the first tools in a developer’s kit for fixing timing and deadlock issues. When you debug concurrent code, the debugger may appear to jump around as different parts of the code are executed. This is true for both multithreaded and asynchronous code. A log file allows you to quickly see the behavior of your application without slowly stepping through tasks in different parts of the code base. Let’s run through a famous example so you can see exactly what I mean.