Last updated at Fri, 03 Nov 2017 17:41:57 GMT

You are on top of your game. You have a log analysis tool churning logs from all your applications and infrastructure. And now that you have data (LOTS and lots of data…), you are able to understand your infrastructure better than you ever did before. You might even build a dashboard or two that tells you what is going on with your IOPS and utilization, at a glance.

But when it comes time to explain system status or configurations to everyone else in the organization you get stuck. Stuck and frustrated that your time is being taken away from tasks that need to get done.

Did you know that the same log analysis tool could be your key to reporting with management, communicating with developers, and building business cases for change? All with much less effort than before.

How?? Let the logs do the talking for you. 

During your busy day you are too consumed with regular system admin tasks to think about your next monthly or quarterly meeting with management. In this meeting, however, you are expected to say what is going well, what is going poorly, and how you are improving it. And that is just one audience; the developers need your help too. They demand issue details, and status updates after new releases.  You know all this stuff in your head, but putting it together is hard.

For the developers you cannot just say “hey, something is wrong”… you have to pinpoint the issue in order to avoid the “it works on my machine, or in the lab” challenge. Management wants to know not only what happened, but also the impact on customers and usage. But, often tech speak does not translate to the business issues. And if you know there is an opportunity for improvement, that is going to cost some money, you will have to prove 1)  there is a problem, and 2) that the spend will fix it. How do you build a case, on top of your other work?

It’s hard. But just like log analysis tools assimilate information for you to better understand what is going on, they can provide you the tools to help others understand what is going on as well.

A well designed system of dashboards and reporting literally makes it possible for you to screenshot a dashboard, add some numbers and comments, and polish off a great presentation in minuets not days.

Here are some best practices to make your reporting life easier.

  1. Be deliberate in your dashboard creation. Sometimes you are compelled to create a dashboard on demand, as the moment strikes you. While you should not suppress that urge, make sure you understand how any new dashboard is going to be consumed.

  2. Name your dashboards with external communication in mind.  Your naming conventions should not be cryptic. You need to be able to quickly spot the dashboard. For example “OutagesWithTimeSeries” in order to report on recent outages for the quarter.

  3. Give developers a piece of the pie. Allow your developers to access the portions of the analysis platform that pertain to them. Why? Because this makes them accept the information from the platform, and makes them feel a part of the solution. You build a comfort level that allows the communication to flow more easily.

  4. If you always have to use a query you are doing something wrong. Design your quires to be repeatable, and something you can report on.  There is no way to avoid unique one-offs but 90% of the time you should not be writing queries to answer common questions. It’s better to turn those quires into pictures.  Use the querying approaches for your research and deep dives into particular issues or analysis only.

  5. Be consistent. Nothing wastes time in meetings like arguing over what a number means.  Be consistent with all reporting so as not to confuse people.  Ideally your presentation will have the same slides, just over different periods of time.

  6. Don’t go too deep. The deeper you go the more questions you create. Also you might just lose people in details of say memory utilization that they do not care about. Rather, report on the overall consumption of your infrastructure, and what you are doing with the underage or overage. For example. This means that your reports need to be more concise than you are used to for your own consumption.

  7. Help your boss. Make your boss look great, by creating reports that he/she can also use to streamline their presentations. Setup regular email alerts with the reports and think about what is useful for business teams to know.

  8. Think about your design. If there is an opportunity to better organize, or collect logs than use it. Often organization is an afterthought and comes too late, and then once a year you are trying to clean everything up. Stay organized at the beginning and you will save a ton of time.

Log analysis is a work horse giving you a better point of view of what is going on. It allows you to see the steady state of your applications and infrastructure in one location, and with no manual effort. Log analysis also allows you to make decisions you could not have previously. But this is only half the benefit.  It can be an excellent communication tool as well.

When you use your log management tool into a reporting and communication tool, you will skip the frustration of preparing for the next meeting, or trying to translate your data for other departments in your organization. Save time by taking the extra step to let the logs do the talking for you.