Hybrid Cloud Logging Best Practices

By: Chris Riley

Managing logs is hard enough. Managing logs for hybrid multi cloud is even harder.

That’s because a hybrid cloud infrastructure introduces unique challenges when it comes to logging. Not only do you have to deal with more logs than you would when using a single cloud, but you also have more tools, log formats and other variables in the mix.

Fortunately, these are all challenges that can be addressed. Keep reading for an overview of hybrid cloud log analysis best practices, which can help you to make the most of the log data generated by your hybrid cloud infrastructure.

Hybrid Cloud Logging Challenges

Before delving into strategies for working with hybrid cloud logs, let’s examine why log analysis on hybrid cloud infrastructure is hard.

On a hybrid multi cloud (by which I mean any type of cloud infrastructure that mixes together on-premises infrastructure, private cloud infrastructure and/or public cloud infrastructure and services), you face several special challenges associated with logging:

  • Log formatting. If all of your workloads were running on one type of infrastructure, you would probably be able to use a consistent type of format for all of them. But log formats across the different infrastructures that compose your hybrid cloud probably take multiple forms.
  • Multiple logging tools. An infrastructure that blends on-premises infrastructure with public and private clouds also usually involves multiple tools for collecting, managing and analyzing logs. You may have to use vendor-supplied tools for your public cloud, for example, while you use different collection techniques for your on-premises infrastructure.
  • Varying levels of log control. You can probably configure logs for your on-premises and private cloud infrastructure in whichever ways you like. On public cloud, however, configurability is typically limited. You are limited to whichever logging tools and formats your cloud vendor chooses to support.

Hybrid Log Analysis Strategies

How can you solve these challenges and make the most of all of your log data, even on hybrid infrastructure? The following practices can help:

  • Simplify your logging toolset. You might not be able to reduce the complexity of the infrastructure you use, but you can simplify the tools that you use to manage its logs. Where possible, choose log collection and analysis tools that can handle all parts of your infrastructure—the on-premises components, the private cloud and the public cloud. In addition to simplifying the logging tools you have to work with, infrastructure-agnostic logging tools also help you avoid lock-in, because they will be able to support new types of infrastructure if you choose to migrate in the future.
  • Abstract-away logging nuances. You also may not be able to control how all of your logs are formatted, where they are stored, and so on. You can, however, choose log analysis tools that effectively abstract that variability away from you by letting you query logs using a single high-level interface that supports whichever specific formats your various logs contain.
  • Strive for holistic as well as granular visibility. You want your logs to provide insight into the overall health of your entire hybrid cloud. At the same time, however, you also want the ability to track specific components of the infrastructure by disaggregating your on-premises, private and public infrastructures. When you plan your hybrid cloud logging strategy and set up your tools, keep this goal in mind.
  • Plan for compliance. The compliance requirements associated with one part of your hybrid infrastructure may be different for another part. For example, you may need to retain log data for longer periods or have a more detailed audit trail for workloads that run on public cloud infrastructure than for those that run on-premises. Or maybe your compliance needs are just strict across the entire infrastructure. Either way, don’t forget to take compliance into account when you develop a hybrid cloud logging strategy.
  • Prefer cloud-based logging. When it comes to deciding where you actually store your logs and host your logging tools, it’s generally a best practice to do so in the cloud. Cloud-based logging provides greater scalability (because you can increase your logging capacity without having to set up new on-premises hardware) and cost consistency (because you pay the same rate—or very close to it) per gigabyte of log data, and can therefore predict your costs accurately.



By its nature, managing logs for hybrid cloud infrastructure is more complex and challenging in many ways. But by simplifying your logging toolset, centralizing logging in the cloud and focusing on using your logs in ways that provide maximum visibility into your hybrid infrastructure, you can handle the special challenges of log management for the hybrid multi cloud.


How to visualize your log data

A picture is worth a thousand words, and when it comes to log data, this has a very literal meaning.

