Ruin The assorted ramblings of Brendan Tobolaski

Parsing Nginx logs with logstash

There happens to be a great many descriptions of how to do this particular thing readily available with just a search but, all of the ones that I was able to find left me wanting. Depending on the systemʼs use, we use either Nginx or Haproxy. Haproxy has a number of great grok templates already but, a similar thing does not exist for Nginx. Given that we use both, it was important to parse the logs in the same way so that the information can be queried using the same syntax. It is surprisingly easy to do.

The first thing that you will need to do is add a custom Nginx log format and set your access log to use the custom format:

http {

  log_format logstash '$http_host $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time';
  access_log /var/log/nginx/access.log logstash;


Only the log_format portion needs to occur in the http{...} block. You can specify the access_log option in each server{...} block but, using this setup will capture access logs for all of the virtual hosts.

Now youʼll also need to modify your logstash configuration:

filter {

  grok {
    type => "nginx-access"
    match => [
      "message", "%{IPORHOST:http_host} %{IPORHOST:client_ip} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:http_verb} %{NOTSPACE:http_request}(?: HTTP/%{NUMBER:http_version})?|%{DATA:raw_http_request})\" %{NUMBER:http_status_code} (?:%{NUMBER:bytes_read}|-) %{QS:referrer} %{QS:agent} %{NUMBER:time_duration:float} %{NUMBER:time_backend_response:float}",
      "message", "%{IPORHOST:http_host} %{IPORHOST:client_ip} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:http_verb} %{NOTSPACE:http_request}(?: HTTP/%{NUMBER:http_version})?|%{DATA:raw_http_request})\" %{NUMBER:http_status_code} (?:%{NUMBER:bytes_read}|-) %{QS:referrer} %{QS:agent} %{NUMBER:time_duration:float}"


After modifying your logstash configuration, youʼll need to restart logstash. Now all you need to do is ship your Nginx access logs to your logstash server using the type nginx-access, I recommend using logstash-forwarder to do this. Once you start shipping them, youʼll see that they are parsed using the same variable names as the Haproxy grok templates so that youʼll be able to query accross both your haproxy and your nginx logs using the same queries.

Logging to Syslog from Play

If youʼre a Java developer, this is probably very obvious but, I had a very hard time figguring out how to do this. This probably has a lot to do with the difficulty of finding information about current versions of various products. We happen to be using Play 2.2.x and this is how you can do it.

  <appender name="SYSLOG" class="">
    <suffixPattern>: %logger{20} %message%n</suffixPattern>

  <logger name="play" level="INFO" />
  <logger name="application" level="INFO" />

  <root level="ERROR">
    <appender-ref ref="SYSLOG" />

Replace `` with the name of your app and then save it as conf/logger.xml and then run your app and it will log to the specified server. Note that this requires that you have syslog server listening over http. Logstashʼs syslog input works great for this.

iPhone 6+

The iphone 6+

I ordered the iPhone 6+ as I said that I would. I received it on launch day so, Iʼve had it for nearly two weeks. Itʼs a great upgrade and I have some thoughts on the changes.


I donʼt know how Apple does it but, every generation of iPhone design is a huge leap forward. Well maybe not the Original to 3G but, that was before I started using an iPhone. Yet again, I find this yearʼs design to be the best one yet. It is far more comfortable to hold than either of the previous two design. The rounded edges feel wonderful in your hands. The way that the curves to join the aluminum backplate is extraordinary. It has only the faintest of seams between the glass and the back. Itʼs barely detectable when you run your fingers over it.

The design is not without its sore spots though. The most widely criticized one of which is the camera bump. While you are using it, it is hardly noticeable as it is unlikely that you will have your fingers near it, due to the shear size of the iPhone 6+. If you do happen to run your fingers by that area, itʼs immediately noticeable. It is the only protrusion from the nearly smooth surface and it sticks out as a sore spot. However, you are only likely to notice it when you look at the phone from the back or when setting it down onto a flat surface. Iʼm not sure what Apple could have done. It seems like the obvious solution is to simply make the whole phone the thickness of the camera lump and to fill that extra volume with battery. Of course, that does sound appealing in the abstract but, I think it would have resulted in a much worse phone. That additional battery would have added significant weight. The 6+ is already quite hefty and the additional weight might have put it into an uncomfortable territory. The other option would have been to shrink the camera. That would have been really bad since it would have greatly decreased the image quality and that would have been a much worse compromise to make.

The other complaint has to do with the plastic separators. Obviously, Apple needed to include some plastic in order for the antennas to get adequate signal. I donʼt like the way that they chose to do them. I feel like the color that they chose is intended to hide them which, it does very poorly. I wish that they would have owned the plastic separators and made them a contrasting color. Perhaps the glossy black that they used in between the parts of the case on the 5s.


The 6+ʼs screen is gorgeous. It has a 1080x1920 which is probably the same as your television (“Full HD”) in a 5.5″ display. That is simply insane. Iʼm fully aware that this is neither the first smartphone with 1080x1920 px display nor is it the most pixel dense display. Its likely overkill to have such a dense display. No matter how closely I look at it, Iʼm completely unable to see the pixels. Even at this pixel density, its not quite enough for going @3x density. Apple renders everything at 1242×2208 and then scales it down to fit the 1080x1920 display. This is the same process that they use with the Retina MacBook Pros and as with the MacBook Pros, it seems completely undetectable. Iʼm sure that it would look slightly sharper if it was rendered at the native resolution but, as it stands, it is by far the best display that I have ever seen.

Once again, Apple has moved the screen closer to the glass. Itʼs just barely noticeable. It makes the screen look a bit better when not viewing it straight on. It is a very minor improvement but one that was worthwhile to make.


Brains are very strange. After less than a day of using the 6+, I picked up my iPhone 5s and it felt like a toy. I turned it on and started using it. I no longer understood how I was able to use a device with such a miniscule display. It no longer capable of doing useful things. I wondered how I was able to work with the even smaller 3.5″ of the previous models.

The 5s in my hand

Choosing to get the 6+ is not without its compromises. It is very unlikely that you will be able to use it one-handed. Iʼm able to reach a surprising proportion of the the display. Much of it is uncomfortable, though. It is also considerably heavier than the 5s. It feels a little too heavy for comfortable one-handed use. When using it with one hand, it put quite a bit of pressure on my pinky. Even with this slight discomfort, this is my preferred way of holding it while reading.


It was a poor choice by Apple to leave developers in the dark until a week before the new iPhone sizes were available. Despite Appleʼs assurances, scaled up apps look awful, they look comically large. Text based apps look really bad. We have this new, awesome, large screen but, you canʼt see any additional information. Itʼs just silly.

Of course, once apps have been updated they are able to utilize the greatly increased area and they look great. I really appreciate the developers that have managed to get their updates out. Many of the developers that you would expect to have gotten their apps updated for the new screen sizes have but, some notable ones havenʼt yet gotten them updated. Most of the apps that I use every day have already been updated but, most of the rest of the apps havenʼt yet. It creates a rather annoyingly inconsistent experience. The apps that have been updated look great but, the apps that havenʼt been updated yet look awful.


This is a comparison from the 3 cameras that I had readily available, the iPhone 6+, the Nikon D60 and the Nikon D7100. The image links to a much higher quality version. I tried to pick images that were similar but, there are clear differences between the photos. What is really remarkable is how little difference there is once you normalize the image size. Of course, this is in nearly perfect lighting. When you get into less than ideal lighting, much larger differences start to emerge.

When I set out to do this comparison, I was expecting the iPhone to be completely blown away by even the 2008 era D60. It turns out that very much isnʼt the case. I think I would have a hard time picking out which is the iPhone photo if, I didnʼt already know. The order is D60, D7100 and then the iPhone 6+ from left to right. The biggest giveaway, for me, is the color. The two dslr photos are considerably more color accurate. The iPhone photo is by far my favorite though. It is a much better composition than the others but the others were the closest ones that I could find.

In well lit photos, the iPhone 6+ takes fantastic photos. I could see it being most peopleʼs only camera. It looks that good to me. Of course, for many people, this has long been the case. Back in 2011, the iPhone 4 became the most popular camera on Flickr and that process has hardly halted in the intervening years. Luckily, Apple clearly realizes that many people use their iPhone as their only camera. Each generation Apple has relentlessly pushed the image quality forward. This generation happens to be a monumental update. This generation adds Phase detection autofocus and Optical Image stabilization. Both of these are usually only found on higher end dedicated cameras and are very welcome additions.

Closing thoughts

The 6+ is another great update to the iPhone line. Iʼm glad that Apple has gone back to a curved back. While the sharp corners on the previous two body designs have looked great, they did not feel very good in use. The rounded edges feel great in my hand. The way that glass blends into the case looks and feels amazing. In my eyes, this is the best update to the iPhone yet. The new screen size is great. I donʼt think I could ever go back to even the 4.7″ iPhone 6. This feels like the size screen that an iOs device should have and it is the perfect pocket computer.

Ghost, again

Some of you may have noticed immediately but, Iʼve switched back to using Ghost. I really really like Jekyll. Its really great, except for doing the main thing that a blog is for, Writing. This is the writing workflow for working with Jekyll:

  1. write post
  2. name post
  3. edit post
  4. move and rename post
  5. fill in the date
  6. tag the post
  7. generate preview
  8. commit the post
  9. build the site
  10. deploy the site

Where as with Ghost, its more like this:

  1. Name the post
  2. write the post
  3. tag the post
  4. edit the post
  5. publish the post

On top of that, I can do all of these steps on any device that has a web browser with Ghost. With Jekyll, I need a Mac for #4 and the last 4 steps. Additionaly, the preview and the build both take ~15 seconds. Not exactly long but, it is long enough to be annoying. I havenʼt been writing here as much as I would like. Obviously its not my blog setupʼs fault but, it is a contributing factor.

I could reduce the number of steps from Jekyll but, only to the level Ghost. It would require significant work. The first simplifications would be easy, I could set up a script to automatically build and deploy the site on commit. That is the easy part though. The next few steps are considerably harder. It involves writing a good web interface for Jekyll. While that does appeal to me in some ways, I realize that Iʼm never going to have time to write a really good web interface.

None of that is to say that I donʼt like Jekyll. Its really really great. Its really good at all of the things that arenʼt writing. It has easily the best theming system. It also supports things like Sass and Coffeescript. It is also extremely easy to deploy. It can be deployed to any web host. It should always perform well as serving static files is very efficient. Its also extremely flexible and it will allow you to do things that things that wouldnʼt. It also has various plugins that add some pretty cool things. One of these makes picture tags. Of course, the bigest benefit of Jekyll is itʼs plain text format. Its easily the best format for blog posts that Iʼve ever run accross.

I miss it already. In fact, I wasnʼt even sure that I was going to be making the switch. I switched back and forth over the weekend. Iʼm very attracted to the plain text format that Jekyll uses. I also like the other tools that it gives me, such as Sass. Iʼm also able to use picture tags which, are awesome. Of course, you need to polyfill it, for now. But, Iʼm giving that all up for the very reason that blogs exist, for writing. That is the most important thing for a blog. Iʼve chosen to optimize for writing above everything else.

Stagnate Blogging Tools

10. The tools for blogging have been extraordinarily stagnant. One of the reasons the art form of blogging isn’t particularly respected lately is because the tools essentially stopped evolving a decade ago. The experience of writing, for most people, isn’t even substantially different than it was when I started 15 years ago, despite the rise of the social web and mobile apps taking over during that timeframe. This matters because tools deeply influence content. And this stagnation is particularly egregious when we consider that almost every common behavior on the big social networks is a subset of what we originally thought blogging might be. — 15 Lessons From 15 Years Of Blogging By Anil Dash

Iʼm going to violate Anilʼs 9th lesson to discuss this point. It is something that Iʼm keenly aware of. I havenʼt found a great way to blog yet. Iʼm currently using Ghost. It shows much promise. It may turn into a really great tool eventually but, right now it is a little bit raw. Theyʼve been making great strides with every release but, itʼs still very light on features. Iʼm not sure that it will turn into the tool that Iʼm looking for.

Bigger iPhones

The “right size” principle was disproven. We were wrong.</ Tomorrow, Apple is extremely likely to launch this yearʼs new iPhone in 4.7- and 5.5-inch screen sizes, blowing away even more of our previous assumptions and theories, and we can’t wait to get these bigger phones. (Well, most of us.) &mdash Marco Arment</figcaption>

I joined both Marco and John Gruber in thinking that 3.5″ was the perfect size for a phone. Previous to getting my iPhone 4, I had a couple of Android phones. I started with Motorola Droid. At that time, I didnʼt have much of a choice of phones. I could have either gotten a Blackberry or a Droid. When I went to upgrade, there were a few different options but, I went with the HTC Droid Incredible. I had a few different options but, I went with the Droid Incredible because it had a rather small screen size. Following that, I got an iPhone 4.

When I got the iPhone 4, I thought it was the perfect phone. The size felt great. I couldnʼt imagine how a bigger phone could be better. Of course, 2 years later Apple introduced the 5 with its larger screen, lighter weight and also the smaller volume. The last 2 parts of that are extremely important. An iPhone 4 resized to 4″ would have been awful. Both the thickness and the heft of it would have made it uncomfortable to use. Of course Apple didnʼt do that.

Now, itʼs expected that Apple will be announcing both a 4.7″ and a 5.5″ iPhone. This time around, Iʼm fully ready for the increase. Assuming that Apple does as expected, Iʼm planning on getting the 5.5″ iPhone. I now realized that there are 3 things that a much larger iPhone would be worse at: actually using it as a phone, using it one handed, and pocket-ability. I so rarely do either of the first two things that the benefits far out-weigh the downsides.

I almost never use my iPad anymore. I do miss the larger screen of the iPad fairly often but, itʼs a pain to drag the iPad around with me as well as the iPhone. What I really want is a device with a larger screen that I always have with me. That is what we will be getting. Iʼm excited.

godoc with homebrew installed Go

This is basically the same information as you would get if you RTFM1. When you install Go from Homebrew, it doesnʼt include godoc which, is pretty annoying. The smart thing to do here would be to RTFM but, I didnʼt. Iʼm guessing that a bunch of other people wont as well. You can Google for the problem but, it doesnʼt immediately come up with a solution for the problem. So lets get back to that RTFM thing again.

➜  ruin-jekyll git:(master) ✗ brew info go
go: stable 1.3.1 (bottled), HEAD
/usr/local/Cellar/go/1.3.1 (4343 files, 135M) *
  Poured from bottle
==> Options
        Build the cross-compilers and runtime support for all supported platforms
        Build the cross-compilers and runtime support for darwin, linux and windows
        Build without cgo
        install HEAD version
==> Caveats
As of go 1.2, a valid GOPATH is required to use the `go get` command:

`go vet` and `go doc` are now part of the sub repo:

To get `go vet` and `go doc` run:
  go get
  go get

You may wish to add the GOROOT-based install location to your PATH:
  export PATH=$PATH:/usr/local/opt/go/libexec/bin

Bash completion has been installed to:

zsh completion has been installed to:

So, to install godoc, set your $GOPATH and then run go get Seems pretty simple right? Except, were is godoc? It isnʼt at $GOTPATH/bin. Turns out that it gets installed into goroot. Youʼll also need to add /usr/local/opt/go/libexec/bin to your path. So, the 3 steps that need to be completed are:

  1. Make sure that your $GOPATH is set already
  2. run go get
  3. add export PATH=$PATH:/usr/local/opt/go/libexec/bin somewhere in your dot files.
  1. Read the Fucking Manual, for those of you that donʼt know. 

Ben Brooks' Redesign

Ben Brooks launched his newest redesign today. I think it looks great but, thats only part of the story. What really resonates with me is the reasoning behind it. To start off with the most unconventional,

No matter what I tried, or designed, a long lists of full-length articles is a pain in the ass to scroll through. Not only that, but most people will stop after the first or second article if they aren’t of interest to them at that point — and then you have lost a potential reader.
Ben Brooks

Iʼve felt this way for a long time. I donʼt really like coming across sites that use the standard blog layout with full articles on the front and each subsequent page. When I come across a new site, I usually read whatever it was that I came to the site for. Then, Iʼll usually check out the home page. I donʼt remember ever stopping and reading all of the posts on the front page. Its just not a reasonable thing to do. If I did that, then I would never have time to do anything else. Instead, what I do is skim through their recent posts to see if Iʼm interested in the general content of the site. This process is fairly annoying with the full text of each post on the home page. It requires a great deal of scrolling and I donʼt think that it is actually benefitting anyone.

In past redesigns of this site and previous sites, Iʼve always stuck with the standard blog layout (except for a brief period of time where I was using the default Ghost theme). For a long time, I thought that it was because of Matt Gemmellʼs piece on blog design. Turns out that he never states that. Its a great piece. I agree with almost everything he says in it. That was never the full reason why I chose to put full text posts on the home page. Every time that Iʼve done a redesign, I take a look at the home pages of my favorite sites. Every time they have been overwhelmingly dominated by full text posts on the front page.

I donʼt remember where I first heard this but, it seems the general consensus is that not having full posts on the home page is greedy. That those writers that choose not to include the full posts are only looking to drive up their page views. I donʼt think that is the case. It is a much better experience for everyone. Its certainly not the case that Iʼm trying to drive up page views for advertising nor is it the case for Ben Brooks. Neither of us have any advertising on our sites.

There is one thing that I think you need to pull this off. Your site needs to be fast. If loading each page takes a couple of seconds then, its a worse experience. Potential new readers will also likely be put off by the amount of time that it takes to browse through your site. That being said, I think I have a pretty fast site. I will be switching around my layout to not include full posts on the front page.

The other major deviation from the standard blog format Ben Brooks makes is:

So linked list posts and quote posts are not on the homepage, as I don’t think it is the place for them. I am proud of the articles I write, and they are my “best foot” — so why wouldn’t I want to show them off first and foremost on the site? And because I had no good answer to that, gone are the links and quotes from the main page. (You can get to them on their own pages now, or via the RSS feed which is still full content.)
Ben Brooks

This makes a great deal of sense to me as well. When I come across a new site, I donʼt really care about their link list type posts. It just obscures the real meat of their site. Once I start following a site, I like to see the link list type stuff. I come across quite a bit of really great stuff this way but, it is very distracting when looking at a new site. This is, again, something that Iʼm going to implement for this site. This is a bit ironic, as you likely came across this post from my home page but, I feel like Iʼve contributed enough of my own thoughts to make this a “full” post. Implementing this may take some work on my part. Iʼm not entirely sure on how to make this happen using Jekyll.

If you have your own site, I hope you take three things away with you. Read both Ben Brooksʼ piece on the new design of his site and Matt Gemellʼs piece on designing blogs for readers, they are excellent. The final point is one that Iʼm still working on; stop caring so much what other people think. Your website is for you first and your readers second. If you think that your site needs something then try it out. Maybe its a bad idea or maybe no one else is doing it because of some misplaced sense of conformity. Iʼm still working on that.

Ansible: Using item in templates

This may seem obvious to some people but, I just stumbled upon this last week, in Ansible, you can use the item variable from a loop, inside of a template. I guess that should be obvious from all the variables being available in the template but, it just never occurred to me that this was something that could be done.

I figured this out while I was attempting to set up our custom services. We have a number of them but, the actual service scripts donʼt vary greatly. It is usually just a single word difference and it didnʼt make sense to create a custom template for each one. So, here is what I did in the template:

description "{{item}}"

console output

start on runlevel [2345]
stop on runlevel [016]

respawn limit 99 5

setuid app
setgid app

end script

This is what I did inside of the role:

- name: Add the service scripts
  template: src=service.j2
    - service1
    - service2

Of course, even if the commands werenʼt the same, it would still be useful to set it up this way. Typically, init scripts contain quite a bit of boilerplate. Here is a more generalized solution, allowing you to reuse the template even with completely different commands:

description ""

console output

start on runlevel [2345]
stop on runlevel [016]

respawn limit 99 5

setuid app
setgid app

end script

with the role containing:

- name: Add the service scripts
  template: src=service.j2
    - {name: service1, command: "/usr/local/bin/service1"}
    - {name: service2, command: "java -jar /usr/local/service2/start.jar"}

You could extend that with anything that you might need to vary between the scripts. For example, you could add a user value to allow the services to run as different users.

I found this to be completely non-obvious when I started out with Ansible. Now, it seems completely obvious that it is possible to do this. Hopefully, youʼll find this to be useful as well.


Iʼve been using the Bellroy Slim Sleeve but it was starting to look a little worse for wear. The multiple trips through the washing machine definitely didnʼt help. At one point in time, I filled it with too many cards which, caused it to stretch. Picking the glossy black finish wasnʼt a great idea. It doesnʼt look great once it starts to wear. So, I decided that I needed to make a change.

I was looking for something rather specific. I wanted it to be smaller than the Bellroy Slim Sleeve, preferrably much smaller. I also didnʼt want it to be leather due to the wearing issues that I had with my Slim Sleeve. Only seldomly do I carry cash, so that wasnʼt a huge priority. What I decided on, after a great deal of research, was the Supr.

The Supr is one of a great many slim wallets that have appeared in the last few years. It features an extremely simple design, its just an elastic band with an opening for cards. This is what drew me to it.

The Supr is extremely small. Its just an elastic loop with the bottom sealed. you are then able to slip cards into the open side. it can fit quite a large number of cards and it stays slim even with a rather large number of cards in it. You can even slip in a number of folded bills if grips the cards very tightly so you dont need to worry about them falling out. another benefit is that is is fairly inexpensive.

The supr empty

Its not without its flaws. its just an elastic loop with everything that entails. its the reason for the thinness but it also feels fairly crappy. it starts out looking fine but over time it starts to look a little bit gross. it starts to look more like an elastic band over time. Getting cards out of it isnʼt convient. If its the front or back card then, you can just slide those cards out. If its anything else, then you need to take all of the cards out in order to get to the one that you are looking for.

The supr open

That is all just the way that I justify not liking it. The real reason that I donʼt like it is that I donʼt like pulling it out. It feels crappy and it looks crappy. I donʼt like that feeling. That goes back to the original reason that I was looking for a new wallet, I wanted something that I liked, not just something that was practical.

Iʼve replaced it already. I spent a month and a half with the Supr but, its not my kind of wallet. It might work for you if you are looking for something that values size over everything else. Other than that, I canʼt think of a reason to recommend it. Even though it is quite inexpensive, it feels cheaper than its price tag. Its a crappy experience.