Product Updates

Achieving Cost Advantages With a Cloud Logging Management Solution

In the past few years, cloud based services have seen tremendous growth. This fast adoption can be attributed to their low cost of acquisition, ease of implementation and economies of scale. Everyday businesses and enterprises of all sizes are making the switch from on-site infrastructures to both hybrid and completely cloud-based log management solutions.

Determining cloud logging cost advantages can be tricky at first. There is no one uniform way to determine how much you’re saving. An IT infrastructure is a complex beast with many different areas contributing to your total cost of ownership (TCO).

But we do know that switching to a cloud based log management system will save you money in the long run. There’s a few different ways to determine your cost advantages. First, you need to evaluate what type of solution will best fit your current needs and also be flexible enough to keep up with your future growth. You’ll also need to know how to determine your unique TCO and how that affects your DevOps and engineering teams.   

General Cost Advantages of Cloud Logging

For the most part, your monthly expenses from cloud logging is based off of log data volume and your unique retention rate. This holds true whether it’s LogDNA or another logging vendor. But there’s a few other things that can be overlooked that cloud logging also helps cut costs from.

An integrated system gets rid of the need to have separate instances for security and access controls and will also seamlessly interact with popular DevOps tools like Pagerduty or JIRA. These are just a few examples, but even those can add up. Cloud logging systems can also scale to handle spikes in seasonal log variations. It creates a redundant system that always makes your logs available, even if your infrastructure is down – the time when you’ll need your logs the most!

Additionally, cloud logging alleviates the need to rely on open source solutions that require you to hire engineering support to set up, manage and deploy systems. A cloud logging solution just requires a simple command line install. Index management, configuration and access control are just a click away in this case. This ease of use frees up your man hours for your DevOps team. With a log management system in place, your team can instead focus on core business operations.

Cost advantages are difficult to quantify in this case, as they will vary from business to business and require an internal accounting system that takes into account inventory costs, engineer support salaries, and opportunity costs saved.  

But we still can look to the general cloud market to see how companies are utilizing cloud-based systems and cloud-logging platforms to cut costs.

Look to the Greater Cloud Market For Answers

Arriving at a clear TCO is a difficult number to compute. SaaS and on premise IT costs are not exactly the easiest things to compare. Internal operational costs with employees will always vary and fluctuate. Just because you’re applying some cloud services into the mix, doesn’t mean you’re going to be cutting off the entire on-premise IT staff. Their roles are changing and evolving by the minute – but they’re also not going anywhere anytime soon.

We look to a compelling study conducted by Hurwitz & Associates comparing cloud based business applications to on-premise solutions. This white paper found that the overall cost advantages for cloud based solutions was significantly greater than on-site IT infrastructure.

Here’s a look at some of the areas of cost that are averted when working with a cloud logging management system.   

Cost Advantages in Focus

  • Setting up IT infrastructure – which includes hardware, software and general ongoing maintenance accounts for around 10% of the total cost of setting up an on-premise solution.
  • Subscription type fees, in which the majority of cloud logging providers offer is the main area of cost. Under these costs is the fact that you don’t have to create an underlying IT infrastructure – for example if you wanted run an ELK stack. That also means you cut down on personnel costs too.
  • A pre-integrated system for both the front and back end functionality of your business reduces disparate integration complexity and lowers implementation costs.

These three examples are just a few of the reasons more businesses are shifting their focus to gain additional cost advantages.

Global Spending Shifted Toward the Cloud

According to the IDC, spending on cloud services is expected to hit $160 billion in 2018 with a 23% increase from 2017. Software as a service (SaaS) is the largest category, accounting for over two thirds of spending for the year. Following that is infrastructure as a service (IaaS). Resource management and cloud logging make up the greatest amount of spending of the SaaS spend this year.  

The United States accounts for the largest market share of cloud services – totalling over $97 billion, followed by the United Kingdom and Germany. Japan and China are the largest in Asia with roughly $10 billion combined. There is a wide range of industries that benefit from cloud logging, from professional services to banking to general applications. Many of these businesses would be better off streamlining and integrating a pre-existing cloud logging solution rather than creating their own or wasting precious resources hiring and maintaining an on-premise IT staff.   

What Cloud Logging Helps Eliminate or Streamline

The first area to go is the operational costs in hiring additional engineers. Let’s use running an ELK stack as our prime example moving forward. Cloud logging platforms have cost advantages in three main areas: parsing, infrastructure and storage.

First, it’s one thing to be able to grab logs and get them churning through the stack – it’s a different ballgame entirely to actually make meaning out of them. While trying to understand and analyze your data, you need to be able to structure it so that it can be read and make sense. Parsing and putting it into a visual medium allows you make actionable decisions on this ever-changing and flowing data.  