A typical IT environment generates far more log data than engineers can review. Manually searching through logs is an extremely time-consuming process, and while log management tools help with this process, engineers are still often left combing through individual events. What’s needed is a way for engineers to quickly digest information from logs in order to make operational decisions.

This is where log visualization comes into play. Visualizing log data provides insights into application availability, performance, resource usage, and errors at a glance. It allows teams to generate statistics, identify trends, and detect patterns in operational behavior. The result is a better overall view of your infrastructure.

A real life scenario

To demonstrate this, consider a web application running on a Linux server. The application consists of a website connected to a PostgreSQL database. The application logs to the /var/log/production.log file, while the server logs to a local syslog service. These events are then sent to your centralized logging solution.

Around 12 PM, a software update required us to reboot the server. Shortly after the restart, we noticed unusually slow application performance and instability. We turned to the logs to understand why this happened and to prevent it from recurring.

1. Detecting Errors

Undetected errors can have catastrophic effects on your environment. Logs provide valuable insight into the cause and impact of errors, including the exact state of your applications and services leading up to the error. This helps teams understand when errors occurred, why they occurred, and what steps need to be taken in order to resolve them.

Visualizing errors lets us quickly determine whether any errors impacted the startup process, and if so, when they occurred. 

LogDNA‘s graphing tool helps us quickly plot the volume of log messages containing the word “error” over time.


Here, we can see a few errors followed by a period of stability. A significant spike occurs shortly after 12 PM, which is roughly when the application restarted. We can view the individual log events by clicking on the spike and selecting Show Logs. For any one of these events, we can then click View in context to see the logs immediately surrounding the error. As it turns out, someone or something repeatedly attempted to log into the PostgreSQL database as an administrator with the wrong credentials. This caused PostgreSQL to log an error each time the user was denied:

In our case, it was an engineer attempting to log in via the command line. We resolved the problem by creating a new PostgreSQL user account specifically for that engineer.

2. Detecting Unusual Behavior

Log volume is a basic but important metric. Sudden changes in log volume can indicate errors, software or hardware failures, performance problems, or problems with the logging infrastructure itself. Restarting a server naturally results in a surge in log volume, which we can easily detect by charting log volume over time. However, any other surges could indicate larger problems. As shown below, our virtual machine experienced two major spikes in log volume followed by a period of relative inactivity:


To learn more about the cause of these spikes, we can click on the peak of each spike and use the Show Logs button to view the logs in the LogDNA dashboard. As it turns out, the first spike is the result of logs generated during the virtual machine’s startup process, which is expected. The second spike, however, consists entirely of logs generated by the popularity-contest service, which records statistics about the software installed on the system. Although popularity-contest only ran for a short time, it generated almost an equivalent volume of log data as the startup process.

To get a better idea of the impact that popularity-contest had on log volume, we can add a new plot to the total volume chart and filter the app field to only show events originating from popularity-contest:


Drilling Down with Histograms

Visualizing your total log volume is useful for an overall outlook, but what if you want more granularity? You may want to count log volume by a specific field such as the log level, host, application, or a custom tag.

We can do this in LogDNA simply by creating a histogram and selecting the field we want to plot on. For example, let’s plot out log volume based on the service that generated each event (stored in the app field). Here we can see the popularity-contest service generates the greatest number of messages, followed by the virtual machine’s syslog service and daemon log:


If we create a histogram using the level field instead of the app field, we see that most of these messages are either info or debug logs. However, there are still a few warning, error, and fatal logs, all of which warrant further investigation:


We can click on the popularity-contest spike and use the Show Logs button to view log entries originating from the service:


The solution to this problem was to disable the popularity-contest service. This resulted in slightly faster startup times, less network traffic, and lower log volumes.

3. Analyzing Changes in Performance

