Revisiting syslog-gollector

It’s been 18 months since the first commit to my first significant Go project — syslog-gollector. After an initial burst of activity to create a functional Syslog Collector that streamed to Apache Kafka, the source code hadn’t been updated much since. But today I received a report that it no longer built, so I spent some time porting the code to the latest Shopify Sarama framework.

It was amusing to see how naive much of my early Go code was.


The poor practices that stood out included:

  • Simplistic use of global variables.
  • Logging errors at low-levels in the code, instead of just returning errors and logging at the highest level possible. That way the log messages have the most context.
  • Using a non-standard logging package.  If there is one thing I learned during my time as a core developer of InfluxDB, it was to minimize use of non-standard packages. This has been fixed.
  • Excessive use of channels. I didn’t address this, but I think the code is trying to be too clever. It’s a common trap for young players.
  • Declaration of interfaces by the package exporting them. This is not the Go way — packages support interfaces implicitly. This too has been fixed.
  • Poor use of structs, and not really understanding the proper way to use the type system. Thankfully I fixed that too.
  • Lack of testing. While some code was tested, much wasn’t. And the code wasn’t constructed in a way to make testing easy.

It’s not all bad

There are some approaches I got right though. I did use an interface for objects that supported statistics and diagnostics output, and I did generally hook up the network services correctly. Command-line option parsing was also implemented in a valid manner.

Syslog-gollector remains quite basic, and was my first real Go program.  It could be improved enormously, but it served its purpose very well — it started me coding in Go.

Leave a Reply

Your email address will not be published. Required fields are marked *