Last updated at Wed, 01 Nov 2017 20:07:57 GMT
Operations teams know the value of scripted infrastructure deployments. And while they can actively create, maintain, and run individual scripts, they do not have oversight on what has been run, and when. By adding log analysis, automated orchestration can go so much further, resulting in a more reliable infrastructure, with better issue response.
Chef, Puppet, Salt, Ansible, Vagrant, and more; once you get to know these tools, it’s easy to crank out scripts. Once you have the original scripts running, it’s easy to make updates. There is also the additional benefit of your work serving as documentation for your infrastructure (despite being only readable to operations).
But wait, there is more! You don’t even have to create the scripts manually; there are tools out there that will scan your base environment, and make the scripts for you!
But there is a problem. A big one.
How do you manage the script runs? How do you know which version of which script was used for which deployment of the infrastructure?
The development team knows exactly what code is in production down to the line. But do you know the same?
If you don’t, you are wasting time by trying to remember which scripts were run. Maybe you have created unmanageable spreadsheets to track. But lets face it, this approach creates entries you never look at again. And when something goes wrong, you have to guess in which script the problem exists in order to correct it.
You can start simple, by storing your scripts in Git.
Get some versioning at least. But, you still might not know anything about their runs, and how those versions correlate to your infrastructure activity, or more important issues. It would nice to know that an old script was run for a particular machine. And how that script correlated to some issue e.g. because it installed the wrong version of Apache. I’m sure you can imagine the possible scenarios.
You can do this, but maybe not in the way you expected.
Log analysis is a simple and cool way to add oversight to your orchestration environments.
During your deploy, and for each script run, add simple calls to your log system that record the run date and time, the version, and any other metadata associated with the deployment. With this log data, you now have a new management tool.
The effort is minimal; the impact is fantastic.
The entire Operations team can now know, for example, which script versions are currently in production. Which versions might not match other scripts runs. And if something goes wrong in the infrastructure, which script and run date was a part of it. You can know what the issue is and address it more quickly.
You can also utilize machine-learning capabilities like anomaly detection to find where a script that was run does not match the previous sequence of script runs. Or Inactivity Alerting to know when something expected did not happen.
If you are using your log analysis platform for application data as well, you will be able to more quickly identify if a current issue is related to backend, infrastructure, or front-end.
While scripting your infrastructure is a powerful tool, using it alone is a quick-hit device.
By using log analysis, and simple calls to the log analysis platform, on every infrastructure deployment, you’ll have instant visibility, real-time dashboards, and smart logic on infrastructure deployments.