In addition to detecting unusual behavior, we can use visualization tools to track application performance metrics including response times, response sizes, and request volumes. It would be useful for your logging graphing engine to calculate and chart statistics for these metrics including averages, minimum and maximum values, sums, differences, and percentiles.

For example, our web application logs the size of each response in bytes. After the restart, the average response size started off significantly higher than usual. Shortly after, the response size fell to a low and steady average:


Using percentiles, we can track metrics that fall far outside of the average, such as unusually large responses. We can do this in LogDNA by changing the metric measured from Averages to 99th Percentile, which displays the top 1% of response sizes over the same period of time:

As with other charts, we can drill-down into each data point to see the relevant log messages. As it turns out, the large responses were caused by users having to re-cache an asset-heavy page after the application was restarted. Once users stopped caching this page, the extremes fell to within 2–3 KB of the average. We can mitigate this by reducing the size of the page, updating the web server caching configuration, or by placing the server behind a content delivery network.



Visualizing your log data is an important step in understanding your infrastructure. While this post doesn’t cover every possible use case, it does show how you can start extracting valuable insights from your logs in a matter of minutes.

To get started, sign in to your LogDNA account and open the graphs tab, or sign up for a free trial account. If you want to learn more about LogDNA’s graphing tools, you can read our announcement on the latest version or view the documentation.

Product Updates

August Product Update

Here’s an update on all the latest and greatest features and improvements we’ve added in the last few months.

GDPR, SAML, and PCI-DSS – oh my!
By popular request, LogDNA has completed our GDPR readiness assessment and Privacy Shield certification, including signing Data Protection Agreements (DPAs). We are also now fully PCI-DSS compliant and have passed our audit with flying colors. And after hearing feedback from multiple customers, we now support custom SAML SSO, including OneLogin and Okta, available upon request.

Graphing 2.0
After weeks of hard work, we’ve released graphing 2.0! Although you may have heard about it earlier, we’d just like to highlight a few key features:

  • Plot multiple lines on the same graph
  • Create breakdowns / histograms
  • Zoom in or set your own custom time range
  • Stack multiple line plots to see proportions

Screen Shot 2018-08-10 at 10.36.22 AM

Other improvements
While we’ve added many improvements, we wanted to highlight a few of them below:

  • Added the ability to provision multiple ingestion keys
  • Improved search performance
  • Improved syslog parsing
  • Enabled autofill on the billing page
  • Switching account now preserves the page you were on

Thank you for your wonderful feedback and until next time, best of logs to you all.

If you want to learn more please register for our August Webinar that walks you through the details on our new graphing engine improvements.

Learn More

Happy Logging,

Ryan Staatz, Head of DevOps @ LogDNA

Comparison, Technical

How Fluentd plays a central role in Kubernetes logging

Written by Twain Taylor

Collecting logs is a complex challenge with containerized applications. Docker enables you to decompose a monolith into microservices. This brings more control over each part of the application. Containers help to separate each layer – infrastructure, networking, and application – from the other layers. It gives you flexibility in where to run your app – in a private data center, or a public cloud platform, or even move between cloud platforms as the need arises. Networking tools are plugins to the container stack and they enable container-to-container communication at large scale. At the application layer, microservices is the prefered model when adopting containers, although containers can be leveraged to improve efficiency in monolithic applications as well. While this is a step up from the vendor-centric options of yesterday, it brings complexity across the application stack. To manage this complexity it takes deep visibility. The kind of visibility that starts with metrics, but goes deeper with logging.

The thing about logging containers is that there are too many data sources. At every level of the stack logs are generated in great detail, certainly much more than traditional monolithic applications. Log data is generated as instances are created and retired, their configurations changed, as network proxies communicate with each other, as services are deployed, and requests are processed. This data is rich with nuggets of information vital for monitoring and controlling the performance of the application.

