At transloadit we use HAProxy "The Reliable, High Performance TCP/HTTP Load Balancer" so that we can offer different services on 1 port. For instance, depending on the hostname, a requests to port 80 can be routed to either nodejs (in case of api.transloadit.com), or nginx (in case of www.transloadit.com).
HAProxy has been good to us and setting it up was a breeze. But getting HAProxy to log on Ubuntu Lucid was harder than I thought. All of the tutorials I found either didn't cover logging, or had deprecated information on it.
Google suddenly stopped being my friend.

HAProxy wants to log

For performance & maintenance reasons HAProxy doesn't log directly to files. Instead it wants to log against a syslog server. This is a separate Linux daemon that most servers are equiped with already, but HAProxy requires it to listen on UDP port 514, and usually that's not enabled.

A syslog server:

• receives log entries
• decides what's interesting
• writes it to disk in a highly optimized way

these aspect can all be configured by you.

If we look at the top of your current /etc/haproxy/haproxy.cfg file, we may find something like:

global
        maxconn         10000
        ulimit-n        65536
        log             127.0.0.1       local0
        log             127.0.0.1       local1 notice

As you can see 127.0.0.1 is where it will try to find a syslog server to log to. On Unbuntu Lucid the default syslog daemon is rsyslogd, so let's make it accept HAProxy log entries.

rsyslogd welcomes HAProxy

Most google hits I found on logging with HAProxy told me to change the /etc/default/rsyslog file, but that's completely ignored with the new upstart system. And even if you make it adhere the defaults file (yep, I tried), it will make rsyslogd go down in compatibility mode. Which is not only a shame, but also unnecessary as it turns out.

Using these config lines:

$ModLoad imudp
$UDPServerRun 514

rsyslogd will open up it's UDP port.

Where to put these lines you say? Well, if HAProxy is the only service you need the UDP syslog port for, you could put/uncomment the lot in just one /etc/rsyslog.d/haproxy.conf file:

# .. otherwise consider putting these two in /etc/rsyslog.conf instead:
$ModLoad imudp
$UDPServerRun 514

# ..and in any case, put these two in /etc/rsyslog.d/haproxy.conf:
local0.* -/var/log/haproxy_0.log
local1.* -/var/log/haproxy_1.log

Now do a quick:

restart rsyslog

And you're done. Check for HAProxy logs in:

tail -f /var/log/haproxy*.log

And don't forget to tweak the debug level in /etc/haproxy/haproxy.cfg.

Happy logging!

--kvz

We are happy to let you know that we have open-sourced our jQuery plugin on Github.

transloadit/jquery-sdk

While doing that, we also added a very cool new feature: events for uploads and results. This means you can now give the jQuery plugin an onUpload or onResult callback, and it will let you know about your file uploads in realtime! A demo will be online soon!

We are now also compiling the plugin using the google closure compiler, you might get a kick out of our Makefile.

To use the new plugin version, make source you include it from assets.transloadit.com.

--fg

You wanted it, you got it. We are happy to present to you:

Feel It - our free plan including 1 GB usage!

While your wallet remains entirely untouched with this plan, we do require a little love in return, namely embedding our badge.

--fg

We have been hard at work this weekend, and one of the first things to come out of it is our shiny new Transloadit iPhone SDK:

The SDK contains a simple example project, as well as a stand-alone TransloaditRequest class you can use in your apps. Images are handled just as well as videos, and the project also uses threading to make sure your users have a great experience with no UI freezes.

A huge thanks goes to Ben Copsey for creating the fantastic ASIHttpRequest library we are using.

The iPhone SDK is the first one we are releasing, because it is the most challenging to roll yourself. Full featured examples for PHP and Ruby will show up in our Github account next.

--fg

Today we are thrilled to announce the commercial availability of transloadit.com.

If you have a web (or mobile) application that needs file uploading you should consider integrating transloadit. Transloadit will handle the upload process, resizing of images, encoding of videos, and final storage of your content on Amazon S3 for you.

Our plans start at $19 / month which includes 3.5 GB of usage. This is enough for ~72 video encodings or ~717 image resizes per month.

This project has been almost two years in the making, with over 150 people participating in testing various versions. The version we are shipping now has already executed 55.000 internal jobs, each spawning 2-5 command line scripts on our servers.