The ability to use Logstash to filter your logs in a coherent way unique to your business needs is no easy feat. It can be incredibly time consuming and require a lot of specialized billable hours. A quick Google search will show you the mass amounts of queries into creating just a Logstash timestamp – something that’s already ingrained and part of a cloud logging platform. Logs are also very dynamic. Which means that over time you’re going to be dealing with different formats and you’ll need to initiate periodic configuration adjustments. All of this means more time and money spent just getting your logs functional. You shouldn’t have to reinvent the wheel just to be able to read your logs.

Next is just plain infrastructure. As your business grows — which is what any viable business is hoping and striving for – more logs are going to be ingested into your stack. This means more hardware, more servers, network usage and of course storage. The overall amount of resources you need to employ to process this traffic will be continually increasing. An in-house log management solution consumes a lot of network bandwidth, storage and disc space. Not to mention, it most likely won’t be able handle large bursts of data when you have spikes in logs.

When an error occurs in production is when you’ll need your precious logs parsed, ingested and ready for action in a moments notice. If your infrastructure isn’t up to snuff and falters – not only will you not be able to investigate your logs, you’ll also spend money fixing your failed underlying systems. Building out and maintaining this infrastructure can cost tens of thousands of dollars on an annual basis.  

Finally, all of your data has to go somewhere. You need to know where it goes and what to do with it. Indices can pile up and if they’re not taken care of, there’s a possibility that this will cause your ELK stack to crash and you’ll lose that precious data. A few things you’ll need to also learn how to do is remove old indices and have logs archived in their original format. All of this can be done with Amazon A3, but costs more time and money.

Flexible Storage & Pricing

In terms of storage, cloud logging ensures that you can store and have flexible data retention at a fraction of the cost it’d cost you to host it locally. Pricing is flexible and most important scalable. These two characteristics make cloud logging cost effective for any kind of business.   

LogDNA’s pay-per-GB pricing (similar that of AWS) is a good example of scalability. When you have an in-house solution, you need to increase your hardware every time your data increases. And being in the business of growth, predicting scalability is tough.  A pay-as-you-grow pricing model allows you to bypass wasted cloud spend and only pay for what you need. Finding the perfect balance is more difficult the other way around.

Overall, these many benefits and an overarching trend of companies shifting towards cloud logging solutions shows that there are multiple cost advantages with these solutions. Determining just how much you’ll save from a TCO standpoint depends on your unique situation and configuration — just be sure to think through hiring, maintenance and hardware.

Security, Technical

Building Secure Applications with Machine Learning & Log Data

In recent years, machine learning has swept across the world of software delivery and is changing the way applications are built, shipped, monitored, and secured.  And log monitoring is one of the industries that keeps evolving with new capabilities afforded with machine learning.

What Is Machine Learning?

Machine learning is the process of using algorithms and computer intelligence to analyze and make sense of large quantities of complex data that would otherwise be difficult or impossible to do by a human security analyst. There are many forms of machine learning from algorithms that can be trained to replicate human decision making at scale to algorithms that take an open-ended approach to find interesting pieces of data with little input or guidance. Differences aside, machine learning looks to get more value out of data in a way that humans can’t do manually. This is critical for security, which deals with large quantities of data, and often misses the important data, or catches it too late.

Gnome-stock_person_bot.svg
Machine learning is made possible by the power of cloud computing and how it makes crunching big data cheaper and more powerful. Analyzing large quantities of complex data takes a lot of computing power, readily available memory, and fast networking that’s optimized for scale. Cloud vendors today provide GPU (graphical processing unit) instances that are particularly well suited for machine learning. The alternate method is to use numerous cheap servers and a distributed approach to analyze the data at scale. This is possible with the advances in distributed computing over the past few years.

Additionally, cloud storage with fast I/O speeds is necessary for complex queries to be executed within a short period of time.  AWS itself offers multiple storage solutions like Amazon EFS, EBS, and S3. Each of these serve different purposes and are ideal for different types of data workloads. The cloud has stepped up in terms of compute, memory, storage and overall tooling available to support machine learning.

Security Threats Are Becoming Increasingly Complex

The primary use case for machine learning in log analysis has to do with security. There are many forms of security attacks today, which range in complexity. Email phishing attacks, promo code abuse, credit card theft, account takeover, and data breaches are some of the security risks that log analysis can help protect against. According to the Nilson Report, these types of security attacks cost organizations a whopping $21.8 billion each year. And that doesn’t even include the intangible costs associated with losses in trust, customer relationships, brand value, and more that stem from a security attack. Security threats are real, and log analysis can and should be used to counter them.

Attackers are becoming more sophisticated as they look to new technology and tools to carry out their attacks. Indeed, criminals themselves are early adopters of big data, automation tools and more. They use masking software to hide their tracks, bots to conduct attacks at scale, and in some cases have armies of humans assisting in the attack. With such a coordinated effort, they can easily break through the weak defenses of most organizations. That’s why you see some of the biggest web companies, the most highly secured government institutions, and the fastest growing startups all fall victim to these attackers, who can breach their defense easily.

SecOps Is Predominantly Manual