With the amount of log data ever increasing, it requires specialized tools to manage and adapt to the specific needs of containers at every step of the log lifecycle. Kubernetes is built with an open architecture that leaves room for this type of innovation. It allows for open source logging tools to be created which can extract logs from Kubernetes and process these logs on their own. In response, there have been logging tools that have stepped up to the task. These logging tools are predominantly open source, and give you flexibility in how you’d like to manage logging. There are tools for every step including log aggregation, log analysis, and log visualization. One such tool that has risen to the top in terms of log aggregation is Fluentd.

What is Fluentd?

Fluentd is an open source tool that focuses exclusively on log collection, or log aggregation. It gathers log data from various data sources and makes them available to multiple endpoints. Fluentd aims to create a unified logging layer. It is source and destination agnostic and is able to integrate with tools and components of any kind. Fluentd has first-class support for Kubernetes, the leading container orchestration platform. It is the recommended way to capture Kubernetes events and logs for monitoring. Adopted by the CNCF (Cloud-native Computing Foundation), Fluentd’s future is in step with Kubernetes, and in this sense, it is a reliable tool for the years to come.

Source: Flickr

EFK is the new ELK

Previously, the ELK stack (Elasticsearch, Logstash, Kibana) was the best option to log applications using open source tools. Elasticsearch is a full-text search engine and database that’s ideally suited to process and analyze large quantities of log data. Logstash is similar to Fluentd – a log aggregation tool. Kibana focuses exclusively on visualizing the data coming from Elasticsearch. Logstash is still widely used but now has competition from Fluentd – more on this later. So today, we’re not just talking about the ELK stack, but the EFK stack. Although, admittedly, it’s not as easy to pronounce.

Fluentd Deployment

You can install Fluentd from its Docker image which can be further customized.

Kubernetes also has an add-on that lets you easily deploy the Fluentd agent. If you use Minikube, you can install Fluentd via its Minikube addon. All it takes is a simple command minikube addons enable efk. This installs Fluentd alongside Elasticsearch and Kibana. While Fluentd is lightweight, the other two are resource heavy and will need additional memory in the VM used to host them and will take some time to initialize as well.

Kops, the Kubernetes cluster management tool, also has an addon to install Fluentd as part of the EFK trio.

Another way to install Fluentd is to use a Helm chart. If you have Helm setup, this is the simplest and most future-proof way to install Fluentd. Helm is a package manager for Kubernetes and lets you install Fluentd with a single command:

$ helm install –name my-release incubator/fluentd-elasticsearch

Once installed, you can further configure the chart with many options for annotations, Fluentd configmaps and more. Helm makes it easy to manage versioning for Fluentd, and even has a powerful rollback feature which lets you revert to an older version if needed. It is especially useful if you want to install Fluentd on remote clusters as you can share Helm charts easily and install them in different environments.

If you use a Kubernetes managed service they may have their own way of installing Fluentd that’s specific to their platform. For example, with GKE, you’ll need to define variables that are specific to the Google Cloud platform like region, zone, and Project ID. Then, you’ll need to create the service account, create a Kubernetes cluster, deploy a test logger and finally deploy the Fluentd daemonset to the cluster.

How it works

The Docker runtime collects logs from every container on every host and stores them at /var/log. The Fluentd image is already configured to forward all logs from /var/log/containers and some logs from /var/log. Fluentd reads the logs and parses them into JSON format. Since it’s stored in JSON the logs can be shared widely with any endpoint.

Fluentd also adds some Kubernetes-specific information to the logs. For example, it adds labels to each log message to give the logs some metadata which can be critical in better managing the flow of logs across different sources and endpoints. It reads Docker logs, etcd logs, and kubernetes logs.

The most popular endpoint for log data is Elasticsearch, but you can configure Fluentd to send logs to an external service such as LogDNA for deeper analysis. By using a specialized log analysis tool, you can save time troubleshooting and monitoring. With features like instant search, saved views, and archival storage of data, a log analysis tool is an essential if you’re setting up a robust logging system that involves Fluentd.

Fluentd Alternatives


