Querying Multiple ElasticSearch Clusters with Cross-Cluster Search

With great power comes great responsibility, and with big data comes the necessity to query it effectively. ElasticSearch has been around for over seven years and changed the game in terms of running complex queries on big data (petabyte scale). Tasks like e-commerce product search, real-time log analysis for troubleshooting or generally anything that involves querying big data is considered “data intensive”. ElasticSearch is a distributed, full-text search engine, or database, and the key word here is “distributed”.

A lot of small problems are much easier to deal with than a few big ones, and DevOps is all about spreading out dependencies and responsibility so it’s easier on everyone. ElasticSearch uses the same concept to help query big data; it’s also highly scalable and open-source. Imagine you need to setup an online store, a private “Google search box” that your customers could use to search for anything in your inventory. That’s exactly what ElasticSearch can do for your application monitoring and logging data. It stores all your data, or in the context of our post, all your logging data in nodes that make up several clusters.

DevOps on Data

Staying with the online store example, modern day queries can get pretty technical and a customer could, for example, be looking for only products in a certain price range, or a certain colour, or a certain anything. Things can get more complicated if you’re also running a price alerting system that lets customers set alerts if things on their wish list drop below a certain price. ElasticSearch gives you those full-text search and analytics capabilities by breaking data down into nodes, clusters, indexes, types, documents, shards and replicas. This is how it allows you to store, search, and analyze big data quickly and in “near” real time (NRT).

The architecture and design of ElasticSearch is based on the assumption that all nodes are located on a local network. This is the use case that is extensively tested for and in a lot of cases is the environment that users operate in. However, monitoring data can be stored on different servers and clusters and to query them, ElasticSearch needs to run across clusters. If your clusters are at different remote locations, this is where ElasticSearch’s assumption that all nodes are on the same network starts working against you. When data is stored across multiple ElasticSearch clusters, querying it becomes harder.

Global Search


Network disruptions are much more common between distributed infrastructure (even with a dedicated link) along with a host of other problems. Workarounds are what adapting to new technology is all about, and there have been a number of them — one of the most recent and effective ones being tribe nodes. ElasticSearch has a number of different use cases within organizations and are spread across departments. It could be used for logging visitor data in one, analyzing financial transactions in another, and deriving insights from social media data across a third.

Since data resides across the cluster on different nodes, some complex queries need to get data from multiple nodes and process them; for that you need to query multiple clusters. If all these clusters are not at the same physical location, tribe node connects them and lets you deal with them like one big cluster. What makes the tribe node unique is that it doesn’t impose any restrictions on core APIs like the cross-cluster search. The tribe node supports almost all APIs, with the exception of meta-level APIs like Create Index, for example, which must be executed on each cluster separately.

Tribe Nodes

The tribe node works by executing search requests across multiple clusters and merging the results from each cluster into a single global cluster result. It does this by actually joining each cluster as a node that keeps updating itself on the state of the cluster. This uses considerable resources, as the node has to acknowledge every single cluster state update from every remote cluster.

Additionally, with tribe nodes, the node that receives the request (the corresponding node) basically does all the work. This means the node that receives the request identifies which indices, shards, and nodes the search has to be executed against. It sends requests to all relevant nodes, decides what the top N-hits that need to be fetched are and then actually fetches them.

The tribe node is also very hard to maintain code-wise over time — especially since it’s the only exception to ElasticSearch’s rule that a node must belong to one and only one cluster.

Cross-Cluster Search

If DevOps is about spreading the load around, it’s pretty obvious what the problem is with tribe node. One node is being taxed with all the processing work while the nodes not relevant to the query standby idle. With cross-cluster search, you’re actually remotely querying each cluster with its own _search APIs, so no additional nodes that need to be constantly updated would join the cluster and slow it down. When a search request is executed on a node, instead of doing everything itself, the node forwards the indices at a rate of one _search_shard request per cluster.

The _search API allows ElasticSearch to execute searches, queries, aggregations, suggestions, and more against multiple indices which are in turn broken down into shards. The concept is that instead of having a huge Database A, Database B, Database C and so on, it merges everything into one giant solid block of data. The next step is to break it down into bits (shards) and give every node a piece to look after, worry about, care for, maintain, and query when required. This makes it a lot easier to query since the load is spread evenly across all the nodes.

Now, unlike in tribe nodes where the first node would wait for every node to reply, do the math and fetch the documents, with cross-cluster search the initial node has done it’s job already. Once the shards are sent to all clusters for comparison, all further processing is done locally on the relevant clusters. Further time and processing power is saved by sending shards to only 3 nodes per cluster by default; you can also choose how many nodes per cluster you would like discovered.

One Direction


Now traffic flows only one way in cross-cluster searches and that means the corresponding node just passes the message on to the three default nodes that carry on the process. You can also choose which nodes you would like to act as gateways and which nodes you would actually like to store data on. This gives you a lot more control over the traffic going in and out of your cluster.

Again, unlike tribe nodes that require an actual additional node in each of your clusters, with cross-cluster search, no additional or special nodes are required for cross cluster searches and it isn’t tied to any specific API. Any node can act as a corresponding node and you can control which nodes get to be corresponding nodes and which nodes don’t. Furthermore, when merging clusters, tribe nodes can’t keep two indices with the same name even if they’re from different clusters. Cross-cluster search aims to fix this limitation by being able to dynamically register, update, and remove remote clusters.

The Need For Logging

