Last updated at Mon, 30 Oct 2017 14:26:09 GMT
A few weeks back, I was reading through Hacker News when I came across an article titled “AWS Tips I Wish I’d Known Before I Started.” Expecting a “Top 5,” or even “Top 10,” list I was surprised to find an extremely nuanced, approximately 50 point list with details on each. Which would make sense, then, why I found it at the top of Hacker News that day. As I read through it, though, I was happy to discover something; we could help with many of the problems that author Rich Adams was describing. Not all of them, no…some of them are far outside of the realm a log management tool could help with. But some of them were right in our wheelhouse, so I wanted to call those out. I’ll go point by point, straight from his original article, to give detail.
“Logs should be handled via syslog and sent to a remote store”
Right out of the gate, we’ve got one that we can help you with. Hooking up via syslog to store and analyze your logs in Logentries is drop dead easy. And we’ll keep them in the product for as long as you’d like to do analysis, then you can automatically backup your logs to your S3 bucket.
“Store extra information in your logs”
We suggest to our users all the time, if you’re not sure, then log it. As our Chief Scientist, Trevor Parsons, is fond of saying, “nobody ever got fired for logging too much.” We’re here to help you sort through the haystack to find the needle…but you’ve got to make sure you’ve put the needle in there first. Beyond that, if you follow Mr. Adams’ suggestions about putting in fields with values, we can help you extract all the field value data you send in about instance-id, region, availability-zone, environment and more.
“Have tools to view your application logs”
Ummm…check. You can view your logs in realtime as they come in, or you can go over them afterwards (say, when an alert tells you something is going wrong). It’s up to you. Both are easy.
“Servers are ephemeral, you don’t care about them”
Mr. Adams’ point here is that, with auto-scaling on EC2, servers will rise and fall like nothing. We’ll still pick up all your logs as EC2 spins up instances and kills bad ones. We’ll help you get all your log data from your application regardless of how big or how quickly your environment has to grow. Plus, as the author states, don’t store anything on your server. With a log management solution, all your logs are stored in our application (and backed up to S3 if you want). You don’t have to worry about losing your log data stored locally on a server. This allows you to troubleshoot issues that may have occurred on an instance to no longer exists.
“Use tags!”
OK, So I know he’s not talking about tags in your logging, but the same idea applies. As Mr. Adams says, “they’re great for organising things, make is easier to search and group things up.” It works with your EC2 environment and it works for your logs as well!
In Conclusion
This is just the tip of the iceberg. To avoid going on forever, I only spoke to the most salient pieces from Mr. Adams’ wonderfully detailed post. The truth is that a solid log management solution can help you in many more of the ways that he details, and other ways as well. When you’re moving to the cloud, be it AWS EC2 or elsewhere, there’s a lot of change you’re going to have to be ready for. You’re going to get overwhelmed by data coming in. We can help you pick out the important pieces and find the actionable insight that you need to make your transition, and continuing operations, smooth.
