Founded in 2011, Scalyr was built by a team of ex-Google engineers with years of DevOps experience. We know what it's like to be on call, get an alert, and not have enough information to track down the problem. We know what it's like to juggle half a dozen balky monitoring systems in an effort to get a complete picture. We know what it's lke to scramble to respond to a crisis, casting about to find out what's wrong, and wait agonizing seconds for each new graph to load. We know what it's like to know that the information you need is in the logs somewhere, but not be able to get to it without taking time you don't have to write code you don't want to maintain.
We knew there was a better way to handle server monitoring and production analytics. It's the year 2013, amazing things are all around us. It had to be possible to get quick, easy, flexible access to monitoring data using a simple interface. But no one seemed to be building it. So... we did.
Scalyr Logs is built around a few core principles:
It all starts with the Scalyr Agent, a lightweight daemon that you install on your servers. The agent is responsible for collecting data and forwarding it to our servers. It records basic system metrics, monitors log files, and accepts data from Graphite- and OpenTSDB-compatible tools. All of this is bundled into a single data stream, buffered, and streamed over SSL to the Scalyr Logs backend. (For platforms like Heroku where installing the agent is not possible, we also support syslog.)
At the backend, parsing rules are applied to extract structured information from log messages. At the end of this process, each data item is represented as an "event" -- an arbitrary list of named attributes, with a timestamp. System metric data points, log messages, and custom data are all represented as events.
Events are then stored in a custom-built event database, where they can be accessed through a powerful query engine. The query engine is the heart of Scalyr Logs. Graphs, log search, facet analysis, dashboards, and alert evaluation are all built around the query engine. This unified design allows us to focus our energy on scaling and optimizing the query engine, delivering the flexibility, depth, and speed that are central to the product vision. Some techniques that we use to accelerate queries:
Scalyr is looking for a few no-nonsense engineers. We hire for talent, track record, and passion, not the ability to tweak your resume to match a job description. If you live and breathe code, enjoy challenges, need to feel proud of your work, and want to get in on the ground floor of something big -- contact firstname.lastname@example.org.
At Scalyr, we mean to change the face of cloud computing, one service at a time. To that end, we’re building a complete new software stack, breaking new ground in data management, scaling, reliability, manageability, performance, and user interface.
Resumes are fine, but what we’re especially looking for is something you’ve done in the past that you’re proud of. That can be a pointer to an open-source project, a technical blog, anything. Often your best work will be something you can’t share directly; in that case, just tell us about it. Regardless, please be clear about what role you played in the project, and what made your part interesting and pride-worthy. To put it another way: take the best paragraph in your resume, expand on that, and don’t worry so much about the rest.
Also please say something about your career goals and the type of role you’re interested in.
Scalyr is located on the San Francisco Peninsula. You’ll be working with a small team of world-class, passionate engineers. Our founder, Steve Newman, was the co-founder and lead engineer on Writely (which became Google Docs) and led the original development of the consistent cross-data-center replication in Google’s Megastore (http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf). Hours and work-from-home are flexible up to a point; we don’t believe in rigid rules, but do believe that face-to-face interaction is critical for a team.