There are also commercial algorithms built on ElasticSearch to make life and logging even easier. LogDNA is a good example, and we’ve been known to talk about our product in context of it being the “Apple of logging”. Along with predictive intelligence and machine learning, LogDNA allows users to aggregate, search and filter from all hosts and apps. LogDNA also features automatic parsing of fields from common log formats, such as weblogs, Mongo, Postgres and JSON. Additionally, we offer a live-streaming tail using a web interface or command line interface (CLI).

LogDNA provides the power to query your log data end-to-end without having to worry about clusters, nodes, or indices. It does all the heavy lifting behind the scenes so you enjoy an intuitive and intelligent experience when analyzing your log data. As we discussed earlier, maintaining your own ElasticSearch stack and stitching together all the infrastructure and dependencies at every level is a pain. Instead, you’re better off saving all that time and opting for a third-party tool that abstracts away low-lying challenges and lets you deal with your log data directly. That’s what tools like LogDNA do.  

From not being able to query across clusters, to querying through a special node, to finally remotely querying across clusters, ElasticSearch is certainly making progress. In an age where data is “big”, nothing is as important as the ability to make it work for you and we can sure expect ElasticSearch to continue to make this feature better. However, if you’d rather save yourself all the effort of managing multi-cluster querying, and instead analyze and derive value from your log data, LogDNA is the way to go.

kubernetes, Technical

Top Kubernetes Metrics & Logs for End-to-End Monitoring

Kubernetes makes life as a DevOps professional easier by creating levels of abstractions like pods and services that are self sufficient. Now, though this means we no longer have to worry about infrastructure and dependencies, what doesn’t change is the fact that we still need to monitor our apps, the containers they’re running on, and the orchestrators themselves. What makes things more interesting, however, is that the more Kubernetes piles on levels of abstraction to “simplify” our lives, the more levels we have to see through to effectively monitor the stack.

Across the various levels you need to monitor resource sharing, communication, application deployment and management, and discovery. Pods are the smallest deployable units created by Kubernetes that run on nodes which are grouped into clusters. This means that when we say “monitoring” in Kubernetes, it could be at a number of levels — the containers themselves, the pods they’re running on, the services they make up, or the entire cluster. Let’s look at the key metrics and log data that we need to analyze to achieve end-to-end visibility in a Kubernetes stack.

Usage Metrics

Performance issues generally arise from CPU and memory usage and are likely the first resource metrics users would want to review. This brings us to cAdvisor, an open source tool that automatically discovers every container and collects CPU, memory, filesystem, and network usage statistics. Additionally, cAdvisor also provides the overall machine usage by analyzing the ‘root’ container on the machine. Sounds too good to be true, doesn’t it? Well it is, and the catch is that cAdvisor is limited in a sense that It only collects basic resource utilization and doesn’t offer any long term storage or analysis capabilities.

CPU, Memory and Disk I/O

Why is this important? With traditional monitoring, we’re all used to monitoring actual resource consumption at the node level. With Kubernetes, we’re looking for the sum of the resources consumed by all the containers across nodes and clusters (which keeps changing dynamically). Now, if this sum is less than your node’s capacity, your containers have all the resources they need, and there’s always room for Kubernetes to schedule another container if load increases. However, If it goes the other way around and you have too few nodes, your containers might not have enough resources to meet requests. This is why making sure that requests never exceed your collective node capacity is more important than monitoring simple CPU or memory usage.

With regards to disk usage and I/O, with Kubernetes we’re more interested in the percentage of disk in use as opposed to the size of our clusters, so graphs are wired to trigger alerts based on the percentage of disk size being used. I/O is also monitored in terms of Disk I/O per node, so you can easily tell if increased I/O activity is the cause for issues like latency spikes in particular locations.

Kube Metrics

There are a number of ways to collect metrics from Kubernetes, although Kubernetes doesn’t report metrics and instead relies on tools like Heapster instead of the cgroup file. This is why a lot of experts say that container metrics should usually be preferred to Kubernetes metrics. A good practice however, is to collect Kubernetes data along with Docker container resource metrics and correlate them with the health and performance of the apps they run. That being said, while Heapster focuses on forwarding metrics already generated by Kubernetes, kube-state-metrics is a simple service focused on generating completely new metrics from Kubernetes.

These metrics have really long names which are pretty self explanatory; kube_node_status_capacity_cpu_cores and kube_node_status_capacity_memory_bytes are the metrics used to access your node’s CPU and memory capacity respectively. Similarly, kube_node_status_allocatable_cpu_cores tracks CPU resources currently available and kube_node_status_allocatable_memory_bytes does the same for memory. Once you get the hang of how they’ve been named, it’s pretty easy to make out what the metric keeps track of.

Consuming Metrics

These metrics are designed to be consumed either by Prometheus or a compatible scraper, and you can also open /metrics in a browser to view them raw. Monitoring a Kubernetes cluster with Prometheus is becoming a very popular choice as both Kubernetes & Prometheus have similar origins and are instrumented with the same metrics in the first place. This means less time and effort lost in “translation” and more productivity. Additionally, Prometheus also keeps track of the number of replicas in each deployment, which is an important metric.

Pods typically sit behind services that are scaled by “replica sets” which create or destroy pods as needed and then disappear. ReplicaSets are further controlled by “declaring state” for a number of running ReplicaSets (done during deployment). This is another example of a feature built to improve performance that makes monitoring more difficult. Replica sets need to be monitored and kept track of just like everything else if you want to continue to make your applications perform better and faster.

Network Metrics


