21–30 of 34 posts
If you're building a Rails app, you should be using Skylight. It gives you: 1. What's slow. 2. What's hit frequently. This combined gives their "agony" ranking for you to fix problems that impact the most. In a very clean UI! Terrific product. I wish I had Skylight for my Phoenix/Elixir stack.
Do you find it significantly better than NewRelic?
Has anyone used New Relic and switched to Skylight or vice versa? Been looking for some comparisons [1]. [1]: https://twitter.com/sunnyrjuneja/status/951973556170215424
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.
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.
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…
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.
[1] https://www.skylight.io/support/faqs#security
[2] https://oss.skylight.io/app/applications/g0gJSNnzYAws/recent...
[3] https://oss.skylight.io/app/applications/jut3BrkJo722/recent...
Earlier quoted context omitted.
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] [1]: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
Do you code in Ruby any more or is it all Rust these days? If you had to build a web app what would you use?
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.
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…
The short answer is no. 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 s…
If you're building a Rails app, you should be using Skylight. It gives you: 1. What's slow. 2. What's hit frequently. This combined gives their "agony" ranking for you to fix problems that impact the most. In a very clean UI! Terrific product. I wish I had Skylight for my Phoenix/Elixir stack.
Do you find it significantly better than NewRelic?
If you're building a Rails app, you should be using Skylight. It gives you: 1. What's slow. 2. What's hit frequently. This combined gives their "agony" ranking for you to fix problems that impact the most. In a very clean UI! Terrific product. I wish I had Skylight for my Phoenix/Elixir stack.
It also supports, profiling background jobs.
"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.
If you're building a Rails app, you should be using Skylight. It gives you: 1. What's slow. 2. What's hit frequently. This combined gives their "agony" ranking for you to fix problems that impact the most. In a very clean UI! Terrific product. I wish I had Skylight for my Phoenix/Elixir stack.
https://www.appsignal.com has a great product, and works for Elixir / Phoenix too. It also supports, profiling background jobs.