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
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.
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
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
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
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.
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.
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.
In a perfect world, there wouldn’t be any errors or bugs in production applications. However, we don’t live in a perfect world, and from experience, you know there is no such thing as a bug-free application. If you are using the Laravel framework, you can leverage its log tracking and error logging to catch bugs early and enhance the performance of your Laravel-based application.
Laravel comes pre-packaged with tools to help you track and monitor events. This reduces the effort required to track down those bugs. It comes with a stackable logging system built on top of the popular Monolog library. It also allows you to set up multiple channels based on the severity of the log or event. These channels include stack (stacked), single, daily, Slack, syslog, monolog, SolarWinds® Papertrail®, and so on.
release of ASP.NET Web Forms had most .NET developers excited for a new
framework to replace old Classic ASP scripting. However, Web Forms made it
tedious to keep track of page states resulting in spaghetti code for many web
MVC was introduced, it made web development much easier with the model, view, controller structure. But
it also introduced its own complications, and many.NET programmers ran into challenges
when switching to MVC.
this article, we’ve compiled some of the most common errors in ASP.NET and how
to resolve them.
Once a new Rails app or a new feature for an existing app is “ready”—meaning that everything works as expected locally and all tests pass—it is moved to production, which brings a new set of problems. In this article, we’re going to explore a number of common issues that new Rails developers might face when deploying and running their apps in production, that result in server errors, missing resources, and even timeouts.
One of the greatest advantages of Ruby on Rails (RoR) is its focus on convention over configuration. RoR convention allows programmers—willing to play by the rule book—to develop a Rails application in significantly less time than other frameworks, as well as with significantly less code. How? Well, by lowering the number of decisions a programmer must make when building out their application.