Now, like with everything else in Kubernetes, networking is about a lot more than network in, network out and network errors. Instead you have a boatload of metrics to look out for which include request rate, read IOPS, write IOPS, error rate, network traffic per second and network packets per second. This is because we have new issues to deal with as well, like load balancing and service discovery and where you used to have network in and network out, there are thousands of containers. These thousands of containers make up hundreds of microservices which are all communicating with each other, all the time.

A lot of organizations are turning to a virtual network to support their microservices as software-defined networking gives you the level of control you need in this situation. That’s why a lot of solutions like Calico, Weave, Istio and Linkerd are gaining popularity with their tools and offerings. SD-WAN especially is becoming a popular choice to deal with microservice architecture.

Kubernetes Logs

Everything a containerized application writes to stdout and stderr is handled and redirected somewhere by a container engine and, more importantly, is logged somewhere. The functionality of a container engine or runtime, however, is usually not enough for a complete logging solution because when a container crashes, for example, it takes everything with it, including the logs. Therefore, logs need a separate storage, independent of nodes, pods, or containers. To implement this cluster-level, logging is used, which provides a separate backend to store and analyze your logs. Kubernetes provides no native storage solution but you can integrate quite a few existing ones.

Kubectl Logs

Kubectl is the logging command to see logs from the Kubernetes CLI and can be used as follows:

$ kubectl logs

This is the most basic way to view logs on Kubernetes and there are a lot of operators to make your commands even more specific. For example, “$ kubectl logs pod1” will only return logs from pod1. “$ kubectl logs -f my-pod” streams your pod logs, and “kubectl logs job/hello” will give you the logs from the first container of a job named hello.

Logs for Troubleshooting


Logs are particularly useful for debugging problems and troubleshooting cluster activity. Some variations of kubectl logs for troubleshooting are:

  • kubectl logs –tail=20 pod1” which displays only the most recent 20 lines of output in pod1; or
  • kubectl logs –since=1h pod1” which will show you all logs from pod1 written in the last hour.

To get the most out of your log data, you can export your logs to a log analysis service like LogDNA and leverage its advanced logging features. LogDNA’s Live Streaming Tail makes troubleshooting with logs even easier since you can monitor for stack traces and exceptions in real time, in your browser. It also lets you combine data from multiple sources with all related events so you can do a thorough root cause analysis while looking for bugs.

Logging Levels and Verbosity

Additionally, there are different logging levels depending on how deep you want to go; if you don’t see anything useful in the logs and want to dig deeper, you can select a level of verbosity. To enable verbose logging on the Kubernetes component you are trying to debug, you just need to use –v or –vmodule, to at least level 4, though it goes up all the way to level 8. While level 3 gives you a reasonable amount of information with regards to recent changes made, level 4 is considered debug-level verbosity. Level 6 is used to display requested resources while level 7 displays HTTP request headers and 8 HTTP request contents. The level of verbosity you choose will depend on the task at hand, but it’s good to know that Kubernetes gives you deep visibility when you need it.

Kubernetes monitoring is changing and improving every day because at the end of the day, that’s the name of the new game. The reason monitoring is so much more “proactive” now is because everything rests on how well you understand the ins and outs of your containers. The better the understanding, the better the chances of improvement, the better the end user experience. So in conclusion, literally everything depends on how well you monitor your applications.

Product Updates

Mega Product Update

It’s been over 3 months since our last product update, so if you thought the last product update was big, we’ve got even more good stuff in store for you!

Embedded Views

After a couple of months hard work, embedded views are now available! Embedding a view allows users outside of your LogDNA organization to view a specific portion of your logs. Use cases include:

  • Building custom dashboards for your internal teams
  • Providing user-specific event logs to your customers
  • Showcasing the inner workings of your product

For full details on how it works and how to get started, check out our Embedded Views guide.

Emails, Domains, and OAuth – Oh My!

By popular request, we’ve added the ability to allow team members to join your LogDNA organization by matching an email domain. Combined with the new require Google OAuth option, team management is now a breeze! Both of these features can be found on the Manage Team page.

New ingestion features

Believe it or not, all of our newest ingestion improvements came directly from user feedback. You can now set an env parameter to designate environment in our code libraries and REST API, authenticate syslog ingestion via structured data, and even send up metadata via our improved Java Logback community library (compliments of @robshep).

New UI features

While there’s a whole host of UI changes, we just wanted to highlight a couple of important ones. We’ve improved the rendering of nested fields in the context menu, as well as added the ability to click on a field value and perform a search on it. In addition, we’ve also added a new time marker with useful jump-to-time defaults, as well as the ability to add a description to your Views! You can find it all in the LogDNA web app.

Other improvements

  • Changed ‘Account’ to ‘Organization’ for improved clarity (under Settings)
  • Added option to select or deselect all in the Levels filter
  • Fixed duplicate logs for Kubernetes v1.6+
  • Fixed dynamic group loading for extremely large dynamic groups

Phew, I know that’s a whole lot of changes, but we hope you like them. We really do rely on your suggestions to inform our product improvements, so thank you for all your feedback, past and future. To logfinity and beyond!

kubernetes, Technical

Kubernetes Logging 101

Containerization brings predictability and consistency across the development pipeline. A developer can package code in a container and ship the same container into production knowing it will work the same. However, for this consistent experience to happen, there are many cogs and levers working in the underlying layers of the container stack. Containers abstract away the complex internals of infrastructure and deliver a simple consistent user experience. The part of the Docker stack that’s especially important in this aspect is the orchestration layer.

