Last updated at Thu, 26 Oct 2017 20:31:42 GMT
Last week we published an article entitled ‘Log Management 101 – Where Do Logs Come From?‘ to which one of our more witty readers retorted:
“Sometimes a server and an app love each other very very much…” 🙂
The article covered some of the basics around collecting log data from various parts of the stack as shown here.
In short these fall into the following categories:
- Libraries for common languages and frameworks – Allowing you to log directly from your application source code.
- Collector agents – Usually built for common operating systems, agents will collect data from your file system in real time and forward it on to a third party service.
- Syslog – Ships out of the box on all Linux and Unix distros and is commonly supported by devices such as routers and switches. It comes in a number of flavors (rsyslog, syslogd, syslog-ng…), with some more capable that others.
Over the coming weeks we’ll be diving into these different options in more detail explaining the pros and cons and best practices around using these. This week we’ve decide to look at agents.
In Defense of the Agent
While some providers tout the evils of running agents on your system and can oft be heard shouting, “no agents here!!!”, we prefer to keep an open mind at Logentries. We’d rather not dictate to our community what approach to take when collecting log data nor do we try to prescribe what’s best for you – rather, we’d prefer to give you the different options and allow you to make that decision for yourself.
That being said, like most things in life, agents have their pros and cons. They are certainly not a silver bullet, but they do have their advantages in certain scenarios.
We want Agents!!!
The two main advantages of using an agent to forward your log data are (1) quick setup and (2) additional functionality.
Having the option to get setup with new tools and technologies quickly is important! It’s often overlooked by providers, but it adds great value for users and, in my opinion, it is a critical component of a service that strives to provide a low barrier of entry to the wider community. From our many conversations with users over the past few years we have found that they do not have a lot of time when it comes to evaluating new tools and technologies. Having the ability to get setup and using features quickly is a must for many of them. I can certainly relate to this, even when I was completing my PhD – where I researched and built performance profiling tools for a living – I had a rule of thumb whereby if configuring a profiler took more than 10 minutes I usually just moved on. I generally had something more important to be doing that forced this – and that was in an academic setting where time could move more slowly than in the commercial world 🙂 In the commercial world people usually have smaller time windows to work in.
Well built and documented agents should allow you to get up and running quickly. For example the Logentries agent can get you up and running within 60 seconds with a single command. It works as follows:
- Copy and paste our single line instruction from our quick start guide to your terminal
- The agent will be downloaded and installed - You will be asked for your Logentries credentials.
- The install process will automatically find standard logs on your system and configure them to send data to your Logentries account.
- The install process will automatically send some sample log events into your account to (1) make sure you have connected to our service and (2) to give you some data to play with so you can immediately play with our features without having to generate log data from your system.
- The install process will automatically configure some sample tags and reports so you can immediately see the value of being able to highlight important events, creating alerts and building reports.
The alternative to the above is configuring syslog (which often assumes a level of understanding for syslog), where its config files live, and how to go about editing them. While this can also be documented (and we have been making our syslog process easier and easier to follow) we find that you can get more easily get tripped up, especially when there are lots of different flavous and versions of syslog. This can be particularly painstaking if you are running some outdated version where instructions or config formats can differ ever so slightly. Syslog can also be a challenge if you want to collect data from non-syslog log files that do not live in the /var/log folder.
Furthermore, if you are living in the Windows world, syslog is not going to be an option (well not out of the box anyway…you can always download and configure Snare – the windows equivalent of syslog). If you fall into this category you will likely require an agent to be able to start collecting your logs without a major time investment.
The second main advantage of agents is that they can come with additional functionality. For example the Logentries agent also provides for the following:
- Data filtering – This can be important if you have sensitive data in your logs. The Logentries agent has a filtering component that can be configured to cleanse your data and to strip out any private information before it leaves your network.
- A command line interface – Traditionally Sysadmins and devs worked with their logs on the command line with a combination of commands like tail -f, grep, awk, etc. So it makes sense that from time to time you may want to reuse some of these old skills even if you are using a log management tool with nice browser-based functionality (e.g. search, tagging, alerts, reports …). The Logentries agent gives you command line access to all your logs contained within your account. For example you can easily search, export and filer data from your Logentries account via the CLI – you can also navigate your account and list your logs as if you are navigating your file system.
No Agents Here!!!
The most common reasons for not using agents are:
- Maintenance – If you have a large environment with 100’s of server instances, the thought of installing/updating/patching another piece of code might be undesirable. This may especially be the case if your systems already ship with syslog. That being said, if you do have such a large environment, you are likely automating deployment through something like Chef or Puppet and so this may be less of an issue. Agents thus need to provide for a silent install so that they can be deployed en masse. Furthermore, if the agent is properly managed and maintained (e.g. though the various *nix package managers – as is the case with the Logentries agent) updating your agent to new versions will be fairly seamless and will happen along with the rest of your updates.
- **Trust **– Running someone else’s code on your system takes a level of trust. You need to know that it has been well written and isn’t going to kill performance or have any major security holes. To help alleviate any concerns however, we have open sourced the Logentries agent so that you can view our code, and even modify it if you so wish. Although it is understandable if you do not have the time (or inclination) to spend reviewing our agent code base 🙂 Furthermore, in some cases, using an agent is just not going to be an option (perhaps due to strict security policies or hard performance constraints). Again this is where syslog may be more of a known and trusted quantity.
In summary agents are not necessarily good or bad, they are not perfect, nor are they evil 🙂 Like most of us, they have their good point and bad points.
