Digital Signage Expo05/04/2012

The last couple of months seemed to fly by quicker than usual, and we noticed we have not kept our blog up to date, so time to catch up on some recent happenings.


(image courtesy Digital Signage Expo)

In March a couple of our employees were able to attend the Digital Signage Expo in Las Vegas. Since this was our first time attending the conference, we spent a good deal of time looking at every booth and every company, big or small, for what was cool, what the trends were, and especially for companies that we could partner with to make some cool content.

The Not So Cool
After looking at a few booths we quickly found out that digital signage content that was not interactive was not that cool. Obviously these have a place in the overall world of digital signage, and are the correct solution for many applications, but the tools for creating this content output nothing more than glorified flash animations, which look increasingly dull when compared to more content-rich interactive applications.

Content “Providers”
Another thing we learned that was interesting came in the world of content providers. This is where we began to see some of the fancier looking custom content that we are familiar with. It was obvious that a lot of these companies knew what they were doing in making digital signage content that would make you stop and look. However many of them admitted that the really just designed the content and really had no idea what the underlying technology was or how it was put together. They just outsourced that to another company.

The Entire Package
It quickly became apparent that MOST of the companies there could not put together the whole package or a complete solution. Obviously you wouldn’t expect the display manufacturer to also be able to code some interactive HTML5 templates for the display, but when you asked about what kind of content or solutions their display was best for the typical answer was ‘we don’t know about any of that, we just make the displays.’ We concluded that what Digital Trike brings to the digital signage world is the knowledge and expertise to put panels, content, and technology together to create the real end product – a digital signage application.

We should note that a few companies did have people in their booths that created awesome solutions with their products, and these were by far the best booths. Also there were a few companies there that understand the importance of having people that could make awesome finished products with their components, and one reason for being at the expo was to meet people to make cool stuff with their products (like us!). We were excited to meet them to and look forward to creating applications with their awesome products in the near future.

Summary
As the world gets more and more into digital signage and interactive touch-based phones and tablets, the demand for well-designed interactive digital signage will continue to skyrocket. Some players in the digital signage world see that future and Digital Trike wants to take their cool products and help make truly amazing digital signage applications.

Publishing HTML5 Content for iOS02/29/2012

This is an extension of our previous post about building HTML5 apps for digital signage.

So you have built an impressive interactive presentation showcasing your product for a large touch screen. Now, how to you make it available to a wider audience? How do you give it to your sales team in the field?

Enter the Baker ebook framework.

The Baker Framework allows a developer to easily wrap any HTML5 presentation into a native iOS app for distribution. Baker defines an ebook specification called “HPub.” In a nutshell, HPub is a package of HTML files and assets along with a manifest file defining the properties of the book. The Baker iOS app loads the HPub and renders it in a webview on your device. It supports any HTML5 video, audio, and fancy animations you can come up with.

To learn more about the Baker Framework or to discuss developing custom ways to showcase your product, send us a note. We’d be happy to help.


HTML5 content in Baker

All About Maintenance02/29/2012

It’s a common story. After months of reviewing ideas, strategy, design, content, and functionality your new website launches to great excitement and fanfare. The euphoria of the moment is unparalleled as all the hard work of your team is realized in a live product for all the Internet to enjoy. But the joy is often short-lived as your marketing strategy doesn’t take off like you expected, or users find your site confusing or hard to navigate, or sections of the website become sluggish as real-world data and users overwhelm the site. In our experience, many agencies are long gone at this point having moved on to next “latest and greatest” website. A recent client experience reminds us why maintaining a website is so important, but first some more about web maintenance.

What is Maintenance?

In web development, maintenance is simply work done on an already deployed site. The work done covers a broad range of components essential to a good website. Some common things done during maintenance include:

  • Making sure the web server is properly tuned and configured to handle site traffic
  • Database monitoring for slow queries and query volume
  • Additional quality tests for real-world user data
  • Uncaught bug fixes
  • User experience enhancements
  • Updated marketing content modifications
  • Statistical analytics, goals, and trends

Obviously this is just a few of the things that need to be done on websites post-launch. But the important thing is that they are essental for keeping your website running smoothly and purposefully long-term.

Why Does Digital Trike Provide Maintenance?