An orchestration tool like Kubernetes takes care of the complexity of managing numerous containers by providing many smart defaults. It takes care of changes and configuration with groups of containers called pods, and groups of pods called clusters. In doing so, it lets you focus on what matters most to you – the code and data that’s housed in your Kubernetes cluster. Because of these advantages, Kubernetes has become the leading container orchestration tool today.


Kubernetes makes it easy to manage containers at scale, but it comes with a steep learning curve. This is the reason for the numerous startups offering managed Kubernetes services – Platform9, Kismatic, OpenShift, and CoreOS Tectonic to name a few. However, learning the ins-and-outs of Kubernetes is well worth the effort because of the power and control it gives you.

No matter which route you take to managing your Kubernetes cluster, one fundamental requirement to running a successful system is log analysis. Traditional app infrastructure required log data to troubleshoot performance issues, system failures, bugs, and attacks. With the emergence of modern infrastructure tools like Docker and Kubernetes, the importance of logs has only increased.

The Importance of Log Data in Kubernetes

Log data is essential to Kubernetes management. Kubernetes is a very dynamic platform with tons of changes happening all the time. As containers are started and stopped, and IP addresses and loads change, Kubernetes makes many minute changes to ensure services are available and performance is not impacted. But there is still the odd time when things break, or performance slows down. At those times, you need the detail that only log data can provide. Not both performance and security, you need log data to ensure proper compliance to laws like HIPAA and PCI DSS. Or, if there’s a data breach, you’ll want to go back in time to identify the origin of the attack and its progression across your system. For all these use cases, log data is indispensable.

There are many ways you can access and analyze Kubernetes log data ranging from simple to advanced. Let’s start with the simplest option and move up the chain.

Monitoring A Pod

Pod-level monitoring is the most rudimentary form of viewing Kubernetes logs. You use the kubectl commands to fetch log data for each pod individually. These logs are stored in the pod and when the pod dies, the logs die with them. They are useful when you’re just starting out, and have just a few pods. You can instantly check the health of pods without needing a robust logging setup for a big cluster.

Monitoring A Node

Logs collected for each node are stored in a JSON file. This file can get really large, and in this case, you can use the logrotate function to split the log data in multiple files once a day, or when the data reaches a particular size like 10MB. Node-level logs are more persistent than pod-level ones. Even if a pod is restarted, it’s previous logs are retained in a container. But if a pod is evicted from a node, its log data is deleted.

While pod-level and node-level logging are important concepts in Kubernetes, they aren’t meant to be real logging solutions. Rather, they act as a building block for the real solution – cluster-level logging.

Monitoring the Cluster

Kubernetes doesn’t provide a default logging mechanism for the entire cluster, but leaves this up to the user and third-party tools to figure out. One approach is to build on the node-level logging. This way, you can assign an agent to log every node and combine their output.

The default option is Stackdriver which uses a Fluentd agent and writes log output to a local file. However, you can also set it to send the same data to Google Cloud. From here you can use Google Cloud’s CLI to query the log data. This, however, is not the most powerful way to analyze your log data.

The ELK Stack

The most common way to implement cluster-level logging is to use a Fluentd agent to collect logs from the nodes, and pass them onto an external Elasticsearch cluster. The log data is stored and processed using Elasticsearch, and can be visualized using a tool like Kibana. The ELK stack (Elasticsearch, Logstash, Kibana) is the most popular open source solution for logging today, and its components often form the base for many other modern logging solutions, including LogDNA (but that’s a topic for a whole other post). The ELK stack offers more powerful logging, and more extensibility than the Stackdriver / Google Cloud option.

One example of an organization that uses this setup for centralized logging for their Kubernetes cluster is Samsung. They use the Fluentd / ELK stack combination, but add Kafka for an added step of buffering and monitoring. Samsung has even open sourced this configuration of tools and called K2 Charts.

Sidecar Containers

You can stream logs of different formats together, but this would be harder to analyze and could get messy, considering the scale of Kubernetes. Instead, the preferred way is to attach a sidecar container for each type of log data. A sidecar container is dedicated to collecting logs, and is very lightweight. Every sidecar container contains a Fluentd agent for collecting and transporting logs to a destination.

Archived Log Storage

Storing logs is critical, especially for security. For example, you may find out about a breach in your system that started two years ago, and want to trace its development. In this case, you need archived log data to go back to that point in time, and see the origin of the breach, and to what extent it has impacted your system.

Kubernetes offers basic local storage for logs, but this is not what you’d want to use for a production cluster. You can either use block storage like AWS S3 or Azure Blog, or you can ask your log analysis vendor to give you extended storage on their platform. For archived data, it’s best to leverage cloud storage than on premise servers as they’re more cost efficient and can be easily accessed when needed.

Dedicated Log Analysis Platforms

The ELK stack is a common way to access and manage Kubernetes logs, but it can be quite complex with the number of tools to setup and manage. Ideally, you want your logging tool to get out of the way and let you focus on your log data and your Kubernetes cluster. In this case, it pays to go with a dedicated log analysis platform like LogDNA, which comes with advanced log management features, and is fully managed so you don’t have to worry about availability and scaling your log infrastructure.

You can start collecting Kubernetes logs in LogDNA using just 2 simple kubectl commands:

kubectl create secret generic logdna-agent-key –from-literal=logdna-agent-key=YOUR-INGESTION-KEY-HERE

kubectl create -f

