We've pushed a lot of features this year at Scout. Here's a look back at what we've added to app monitoring in 2016:
One of the technical bits I learned when joining Scout was Slim, a lightweight templating engine. I was a quick convert: Slim eliminates boilerplate code while making it easy to "break away" when full HTML markup is needed.
I'm a big fan of Linters, especially when learning a new syntax/language. It's like having a soft code review before the real thing. To assist with my conversion to Slim, I created an Atom package for
linter-slim-lint provides a lightweight interface inside of Atom to the output of slim-lint's analysis.
I follow a simple rule before configuring a monitoring alert: if I receive this alert at 3am, will I act on it?
If not, it shouldn't be an alert.
Few performance-related alerts meet this criteria. For example, if our app is running 25% slower, it's not worth a hasty 3am fix, but it is worth a first-thing-in-the-morning effort.
That's the drive behind a feature we'll make available soon: The Digest Email. Available in daily or weekly editions, the Digest Email summarizes your app performance and directs you to bottlenecks with ease:
This is a guest post by Tomasz Kowal, a software developer currently working full time with Elixir at ClubCollect. He started with Erlang 6 years ago and is still amazed by the power functional languages provide. In his free time he likes tinkering with flying robots.
Have you ever reached for a drink of water, then realized, half-way through your first sip, it was Sprite? I like Sprite, but that first sip of a similar-looking, but very different liquid is a shock.
That's how Elixir can feel if you're coming from Ruby. The syntax looks similar, but Elixir is different from the first sip. For a smooth transition, you need to (a) learn some functional programming patterns and (b) unlearn some Object-Orientated habits.
A core design pattern of Elixir is the focus on data transformations: you'll see it in libraries like Ecto.Changeset, Ecto.Multi, Plug.Conn and built-ins like Enum. Let's dive in.
We're happy to introduce a lightweight addition to Scout: GitHub-enhanced deploy tracking.
Deploy tracking makes it easy to correlate deploys to your app's performance. Scout's deploy tracking goes beyond chart markers: enable our GitHub integration to see which branch or tag was deployed, the team members that contributed, and a diff summary of what changed.
Enable deploy tracking
The latest version of the
scout_apm gem tracks your deploys without additional configuration if you are running Capistrano. If you aren’t using Capistrano or deploying your app to Heroku, see our deploy tracking configuration docs.
- DelayedJob - we've added DelayedJob instrumentation, which provides the same level of detail on DelayedJob as you've come to expect on your web requests. Update to the latest agent version to enable.
- ScoutProf - looking for more insights on your traces? Try our ScoutProf beta.
- Heroku Addon - featured in last month's Heroku newsletter, the Scout Addon makes provisioning Scout on Heroku even easier.
DevTrace is a performance widget for your Rails applications in development. It sits unobtrusively in the corner of your page, just waiting to drop insight on your application:
This kind of insight is powerful. You can see how your app executes, and head off performance issues before they get to production.
But what I want to cover here is how DevTraces stays out of the way -- how it's simultaineously powerful and unassuming.
1) Installed via Gem only
2) Visually Lightweight
DevTrace shows up as a small, semi-transparent badge displaying your page load time. It's placed in the lower left corner of your page, to stay out of the way of navigational elements. Since your eyes natually move from the upper-left to the lower-right of a page, DevTrace is only there if you look for it. Finally, we added subtle animations for Ajax requests -- enough to notice, but not enough to be distracting.
3) HTML Hygene
HTML hygene (AKA staying the f* out of your markup as much as possible) is important. We know that — as a developer — you'll be inspecting your source, and don't want to see extra cruft from your performance tools.
DevTraces injects as little as possible into your page (we do have to add something though):
<style>tag, with classes carefully scoped to our namespace
- finally, for HTML pages, a JSON data structure with the trace information for the page
4) Keeping Ajax / JSON Payloads Clean
6) Development Environment Only
Profiling in development is different from profiling in production. Always-on tracing works in development, because traffic is limited to just you (the developer), and overhead is less of a concern. In contrast, production environments require a smart sampling approach (which we're perfecting in Scout APM). No need to worry about leaving DevTrace on in the wrong environment: even if you accidently configure it for production, it won't even insert its rack middleware into your application in a non-development environment.
Staying out of the Way While Giving you What you Need