Logstash is the most similar alternative to Fluentd and does log aggregation in a way that works well for the ELK stack.

Logstash uses if-then rules to route logs while Fluentd uses tags to know where to route logs. Both are powerful ways to route logs exactly where you want them to go with great precision. Which you prefer will depend on the kind of programming language you’re familiar with – declarative or procedural.

Next, both Fluentd and Logstash have a vast library of plugins which make them both versatile. In terms of getting things done with plugins, both are very capable and have wide support for pretty much any job. You have plugins for the most popular input and output tools like Elasticsearch, Kafka, and AWS S3 and plugins for tools that may be used by a niche group of users as well. Fluentd here has a bit of an edge as it has a comparatively bigger library of plugins.

Source: Flickr

When it comes to size, Fluentd is more lightweight than Logstash. This has a bearing on the logging agent that’s attached to containers. The bigger the production applications, the larger the number of containers and data sources, the more agents are required. A lighter logging agent like Fluentd’s is prefered for Kubernetes applications.

Fluent Bit

While Fluentd is pretty light, there’s also Fluent Bit an even lighter version of the tool that removes some functionality, and has a limited library of 30 plugins. However, it’s extremely lightweight weighing in at ~450KB next to the ~40MB of the full blown Fluentd.


Logging is a critical function when running applications in Kubernetes. Logging is difficult with Kubernetes, but thankfully, there are capable solutions at every step of the logging lifecycle. Log aggregation is at the center of logging with Kubernetes. It enables you to collect all logs end-to-end and deliver them to various data analysis tools for consumption. Fluentd is the leading log aggregator for Kubernetes due to its’ small footprint, better plugin library, and ability to add useful metadata to the logs makes it ideal for the demands of Kubernetes logging. There are many ways to install Fluentd – via the Docker image, Minikube, kops, Helm, or your cloud provider.

Being tool-agnostic, Fluentd can send your logs to Elasticsearch or a specialized logging tool like LogDNA. If you’re looking to centralize logging from Kubernetes and other sources, Fluentd can be the unifying factor that brings more control and consistency to your logging experience. Start using Fluentd and get more out of your log data.


How to Learn Kubernetes – The Best Tutorials, Comics, and Guides

Want to learn Kubernetes but don’t know where to start? I was in the same boat, and after reading numerous Kubernetes tutorials, I realized there had to be an easier way for beginners to learn.

Having recently joined LogDNA, I’m going to share what I learned in the past two weeks, as well as the best resources I found – comics, guides, tutorials – all so you can go from zero to Kubernetes expert in no time.

Full disclosure, I started out building php and wordpress sites long ago, and I am mostly familiar with “ancient” self hosted monolithic applications. I’m a newbie when it comes to containers and container orchestration.

Surprisingly, of all resources, it was through a series of comics that I found my bearings of what Docker containers and Kubernetes is. The first and best was created by Google: Smooth Sailing with Kubernetes. I highly recommend reading this first.

What Are Containers?

The most familiar reference that I have to compare containers to are Virtual Machines. Virtual Machines offer isolation at the hardware level, where a server offers guest operating systems to run on top of it. Not only VMWare but Microsoft Hyper-V, Citrix XenServer, and Oracle VirtualBox all with Hypervisors that enabled hardware virtualization and let each guest OS have access to CPU, memory and other resources. The limitations with VM was that each guest operating system had a large footprint of its own full OS image, memory and storage requirements. So scaling them was costly and the applications weren’t portable between hosting providers, and private/public clouds.

Containers sit on top of the physical hardware and its host operating system to share the host OS’ kernel, binaries, and libraries. This way they’re much more light weight with image sizes in the megabytes instead of gigabytes and can start up in seconds rather than minutes. Along with obvious performance benefits, they also reduce management overhead of updating and patching full operating systems and they’re much more portable to different hosting providers. Multiple containers can run on a single host OS which saves operating costs.

