Mostro

Mostro was an infrastructure monitoring service that brought usability and ease of setup to a world of complex, often critical problems. From 2014 to 2015, I was leading its development team.

Users could get a server fully monitored within seconds, with actionable insights for services such as MySQL, PostgreSQL, Memcache etc. out of the box, and hundreds of checks and triggers already configured with sensible defaults.

The shell-based agent was secure, open-source, lightweight and extensible, while the text-based, server-side configuration allowed for an easy deployment across a variety of infrastructures using tools like Ansible, Chef and Puppet. Users could easily write their own additional checks using in any language.

iPad next to an Apple display on a white desk in a bright office. The iPad displays Mostro's recommendations for database settings. It reads 'Query cache' and lists diagrams for hit ratio and memory usage. The display shows Mostro's dashboard listing 19 servers and 231 checks, 1 warning for a web server ('HTTP Status - Processing time - 6.2 seconds ≥ 5 seconds') and 1 critical error for the same server ('CPU usage=84.2% ≥ 75%') acknowledged by John 9 minutes ago.
The dashboard highlighted what the issue was, how bad it was, how long it has been, and who was working on it. The app provided actionable solutions, for instance specific MySQL settings.
TV mounted on a wall displaying the Mostro dashboard with a green navbar and a green checkmark with the text: 'All systems operational. 26 servers and 313 checks reporting. The last incident was about 3 hours ago.'
No need for flashy charts when everything is running smoothly. Mostro would let you know if anything went wrong.
Two hands holding an iPad displaying Mostro's Alerts & Integrations settings, highlighting the rules in blue, the actions for warning-level alerts in yellow and for critical alerts in red.
"Alert me via Slack if the CPU on #worker servers is critical for more than 1 minute, and text the whole team if the problem persists for more than 5 minutes."
Top-down view of two pairs of hands, each holding and interacting with an iPad. The left iPad displays the configuration for a new alert trigger for the Nginx web server. The right iPad displays a server's CPU usage chart.

What happened?

Mostro publicly launched around the time Docker became popular, but wasn't flexible enough to support the new challenges containers brought to the world of DevOps. In retrospect, we should have tried to focus on emerging trends, ship it sooner, learn from our market and adjust to the rapidly shifting needs of our potential customers. Instead, we built a solution for a disappearing problem. It's a classic tale of a bad market fit and a rigid solution.

One lesson I learned from this experience: ship early to validate your assumptions.