Java IoT Authors: Pat Romanski, Zakia Bouachraoui, Yeshim Deniz, Liz McMillan, Elizabeth White

Related Topics: @DevOpsSummit, Java IoT, @DXWorldExpo

@DevOpsSummit: Blog Post

Four Steps for Structuring Log Data By @Leigh313 | @DevOpsSummit [#DevOps]

In the age of Big Data we are taught that no pile of data is too large or too complex

Four Steps for Structuring Your Log Data
By Leigh Merrigan

In the age of Big Data we are taught that no pile of data is too large or too complex. This is absolutely true. Most data analysis systems can take any type and volume of data - but ingestion is much different from consumption. The way your data is structured directly impacts its ability to be consumed, understood, and correlated with other data. Here are the top 4 ways to make sure your system and app logs help you to do this effectively.Structuring Your Log Data

Before you start ingesting a new source type, spend a little time to ensure that the effort cost to report on the new information is low. Also, it's important to have the ability to correlate one log with another so the insights that log data provides is consumable by the entire team.

Here are four top steps to deliberate log management adoption:

1. Think about query-ability:
There are thousands and thousands of logs available to you for collection and future analysis.  And generally it is very easy to start sucking them in. But you need to ask yourself one simple question: What am I going to do with this data? The results are mixed. Sometimes it's obvious, but often the obvious can also lead to surprising conclusions.

For example, did you ever think that you would have to correlate a pegged server process with a new user on the system? It's not an uncommon test when new application registrations have a lengthy provisioning process. And Ops needs to know where and how to distribute such loads.

When can this cause serious issues? When your organization has a special event, and there are a lot of new registrations in a short amount of time. I've seen this happen more than once. It has brought servers to their knees. And causes a lot of embarrassment. But if queries were set-up to identify this trend, it's load balancing could be established early on.

This is an example of a use case or question that operations should have asked, before these logs were added to the system.

2. Align standard naming conventions
Thinking ahead also means that there needs to be a consistent language. This usually presents itself when it comes to asset, and component names. Values of these need to be consistent across all logs. For example if you call servers "nodes," or name them based on server type. These names need to be represented every time a particular server is referenced. Or are you going to reference configuration script runs by their name, or by the version of the environment build? By making sure names are consistent, not only is it easy to query on named assets and components, it's easier to communicate across teams when activities do not 100% align, but the same assets are involved.

3. Avoid nested documents
Really nested documents are impossible to avoid. And they provide a huge value in logs where nested data creates an automatic correlation between objects. The trick is that nested data creates nested queries. Which increases query complexity. This is no problem for your log analysis system. It is a greater problem for the people using it. Individuals can easily get confused about nested objects, and easily mis-interpret them.

There are a few options to mitigate this. You can explode your logs, but you will lose some value. Or you can create better references to critical data in the parent document, but this creates duplication. Both have pros and cons. What you choose will depend on the log. You might have a combination of both solutions, or perhaps one that I did not even name here.

4. Find the false positives
There is another thing nested documents, and all logs might contain. And that is replicated data, where the key's repeat throughout sections of the log. This is a problem in any information architecture type project.

When you have repeating keys, it can be especially easy to confuse one key with another intended one in full-text search, but also in queries. Again no problem for the log platform, but humans can easily get confused during interpretation. And the net result can be false positives. One approach to avoid this is to eliminate them. But this is often not even a choice. Next approach is to just be aware, and use caution when you think it is a potential.

One thing I imply throughout this post is that you may want to reformat your system logs. But reformatting logs is a lot of effort. It adds an additional step in the process, which is another point of possible failure. It is not a recommended first approach. Ideally you are confident in your teams ability to be consistent, and aware, which makes reformatting unnecessary. When it comes to software logs however, it is a lot easier, because often your developers have control. And the team should spend the time to plan out how these logs should look.

Some of these suggestions also imply a set of rules or strategies for your logs. And those rules or strategies need to be socialized. There are several ways to do this. You can create a library of standard queries that contain common elements, such as user, or system queries. And some log management services also offer the ability to save searches so they are accessible for repeated use, and shared usage across a team.  Or you can document the rules and strategies. Unfortunately published documentation is easy to avoid. So this is less than ideal but sometimes necessary, depending on the culture and size of the team. An easier, but harder to measure approach is to use a consistent spoken language. Push your team to talk in terms that map to queries and things everyone understands. Such as server naming conventions, and settings. It takes a lot of consistent pressure on the team but very helpful no matter what. And finally training; more formal sessions teaching all users on strategies and approaches to the log platform.

Log analysis encourages you to dive right in, and you should. But dive in with an idea of what you are going to do after. How are you going to use the logs? What questions are you going to ask regularly? How are you going to report on the data to the rest of the organization so that there is a consistent understanding?

Most log analysis platforms can take whatever you throw at it. By being deliberate about what you feed it, you are ensuring the greatest query efficiency, helping with better reporting, and avoiding a lot of frustration.

More Stories By Trevor Parsons

Trevor Parsons is Chief Scientist and Co-founder of Logentries. Trevor has over 10 years experience in enterprise software and, in particular, has specialized in developing enterprise monitoring and performance tools for distributed systems. He is also a research fellow at the Performance Engineering Lab Research Group and was formerly a Scientist at the IBM Center for Advanced Studies. Trevor holds a PhD from University College Dublin, Ireland.

IoT & Smart Cities Stories
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...