Since much of security is conducted by humans, or at most by tools that use rules to authorize or restrict access, attackers eventually understand the rules and find ways to breach them. They may find a limit to the number of requests a gatekeeper tool can handle per second, and then bombard the tool with more requests than the limit. Or they may find unsecured IoT devices on the edge of the network that can be easily compromised and taken control of. This was the case with the famous Dyn DDoS attack which leveraged unsecured DVRs and then bombarded the Dyn network, taking down with it a large percentage of the internet’s top websites that relied on Dyn for DNS services. The point is that manual security reviews, and even rule-based security, doesn’t scale and is not enough to secure systems against the most sophisticated attackers. What’s needed is a machine learning approach to security, and one that leverages logs to detect and stop attacks before they escalate.

Dyn_logo_(black_text).svg

Many security risks occur at the periphery of the system, so it’s essential to keep a close watch on all possible entry points. End users access the system from outside, and can sometimes knowingly or unknowingly compromise the system. You should be able to spot a malicious user from the smallest of triggers; for example, an IP address or a geo location that is known to be suspicious should be investigated. Login attempts are another giveaway that your system may be under attack. Frequent unsuccessful login attempts are a bad sign and need to be further investigated. Access logs need to be watched closely to spot these triggers, and it is best done by a machine learning algorithm.

While manual and rule-based review can work to a certain point, increasingly sophisticated attacks are best thwarted by using machine learning. You may need to crawl external third-party data to identify fraudulent activity, and it helps to look not just inside, but outside of your organization for data that can shed light on suspicious activity. But with growing data sets to analyze, you need more than basic analytics — you need the scale and power of machine learning to spot patterns, and find the needle in the haystack. Correlating your internal log data with external data sets is a challenge, but it can be done with machine learning algorithms that look for patterns in large quantities of unstructured data.

Machine Learning For Security

Machine learning can go further in spotting suspicious patterns from multiple pieces of data. It can look at two different pieces of data, sometimes not obviously associated with each other, and highlight a meaningful pattern. For example, if a new user accesses parts of the system that are sensitive, or tries to gain access to confidential data, a machine learning algorithm can spot this from looking at their browsing patterns or the requests they make. It can decipher that this user is likely looking to breach the system and may be dangerous. Highlighting this behavior an hour or two in advance can potentially prevent the breach from occurring. To do this, machine learning needs to look at the logs showing how the user accesses and moves through the application. The devil is in the details, and logs contain the details. But often, the details are so hidden that human eyes can’t spot them; this is where machine learning can step in and augment what’s missing in a human review.

In today’s cloud-native environment, applications are deeply integrated with each other — no application is an island on its own. This being the case, many attacks occur from neighboring apps which may have escalated their privileges. It’s easy to read the news about data breaches and find cases where organizations blame their partner organizations or an integrated third-party app for a security disaster. Monitoring your own system is hard enough, and it takes much more effort and sophistication to monitor outside applications that interact with yours.

Whereas humans may overlook the details when monitoring a large number of integrated applications and APIs, a machine learning algorithm can monitor every API call log, every network request that’s logged, and every kind of resource accessed by third-party applications. It can identify normal patterns as well as suspicious ones. For example, if an application utilizes a large percentage of available memory and compute for a long period of time, it is a clear trigger. A human may notice this after a few minutes or hours of it occurring, but a machine learning algorithm can spot the anomaly in the first few seconds, and bring it to your attention. Similarly, it can highlight a spike in requests from any single application quickly, and highlight that this may be a threat.

Elasticsearch-Logo

Machine learning algorithms are especially good at analyzing unstructured or semi-structured data like text documents or lines of text. Logs are full of text data that need to be analyzed, and traditional analytics tools like SQL databases are not ideally suited for log analysis. This is why newer tools like Elasticsearch have sprung up to help make sense of log data at scale. Machine learning algorithms work along with these full-text search engines to spot patterns that are suspicious or concerning. It can derive this insight from the large quantities of log data being generated by applications. In today’s containerized world, the amount of log data to be analyzed is on the rise, and only with the power of machine learning can you get the most insight in the quickest time.

Conclusion

As you look to get more out of your log data, you need an intelligent logging solution like LogDNA that leverages machine learning to give you insight in a proactive manner. Algorithms are more efficient and faster than humans at reading data, and they should be used to preempt attacks by identifying triggers in log data. As you assess a logging solution, do look at its machine learning features. Similarly, as you plan your logging strategy, ensure machine learning is a key component of your plans, and that you rely not just on traditional manual human review, but leverage the power of machine learning algorithms.

Security, Technical

The Role of Log Analysis in Application Security

Security is perhaps the most complex, time-sensitive, and critical aspect of IT Ops. It’s similar to the ICU (Intensive care unit) room in a hospital where the most serious of cases go, and any mistake can have far-reaching consequences. Just as doctors need to monitor various health metrics like heart rate, blood pressure, and more, Security Analysts need to monitor the health of their systems at all time – both when the system is functioning as expected, and especially when things break. To gain visibility into system health at any time, the go-to resource for any Security Analyst is their system logs. In this post, we cover all that can go wrong in the lifetime of an application, and how Security Analysts can respond to these emergencies.

