Sure. Most engineers will probably poke around on the UI to look at graphs, and write any special monitoring configs in GMon (a DSL in Python, which is then tra

Sure. Most engineers will probably poke around on the UI to look at graphs, and write any special monitoring configs in GMon (a DSL in Python, which is then transpiled to mash). Directly interacting with monarch_tool should be rare, as monitoring integration with rollout automation is also provided by default. Further, the entire point of automon is to automatically generate common monitoring dashboards, which you should expect to be sufficient if you're creating a bog-standard setup. > It didn't matter if the backend was Monarch or not. It totally does. Borgmon has a totally different data model, a custom query language, its own UI, and various quirks along the way. To add insult to injury, it was a very real thing where if you wanted to set up new monitoring, you needed to get someone with Borgmon readability to approve your change (that requirement has since been lifted). Meanwhile, today, you don't need anyone with Python readability to ever look at your GMon code. You can have Automon graphs that fetch from Borgmon under the hood, but everything else that you've described is 100% Monarch-specific.