Welcome!

@DevOpsSummit Authors: Jnan Dash, Liz McMillan, Zakia Bouachraoui, Janakiram MSV, Pat Romanski

Related Topics: @DevOpsSummit, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Article

Make Sense of Errors and Logging By @Stackify | @DevOpsSummit [#DevOps]

While errors and logs are often instrumental to diagnosing application issues, getting the most out of them isn't easy

Three Ways to Make Sense of Errors & Logging
By Craig Ferril

Errors and log files are two of the most important tools a developer have to try and find the source of a problem.  If you're like most developers, your approach to capturing and utilizing errors and logs is fairly straightforward. You probably send log output to a file or a log aggregation product. You may notify on the occurrence of errors, either sending emails directly from your code, or via an error monitoring product.

What's lacking from these approaches is something a bit more holistic, comprehensive, and contextual. The trouble comes in two forms:

  • There's often way more noise than signal if you're solely relying on logs to track, isolate, and make sense out of your errors, especially if an error is being thrown over and over again, or if you're dealing with log files across numerous servers
  • If you're focused primarily on errors, either emailing on error occurrences or using an error monitoring program, that approach removes the relevant logs from the picture altogether, leaving you without the context you need to determine root cause.

In this article , I'll cover three ways you can make sense of your errors and logs together:

  1. Aggregation - If you're developing an application that runs on a single server, finding all of your logs isn't an issue for you.  But it's far more likely that you have applications hosted on multiple servers for purposes of availability, scalability and redundancy, making it more difficult to easily (and centrally) access errors and logging data. Tools exist to aggregate logs in various standard formats (assuming you have access ), which is a good step in the right direction, given the potential for numerous separate logging files, as well as log file rotation and retention issues. The right answer is to implement a solution that aggregates logs and errors with development in mind. That way, you can be sure you are collecting every piece of information necessary and have it presented in a way that's geared toward developers.
  2. Error De-duplication - While aggregation ensures that all of your logs and errors end up in a central location, that can lead to a lot of noise that hides the truly valuable insights that are hiding in your logs. Taking a step beyond simply aggregating log statements, toward deriving fast insights from your logs and errors, means implementing a strategy that de-duplicates errors and provides additional information anchored to each incident of the error, without forcing you to wade through an endless stream of error statements in a log. Treating individual errors as first-class items of interest, rather than just yet another line in the log file, gives you top-level visibility, enables you to configure effective notification and resolution strategies focused on a specific exception, and, with the right platform, gives you an anchor point for seeing only the log statements related to that error (rather than sifting through all log statements to find the ones that matter). This all adds up to a strategy that filters out all the noise and focuses your efforts in on just what you care about.
  3. Analysis - Even if you can aggregate your data and associate the error and logging data together, you still are left with a very long chronological list of stuff your application did (and didn't do - thus, the exceptions).  There are still several needs to be addressed before we can truly say we can make sense of this data set - issues like seeing the frequency of errors, tying exceptions on one server with methods and processes on another, being able to search quickly through this massive data set, and even just being able to quickly jump to a particular point in time - all of these, and more, need to be part of the solution to properly make sense of the data you have.

While errors and logs are often instrumental to diagnosing application issues, getting the most out of them isn't easy. If you're using a narrowly focused tool or rolling your own solution, it's likely you're either struggling to quickly get to the data you need when you need it, or you're trying to find a needle in a haystack (or, perhaps more apt, a needle in a needle stack). Creating effective error notifications, error de-duplication, log aggregation and analysis, and seamless correlation between errors and just the log statements that are relevant presents an especially difficult challenge. Getting it right requires tremendous custom development, a mix of custom development on top of a product that offers a partial solution, or possibly adopting multiple solutions that each only solve part of the problem. That is, of course, unless you use Stackify Smart Error and Log Management!

To get a more in-depth look at evolving your application troubleshooting, read the whitepaper 3 Steps to Evolve your Application Troubleshooting .

Photo Credit: Windell Oskay

More Stories By Stackify Blog

Stackify offers the only developers-friendly solution that fully integrates error and log management with application performance monitoring and management. Allowing you to easily isolate issues, identify what needs to be fixed quicker and focus your efforts – Support less, Code more. Stackify provides software developers, operations and support managers with an innovative cloud based solution that gives them DevOps insight and allows them to monitor, detect and resolve application issues before they affect the business to ensure a better end user experience. Start your free trial now stackify.com

@DevOpsSummit Stories
If you are part of the cloud development community, you certainly know about “serverless computing,” almost a misnomer. Because it implies there are no servers which is untrue. However the servers are hidden from the developers. This model eliminates operational complexity and increases developer productivity. We came from monolithic computing to client-server to services to microservices to the serverless model. In other words, our systems have slowly “dissolved” from monolithic to function-by-function. Software is developed and deployed as individual functions – a first-class object and cloud runs it for you. These functions are triggered by events that follow certain rules. Functions are written in a fixed set of languages, with a fixed set of programming models and cloud-specific syntax and semantics. Cloud-specific services can be invoked to perform complex tasks. So for cloud-na...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex to learn. This is because Kubernetes is more of a toolset than a ready solution. Hence it’s essential to know when and how to apply the appropriate Kubernetes constructs.
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It's clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. That means serverless is also changing the way we leverage public clouds. Truth-be-told, many enterprise IT shops were so happy to get out of the management of physical servers within a data center that many limitations of the existing public IaaS clouds were forgiven. However, now that we've lived a few years with public IaaS clouds, developers and CloudOps pros are giving a huge thumbs down to the...
To enable their developers, ensure SLAs and increase IT efficiency, Enterprise IT is moving towards a unified, centralized approach for managing their hybrid infrastructure. As if the journey to the cloud - private and public - was not difficult enough, the need to support modern technologies such as Containers and Serverless applications further complicates matters. This talk covers key patterns and lessons learned from large organizations for architecting your hybrid cloud in a way that: Supports self-service, "public cloud" experience for your developers that's consistent across any infrastructure. Gives Ops peace of mind with automated management of DR, scaling, provisioning, deployments, etc.
xMatters helps enterprises prevent, manage and resolve IT incidents. xMatters industry-leading Service Availability platform prevents IT issues from becoming big business problems. Large enterprises, small workgroups, and innovative DevOps teams rely on its proactive issue resolution service to maintain operational visibility and control in today's highly-fragmented IT environment. xMatters provides toolchain integrations to hundreds of IT management, security and DevOps tools. xMatters is the primary Service Availability platform trusted by leading global companies and innovative challengers including BMC Software, Credit Suisse, Danske Bank, DXC technology, Experian, Intuit, NVIDIA, Sony Network Interactive, ViaSat and Vodafone. xMatters is headquartered in San Ramon, California and has offices worldwide.