The Role of Log Analysis in Application Security
Log Analysis is an integral component to application security

Common security incidents

An application can be attacked in any number of ways, but below are some of the most common type of security issues that SecOps teams deal with day in and day out.

  • Viruses & malware: This is when a malicious script or software is installed on your system and it tries to disrupt, or manipulate the functioning of your system.
  • Data breaches: The data contained in your systems is an extremely valuable asset. A data breach is when this valuable data is accessed, or stolen by an attacker.
  • Phishing attacks: This tactic is used on end users where an attacker poses as a genuine person or organization, and lures the user to click on a link after which their credentials like logins, and financial information are stolen.
  • Account takeovers: This is when a cyber criminal gains access to a user’s login credentials and misuses it to their own advantage.
  • DDoS attacks: Distributed denial of service (DDoS) attacks occur when multiple infected computers target a single server and overload it with requests. The server is overloaded with requests and denies service to other genuine users.
  • SQL injection: This happens when an attacker runs malicious SQL queries against a database with the aim of taking the database down.
  • Cross-site scripting: This type of attack involves the hacker using browser scripts to execute harmful actions on the client-side.

Initial response

When an incident occurs, the first thing you need to do is estimate the impact of the attack.

Estimate the impact of the attack. Which parts of the system have failed, which parts are experiencing latency, how many users and accounts are affected, which databases have been compromised, and more. Understanding this will help you decide what needs to be protected right away, and what your first actions should be. You can reduce the impact of an attack by acting fast.

Incident management using log data

Once you’ve taken the necessary ‘first aid’ measures, you’ll need to do deeper troubleshooting to find the origin of the attack, and fully plug all vulnerabilities. When dealing with these security risks, log data is indispensable. Let’s look at the various ways you can use log data to troubleshoot, take action, and protect yourself from these types of attacks.

Application level

When an incident occurs, you probably receive an alert from one of your monitoring systems about the issue. To find the origin of the incident, where you look first will depend on the type of issue.

At the application level you want to look at how end users have used your app. You’d look at events like user logins, and password changes. If user credentials have been compromised by a phishing attack, it’s hard to spot the attacker initially, but looking for any unusual behavior patterns can help.

Too many transactions in a short period of time by a single user, or transactions of very high value can be suspicious. Changes in shipping addresses is also a clue that an attacker may be at work.

At the application layer, you can view who has had access to your codebase. For this you could look at requests for files and data. You could filter your log data by application version, and notice if there are any older versions still in use. Older versions could be a concern as they may not include any critical security patches for known vulnerabilities. If your app is integrated with third-party applications via API, you’ll want to review how it’s been accessed.

When looking at log data it always helps to correlate session IDs with timestamps, and even compare timestamps across different pieces of log data. This gives you the full picture of what happened, how it progressed, and what the situation is now. Especially look for instances of users changing admin settings or opting for their behavior to not be tracked. These are suspicious and are clear signs of an attack. But even if you find initial signs at the application layer, you’ll need to dig deeper to the networking layer to know more about the attack.

Network level

At the network level there are many logs to view. To start with, the IP addresses and locations from where your applications were accessed from is important. Also, notice the device types like USBs, IoT devices, or embedded systems. If you notice suspicious patterns like completely new IP addresses and locations, or malfunctioning devices, you can disable them or restrict their access.

Particularly, notice if there are any breaches to the firewall, or cases of modifying or deletion of cookies. In legacy architecture a breach in a firewall can leave the entire system vulnerable to attackers, but with modern containerized setups, you can implement granular firewalls using tools like Project Calico.

Look for cases of downtimes or performance issues like timeouts across the network, these can help you assess the impact of the attack, and maybe even find the source. The networking layer is where all traffic in your system flows, and in the event of an attack, malicious events are passing through your network. Looking at these various logs will give you visibility into what is transpiring across your network.

Going a level deeper, you can look at the health of your databases for more information.

Database level

Hackers are after the data in your system. This could include financial data like credit card information, or even personally identifiable information like a social security number or home address. They could look for loosely stored passwords and usernames associated with them. All this data is stored in databases in cloud or physical disks in your system, and they need to be checked for breaches, and secured immediately if not compromised already.

To spot these breaches take a look at the log trail for data that’s been encrypted or decrypted. Especially notice how users have accessed personally identifiable information or payment related information. Changes to file names and file paths, an unusually high number of events from a single user are all signs of data breaches.

Your databases are also used to store all your log data, and you’d want to check if disk space was insufficient to store all logs, or if any logs were left out recently. Notice if the data stored on these disks were altered or tampered with.

OS level

The first thing to check in the operating system (OS) layer should be the access controls for audit logs. This is because savvy attackers will first try to delete or alter audit logs to cover their tracks. Audit logs record all user activity in the system, and if an attack is in progress, the faster you secure your audit logs the better.

