NewRelic is much more comprehensive (they also have a "profiling" feature), but you rarely, if ever, find yourself needing any of the additional features. For the price, it's hard to beat Skylight. Also, we've found pganalyze to be an amazing bang for the buck.
I could never find anything actionable in NewRelic. Seems like interesting data, but nothing I could optimize for. Skylight has identified slow performing areas where we've worked on and watched a downward trend.
Come on, I love Skylight, but really! Slowest queries, slowest requests, breakdown of every hit into details how much time everything took. It gives you too much actionable data if you ask me. You can constantly optimize some slow-pokes, I have to remind myself to not optimize pages that are not most used.
Note to the Skylight marketing team: I had never heard of your service in 10 years of using Rails, even if it was something that could very valuable to me. But if I open the homepage what I see is:
"DO THE ANSWER DANCE". Cool looking weirdo characters dancing. Generic charts-filled dashboard screenshots. Comparatively very small text saying "learn why your app is slow".
If you hadn't been vouched by this HN thread, I would have never read below the fold to learn that you allow profiling Rails apps.
I see that the logs and analysis will be open to everyone. I guess that's equivalent to using Travis, CircleCI, etc. on their free/open tiers. But API logs and analysis like Skylight performs can have much more unpredictable and sensitive info in them than test/build logs.
Does this mean that all private fields needs be scrubbed in-app, before Skylight? For example, a hosted OSS service that includes e-mail addresses or location data in API query strings.
We work differently than other similar products, in that we rely heavily on aggregation, both for presenting useful data in the UI and also to keep our backend scalable. We don't keep around particular aspects of individual requests. Individual requests are essentially only used as "data points" to build statistical models about your app/endpoints. For example, any SQL queries are parsed and sanitized on your server before they are sent to us[1].
That probably sounds more involved than it actually is in practice – you can see it for yourself on the dashboards for The Odin Project[2] and the Homebrew formula browser[3]. The bottom line is that there is no way to get from the aggregated data back to an individual request.
As a further historical note that may interest HN users specifically, Skylight was the world's first production user of Rust (the Ruby gem they ship is written in it), dating back to well before Rust was even stable.
To be clear about the chronology here, wycats made the decision to go with Rust, then did a lot of work in Rust, then became a core team member. He chose Rust because of his needs in Skylight, not because he was already invested in Rust.
> Yehuda Katz will be known to many in the Rust community for his work on the initial design and implementation of the Cargo project. He is also a co-founder of Tilde, which has been using Rust commercially in their Skylight product for quite some time
For slightly more context, I wrote the first lines of Rust code for Skylight as a spike at the end of 2013, and joined the Rust core team more than a year later. :)
I was largely inspired by a blog post in June 2013 by Patrick Walton: Removing Garbage Collection From the Rust Language[1]
I split my time between Ruby, JavaScript (mostly with TypeScript) and Rust, with occasional Java and devops work. Of those, JavaScript (with TypeScript) is my predominant language at the moment, but the mix changes pretty often.
Skylight's stack is Rust and Ruby for the agent, Rails for the backend, Java for our data processing pipeline (essentially a custom data store) and Ember for virtually the entire front end. The graphs in Skylight are Ember components written in d3.
I still think that Rails is a great choice for most web apps, since (to this day) it provides an extremely productive baseline for building account management and working with third-party integrations, which turn out to be a surprising percentage of the total code (and an even higher percentage of backend code changes) in even an ambitious project like Skylight.
I also think it's reasonable to use something like Java or Rust for any heavy data-crunching your app might do, but I think people over-estimate which aspects of their application are truly performance and efficiency critical.
Interesting. I see, thanks. From your list Ember stands out, was not expecting that. Rails and Ember integration looks painful? Maybe using Rails 5 and API mode is the way to go.
[0] https://www.rust-lang.org/pdfs/Rust-Tilde-Whitepaper.pdf