So if so few companies provide maintenance why do we do it? Well, your success is our success, and we pride ourselves on developing long-term business partnerships that allow us to create awesome solutions for your business. Second, we have an entire team of people with a wide range of experience and expertise. From strategiests, consultants, programmers, and system administrators, chances are there’s someone here who can help.

Real-world Example

So a recent client experience is what inspired us to write this blog post (which we’ve been meaning to do for a long time). In this example, when a user logged in to the client’s website and went to manage their data it usually took a couple minutes for the page to load. A programmer and sys admin monitored the server and the sys admin located a query that was taking a lot of time to complete. The team ran the query on our development server and found that it was taking that long, concluding that the problem was with the query/database and was not related to the server load. The team added some indexing to the database table to help lookup times, and in the end the query was taking less than one-tenth of a second to complete. This was a simple fix to make, and a simple oversight in database design, but would have never shown up in pre-launch testing due to the lack of hundred of thousands of database entries.

In conclusion, no matter who created and coded your website it needs tuning and improving post-launch to ensure the site is running as it should and serving the purpose for which it was created. Contact us for help in maintaining and improving your already existing website.

Firefox Losing its Luster01/31/2012

no firefox

Once upon a time Microsoft’s Internet Explorer ruled the browser wars. Actually IE was so dominant that the “browser wars” was a laughable concept. But then Mozilla’s Firefox browser came along and the competition resumed. Firefox rendered faster, had more support for future CSS proposals, and was innovating at a time when those developing IE saw no need for further innovation. Now the once powerful and innovative Firefox is slipping. To those of us that championed the arrival of a better browser this is sad, but the fact is that Firefox is lagging behind in areas where other browsers are excelling.

When it was first launched Firefox was leading browser innovation with things like tabbed browsing, add-ons and style customization (not to mention security), but now the best features are first implemented in other browsers. Google’s Chrome browser introduced multi-process tabs so that if one site runs slowly or outright crashes, it doesn’t crash the browser itself. And Apple’s Safari browser was instrumental in making HTML5 and CSS3 more mainstream.

Today we found our newest frustration with Firefox: the inability to import fonts from domains other than the domain it is used on. Apparently this is for the sake of security and to prevent unlicensed copying. Firefox provides two workarounds: host the content yourself, or have the server admin of the other domain change some setting to specifically allow your cross-domain request. However, if the fonts are licensed and are not available to host yourself, or if the fonts are stored on a 3rd party site or large content delivery network that can’t (or won’t) change its settings, you’re pretty much out of luck.

It seems to be the blog theme this month, but we here at Digital Trike are against anything that breaks the fundamental working of the web in the attempt to police or regulate it. We like Firefox and will never forget the great day when it gave web development a viable alternative to Internet Explorer, but if it doesn’t evolve and innovate again it will soon fade away as Chrome and Safari continue to develop a better browser.

What’s wrong with SOPA and PIPA01/18/2012

google protest of SOPA and PIPA

If you have been browsing the web today, chances are you came across some large internet site that is blacked out or otherwise protesting two potential pieces of legislation in the United States. There is a lot of attention being drawn to H.R.3261, the Stop Online Piracy Act, and S.968, the Protect IP Act of 2011, also known as SOPA and PIPA respectively. On the surface these bills appear to be all about stopping piracy and other acts of copyright infringement on the Internet, when actually it allows government censorship of the Internet and classifies aspects of common Internet usage as a felony.

If SOPA or PIPA or some version of these bills in their current form become law, the potential harm to how the Internet operates in the USA is staggering. First off, it allows the Attorney General to take action against any site it judges as “facilitating copyright infringement” by forcing all Internet Service Providers (ISPs) to block access to the site. Search engines like Google, Yahoo, and Bing would be forced to remove any indexed pages from offending sites, and any payment providers (credit card gateways, PayPal) would be required to cut off financial doings with the site. All this would be done without any legal requirement to notify the site owner.

wikipedia blackout in protest of SOPA

One particularly troublesome part of SOPA is that a site not need to exist solely for the purpose of piracy to be targeted. Under the language of the bill, any website that “facilitates” copyright infringement is a viable target. Any site that allows posting comments where someone could post links to copyrighted material could be considered one that facilitates piracy, not to mention one where you could post images or videos.