Another thing to check is if timestamps are consistent across all your system logs. Often, attackers would change the timestamps for certain log files making it difficult for you to correlate one piece of log data with another. This makes investigation difficult and gives the attacker more time to carry out their agenda.

Once you’re confident that your audit logs and timestamps haven’t been tampered with, you can investigate other OS level logs to trace user activity. How users logged in and out of your system, system changes especially related to access controls, usage of admin privileges, changes in network ports, files and software that was added or removed, and commands executed recently, especially those from privileged accounts – all this information can be analyzed using your system logs.

The operating system is like the control center for your entire applications stack, and commands originating from here need to be investigated during an attack. The next place to look for vulnerabilities is the hardware devices in your system.

Hardware or infrastructure level

Some of the recent DDoS attacks, like the one that affected Dyn last year was a result of hackers gaining access to hardware devices that end users owned. They cracked the weak passwords of these devices and overloaded the server with requests. If end user devices are a major part of your system, they should be watched carefully as they can be easy targets for hackers. Looking at log data for how edge devices behave on the network can help spot these attacks. With the growth of the internet of things (IoT) and smart devices across all sectors, these types of attacks are becoming more common.

Additionally, if your servers or other hardware are also accessed by third-party vendors, or partner organizations, you need to keep an eye on how these organizations use your hardware and the data on it.

After the incident

Hopefully, all these sources of log data can help you as you troubleshoot and resolve attacks. After the incident, you’ll need to write a post-mortem. Even in this step, log data is critical to telling the entire story of the attack – its origin, progression, impact radius, resolution, and finally restoring the system back to normalcy.

As you can tell, log data is present at every stage of incident management and triaging. If you want to secure your system, pay attention to the logs you’re collecting. If you want to be equipped to deal with today’s large scale attacks, you’ll need to look to your log data. It’s no doubt logs are essential to SecOps, and understanding how to use them during an incident is an important skill to learn.

Comparison, Technical

3 Logging Use Cases

The versatility of logs allows them to be used across the development lifecycle, and to solve various challenges within an organization. Let’s look at three logging use cases from leading organizations at various stages of the product life cycle, and see what we can learn from them.

logdna_in_action.png

Transferwise – Improving Mobile App Reliability

Transferwise is an online payments platform for transferring money across countries easily, and their app runs across multiple platforms. One of the challenges they face with their mobile app is analyzing crashes. It’s particularly difficult to reproduce crashes with mobile as there are many more possible issues – device-specific features, carrier network, memory issues, battery drain, interference from other apps, and many more. A stack trace doesn’t have enough information to troubleshoot the issue. To deal with this, Transferwise uses logs to better understand crashes. They attach a few lines of logs to a crash report which gives them vital information on the crash.

To implement this, they use the open source tool CocoaLumberjack. It transmits crash logs to external loggers where they can be analyzed further. It enables Transferwise to print a log message to the console. You can save the log messages to the cloud or include them in a user-generated bug report. As soon as the report is sent, the user is notified that Transferwise is already working on fixing the issue. This is much better than being unaware of the crash, or ignoring it because they can’t find the root cause.

You should ensure to exclude sensitive data in the log messages. To have more control over how log messages are reported and classified, Transferwise uses a logging policy. They classify logs into 5 categories – error, warning, info, debug, and verbose – each has a different priority level, and are reported differently.

While CocoaLumberjack works only on Mac and iOS, you can find a similar tool like Timber or Hugo for Android. But the key point of this case study is that logging can give you additional insight into crashes especially in challenging environments like mobile platforms. It takes a few unique tools and some processes and policies in place to ensure the solution is safe enough to handle sensitive data, but the value is in increased visibility into application performance, and how you can use it to improve user experience.

[Read more here.]

Wealthfront – Enhancing User Experience with A/B Tests

Wealthfront is a wealth management solution that uses data analytics to help its users invest wisely and earn more over the long term. Though the Wealthfront web app is the primary interface for a user to make transactions, their mobile app is more actively engaged with and is an important part of the solution. Wealthfront is a big believer in A/B testing to improve the UI of their applications. While they have a mature A/B testing process setup for the web app, they didn’t have an equivalent for their mobile apps. As a result they just applied the same learnings across both web and mobile. This is not the best strategy, as mobile users are different from web users, and the same results won’t work across both platforms. They needed to setup an A/B testing process for their mobile apps too.

For inspiration, they looked to Facebook who had setup something similar for their mobile apps with Airlock – a framework for A/B testing on mobile. Wealthfront focussed their efforts on four fronts – backend infrastructure, API design, the mobile client, and experiment analysis. They found logs essential for the fourth part – experiment analysis. This is because logs are a much more accurate representation of the performance and results of an experiment than relying on a backend database. With mobile, the backend infrastructure is very loosely coupled with the frontend client and reporting can be inaccurate if you rely on backend numbers. With logs, however, you can gain visibility into user actions, and each step of a process as it executes. One reason why logging is more accurate is that the logging is coded along with the experiment. Thus, logging brings you deeper visibility into A/B testing and enables you to provide a better user experience. This is what companies like Facebook and Wealthfront have realized, and it can work for you too.