Consolia’s comic offers a great visualization of the difference between VM and Containers:

And xkcd offers offers some humor on containers.

Docker wanted to allow developers to create, deploy and run applications through the use of containers. With Docker containers, they focused on faster deployment speeds, application portability, and reuse. Docker does not create an entire virtual operating system and will require that the components that are not already on the host OS to be packaged inside the container. Applications will be packaged up with exactly what they need to run, no more and no less.

Some interesting information on Docker containers and how incredibly quickly they’ve been adopted around the world:

  • It was only released in 2014
  • Over 3.5M applications have been placed in containers using Docker
  • 37B containerized apps have been downloaded so far

What is Kubernetes?

This Illustrated Children’s Guide to Kubernetes is really good at explaining the need for Kubernetes.

Google created and open sourced the Kubernetes orchestration system for docker containers. It is used to automate the deployment, scaling and management of containerized applications.

Google runs over 2 billions containers per week and built Kubernetes to be able to do so at worldwide scale.The idea is to provide tools for running distributed systems in production like load balancing, rolling updates, resource monitoring, naming and discovery, auto-scaling, mounting storage systems, replicating application instances, checking the health of applications to log access, and support for introspection.

Kubernetes allows developers to create and manage clusters and scale them. Brian Dorsey’s talk at GOTO 2015 helped get from concept to seeing a real life example of deployment, replication and updates within an hour.

Side note, I’m currently reading Google’s SRE book and awe-struck by their story of scaling up.

How to Get Started

I started with the official docs of Kubernetes Basics And then followed this Hello World Mini Kubes tutorial. I’m just making my way through this excellent tutorial now called Kubernetes the Hard Way.

So far, now that I have a basic understanding of Containers and Kubernetes, I’m really excited at all its possibilities. It’s incredible to see that such powerful tools are available to all, both for developers to do CI/CD and especially for devops to scale, maintain 24/7 availability regardless of what happens and get a good night’s rest without alerts of catastrophic failures.

I’m also realizing that using Kubernetes also requires the use of other additional tools like Helm for managing Kubernetes packages and expedites the need for centralized logging and monitoring tools. It’s not as simple as logging into a server to look at a log file anymore when you’re dealing with many replicas and nodes that start and stop on the fly. As you come up with your Kubernetes logging strategy, here are some key Kubernetes metrics to log. It’s cool to see how LogDNA solves this integration with Kubernetes better than any other log management solution in the market. You have a choice of doing this yourself or get up and running with just two lines.


Challenges with Logging Serverless Applications

Serverless computing is a relatively new trend with big implications for software companies. Teams can now deploy code directly to a platform without having to manage the underlying infrastructure, operating system, or software. While this is great for developers, it introduces some significant challenges in monitoring and logging applications.

This post explores both the challenges in logging serverless applications, and techniques for effective cloud logging.

What is Serverless, and How is it Different?

In many ways, serverless computing is the next logical step in cloud computing. As containers have shown, splitting applications into lightweight units helps DevOps teams build and deploy code faster. Serverless takes this a step further by abstracting away the underlying infrastructure, allowing DevOps to deploy code without having to configure the environment that it runs on. Unlike containers or virtual machines, the platform provider manages the environment, provisions resources, and starts or stops the application when needed.

For this post, we’ll focus on a type of serverless computing called Functions as a Service (FaaS). In FaaS, applications consist of individual functions performing specific tasks. Like containers, functions are independent, quick to start and stop, and can run in a distributed environment. Functions can be replaced, scaled, or removed without impacting the rest of the application. And unlike a virtual machine or even a container, functions don’t have to be active to respond to a request. In many ways, they’re more like event handlers than a continuously running service.

With so many moving pieces, how do you log information in a meaningful way? The challenges include:

  • Collecting logs
  • Contextualizing logs
  • Centralizing logs

Collecting Logs