And it’s not just offending websites that are targeted. Under SOPA any act of copyright infringement is defined as a felony. For example, if you were to upload a video of you singing the lastest pop song to youtube and the copyright holder were to sue, you could be put in prison for a couple of years and fined thousands of dollars. Worse, you would forever be a felon and have a criminal record. All this despite the fact that you did not earn any money or even try to make money from the video.

To learn more about the specific language of the bill and the potential damage it can do, we recommend mashable’s op-ed article on the subject.

It may be that these arguments against SOPA and PIPA represent the worst-case scenarios, and that we or you may never be actually targeted if this were to become law. But if you are targeted, the provisions in SOPA have the potential to destroy your business, livelihood, or even your life, despite not engaging in actual piracy. In the end what is bad for the Internet is bad for our clients and for our business. Digital Trike and so many other Internet-related businesses only exist because of the amazing Internet that we now enjoy. The challenging, innovative, and rewarding web-based solutions that we love working on each day would be permanently stifled for fear of becoming a SOPA target. We hope you will join us in our opposition of SOPA, PIPA and any other future legislation that allows the government to censor or otherwise control the Internet.

HTML5 Application for Digital Signage12/16/2011

Digital Signage HTML5 Presentation

We recently had a client request a piece of presentation software to be used on the show room floor at an industry conference. The presentation would run on a 46” touch screen HD TV powered by a Windows 7 PC, allowing conference attendees to learn about the product in an interactive manner.

Since, here at Digital Trike, we are always looking for new challenges that allow us to experiment with new hardware and software, we were all excited about this opportunity.

Planning and Strategy

After some research, we settled on creating an HTML5 application running in a customized WebKit-based browser. This would allow us to do our development and initial testing in Mac OS X, and to utilize several wonderful open source JavaScript libraries.

Development

All of the functionality for this presentation had to be performed client side, but rather than manually creating a bunch of HTML and Javascript files with header and footer content duplicated across all files, we settled on a static site generator called Nanoc. Nanoc allowed us to write layouts and partials in HAML, stylesheets in SASS, and routing rules and filters in Ruby. When we were ready to output the static site, we simply compiled the Nanoc project to generate the HTML files.

Digital Signage HTML5 Presentation

Testing

Oddly enough, the testing process for this project proved to be the best part! We were essentially playing with a 46” touchscreen tablet. It was in the testing phase that we discovered the embedded browser we had chosen was not mature enough to be used for this project. After doing some research, we discovered that Google Chrome has a setting called kiosk mode. When Chrome is started in kiosk mode, all user controls are hidden, and the website is displayed in full screen, providing a very professional interface for our presentation.

Delivery

When all the kinks were ironed out during the testing process, it was time to package the presentation for final delivery. Since the project was made up of many different HTML, Javascript, and CSS files along with many images and the web browser itself, we needed to come up with a clean way to package the app so the end user could easily launch it with a single click. To do this, we wrote a simple batch file to launch the web browser in Kiosk mode:

"GoogleChromePortable/GoogleChromePortable.exe" --kiosk "file://%CD%/project/index.html"

Conclusion

Digital Trike is eager to work on our next digital signage project.

Web Frameworks11/29/2011

Every now and again when discussing building a new website for a client the term “custom” comes up. While we love custom and all the benefits that word implies, we’ve found that many people associate “custom” with a lot of negative things about web development. In our experience, the three most common bad things people think of when they hear “custom code” are:

1) writing a custom website from scratch is expensive
2) custom code is more prone to bugs and security issues
3) if I need a different team to work on some part of the site, there’s a good chance they will waste time learning or conforming to the custom code

At Digital Trike we’ve learned to be careful about simply throwing the word “custom” around because of the possibility of these and other negative connotations of the word. When we talk about custom, we mean that the website is completely custom to a client’s needs and wishes, not all of the code. When beginning any web project we begin with a framework. A framework is simply code that assists in rapid web development by having already written the most common functionality of any website, and providing tools for generating common code that can be further expanded according to need. In contrast to the negatives of custom code, the positives of frameworks include:

1) lots of important code is already written saving time and money
2) already written code is constantly tested and improved, leading to fewer bugs and more secure sites
3) conventions and APIs are standardized and well documented so anyone can learn it fast, in the rare case they don’t know it already

All of the frameworks that Digital Trike use are free and open source. This is great because it’s like having an additional programming team working on your project without having to pay for any of it. Our favorite frameworks include Yii for PHP, Ruby on Rails for Ruby, and Django for Python. All of these web frameworks are great for developing projects rapidly while maintaining quality. Feel free to contact us to talk about how we can support your web project.