[Read more here.]

Twitter – Achieving Low Latencies for Distributed Systems

At Twitter where they run distributed systems to manage data at very large scale, they use high-performance replicated logs to solve various challenges brought on by distributed architectures. Leigh Stewart of Twitter comments that “Logs are a building block of distributed systems and once you understand the basic pattern you start to see applications for them everywhere.”

To implement this replicated log service they use two tools. The first is the open source Apache BookKeeper which is a low-level log storage tool. They chose BookKeeper for its low latency and high durability even under peak traffic. Second, they built a tool called DistributedLog to provide higher level features on top of BookKeeper. These features include naming and metadata for log streams, data segmentation policies like log retention and segmentation. Using this combination, they were able to achieve write latencies of 10ms, and not exceeding 20ms even at the slowest write speed. This is very efficient, and is possible because of using the right open source, and proprietary tools in combination with each other.

[Read more here.]

As the above examples show, logs play a vital role in various situations across multiple teams and processes. They can be used to make apps more reliable by reducing crashes, improve the user interface using A/B tests, and enforce better safety policies on end users. As you look to improve your applications in these areas, the way these organizations have made use of logs is worth taking note of and implementing in a way that’s specific to your organization. You also need a capable log analysis platform like LogDNA to collect, process and present your log data in a way that’s usable and actionable. Working with log data is challenging, but with the right goals, the right approach, and the right tools, you can gain a lot of value from log data to improve various aspects of your application’s performance.

Comparison, Technical

LogDNA Helps Developers Adopt the AWS Billing Model for More Cost-Effective Logging

Amazon Web Services (AWS) uses a large scale pay-as-you-go model for billing and pricing some seventy plus cloud services. LogDNA has taken a page from that same playbook and offers similar competitive scaling for our log management system. For most companies, managing data centers and a pricey infrastructure is a thing of the past. Droves of tech companies have transitioned into cloud-based services. This radical shift in housing backend data and crucial foundations has completely revolutionized the industry and created a whole new one in the process.

logdna_adopts_aws_billing_model
LogDNA Helps Developers Adopt the AWS Billing Model for More Cost-Effective Logging

For such an abrupt change – one would think that an intelligent shift in pricing methods would have followed. For the majority of companies this is simply not the case.

New industries call for new pricing arrangements. Dynamically scalable pricing is practically a necessity for data-based SaaS companies. Flexible pricing just makes sense and accounts for vast and variable customer data usage.

AWS, and for that matter, LogDNA, have taken the utilities approach to a complex problem. The end user will only pay for what they need and use. Adopting this model comes with a set of new challenges and advantages that can be turned into actionable solutions. There is no set precedent for a logging provider using the AWS billing model. We are on the frontier of both pricing and innovation of cloud logging.

LogDNA Pricing Versus a Fixed System

The LogDNA billing model is based on a pay-per-gig foundation. That means that each GB used is charged on an individual basis before being totaled at the end of the month. What follows then is for each plan: low minimums, no daily cap, and scaling functionality.

Here is an example of a fixed tiered system with a daily cap. For simplicity’s sake, here is a four day usage-log (no pun intended) of a log management system with a 1 GB /day cap.

Monthly Plan: 30 GB Monthly – $99

Day 1: 0.2 GB

Day 2: 0.8 GB

Day 3: 1 GB

Day 4: 0.5 GB

This four day usage is equivalent to 2.5 GB logged. That’s an incredible amount of waste because of a daily cap and variable use. Let’s dive into a deeper comparison of the amount of money wasted compared to our lowest tiered plan.

LogDNA’s Birch Plan charges $1.50 per GB. If we had logged that same amount of usage with our pricing system it would cost roughly $3.75. While the fixed system doesn’t show us the price per GB – we can compare it to LogDNA with some simple math. If a monthly plan at a fixed rate of $99 per month is equal to 30 GB usage per month then you can reasonably say that each GB is equal to about $3.30 in this situation.

Can you spot the difference in not only pricing, but cloud waste as well? With a daily cap, the end-user isn’t even getting to use all of that plan anyhow. A majority of cloud users are underestimating how much they’re wasting. Along with competitive pricing, our billing model cuts down tremendously on wasted cloud spend.       

Challenges of the Model

It’s important again to note that our model is unique amongst logging providers. This unearths a number of interesting challenges. AWS itself has set a great example by publishing a number of guides and guidelines.

The large swath of AWS services (which seems to be growing by the minute) are all available on demand. For simple operations, this means that only a few services will be needed without any contracts or licensing. The scaled pricing allows the company to grow at any rate they can afford, without having to adjust their plan. This lessens the risk of provisioning too much or too little. Simply put, we scale right along with you. So there’s no need to contact a sales rep.