Serverless platforms such as AWS Lambda and Google Cloud Functions provide two types of logs: request logs and application logs.

Request logs contain information about each request that accesses your serverless application. They can also contain information about the platform itself, such as its execution time and resource usage. In App Engine, Google’s earliest serverless product, this includes information about the client who initiated the request as well as information about the function itself. Request logs also contain unique identifiers for the function instance that handled the request, which is important for adding context to logs.

Application logs are those generated by your application code. Any messages written to stdout or stderr are automatically collected by the serverless platform. Depending on your platform, these messages are then streamed to a logging service where you can store them or forward them to another service.

Although it may seem unnecessary to collect both types of logs, doing so will give you a complete view of your application. Request logs provide a high-level view of each request over the course of its lifetime, while application logs provide a low-level view of the request during each function invocation. This makes it easier to trace events and troubleshoot problems across your application.


Contextualizing Events

Context is especially important for serverless applications. Because each function is its own independent unit, logging just from the application won’t give you all the information necessary to resolve a problem. For example, if a single request spans multiple functions, filtering through logs to find messages related to that request can quickly become difficult and cumbersome.

Request logs already store unique identifiers for new requests, but application logs likely won’t contain this information. Lambda allows functions to access information about the platform at runtime using a context object. This object lets you access information such as the current process instance and the request that invoked the process directly from your code.

For example, this script uses the context object to include the current request ID in a log:

import logging

def my_function(event, context):"Function invoked.",
extra={"request_id": context.aws_request_id})

In addition, gateway services such as Amazon API Gateway often create separate request IDs for each request that enters the platform. This lets you correlate log messages not only by function instance, but for the entire call to your application. This makes it much easier to trace requests that involve multiple functions or even other platform services.

Centralizing Logs

The decentralized nature of serverless applications makes collecting and centralizing logs all the more important. Centralized log management makes it easier to aggregate, parse, filter, and sort through log data. However, serverless applications have two very important limitations:

  • Functions generally have read-only filesystems, making it impossible to store or even cache logs locally
  • Using a logging framework to send logs over the network could add latency and incur additional usage charges

Because of this, many serverless platforms automatically ingest logs and forward them to a logging service on the same platform. Lambda and Cloud Functions both detect logs written to stdout and stderr and forward them to AWS CloudWatch Logs and Stackdriver Logs respectively, without any additional configuration. You can then stream these logs to another service such as LogDNA for more advanced searching, filtering, alerting, and graphing. This eliminates the need for complex logging configurations or separate log forwarding services.


Although the serverless architecture is very different from those preceding it, most of our current logging best practices still apply. The main difference is in how logs are collected and the information they contain about the underlying platform. As the technology matures, we will likely see new best practices emerge for logging serverless applications.

Product Updates

Graphing 2.0 is Now Live!

We wanted to share some exciting details around our new graphing engine which went live today.  One of the biggest areas of feedback we’d been consistently hearing was that our customers wanted a better way to visualize their log data.

While working on the new graphing features, our engineering team spoke with dozens of teams using our tools today. This shaped how we rebuilt our graphing engine, including improved stability and performance as well as new visualizations that can provide deeper insights into your log data. Here are a few of the key features below:

New Features

Feature Details
Histograms Create value distributions from queries
Multiple plots on the same graph Compare different data sets on the same graph
Specify your own time ranges Zoom in, zoom out and even select custom time ranges from a calendar
Lines for plots, bars for histograms All your existing bar graphs are now line graphs. This improvement allows for multiple plots.
Field value autocomplete See possible field values to select from when making a query

The new graphing engine is available today! All you need to do to start using the latest graphs is login to your account or sign up for free.  

We’re also hosting a 30 minute graphing webinar to dive deep into our new graphing engine and highlight some of the new features mentioned above. Learn how to get the most out of our latest graphing capabilities! Register for our webinar here

If you have any questions, feedback or want to talk to support please drop us a note at