This looks really polished and definitely a great idea. I can see why you chose Ruby for the scripting of the monitors, being able to evaluate that code in a predefined binding can be quite powerful, especially with the aid of helpers being pre-defined as well.
Why not a full ruby stack, or was the "live" scripting done after the initial inception?
We have always used Ruby for the scripting (we're predominately a Ruby shop so this was key for future adoption.) The very first mvp for this tool was individual Ruby scripts running against Graphite and being scheduled via cron. The first real backend scheduler was built in Scala, but for various reasons we've converted to Rails/Puma/Celluloid running in a VM using Jruby. The monitors themselves run in an MRI sandbox for security purposes.
Comments
This looks really polished and definitely a great idea. I can see why you chose Ruby for the scripting of the monitors, being able to evaluate that code in a predefined binding can be quite powerful, especially with the aid of helpers being pre-defined as well.
Why not a full ruby stack, or was the "live" scripting done after the initial inception?
We have always used Ruby for the scripting (we're predominately a Ruby shop so this was key for future adoption.) The very first mvp for this tool was individual Ruby scripts running against Graphite and being scheduled via cron. The first real backend scheduler was built in Scala, but for various reasons we've converted to Rails/Puma/Celluloid running in a VM using Jruby. The monitors themselves run in an MRI sandbox for security purposes.