When you use a centralized server to store your enterprise log files, you’ll quickly discover that the system can become very big, very difficult to manage without using a good naming convention in the files names and the directory structure, If all your event and application logs from multiple systems and servers are simply dumped into some central repository then at best you’ll create an admin nightmare, at the worst you’ll lose data by overwriting log files accidently.
This is likely to cause a huge level of confusion, or even make the whole point of storing and archiving your log files pretty much pointless. To prevent this, there are three key steps that you must take:
1) Name Your Log files in an accurate and logical manner. Basically define a naming convention that suits your need – try and use descriptive names like gateway server or ticket proxies. You should also include all relevant information and try to consider future developments and allow scope for this. Make sure this is consistent and ensure that anyone who has access to the repository (be it human or application) uses this naming convention when adding files to the system.
2) Use a hierarchical directory structure on your file system to store the log files. It’s difficult to specify the exact method and structure you should use because it will vary depending on the requirements. For example you could start the top level with system name and then split lower down the directory structure by date, application or system whichever is appropriate.
3) Specify locations – it’s important to know which computers and server these logs are from. This might seem a very simple idea but it’s vitally important. Don’t rely on IP address or DNS names as these can change, indeed the best logs have hardware information which rarely change. High traffic computers like fast proxies will generate huge amounts of traffic and rarely be out of use.
There is no specific way to configure either of these two requirements simply because there are multiple variables needed to make the decision. However it is essential that some thought goes into these decisions as they are crucial to maintain your log structure and making a useable resource.
There is a certain level of personal preference in these decisions, however there are some steps that can be included before deciding on a structure. One of the most important things to do is to ask any users or analysts who need access to these logs – their own opinion. Many will need to run reports or look for logs based on certain criteria, you can make these tasks significantly easier with a logical and consistent structure which encompasses the information they need. Don’t assume that basing the structure or naming convention purely on names, systems or dates is the best option – ask the users.
Recent Comments