Deeply customized for Kubernetes, LogDNA automatically recognizes all metadata for your Kubernetes cluster including pods, nodes, containers, and namespaces. It lets you analyze your Kubernetes cluster in real-time, and provides powerful natural language search, filters, parsing, shortcuts, and alerts.

LogDNA even mines your data using machine learning algorithms and attempts to predict issues even before they happen. This is the holy grail of log analysis, and it wasn’t possible previously. Thanks to advances in machine learning and the cloud enabling computing at this scale, it’s now a reality.

To summarize, Kubernetes is the leading container orchestration platform available today. Yet, running a production cluster of Kubernetes takes a lot of familiarity with the system and robust tooling. When it comes to log analysis, Kubernetes offers basic log collection for pods, nodes, and clusters, but for a production cluster you want unified logging at the cluster level. The ELK stack comes closest to what a logging solution for Kubernetes should look like. However, it’s a pain to maintain and runs into issues once you hit the limits of your underlying infrastructure.

For unified log analysis for Kubernetes, you need a dedicated log analysis platform like LogDNA. It comes with advanced features like powerful search, filtering, and machine learning to help you get the most out of your log data. Being a fully managed service, you can focus on your Kubernetes cluster and leave the drudge of maintaining log infrastructure to LogDNA. As you run a production Kubernetes cluster, you need a powerful log analysis tool like LogDNA to truly enjoy the promise of Kubernetes – running containers at massive scale.

Learn more about LogDNA for Kubernetes here.


Choosing The Right Ingestion Client

LogDNA has a range of options by which you can supply your account with log data. If you’re not entirely familiar, these are via the Collector Agent, syslog, code libraries, PaaS integration, and REST API.

Given all these options, which one is right for you? Unfortunately, like many things in tech (as in life), the question is difficult to answer definitively. I don’t mean this in any non-committal way. I only mean that it’s hard to say which option is the right one without some form of well thought through qualifications.

Given that, let’s work through the five options which LogDNA provides, and consider when they would, and when they wouldn’t, be the right option to choose. Let’s start off with, arguably, the simplest of the five, the logging agent.

The Collector Agent

If you want the easiest option, one supported across all of the major operating systems, (Linux, macOS, and Windows), then the Collector Agent is the choice to make. Written in Node.js, it logs information at the OS level. To quote the official documentation, it:

Reads log files from the computer it is installed on and uploads the log data to your LogDNA account…It opens a secure web socket to LogDNA’s ingestion servers and ‘tails’ for new log files added to your specific logging directories. When those files change, the changes are then sent to LogDNA, via the secure web socket.

In addition to reading log files on your server(s), the Collector Agent can also read from the Windows Application Log.

As you may expect from a system daemon or service, after installation, all that’s required is to provide a configuration. On Linux/UNIX systems, this is stored in /etc/logdna.conf and on Windows, it is stored in C:\ProgramData\logdna\logdna.conf.

As an example, let’s assume that my servers are running Ubuntu 16.04 and that I have installed the agent. With that done, the minimum configuration that I’d need to add to /etc/logdna.conf, so that it started sending my log data is:

logdir = /var/log/nginx,/var/log/auth

I’ve only needed to provide the directories to read the log files from that are of interest to me, as well as my LogDNA ingestion key. In the example provided, it would send log information from my NGINX server, as well as authentication requests to my LogDNA account.

If there are files that shouldn’t be included, then I can use the exclude option to have the agent skip over them. And there’s another handy option: tags. It allows you to group hosts automatically into dynamic host groups without having to explicitly assign a host to a group within the LogDNA web app.

The agent can be installed using package managers, such as Homebrew, APT, and Yum, as well as from source. Additionally, it also integrates with Kubernetes, if you’re using Docker containers.

Given this level of simplicity, if you’re just getting started with LogDNA, want an option that requires a minimum investment, both initially and over time, and want something that’s available on all the major platforms, then the Collector Agent is the right one to choose.

However, it is considered a bit of a shotgun approach. That is, while it can send your log data straight to LogDNA with little effort, you have only negligible control over how and when it does so. Specifically, you can’t choose a level of log granularity, such as debug, info, warning, and critical.


The next option is syslog. It is the veteran logging daemon, available on all Linux/UNIX installations, since its development by Eric Allman back in the 1980s. If you’re not familiar, syslog (also available as syslog-ng and rsyslog) is a logging system which allows for logging on a server locally, as well as to remote syslog servers.

It is an excellent choice for logging information across a wide range of devices, such as printers and routers, and a wide range of system-services, such as authentication, servers such as NGINX, CUPS, and Apache, system-level events, and kernel-level events.

To send log data to LogDNA using syslog requires a little bit more effort than the logging agent. Gladly, they’re well documented under Settings -> "View your logs" -> "Via syslog".

Setting up syslog requires adding an entry to /etc/syslog.conf, which can be generated in the “Log Source” modal dialog. For example: *.* syslog-ng and syslog require a little more configuration effort. But like syslog, the instructions are well documented.

syslog is a particularly appealing option if you’re looking for simplicity and minimal cost. One of the three daemons is likely universally available on any Linux/UNIX system, as they’ve been around for so long. What’s more, it’s a very well understood application, with a wealth of documentation available on how to configure it across a wide variety of use cases.

This gives it an advantage over the Collector Agent. Where the agent passes log data as-is, syslog allows you to choose the format in which the log messages are written. This may not be necessary. But it’s handy nonetheless, as you can write log data that better suits the needs of your applications. Doing so, you’re better able to parse the log data when the time comes, as it will make more sense.

