Loggly

Logs. This time it's personal

Posted 2 May, 2013 by Philip O'Toole

Here at Loggly, we know logs are special. Why are they special? Because we know the specifics of the data that makes them special to you.

Logs are different. Logs are personal. Almost all monitoring tools and platforms reach into your systems and pull out impersonal data. Data such as CPU load, free disk space, and transaction times, are often critical but is not yours. But logs allow your system to reach out in a way only your system can.

I know, as a developer, the first time I saw the code I wrote, and the systems I built, send its logs to Loggly, it was like that system had extended its reach and was now a little bit resident on the Loggly platform too. 

Many developers, when they first see their logs messages up in Loggly, feel a sense of excitement and pride. After all, they wrote each one of those messages. It's like watching the initial pulse of the system, as it comes to life.

So sign up with Loggly and send your logs to us.  Then enjoy seeing your system reach out all the while letting us do all the hard work.

At Loggly we bring life to your system... by bringing your system to life.

No Comments   |   Leave a Comment   |   Tweet

At Loggly, we're not your father's IT company

Posted 1 Apr, 2013 by dave@loggly.com in Business, Log Management, and Startup

A few days ago an editor from CIO.com asked Loggly to provide two tips on hiring/retaining engineering talent for a future article.  “Sure -- happy to help”, I replied.  I then mentally outlined how we build and keep our highly sought after development team happy (out of 24 employees 25 employees, another just signed, 22 of our hires write code).  The standard Silicon Valley startup checklist popped up:

• Competitive salary, equity packages, etc
• Open vacation, flex hours, etc
• Catered lunches, snack bars, and top-shelf beverages
• Latest-greatest technology and development environments

• Work on a product that thrives on big data for a formidable challenge ($100b market, per IDC)
• Solve a true market created big problem, that matters... and one that people pay for
• Make a difference, and be recognized for it.

"Thanks for the tips... Unfortunately, they weren't quite right for the article.
(Every IT guy I have ever known has DREADED being asked to man the booth or attend trade shows and conferences)."

• Building an old-school IT product (legacy deployment cycles aimed at non-cloud savvy companies run by stiff CIOs)
• Selling an old-school IT product (hundreds of end-users who are also our buyers sign up WEEKLY)
• Selling into the CIO and expecting our technology to be forced down (vs adopted, loved and shared)
• Looking, hiring or retaining old school ‘Dilbertized IT guy' engineering talent who hides at the mere thought of customer interaction

• The billion dollar opportunity we are solving in log management (the booth was busy!)
• The ability to hear from customers and prospects exactly what they want in a product and how they are using it (the good and the bad)
• The way they can make a difference with their efforts to improve and continually optimize the product (our customers enjoyed the face-to-face conversations)

• Software Developer
• Sales Engineer
• Director of Product Marketing

No Comments   |   Leave a Comment   |   Tweet

Use the source, Loggly

Posted 29 Mar, 2013 by Philip O'Toole in Code

Here at Loggly we make great use of open-source software to avoid remanufacturing wheels.  It allows us to employ the latest technologies to build exciting, interesting and large-scale systems quickly -- all without worrying that the building blocks will forever remain a black-box.  But working with open-source at such an accelerated pace requires its own set of skills. Here are five key lessons learned from our Engineering team -- that might help you.

1. Assume at your own risk


It's easy to assume that the project developers implemented a certain feature in a certain way, and before you know it that assumption becomes taken for granted. Without realizing it, one is building a system on that assumption. This is insidious and one needs to deliberately check the source and test the system before making any major decisions. Time is short at a small company like ours, but it'll be even shorter if you have to re-implement due to an invalid assumption.
  Also, never make customer adoption assumptions in a vacuum, the Steve Jobs effect is awesome but rare. Leverage your customer community for responsive feedback.

2. Community support


Look for tools that can help debug, deploy, and manage the technology. If the tools ecosystem is healthy, then the open-source technology is probably vibrant too. Your sysadmins will thank you too, if they don't have to build everything from scratch. And take the pulse of the community. Join the mailing lists. Do the same questions come up over and over again? And do they get answered?

3. The project's strength of vision


We at Loggly always feel better when the direction of the project aligns closely with the problems we're trying to solve. For example, ZeroMQ is a technology with a clear purpose. Problems arise when this clear direction is missing, because the items high on your list may not be high on the project maintainers' list.


4. Gambling on the "Killer Feature"


Sometimes you just have to take a gamble because of a "killer feature". ZeroMQ is a good example, a technology we chose during its early days. Data-driven experiments showed that it was an order of magnitude faster and less resource intensive than the alternatives, but it was a very young project at the time we chose it. But we chose it because of its performance, even though it it was immature -- but it did have a strong vision.


5. When there are multiple contenders, choose the one that is weak on the things you want to be strong on, and strong on the things you'd rather be weak on.


This is my favorite insight from the Loggly Engineering team -- it's comparitive advantage applied to software design. Engineering is about trade-offs. Imagine you need to choose from 2 competing technologies. One has great algorithm support, but is weaker when it comes to IO. The other technology is not as strong when it comes to algorithms, but has superb IO support. So if you're planning to design and implement novel algorithms, you're going to become strong in algorithms -- in fact you want to be strong in that area. So choose the system with the strong IO support, and focus on the algorithms yourself.



Hopefully these pointers help you when you next come to evaluating an open-source technology.  We believe it shows in the adoption of our world's most popular cloud-based log management service.

Even better, why not join us and help choose the technology for Loggly's next generation systems?

No Comments   |   Leave a Comment   |   Tweet