LogDNA as an all-in-one system deals with a number of these same challenges. The ability to track usage is a major focus area to us so that we can ensure you have full transparency into what your systems are logging with us. Our own systems track and bill down to the MB, so that the end-user can have an accurate picture of the spend compared to usage rates. This is not only helpful, but allows us to operate in a transparent manner with no hidden fees. Though it is powered by a complex mechanism internally, it provides a simplified, transparent billing experience for our customers.

LogDNA users have direct control over their billing. While this may seem like just another thing to keep track of, it’s rather a powerful form of agency you can now use to take control of your budget and monetary concerns. Users can take their methodical logging mentality and apply that to their own billing process, allowing greater control over budgets and scale.   

Say, for example, that there is an unexpected spike in data volume. Your current pricing tier will be able to handle the surge without any changes to your LogDNA plan. As an added bonus, we also notify you in the event of a sudden increase in volume. Due to the ever-changing stream of log data – we even offer the tools of ingestion control so that you can even exclude logs you don’t need and not be billed for them.

Our focus on transparency as part of the user experience not only builds trust, but also fosters a sense of partnership.

Scaling for All Sizes & Purposes

Our distinctly tiered system takes into account how many team members (users) will be using LogDNA on the same instance and length of retention (historical log data access for metrics and analytic purposes.) Additionally we also have our scaled pricing tier – HIPAA compliant for protected health information (which includes a Business Associate Agreement, or BAA, for handling sensitive data).

Pictured here is a brief chart of some basic scaled prices for our three initial individual plans. The full scope of the plans is listed here. This is a visualization of a sample plan per each tier.

Plan Estimator

BIRCH – $1.50 /GB – Retention: 7 Days – Up to 5 Users
Monthly GB Used 1GB 4GB 16GB 30GB
Cost Per Month $1.50 $6 $24 $45

Monthly Minimum: $3.00

MAPLE – $2.00 /GB – Retention: 14 Days – Up to 10 Users
Monthly GB Used 10GB 30GB 120GB 1TB
Cost Per Month $20 $60 $240 $2000

Monthly Minimum: $20.00

OAK – $3.00 /GB – Retention: 30 Days – Up to 25 Users
Monthly GB Used 50GB 60GB 150GB 1TB
Cost Per Month $150 $180 $450 $3,000

Monthly Minimum: $100.00

Custom Solutions for All & Competitive Advantages

Many pricing systems attempt to offer a one size fits all model. Where they miss the mark, we succeed with a usability that scales from small shops to large enterprise solutions. Our WIllow (Free) Plan is a single user system that allows an individual to see if a log management system is right for their individual project or eventual collaborated team effort into a paid tier. High data plans are also customized and still retain the AWS billing model. We also offer a full-featured 14-day trial.

The adoption of this model creates a competitive advantage in the marketplace for both parties. LogDNA can provide services to all types of individuals and companies with a fair transparent pricing structure. The end user is given all relevant data usage and pricing information along with useful tools to manage it as they see fit.

For example, imagine you are logging conservatively, focusing only on the essentials like poor performance and exceptions. In the middle of putting out a fire, your engineering team realizes that they are missing crucial diagnostic information. Once the change is made, those new log lines will start flowing into LogDNA without ever having to spend time mulling over how to adjust your plan. Having direct control over your usage and spending without touching billing is enormously beneficial to not only our customers, but also reduces our own internal overhead for managing billing.

Competitive Scenario – Bridging the Divide Between Departments

Picture this scenario; there has been an increased flux of users experiencing difficulty while using your app. The support team has been receiving ticket after ticket. Somewhere there is a discrepancy between what the user is doing and what the app is returning. The support team needs to figure out why these users are having difficulty using the app. These support inquiries have stumped the department – the director needs to ask the engineering team how they can retrieve pertinent information to remedy a fix.  

LogDNA helps bridge the divide by providing the support team with relevant information to the problem at hand. For this particular example, the engineering team instruments new code to log all customer interactions with API endpoints. The support team has a broader vision of how users are interacting with the interface. They’ve now been equipped with a new tool in their arsenal from the engineers. There was nothing lost in translation between the departments during this exchange.  

After looking through the new logged information, the support team is able to solve the problem many of its users were experiencing. The support team has served its purpose by responding to these inquiries and making the end-user happy. All it took was some collaboration between two different departments.   

The log volume has increased due to new logs being funneled through the system. But the correlation between increased log volume and better support is worth it. During this whole process no changes are required to your current account plan with LogDNA. Future issues that may arise will be easily fixed as a result of this diagnostic information being readily available. The cost of losing users outweighs the cost of extra logs.

LogDNA places the billing model on an equal level of importance as the actual log management software itself. It can be used to make decisions all across the board. LogDNA’s billing model allows itself to adapt to budgetary concerns, user experience and a better grasp of your own data all at once.  

Product Updates

LogDNA Announces a Host of New Features for 2018

2017 was a transformative year for LogDNA and our developer community. While developers continue to build and leverage our platform in truly amazing ways, developer and operations teams have also saved thousands of hours of sifting through logs looking for issues by harnessing the power of LogDNA. Thanks to LogDNA, dev teams are free to do what they do best: building great products.

