liveBook · Manning

Monitoring

As explained in Delivering Machine Learning Projects: From design to deployment

Monitoring is the systematic inspection and recording of a system's behavior to detect issues and notify responsible parties.

Monitoring makes a production ML system’s behavior visible to its users and owners. System inspections, recorded behavior, and alerts help responsible people notice issues and investigate them. Monitoring is also a safety safeguard: it remains necessary after development checks and acceptance testing, when the system is operating in the world. section 2.6 section 9.5

A production ML system needs monitoring of both nonfunctional performance and functional behavior. A system may keep running while its predictions become less useful because the world has changed since model development. Logs and alarms must therefore help establish if, where, and when functional failure occurs—not merely whether the software is available. section 9.5

Treat monitoring as a production support deliverable:

  • Build logging, monitoring, and alerting components, alongside the interfaces technical support needs to operate the system. section 9.5
  • Record operationally relevant events, including database connections, user logins, data updates, and model decisions, so failures can be traced. section 9.5
  • Set logging frequency, detail, and retention for the application; account for the load of calculating performance metrics and the cost of storing logs. section 9.5
  • Arrange alerts to bring issues to users and stakeholders, including a support group that can respond to failures. Agree on governance and hand-over arrangements, and produce maintenance and support documentation. section 2.6 section 9.5

A model can fail while the system keeps running

A model trained to predict music sales before streaming became widespread might no longer predict well afterward. Monitoring its functional behavior matters even if its connections and other software operations appear healthy. section 9.5

For an existing ML system, first check whether activity logs exist, whether performance can be understood, and whether failures alert a support group. Missing logging and monitoring are technical debt: logs underpin troubleshooting, while early warnings can make failures less difficult to resolve. section 10.2.2

How Delivering Machine Learning Projects: From design to deployment covers it

How deep it goes
Specifies events to log, behaviors to monitor, alert recipients, and logging costs; stops short of naming tools or implementation settings.
Examples
Uses music-sales predictions disrupted by streaming and logs of database connections, user logins, data updates, and model decisions.
What it assumes
Assumes an ML model moving into production and a technical support group; does not teach monitoring tools from zero.
What you can do after
Operate/configure it: specify production logs and alerts, then check their presence when taking over a legacy ML system.
How it connects
Connects monitoring to logging, alerting, model drift, technical debt, and ML safety safeguards.

Also explained in

Compare how 40 books explain monitoring →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Delivering Machine Learning Projects: From design to deployment. The section links point to the parts of the book it draws on.