x264 preset reference guide11/17/2011

Hi there, this is Steve again, the systems administrator for Digital Trike.  This time, I’m going to be covering a bit about video encoding.

Here at work, we do a lot with multimedia.  Most of it is working with video that our clients need on their websites, so we’ll handle those requests.  When we do, we use x264 to encode video.

One really nice thing about x264 is that the developers setup presets to make life easier for users.  The presets default to good settings that will make the video look nice.  There are nine presets in addition to the original one, and they go in both directions — lower quality to much better.

When working with multimedia, I’m pretty meticulous about my options, so I put together a reference guide for what settings each x264 preset uses.  It’s helpful for me to get an aerial view of what the subtle changes between settings are.

Most of the time, a user isn’t going to want to deviate from the presets.  Multimedia encoding is one area where flipping random bits that appear to be helpful often end up making things worse, or just as annoying, make the encode time take much longer with very little gain.  My advice would be simple: stick to the presets, then go with what looks best to you.  Keep it simple!

Gathering system statistics in Linux, part two11/08/2011

Okay, so in the first part of this two-part howto, I covered how to setup collectd to run on your system to gather system statistics.  In this part, I’m going to cover setting up a frontend called CGP which will display the collectd data as graphs.

CGP is written in PHP, so you will need a webserver already serving up PHP pages to begin with.

Instead of using a release version of CGP, I went with checking out the git repo directly just because there were some bugs that have been fixed since the 0.3 release.

On your filesystem, you can check out the git repository into a directory that will be served publicly.

git clone http://git.nethuis.nl/pub/cgp.git

This will create a directory named “cgp”.

Next, open conf/config.php with an editor.   You will need to change the first directive, $CONFIG['version'] to 5 instead of 4.  Next, change $CONFIG['datadir'] to /usr/var/lib/collectd/rrd since that is where we specified the installation location in the first part of the howto.

The rest of the configuration options are fine with the defaults, but I’ll elaborate on a few of them.

$CONFIG['cat']['category1'], if set, will show the name of the hostnames to display on the first page.  The default is commented out, and it will just show the hostname of the computer by default.  So if you wanted to change this, it would just be for cosmetics, and you would put the hostname you want to display as the first and only option of the array.  For example: $CONFIG['cat']['category1'] = array(‘dev.server.com’);

The $CONFIG['overview'] option is another array.  This one specifies which collectd stats are shown, expanded, by default.  CGP will display all the stats that it supports reading from collectd, but they will be minimized by default, with an option to expand the sections.  The ones in this array are automatically expanded, so it’s just a matter of cosmetics and preference again.

When you view any of the graph stats, it will by default, show the statistics for the last 24 hours, or 86400 seconds.  You can change the default value with the $CONFIG['time_range']['default'] variable.  Just set it in the number of seconds.

There is one gotcha that is worth mentioning.  If there is any errors generated by the code, because it can’t read some RRD files for example, then it will break the output of the graph.  Depending on your browser, you will see a broken image icon in it’s place.  If you disable error reporting, then it will fix some of the displays.  You can disable error reporting in the conf/config.php file by adding this somewhere:

ini_set(‘error_reporting’, ‘E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_WARNING’);

That’s about it.  The last thing to do is load it up in your browser, and make sure it works.

There is one additional tweak I like to throw in, and that is putting the documents for CGP outside of the webroot, and creating an alias in Apache (my webserver of choice).  The reason for doing this is that if directories that look like they don’t belong often get deleted or forgotten about when migrating.  A separate directory keeps things nicely separated.

Setting up an alias means that a URL like http://domain.com/cgp will still work, despite that there is no directory named cgp in the root public directory of documents.

In addition to that, I also like to restrict access to the stats so I can only get them from my network connection at work.  Since we get a static IP address from our Internet provider, that is easy to accomplish.    If you’re interested in doing the same, here is the syntax you would add to the Apache configuration for both features:

Alias /cgp “/var/www/cgp”
<Directory “/var/www/cgp”>
AllowOverride None
Options None
Order deny,allow
Deny from all
Allow from 1.2.3.4
</Directory>

Once you made the changes to your httpd.conf, if using Apache, you can gracefully restart it.  Then browse to http://domain.com/cgp and you should see your spiffy statistics graphs.  Enjoy!

