Principle:SeldonIO Seldon core Monitoring Component Deployment
| Property | Value |
|---|---|
| Principle Name | Monitoring Component Deployment |
| Overview | Deploying classifier, preprocessor, drift detector, and outlier detector as independent model components for a monitoring pipeline |
| Domains | MLOps, Kubernetes |
| Related Implementation | SeldonIO_Seldon_core_Seldon_Model_Load_For_Monitoring |
| Knowledge Sources | Repo (https://github.com/SeldonIO/seldon-core), Doc (https://docs.seldon.io/projects/seldon-core/en/v2/) |
| Last Updated | 2026-02-13 00:00 GMT |
Description
A production monitoring pipeline requires four independently deployed models:
- Classifier (income) - The main inference model producing predictions
- Preprocessor (income-preprocess) - Transforms raw features into the format expected by detectors
- Drift Detector (income-drift) - Tests for distribution shift using batched requests
- Outlier Detector (income-outlier) - Flags anomalous individual inputs
Each model uses a different MLServer runtime:
- sklearn runtime for the classifier and preprocessor (scikit-learn models serialized with joblib)
- alibi-detect runtime for the drift and outlier detectors (alibi-detect models serialized with save_detector)
All four components must be loaded and ready before the pipeline can be created and activated.
Theoretical Basis
Decomposing monitoring into independent services follows the microservices pattern. This architecture provides several advantages:
- Independent scaling - Each detector has different compute and memory requirements. The VAE-based outlier detector may need GPU resources, while the drift detector primarily needs CPU for statistical tests.
- Selective updates - Retraining the drift detector (e.g., with updated reference data) does not require redeploying the classifier or outlier detector.
- Fault isolation - If the outlier detector fails, the classifier continues producing predictions. Monitoring degradation does not cause inference degradation.
- Runtime heterogeneity - Different model frameworks (sklearn, alibi-detect, TensorFlow) can coexist through MLServer's pluggable runtime architecture.
Each model is defined as a Seldon Model CRD (Custom Resource Definition) with:
- A storageUri pointing to the serialized model artifact in cloud storage
- A requirements list specifying which MLServer runtime to use
The Seldon scheduler handles downloading artifacts, instantiating the correct runtime, and registering the model for inference.
Usage
Use this principle when setting up a production monitoring pipeline with drift and outlier detection capabilities. The deployment sequence is:
- Upload trained model artifacts to cloud storage (GCS, S3, or local)
- Define a Model CRD YAML for each component specifying storageUri and requirements
- Load each model using the seldon CLI
- Wait for all models to reach ModelAvailable state
- Proceed to pipeline definition
Related Pages
- SeldonIO_Seldon_core_Seldon_Model_Load_For_Monitoring (implements this principle) - Concrete CLI tool for deploying monitoring pipeline component models
- SeldonIO_Seldon_core_Drift_And_Outlier_Detection_Training (prerequisite) - Training the detectors that will be deployed
- SeldonIO_Seldon_core_Alibi_Detect_Training (produces artifacts) - Concrete training code that produces the model artifacts
- SeldonIO_Seldon_core_Monitoring_Pipeline_Definition (next step) - Composing deployed components into a monitoring pipeline
- SeldonIO_Seldon_core_Model_Resource_Definition (related principle) - General model resource definition concepts
Implementation:SeldonIO_Seldon_core_Seldon_Model_Load_For_Monitoring