[This article was written by Chris Riley]
Today, everything must be faster. Faster releases; faster and larger backlogs; faster complaints; faster bugs. The speed and performance of the modern software delivery pipeline brings a new set of challenges. How do you keep up? There really is only one option — automation and measurement. You need a method for automatically collecting data about your application and how it is being used. But also a good way to find the relevant information and act on it. And in order to do this your development team needs to lead with analytics first.
There are many types of analytics platforms. The breadth of each platform is determined by the amount and type of data they contain from the delivery pipeline.
Log management and analytics butters across all data produced by the pipeline. And for this reason it is one place the team can centralize the collection of new data. Data collection is great and relatively easy, but there are a few problems.
- Data stored without a purpose or way to analyze has no value.
- IT often owns Log analysis and sometimes developers have limited access or participation.
Yes, you can log everything; and you should. The reason you should is because getting data retroactively is expensive and difficult; and it might not provide value right away. But another reason is to improve communication and ownership around the log analysis service itself. Often with log analysis, Ops owns its implementation and usage. Depending on the culture of the teams this could hinder the development team from gaining value or insights from the tool. In a worse case scenario IT locks out all data and usage that is not system and infrastructure related. In the best case developers have their own level of access or even their own tools, and are storing data in the system as well.
Without everyone working in, storing, analyzing and sharing value from the log analysis service there are guaranteed gaps in communication and issue resolution. It is critical that the entire team use the system to ensure consistent communication and continuity between application layer and system layer issues. Not only will developers help enrich the platform, they also can benefit from bugs that are identified more quickly.
So how can the developers better use log analysis platform? Here are 10 things developers can do to lead with analytics.
In Your Code
- Exception Blocks: This is a simple idea, but not commonly done. In your exception blocks, log the error message or maybe even the entire stack trace. This is a great way to create dashboards on error types. And historically measure the number and frequency of error types.
- Log Trigger Events: Log critical actions such as user activity. This data can later be related to user cohorts for marketing, product management, and growth hacking purposes. But also for the developers to optimize user flow. For example, events you expect a user to take, but they do not. Or accidental actions such as a logout.
- Run Duration for Bigger Processes: For large process intensive or lengthy application processes, log start and stop times. It can then be correlated to pegged servers, outages or load issues if they arise. This data can help to identify areas where the product is slow to respond, or issues of application processes effecting infrastructure.
- Log Deprecated Functionality: When deprecated functionality is called, log it so the team can be alerted. This will help QA and Development know when outdated classes are being used by other team members by accident.
- Log flag Changes: Some developers like to use flags in their code to indicate different states. Create a function for changing flags so that it is logged and clear when flags are off or on. This allows the reporting or alerting of when a particular flag that should have been off, remained on in production.
- Log Component Usage: Applications are a treasure pile of 3rd party component libraries. These libraries pose a risk when they are not monitored. For all the components used, it is good to log their usage – component name and version. There is a downside as this can be very chatty if not designed well. And it has to be backed by some good component tracking process outside of the collection, and from the insights.
With the Team
- Architect Your Logs: Make sure the development team agrees on a standard for logging key value pairs. A consistent language and format so that everyone on the team can understand it.
- Leverage Tags: Creating the logs is part of it, but create relevant tags once the logging happens. For example “User” for user data. “Error” for the above error exception data.
- Create Dashboards: If you log it, use it. Create dashboards give them convenient names and share them with the team. Also create alerting and email reports on regular basis. There does need to be a process to review and prune unused or old dashboards or you will have dashboard sprawl/confusion.
- Unify System to Application: Help the broader team understand the relationship of applications to the infrastructure they run on. For example apache functionality specific to a new version, ties to orchestration scripts or containers, etc. If you do this successful IT may not have to ask you about OS level configurations and backend code, they can fix it themselves.
For a team to be metrics- and results-driven, they need to lead with analytics. And to lead with analytics means to log everything and establish easy ways to leverage what is logged. Developers have a lot to gain from a valuable system and application logging service including reducing bugs, faster time to resolution, and better insight across infrastructure and application layers.