As with the previous article, I’ll keep this one as updated as is reasonable.  Feedback is welcome.

Document version: 1.1  Last update: 2011-11-08

Gathering system statistics in Linux, part one (Gentoo and CentOS)10/21/2011

When designing a system, one of the first things I typically like to do is setup tools for monitoring.  Without proper logs and statistics about what is going on a server, when something happens, you are usually left scrambling trying to figure out two things: what was the anomaly, and what caused it.

Using system monitoring, you can quickly gauge what is a normal capacity load for a server, by seeing over time the statistics.  A server may have issues, but without knowing what is normal, you can’t really tell how out of the ordinary it is.

Enter collectd, a service that runs on Linux to gather the statistics of not only the system, but some other programs as well, such as Apache and MySQL.  The upstream developers describe what collectd does better than I could, so I’ll just let them explain it:

collectd gathers statistics about the system it is running on and stores this information. Those statistics can then be used to find current performance bottlenecks (i.e. performance analysis) and predict future system load (i.e. capacity planning). Or if you just want pretty graphs of your private server and are fed up with some homegrown solution you’re at the right place, too ;).

Usually one graph says more than a thousand words, so here’s a graph showing the CPU utilization of a system over the last 60 minutes:

 

Since you need something to display these graphs, and not just generate them, I’ll go into explaining how to use CGP, a PHP-driven website application that displays them in part two of this howto.  For now, we’ll just stick to installing and configuring collectd.

Here at Digital Trike, we use Gentoo Linux as well as CentOS Linux, so I’ll be covering how to install them on both systems.  With Gentoo, all the packages necessary for collectd are included in the portage tree, while CentOS users will have to install a few packages from source.

First of all, let’s get the package installed.

Gentoo Linux

As of this writing, collectd is marked unstable for x86 and amd64 architectures.  That’s not going to pose a problem.  Generally speaking, there are many reasons why packages remain in an unstable state in the portage tree.  They can range from having many dependencies that are also marked unstable, or it could just be that no one has ever requested them to be stabilized.  Either way, don’t let the status offset you from installing the package in this case.

You will need to keyword the packages, and with recent versions of portage (>=2.1.1.11), this is easily done with some emerge foo.  Before we do that, though, you should update your make.conf file with the plugins that you would like to install.

Collectd ships with a number of plugins.  In this scenario, I’m going to focus just on the ones that would be applicable for a LAMP stack.  Add this to your make.conf file in /etc:

COLLECTD_PLUGINS=”apache cpu curl disk dns filecount fscache logfile mysql network processes uptime users swap syslog load csv conntrack interface memory netlink rrdtool rrdcached table tcpconns unixsock vmem df protocols”

This is actually a small number of the available plugins, but it is aligned to support the ones that CGP draws graphs for.  You can always use another frontend to display the statistics, but I’m going to stick to these two applications.

Next, emerge the application.  Since it is already masked, we can unmask it automatically using portage, instead of tracking down the dependencies ourselves:

emerge –autounmask –autounmask-write “=app-admin/collectd-5.0*”

You’ll probably get some output similar to this:

The following keyword changes are necessary to proceed:
#required by =app-admin/collectd-5.0* (argument)
>=app-admin/collectd-5.0.0-r2 ~amd64
#required by app-admin/collectd-5.0.0-r2[collectd_plugins_rrdtool], required by =app-admin/collectd-5.0* (argument)
>=net-analyzer/rrdtool-1.4.5-r1 ~amd64

At this point, go ahead and run dispatch-conf, etc-update, or  your choice of program to update portage configuration files, and approve the change.  Then you can re-run the same emerge command, and portage will install the packages for you.

CentOS Linux

As I mentioned before, for CentOS, you will need to install some programs from scratch.  While that may seem a little daunting if you have never done this before, in this case, the packages necessary are easy to compile and install with minimal fuss.  You will need to be logged in as user root to install new packages.

The first step you will need to do on a the system is install the development packages so that you can compile programs from source.  In CentOS, these are packaged in two group installs.  We will also need an additional development package for libpcap.  The command to install them using yum is:

yum groupinstall ‘Development Tools’
yum groupinstall ‘Development Libraries’
yum install libpcap-devel

