“For Scalyr, it’s about speed, scale, and simplicity in log management,” is the title of 451 Research’s recent report on Scalyr. Nancy reached out to us to discuss our product a few weeks ago. We gave her a demo and spoke a number of times in detail about Scalyr. I was excited when I saw that she had decided to write about us and I’m even more excited to share the content of that report with the greater Scalyr family.
To help get the word out about Scalyr, we’re looking for people to write honest reviews of our product on GetApp and Capterra. If you take the time to write a review on one of those sites we’ll send you a $20 gift card for either Starbucks or Amazon (please see details below).
To write a review on GetApp you need to have a LinkedIn account and be willing to sign into GetApp with it, but your review can be anonymous once posted. For Capterra you need to give your email address and the name of the company where you used the product that you are reviewing, and finished reviews will include your name and company name.
We are only looking for reviews from current Scalyr customers or Scalyr trial users who have uploaded data and spent more than two hours using Scalyr. In order to qualify for the gift cards, please send the following information to email@example.com:
- a link to the review in question
- your name and the email address you use to log into scalyr
- the email address where you’d like us to send the gift card code
We’ll take honest reviews anytime, but this particular offer of a gift card when you review us expires on February 17th, 2017. All gift cards will be issued for USD $20 from the US Starbucks or US Amazon website.
Thanks in advance!
Our new UI is now the default
We flipped the switch, and our new UI is now the default. The original UI will still be available for a while, but to access it, you’ll have to click on the settings menu (upper-right corner of the window) and choose “Flip To Classic UI”.
If there’s a reason you prefer our original UI, please let us know! We’re working hard to make this an easy transition.
The log timeline chart now includes both line and bar graphs
By popular demand, we’ve superimposed the old “events per second” line graph over the bar chart. This allows you to see fine-grained spikes and changes in message frequency. Note that the Y axis is scaled for the bar chart only.
Editor’s note: here at Scalyr, robust systems are a topic near and dear to our heart, so we were happy to have the chance to work closely with Mathias on this piece. It’s based on the two-part series “How Complex Web Systems Fail” originally published on his Production Ready mailing list.
Distributed web-based systems are inherently complex. They’re composed of many moving parts — web servers, databases, load balancers, CDNs, and many more — working together to form an intricate whole. This complexity inevitably leads to failure. Understanding how this failure happens (and how we can prevent it) is at the core of our job as operations engineers.
In his influential paper How Complex Systems Fail, Richard Cook shares 18 sharp observations on the nature of failure in complex medical systems. The nice thing about these observations is that most of them hold true for complex systems in general. Our intuitive notions of cause-and-effect, where each outage is attributable to a direct root cause, are a poor fit to the reality of modern systems.
In this post, I’ll translate Cook’s insights into the context of our beloved web systems and explore how they fail, why they fail, how you can prepare for outages, and how you can prevent similar failures from happening in the future…
One of the inevitable joys of working in DevOps is “the page” — that dreaded notification from your alerting system that something has gone terribly wrong…and you’re the lucky person who gets to fix it.
Here at Scalyr, we’ve got a few decades of collective DevOps experience and we’ve all been on the receiving end of a page. Even though we do our best to avoid being woken up, it happens.
In this post, we’re going to put some of that experience to use and show you how to handle an incident the right way. You’ll learn not only how to fix the immediate problem, but how to grow from the experience and set your team up for smooth sailing in the future.
We’ve added a lot of features to the New UI this month and we’re excited to share them with you. If you haven’t given it a try, now is a great time to join the large body of Scalyr users who have switched over.
New UI to become default on October 10th
Last year we began a ground-up rewrite of the Scalyr interface. Our goal was to preserve the speed and power that made people love Scalyr, while making it easier to learn, quicker to use, and – let’s face it – easier on the eyes.
We’ve been testing this new UI (appropriately dubbed….the New UI) over the past few months and steadily making improvements along the way. We’re now ready to jump into the deeper end of the pool:
We’ll be flipping the switch to make the New UI the default choice starting on October 10th. (Note – The original UI will still be available for a while, but you’ll have to enable it on a per-session basis.)
If there’s a reason you prefer our original UI or are hesitant to switch, please let us know! We’re working hard to make this an easy transition.
Distributions (previously known as “Histograms”) show you a breakdown of the values in a numeric field by frequency. A graph only provides basic statistics such as average or 90th percentile. Distribution view shows how the values break down in detail.
Here at Scalyr we’ve been hard at work on some major product improvements, and we’re pleased to share the fruits of those labors.
1) New UI Beta: Logs & Graphs
Last year we began a ground-up rewrite of the Scalyr interface. Our goal was to preserve the speed and power that made people love Scalyr while making it easier to learn, quicker to use, and – let’s face it – easier on the eyes.
Summary: Most server problems, once identified, can be quickly solved with a simple compensating action—for instance, rolling back the bad code you just pushed. The worst outages are those where reversing the cause doesn’t undo the effect. Fortunately, this type of issue usually generates some visible markers before developing into a crisis. In this post, I’ll talk about how you can avoid a lot of operational grief by watching for those markers.
A few years ago, we set out to rebuild server and log monitoring from the ground up. Today marks a new and exciting chapter in the story. To tell it properly, let me take you back to a simpler time: the year 2005.
I had just co-founded Writely — “The Web Word Processor!” — and usage was skyrocketing. We ran the whole thing on four leased servers in Texas. It was the clunkiest setup you’d ever seen, but there were few moving parts and it wasn’t much trouble to manage.
Within a year, we were acquired by Google, merged with a spreadsheet app, renamed “Google Docs”, and relaunched on Google infrastructure. The new system was infinitely more scalable, but quite complex. We depended on a slew of independent services: load balancing, data storage, user identity, email, spell checking, and more.
This is a post I’ve been looking forward to writing. We’re entering a new stage at Scalyr, and we’re looking for a few strong engineers — frontend, backend, and devops — to join us as we reinvent system monitoring and log analysis from the ground up, and bring Google Search levels of power and responsiveness to operations visibility.
Here’s why this matters to you: we have a small, tight team (lots of room for personal growth), traction, plenty of runway, a low-stress culture, and meaty problems to tackle. Want to be part of an awesome founding team (and draw a real salary while you’re at it)? We’re aiming high, rethinking everything from how to manage huge data sets to how engineers interact with their tools.
Sure, you’re doing fine in your current job. But if you love building and using great tools, you can do better than “fine”.
If you’d like to have a low-pressure chat about what we’re up to, check out Scalyr Careers to learn more about us, then drop me a line at firstname.lastname@example.org.