Given this advantage, the fact that syslog is free, and that LogDNA provides detailed configuration instructions and supports host tags/dynamic groups, it’s well worth considering.

You won’t have to look far to find support for it, and you won’t have to invest much time in maintaining it. Another handy aspect of sending log data using syslog is that you don’t need to explicitly integrate against LogDNA, such as when developing applications, to send the log data from your applications. By logging to the system logs, that information is automatically, and transparently sent by syslog.

However, one thing that works against using syslog is a lack of native Windows support. Having said that, there are syslog daemons for Windows, such as Kiwi syslog Server. And you’ll find others if you do further research. But they’re not natively available like syslog is for Linux/UNIX systems.

PaaS Integration

Let’s say that neither the agent nor a syslog daemon suits your purposes, as you’re using a PaaS (Platform as a Service), such as Heroku. In that case, you still need to send your log data to LogDNA, but you may not have as much control as you otherwise might.

In this case, while the options aren’t extensive, you’re not without options. LogDNA supports Heroku, Kubernetes, Docker (including Docker Cloud, Convox, and Rancher), Fluentd, Flynn, CloudWatch, Elastic Beanstalk, and Cloud Foundry.

Assuming that you’re using one in the above list, let’s first consider what you get, which depends on the platform. Some provide more configuration and flexibility; some provide less. In many cases, there isn’t much choice in how logs can be forwarded.

Then there’s the setup complexity and time. While I won’t say that any of the setups are easy, some will require more time and effort than others. However, regardless of what you’re using, LogDNA provides thorough documentation for each one.

Code Libraries

Now to my favorite option, code libraries. As a software developer, you’d naturally expect that it would be. LogDNA has libraries officially developed and supported for four languages — Node.JS, Python, Rails, and Ruby. There are also libraries for Go, iOS, Java, and PHP.

Given that these are some of the most popular languages and that they have runtimes available on the major operating systems, it’s likely that at least one of them will suit your needs.

Now let’s consider the positives of using code libraries. Unlike the previous two options, code libraries afford you complete control over both how and when your log data is sent. You can integrate logging support into your existing application(s).

You can log as much or as little as your application or regulatory environment demands. You can add as much optional extra information as you want. And you can specify, exactly, the information that is sent, such as custom metadata.

Here’s a minimalist example using PHP, which is often my language of choice.


use Monolog\Logger;
use Zwijn\Monolog\Handler\LogdnaHandler;

require_once ('vendor/autoload.php');