We are also one of the first commercial software / infrastructure as a service product built on node.js. After experimenting with various technologies, we found it to be the perfect fit for our uploading and processing requirements.

Another thing we are very proud of is the ~95% of test coverage of the service's code base. We have an extensive suite of unit, integration and system tests that have already proven incredibly reliable for detecting problems, be it in our code, or changes to our stack.

If you are a long time reader of this blog, we would feel incredibly grateful if you would spread the word about our service to your boss, co-workers and geek-friends.

Otherwise we would be very happy to hear as much feedback, ideas and questions as you can come up with!

--fg

PS: I also want to use this opportunity to thank my co-founders Tim and Kevin for being the best partners in this business I can imagine. I love you guys.

Exciting news, we have overcome our earlier setback and are now headed for launching on:

Tuesday, July 13

What's new? Well, everything. We rewrote the entire system. As you know, rewriting can be a very nerve-wrecking experience, but we did not compromise on the quality goals we set:

• Every single line of code in api2 has a unit test
• Every major component has an integration test
• There is a suite of 25 system tests

This has turned out to be the best decision we have ever made. A client of ours has been using the new system since June 8, and it has been rock-solid from day one. At this point transloadit is processing around 100 uploads a day with over 30,000 internal jobs spawned so far. We couldn't be happier.

What does this mean for you? Well, you can already start experimenting with the new version today. We have updated our documentation, and all the functionality is in place. At this point we are mostly working on the payment system and additional reporting tools.

On July 13, we will announce our official pricing.

Thanks to everybody who has helped with testing and provided their feedback!

--fg

A few weeks ago, the team gathered into one of those tiny Skype conference windows to discuss an important question: Should we launch the current transloadit version?

The problems we faced at this point were, ordered by importance:

• We were stuck on node v0.1.28
• We had very few unit tests
• The system had some weak spots in the design

However, at the same time we knew the system was capable of amazing things. Some of our alpha testers are using it to upload large videos and produce up to 32 result files from them (watermarks and different thumb sizes) which are then uploaded to S3. That's 100++ internal jobs we're spawning and managing in harmony, all thanks to the awesomeness of node.

So we decided to go ahead and launch at the upcoming JSConf. Up until last week we worked furiously to deliver on that goal. We integrated credit card payments into the website, came up with a great plan & pricing model, and put tons of hours into squeezing the last bugs from the system.

And then - Bytes hit the fan.

We had noticed our node server dying every ~1-2 weeks, but we attributed that to something we screwed up and didn't think it would become a huge issue. Well, eventually it did. While testing some of the more intense assemblies mentioned before, we noticed the server dying more frequently. It turns out the old version we are on has some bad issues in the networking code, and the last thing one sees is:

(evcom) recv() Success

And then the server dies. No segfault, no details.

Ouch, 1 year of hard after-hour work going up in flames. Now we could try to put some massive effort into tracking this bug down, maybe even fixing it. But the fact is, that this would be fixing the wrong problem.

The real problem is that we are on an old node version. And the reason for that is that we didn't go by the words of uncle bob:

"Professionalism - did the doctor wash their hands, did you write your tests?"

If we had a good test coverage for our code, upgrading node would not be a big problem. Refactoring some of the design issues within the application, it would not be a big problem.

So we're doing what we should have done from the beginning, rewriting our old version into a new, fully tested one build against the upcoming node 0.2.0. This will take some time, but we can re-use a lot of hard trial-error work we learned from version 1.

We thank everybody who has tested version 1, and we're looking forward to keeping you updated on version 2.

-- fg

PS : It turns out I couldn't make it to JSConf after all due to the volcano. We'll take that as a sign : ).

As we're getting closer to the launch, we are making a few last changes to the API to make it more consistent.

One of this changes is to rename the "/s3/upload" and "/sftp/upload" robot to "/s3/store" and "/sftp/store" respectively.

This is because the term 'upload' overlaps with our vocabulary to describe file uploads into the system.

For now, the old aliases will still continue to work, but you should try to update to the new names right away. We will remove the aliases within a few weeks.

--fg

As we are ramping up our efforts to launch Transloadit commercially, we created this blog to make announcements, and to share some of the things we learned while building the service.

So welcome to the blog and stay tuned for interesting posts to pop up!

--fg