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.

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.

The Microsoft 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 projects.

When 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.

In 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.

One of the biggest challenges organizations face when operating web applications is monitoring the availability of complex transactions that involve multiple steps. Developers and testers are often left manually stepping through their applications in the hopes of reproducing problems and replicating the complex nature of user experience. What they really need is a way to simulate real user activity independent of any actual users.

In this article, we’ll explain how to create and monitor web applications using synthetic transactions. We’ll show you how to simulate traffic to a web application, how to record each action using transaction monitoring software, and how logs provide important context to user activity.

If you are looking for a Docker-enabled PaaS, but want to run it on your own infrastructure, Dokku might be a great option to consider. It is basically lightweight open source software that runs on your server. Dokku simplifies deployment by handling the movement of source code, containerization of sites, assignments of domains, builds, SSL certs, and more—just like a cloud-based PaaS. 

Dokku apps are restricted to a single host. When you don’t have enormous scaling needs, Dokku might be a great option. Prototyping, for example, is perfect for Dokku.  You can quickly pull a prototype together and get it out to users for feedback, frequently in the same day. It lets DevOps teams spend more time designing and building projects and less time fiddling with server configurations and deployment issues.

DevOps engineers wishing to troubleshoot Kubernetes applications can turn to log messages to pinpoint the cause of errors and their impact on the rest of the cluster. When troubleshooting a running application, engineers need real-time access to logs generated across multiple components.

Collecting live streaming log data lets engineers:

• Review container and pod activity
• Monitor the result of actions, such as creating or modifying a deployment
• Understand the interactions between containers, pods, and Kubernetes
• Monitor ingress resources and requests
• Troubleshoot errors and watch for new or recurring problems

When it comes to managing risk and ensuring the safety of the data within your network, auditing and managing log data is one of the most important components of any monitoring solution. Keeping detailed records of user activities or changes on your critical systems helps you understand what is occurring within your environment and detect real-time risks.

This tutorial will demonstrate deploying Auditd on a standard web server to monitor user logins, modifications to the /etc/passwd file, and changes to any file in the webserver directory. We’ll setup Auditd monitoring and then use a vulnerability testing tool called Metasploit to trigger a warning. We’ll also show you how to use SolarWinds^® Papertrail^™ to notify you of critical system file or directory changes.