$logger = new Logger('general');
$logdnaHandler = new LogdnaHandler(

# Sends debug level message "mylog" with some related meta-data
    "mylog", [
        'logdna-meta-data-field1' => [
            'value1' => 'value',
            'value2' => 5
        'logdna-meta-data-field2' => [
            'value1' => 'value'

This example initializes a logger object, which will send log messages, at or above the level of DEBUG to LogDNA. It will also send two sets of custom metadata — metadata which could be anything that makes sense to your application.

To be fair, this is rather a “Hello World” example. And integrating logging into your code base would take more effort than it took to create this short example — especially if it’s an older and quite complex legacy codebase.

That said, I hope you’ll appreciate the level of power and customizability that using a code library provides. On the flip side, code libraries also incur a high(er) investment, both in their initial investment, as well as in their maintenance over the longer term.

They take special planning, design, testing, and debugging. They also need to be developed using security best practices, both in the code itself, as well as in the deployment process. Given that, while you have much more power, the investment will be higher. Something to keep in mind.


And now to the last option. If none of the previous four options suit — or your particular setup is entirely custom — there’s one last option that just may work, the LogDNA REST API.

Similar to using a code library, the REST API allows you to send log data, along with custom metadata, to LogDNA.

curl "$(date +%s)" \
-H "Content-Type: application/json; charset=UTF-8" \
-d \
   "lines": [
       "line":"This is an awesome log statement",
       "level": "INFO",
       "env": "production",
       "meta": {
         "customfield": {
           "nestedfield": "nestedvalue"

In the example log request, from the docs, above, you can see that requests to the API are GET requests, and require that a hostname and LogDNA ingestion key are provided. A MAC address, IP address, and a timestamp are able to be included as well.

The request body is in JSON format and can contain one or more message lines. JSON is a light-weight and almost universally accepted format, one able to be created by most every popular software language, along with a variety of tools, today.

As with the code libraries, and as you can see in the example above, the message lines contain the message’s timestamp, body, application name, and log level, as well as optional metadata.

Given that the request is being made using curl, it could be wrapped in a shell script on Linux/UNIX or batch script on Windows. Then, if applicable, the script could be tied into either CRON or the Windows Scheduler. If written well, it could also take input from any number of services, or be called from an existing process via a system call.

However, you don’t need to use curl. You could use any software language that can compose and send a GET request, whether natively or via a third-party package, such as GuzzleHTTP for PHP. Similar to how they work, you could integrate logging directly into an existing application, even if it didn’t have dedicated support via one of the eight code libraries.

The REST API offers quite a significant level of flexibility; a flexibility that the Collector Agent, syslog, and PaaS options simply don’t — or can’t — provide.

Unfortunately though, as with the code library option, there won’t be a clear set of steps required to integrate it. Every application is different and has different needs and requirements. What’s more, it will require a higher investment, both at the start and over time. However, if it’s the one that best suits your needs, then it’s worth considering.

In Conclusion

These are the five ways in which you can send log data from your servers and applications to LogDNA. They all have pros and cons, they’re not all equal, and they can’t be compared in the proverbial “apples to apples” way.

The needs of your particular setup, whether server or application, will supply most of the criteria; as will your budget and the experience of your technical staff. But regardless of the choice that you make, you can get started quite quickly, likely using the collector agency or syslog, and then progressing to the more involved options as time goes by, according to your particular use case, and as your budget allows.


The Role of AWS in HIPAA Compliance

If you’re considering storing your HIPAA log archives in AWS, it’s important you know the details about how Amazon treats HIPAA compliant data.

Healthcare companies are used to having control over physical storage systems, but many are now struggling when it comes to utilizing a cloud environment. There are many misconceptions about ownership, compliance and how the entire log-to-storage process intersects and works.

HIPAA is a set of federal regulations, meaning there is no explicit certification for remaining compliant. Rather, there are guidelines and laws that needs to be followed. Tools like LogDNA and AWS will ensure that compliance is maintained.

A Primer for AWS Customers

All healthcare users of AWS retain ownership over their data and maintain control in regards to what they can do with it. You can move your own data on and off AWS storage anytime you’d like without restriction. End users are in control of how third party applications (like LogDNA) can access AWS data. This access is controlled through AWS Identity and Access Management.

The most popular services for creating backups come from Amazon S3 and Glacier. AWS is responsible for managing the integrity and security of the cloud, while customers are responsible for managing security in the cloud. It’s a minor difference, but an important one at that. This leads us to the core question many healthcare providers ask about AWS.

Is AWS HIPAA compliant?  

There is no way to answer this with a simple yes or no. The question also leads down a faulty path about understanding how these cloud services work. The question should be reframed as:

How does using AWS lead to HIPAA compliance?

The United States’ Health Insurance Portability and Accountability Act (HIPAA) does not issue certifications. A company and its business associates will instead be audited by the Health & Human Services Office. What AWS does is set companies on the path to compliance. Like LogDNA, Amazon signs a Business Associate Agreement (BAA) with the health company. Amazon ensures that they’ll be responsible for maintaining secure hardware servers and provide their secure data services in the cloud.      

How does Amazon do this?

While there may not be a HIPAA certification per say, there are a few certifications and audit systems Amazon holds that establishes their credibility and trust.

ISO 27001

The International Organization for Standardization specifies the smartest practices for implementing comprehensive security controls. In other words, they’ve developed a meticulous and rigorous security program for Information Security Management Systems (ISMS). In summary, the ISO guarantees the following:

  • Systematically evaluate our information security risks, taking into account the impact of company threats and vulnerabilities.
  • Design and implement a comprehensive suite of information security controls and other forms of risk management to address company and architecture security risks.
  • Adopt an overarching management process to ensure that the information security controls meet our information security needs on an ongoing basis.

Amazon’s ISO 27001 certification displays the company’s commitment to security and its willingness to comply with an internationally renown standard. Third party audits continually validate AWS and assure customers that they’re a compliant business partner.


The company’s Service Organization Control (SOC) audits through third party examiners, and determines how AWS is demonstrating key compliance controls. The entire audit process is prepared through Attestation Standard Section 801 (AT 801) and completed by Amazon’s independent auditors, Ernst & Young, LLP.

The report reviews how AWS controls internal financial reporting. AT 801 is issued by the American Institute of Certified Public Accountants (AICPA).

Secured ePHI Logging Storage

Healthcare companies that use any AWS service and have a BAA will be given a designated HIPAA account. The following is a comprehensive list sourced from Amazon cataloging HIPAA eligible services. This list was last updated on July 31, 2017. These services cannot be used for ePHI purposes until a formal AWS business associate agreement has been signed.

Amazon API Gateway excluding the use of Amazon API Gateway caching
Amazon Aurora [MySQL-compatible edition only]
Amazon CloudFront [excluding Lambda@Edge]
Amazon Cognito
AWS Database Migration Service
AWS Direct Connect
AWS Directory Services excluding Simple AD and AD Connector
Amazon DynamoDB
Amazon EC2 Container Service (ECS)
Amazon EC2 Systems Manager
Amazon Elastic Block Store (Amazon EBS)
Amazon Elastic Compute Cloud (Amazon EC2)
Elastic Load Balancing
Amazon Elastic MapReduce (Amazon EMR)
Amazon Glacier
Amazon Inspector
Amazon Redshift
Amazon Relational Database Service (Amazon RDS) [MySQL, Oracle, and PostgreSQL engines only]
AWS Shield [Standard and Advanced]
Amazon Simple Notification Service (SNS)
Amazon Simple Queue Service (SQS)
Amazon Simple Storage Service (Amazon S3) [including S3 Transfer Acceleration]
AWS Snowball
Amazon Virtual Private Cloud (VPC)
AWS Web Application Firewall (WAF)
Amazon WorkDocs
Amazon WorkSpaces

Amazon ECS & Gateway in Focus

Amazon EC2 Container Service (ECS) is a major container management service, which supports Docker container logs and can be used to run apps on a managed cluster of EC2 instances. ECS provides simple API calls that you can use to easily deploy and stop Docker-enabled apps.

ECS workloads required to process ePHI do not require any additional configurations. ECS data flow is consistent with HIPAA regulations. All ePHI is encrypted while at rest and in transit when being accessed and moved by containers through ECS.

The process of complete encryption is upheld when logging through CloudTrail or logging container instance logs through CloudWatch into LogDNA.  

Users can also use Amazon API Gateway to transmit and store ePHI. Gateway will automatically use HTTPS encryption endpoints, but as an extra fail-safe, it’s always a good idea to encrypt client-side as well. AWS users are able to integrate additional services into API Gateway that maintain ePHI compliance and are consistent with Amazon’s BAA. LogDNA helps ensure that any PHI sent through Gateway only parses through HIPAA-eligible services.  

Compliance Resources – A Continued Approach  

Amazon is serious about staying compliant in a number of industries. They’re constantly innovating and are continually creating new security services. LogDNA shares this same tenacity for security and continued innovation.

LogDNA Blog Image

Additional Resources:
CloudWatch Logging:
AWS Hub:
Technical DevOps Guide:



Firewall Logging: Importance for the Healthcare Industry

A large number of healthcare companies are at a loss when it comes to understanding their internal security environment. While the HIPAA Security Rule provides a comprehensive legal framework for ensuring secure technical safeguards, it doesn’t give many specifics on which tools to use.

We’ve already established what proper logging brings to a healthcare environment, as well as its importance. But what about the contents of those logs? Security indicators are one of the most crucial logs a system can receive. The majority of these logs and alerts come from your firewall, and firewalls are the number one security measure a healthcare company needs to have.

Section 164.312(c)(1) states that the integrity of ePHI must be upheld through proper technical procedures and policies to stop this information from being altered or destroyed. This is where Firewall Logging comes in.   

Firewall HIPAA Logs – The Wall of Compliant Protection

Patient data may seem mundane to the multitude of healthcare workers keying and plodding away records daily. But it’s important to realize that this data is coveted by unscrupulous characters lurking around the web. Stolen information can cause irreparable damage to the patients and the establishments responsible for safeguarding that data.

Firewalls are just one component there to stop online intruders. Imagine a towering brick wall denying entrance to attackers in the night. In our case, this metaphoric wall is part of a computer system that denies unauthorized access from the outside and limits outward communication deemed unsafe, i.e. the ability for office computers to access unprotected websites. This system is reactive – what we also need is something proactive.

Firewall logs are the sentries posted up on this proverbial wall – the loggers on the wall. They can respond to real time alerts and backtrack to see what happened. HIPAA compliance requires healthcare companies to have configured log monitoring. Our firewall logs – or rather firewall sentries, serve an important function for maintaining the integrity of ePHI. They do this by:

  • Helping to determine if an attack has taken place
  • Alerting system administrators if an attack is currently happening
  • And logging security data for required audits

Firewall logs watch for intrusions and will relay what action the firewall took to block network attacks on either an individual computer, or an entire in-house data system. A firewall log will relay a few pieces of crucial information: incoming network traffic, a description of suspicious network activity, and the location of activity logged.

Our logging platform gives these logs a foundation so that they can be used, stored and monitored to ensure ePHI safety and HIPAA compliance. We give form to the shapeless firewall data that’s usually left floating around and left inaccessible.

There are a few different types of firewalls. All of them will produce logs, but it’s important to understand the distinction between them in order to build a proper foundation.

Different Bulwarks of Safety

For our purposes here, we’ve divided the number of firewalls into three different types of network firewalls. These include software, web applications, and hardware; all are crucial in maintaining HIPAA safety compliance. Remember that the goal of our firewall system is to stop harmful unauthorized traffic and limit dangerous exterior communication. The goal of our firewall logging is to take actionable steps to stay alert and maintain the integrity of the system and thwart any attacks.

Simply having a firewall won’t cut it. Possessing an interconnected system with multiple protected funnels and monitoring means is more effective.

Software Firewall Safeguard

This is a type of firewall that is often overlooked because it’s usually pre-installed on a number of computers. A healthcare entity needs a firewall between the systems responsible for housing ePHI and all other connected systems. This also includes internal systems.

Software firewalls protect lone computers from a few different types of threats – namely mobile devices that can be compromised. Take for example, a remote employee accessing data from home or on the go. If they’re caught in an unlucky phishing debacle, their firewall will act to protect their personal computer or device and save the integrity of any connected medical data in the process.

Software firewalls are easy to maintain and allow for the remote work to take place. While they might not protect an entire system, they patch up an area liable to attack.

Web Applications Firewall Safeguard

Also commonly known as (WAFs), these should be placed at the frontlines of any application that needs to access the internet, which at this point is the vast majority of them. WAFs help detect, monitor and stop attacks online. A bevy of firewall logs will be sourced from here. Note that a WAF is not an all-purpose firewall; it’s main function is to block suspicious web traffic.

Many databases require access to the internet. Cyber security reports can be generated through logging platforms and then acted upon. The WAF logging combination is akin to the heart rate monitor, but for online security health. If everything is going well, there won’t be any dramatic spikes. But if danger strikes, the necessary alerts and response team will be on it.

There needs to be special care when setting up a WAF, since critical functions could be hampered if it’s not setup properly. But nothing beats this firewall when it comes to protected third party modules and quick logged response time.

Hardware Firewall Safeguard

Hardware firewalls are installed company wide throughout the entire organization’s network. Internal systems are protected from the outside internet. They’re also used to create network segments inside the company that divide access to those with ePHI access from those without it.

Other networks inside the company system may need fewer firewall restrictions placed on them. For example, maybe a medical device designer needs to collaborate with an outside agency of some kind. This particular job function doesn’t require ePHI access; their segmented network shouldn’t be affected, nor should they be on the same network with employees handling ePHI.

A secure network will employ these different types of firewalls together ensuring a protected and HIPAA compliant healthcare company.