The yum package manager will display the packages and it’s dependencies that will be installed and confirm that you want to proceed.

Once that is done, then you only have two packages to install: rrdtool, which gathers the system stats, and collectd.

First, download rrdtool from the maintainer’s website.  As a general rule of thumb, it’s best practice to choose the latest version available, provided it is considered stable by the developers.  In this case, the latest release as of this writing is 1.4.5.  You can download it using wget easily.

# wget http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.4.5.tar.gz

Next, unpack the file, and run configure using /usr as the prefix, then just make and make install as normal.

# tar -zvxf rrdtool-1.4.5.gz
# cd rrdtool-1.4.5
# ./configure –prefix=/usr
# make
# make install

Normally, I would advocate installing external packages into /usr/local instead of /usr, but on some systems, I had difficulty using that prefix, so here I just use /usr instead.

At this point, rrdtool should be installed correctly.  You can verify that it installed by running “rrdtool –help” or “which rrdtool”.

Next, you’ll need to download collectd and install it.  The default configuration will work fine for plugins, installing a decent amount of them, so I’m not going to tinker with the configure script at all.

# wget http://collectd.org/files/collectd-5.0.0.tar.gz
# tar -zvxf collectd-5.0.0.tar.gz
# cd collectd-5.0.0
# ./configure –prefix=/usr
# make
# make install

Now that the OS-specific instructions are complete, we’re ready to move on to configuring some dependencies for collectd to run properly.

Setup up MySQL for monitoring

Since one of the nifty features of collectd is to monitor MySQL, I like to setup a separate user solely for this task.  This, of course, is optional, but it I find it a good policy to separate users with their specific privileges.

The MySQL user will need special privileges to access all the necessary data from the database server.  You can setup this user using the mysql console.

These commands will create the user, grant it’s privileges, and then reload the user access so the collectd user can start connecting:

# mysql -u root
mysql> CREATE USER ‘collectd’@'localhost’ IDENTIFIED BY ‘password’;
mysql> GRANT SELECT, PROCESS, SHOW DATABASES, SUPER ON *.* TO ‘collectd’@'localhost’;
mysql> FLUSH PRIVILEGES;

Setup Apache server-status

Apache 2.2, by default, ships with a module named mod_status which can display specific statistics about the server load that the web server is experiencing.

Gentoo Linux Apache

In Gentoo, this module is not enabled by default.  You will need to add “-D STATUS” to your file located at /etc/conf.d/apache2 and then restart the apache server.

# /etc/init.d/apache2 restart

CentOS Linux Apache

On CentOS, the module is installed by default, but you will need to enable its usage.  Edit /etc/httpd/conf/httpd.conf and uncomment the lines starting with <Location /server-status> until </Location>.  Change the “Allow from” directive from example.com to 127.0.0.1.  Restart the httpd server when finished.

# service httpd restart

You can test the installation after rebooting with curl:

$ curl http://localhost/server-status?auto

collectd: global configuration

Now that we have monitoring setup for Apache and MySQL, collectd will handle the rest.  It’s time to move on to configuring the collectd daemon.  You can find the config file in /etc/collectd.conf.

The configuration file is easy to understand, and when it comes to modules, is split into two parts: enable the module, configure the module.  Before that, though, let’s look at setting up the global configuration and the logging.

You’ll see at the top of the file the “global settings for the daemon”.  The defaults here are fine.  The only thing worth changing is the Hostname to the hostname of your box — you can run “hostname –fqdn” as any user if you’re not sure what it is.

In the next section, Logging, all I usually do is uncomment the line “LoadPlugin syslog”, since I prefer to have logging sent to the system log, which will then show up in “/var/log/messages” for both CentOS and Gentoo Linux.

collectd: plugins

Now let’s look at the plugins themselves.  Again, I’m only going to cover a small part of the ones that are available to look after a box running as a LAMP server.  You will need to uncomment each LoadPlugin line for the modules you want to run.  One thing collectd does that is really nice, is that if it the plugin was not built when you installed it, then it will be commented out with ##.  If it is available, it will only be commented out with one #.

Going down the list, these are the ones to enable, or uncomment:

Next, let’s look at setting up the plugins individually.  Again, like before, most of the default configuration is fine and won’t need any modification.  I’ll only be covering the ones that need to be setup. 

collectd plugins: apache

Documentation