logdna-new-website

New Year, New Features, New Look

To start things off fresh, logdna.com has a new look, thanks to our new design team. We’ve also added an All Tags filter and two new archiving options: Google Cloud Storage and Digital Ocean Spaces to the LogDNA web app. For field search, we’ve even added a brand new search syntax for exact match.

New SOC 2 Compliance

After weeks of hard work, we are proud to announce that LogDNA is officially SOC 2 compliant! Like our HIPAA/HITECH, and Privacy Shield (GDPR) compliance, the decision to become SOC 2 compliant stemmed directly from valuable feedback from our awesome community.

New Functionality

By popular request, invoices can now be downloaded as PDFs on the billing page, and tags can now be searched directly in the search bar (e.g. tag:my-tag). You can now even click each bar in the dashboard graph to show that day’s data usage breakdown. To top it off, one of our customers, RedBear, has kindly released a community .NET code library for LogDNA.

Other Improvements

  • Added show raw line option under user preferences
  • Dyno is now available as a field in line format under User Preferences
  • Added time zone as a configuration option for email alerts
  • Added color as a configuration option for Slack alerts

Thanks to your support, we’ve been able to grow our team quite a bit, so you can expect many more cool features to come. Until next time, log safe!

 

Case Studies

Home Buying App Open Listings Goes With LogDNA for Affordable, Fast, Cloud-Based Log Management

Byline: Kevin Miller – Director of Growth at Open Listings

At Open Listings, we needed an affordable cloud-based log management system that was both fast and simple to administer. One that could help us find and resolve production issues instantly. We found that tool with LogDNA.

Problem we faced that led us to LogDNA

Before LogDNA we were building and maintaining our own internal tools to compile our log data and make it searchable. A problem that a lot of small companies have is that they often find themselves committing considerable person-hours to create cost-effective solutions, only to realize that you actually need those resources to focus on your core business. Using LogDNA made it possible for us focus on our core strengths as a team and our product, and we benefited from leveraging a team that’s focused on creating an amazing product (versus us using a tool in our spare time). In this case LogDNA had the tool we needed. They helped solve a common pain point that almost all small companies face.

Open Listings uses LogDNA to pinpoint production issues instantly.
Open Listings simplifies the homebuying process.

Why LogDNA?

LogDNA makes it easy to search based on user behavior, which helps our team better understand what actions a user took before or after an event that we are investigating. Simply put, we often times need to audit how and why a lead was sent to a specific mortgage lender or partner agent. LogDNA enables us to find the answer in the shortest amount of time.

Of course, LogDNA isn’t the only solution in this space. While Splunk is the big player here, there are many other options, some of which are Open Source. The thing is, going with a company like Splunk becomes cost prohibitive really quickly if you are a small company, as it stands today, most solutions are only built for enterprise size organizations. A lot of small companies initially go with one of the Open Source options available. However, even they become cost prohibitive as you often have to dedicate your own engineering resources to administer it. Once again pulling important members of your team away from your core mission.

LogDNA simplifies the process of searching through log data.
LogDNA helps Open Listings quickly search their log data to pinpoint issues.

Additionally, all of our data is pulled in live and indexed instantly. This is important for us in particular when we are ready to offer assignment routing. This means we assign a home offer to a particular agent for them to submit to the leasing agent and get an acceptance on a house. It is extremely important that we correctly route the offer to ensure the agent who receives it is both relevant for the end buyer and knowledgeable of the local area.

If an offer is improperly routed, LogDNA help us uncover the decision process to better understand how that offer got routed.

Also, if a user reports a bug, LogDNA diagnoses it quickly. Everybody on the team can use it, including those that aren’t technical, who can view a read-only version of a page.  You can filter and mix / match to customize the screen to see everything you can do.

LogDNA’s pricing structure works very well for us!

We push hundreds of Gigs of data a month into LogDNA and their “pay as you grow” pricing structure works perfectly for us. It acts as a major cost savings vs. storing all that on our own infrastructure (on-premise). Additionally, there is less to manage, and we don’t have to have someone managing all the data that is moving around. We are thrilled to have LogDNA take that data and make it useable for us quickly, on the cloud. Regarding integrations, all of the data we push goes into LogDNA using AWS cloud, which we are already on, so integration was a snap.

Open Listings uses LogDNA to help pair homebuyers with qualifying agents.
With Open Listings, homebuyers can easily create offers on homes.

Overall, Open Listings has seen incredible value from LogDNA due to it’s affordable pricing, time savings with regards to engineering resources, and cloud based infrastructure, making the data housed there accessible and usable by any employee.

About Open Listings

Open Listings is an all-in-one home buying service designed to give buyers an edge in any housing market. With Open Listings, would-be homeowners can house hunt 24/7, create offers, and save thousands in fees — all from their computers or phones. To-date, we’ve helped buyers get over $500 million worth of homes all the while saving upwards of $5 million!