Look for the line starting with <Plugin apache>.  Remember when you setup mod_status to give details about the server processes before?  This is where you’ll need that URL.  Just uncomment the URL line, and put that in there, and you’re finished with this module.

Here’s what mine looks like:

<Plugin apache>
  <Instance "local">
    URL "http://localhost/server-status?auto"
#    User "www-user"
#    Password "secret"
#    CACert "/etc/ssl/ca.crt"
  </Instance>
</Plugin>

collectd plugins: df

Documentation

This one monitors the free disk space on the system.  Just setup the Device, the MountPoint, and the FSType.  I like to set IgnoreSelected to true so that it doesn’t poll every disk.

<Plugin df>
        Device "/dev/root"
#       Device "192.168.0.2:/mnt/nfs"
        MountPoint "/"
        FSType "ext3"
        IgnoreSelected false
#       ReportByDevice false
#       ReportReserved false
#       ReportInodes false
</Plugin>

Finding the device name is pretty simple.  Just run ‘df’, and it’s most likely the first one listed.  On Gentoo, it is commonly set /dev/root.  On CentOS, it could be /dev/sda1.  On some VPS systems, it may be named something different, like /dev/vzfs for example.

collectd plugins: disk

Documentation

This is one you want to enable only if your system is the one hosting the harddrive.  In other words, in a system like a shared host or VPS, you won’t need this.

<Plugin disk>
        Disk "/^[hs]d[a-f][0-9]?$/"
        IgnoreSelected false
</Plugin>

The configuration for Disk is a regular expression.  It says that it will automatically find any device names like hda0 to hdf9, from sda0 to sdf9 and everything in between.  Chances are you can leave that alone, as that’s the normal naming scheme for Linux devices.

collectd plugins: interface

Documentation

This plugin will monitor your Ethernet devices.

<Plugin interface>
        Interface "eth0"
        IgnoreSelected false
</Plugin>

Again, on a VPS the device name may be different, such as venet0.  Run ifconfig to see what your device interface names are.

collectd plugins: mysql

Documentation

For this plugin, you can monitor as many database servers as you like, by adding one per section for <Database>.  In this scenario, I’m only monitoring the one database server running on the Linux server.  You can enable the MasterStats configuration if you like, but it is only necessary if you are running MySQL in replication.  If you don’t know what that means, then you’re not using it. :) 

<Plugin mysql>
        <Database mysql>
                Host "localhost"
                User "collectd"
                Password "Secrets of the Universe with Philo"
                Database "mysql"
                # MasterStats true
        </Database>
</Plugin>

Make sure you setup your MySQL user before, as documented earlier.  Also, find another password. :)

collectd plugin: rrdtool

Documentation

You’ll have to scroll a few pages down after mysql to find and configure this one.  The DataDir directive needs to set where the rrdtool data is stored.

<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
#       CacheTimeout 120
#       CacheFlush   900
</Plugin>

collectd plugin: vmem

Documentation

For this one, I just disable verbosity.

<Plugin vmem>
        Verbose false
</Plugin>

And that’s the last plugin I configure!  Finally. :)

Setting up collectd as a service

The last thing we’ll need to do, for setting up collectd, is to get it to run as a service.  Or in other words, make it so it starts up automatically on boot.  Then start it up.

On Gentoo, this is a simple set of commands:

# rc-update add collectd default
# /etc/init.d/collectd start

For CentOS, you need to create an init script.  I have one I use already that you can download here, that I extracted from an RPM (md5sum: 6986adbc79b647399aa3db52d48aedc7).  To install it, you need to download it, set it as executable, and then tell CentOS to load it by default.  Finally, start it up!

# wget http://dev.digitaltrike.com/~steve/blog/centos/init.d/collectd -O /etc/init.d/collectd
# chmod +x /etc/init.d/collectd
# chkconfig collectd on

You can verify it got started to the inital boot processes by running ‘ntsysv’ or something similar.

Wrap-up

Well, congratulations, you made it this far.  Collectd should be running and gathering stats for you.  To take it from here, there are lots of frontends out there that you can use to see the stats that are collected.  In my next blog post, I’ll be discussing one of these, and how to set it up: CGP or Collectd Graph Panel.

Until then, have fun. :)

I’ll continue to keep this howto updated as necessary, and is reasonable. :)

Document version: 1.0.1.  Last update: 2011-10-21