SentinelD’s extensible monitoring system is architected around the collector-core framework, which provides a reusable, modular foundation for multi-domain event collection and operational consistency across both open-source (OSS) and enterprise deployments. This document outlines the architectural vision, multi-domain event collection strategy, shared infrastructure, extensibility mechanisms, and specification milestones, with references to design rationale and implementation details.

Architectural Vision#

The collector-core framework was extracted from the original monolithic procmond binary to enable a pluggable, multi-component monitoring platform. It abstracts collection logic from operational infrastructure, allowing process, network, filesystem, and performance monitoring components to share a common runtime, configuration, and communication layer. This approach supports both OSS and enterprise features, enabling rapid development of new monitoring domains and seamless integration of proprietary extensions without duplicating infrastructure or compromising maintainability [1].

The architecture is designed for cross-platform compatibility (Linux, Windows, macOS), with platform-specific event sources abstracted behind a universal interface to ensure consistent behavior and performance [2].

Multi-Domain Event Collection#

collector-core enables multi-domain event collection by defining a universal EventSource trait. Each monitoring domain—process, network, filesystem, and performance—implements this trait, encapsulating domain-specific collection logic while exposing a consistent interface to the collector runtime [3].

Event sources declare their capabilities using SourceCaps bitflags, which support dynamic feature discovery and task routing. For example, a process monitoring source might declare PROCESS | REALTIME | SYSTEM_WIDE, while a network source might declare NETWORK | KERNEL_LEVEL | REALTIME. This enables the collector to aggregate capabilities and route tasks appropriately [4].

The event model uses a unified CollectionEvent enum, with strongly-typed, extensible, and serializable structures for each domain:

pub enum CollectionEvent {
    Process(ProcessEvent),
    Network(NetworkEvent),
    Filesystem(FilesystemEvent),
    Performance(PerformanceEvent),
}

Each event includes a timestamp and domain-specific fields, supporting extensibility and type safety [5].

Component Relationships#

Shared Infrastructure for OSS and Enterprise#

collector-core provides shared infrastructure components, including:

• Hierarchical configuration management
• Structured logging and metrics
• Health checks and telemetry collection
• Event batching and backpressure handling
• Graceful shutdown coordination
• IPC server for agent communication

Both OSS and enterprise features leverage this infrastructure. Enterprise extensions, such as kernel-level monitoring via eBPF (Linux), ETW (Windows), or EndpointSecurity (macOS), are implemented as additional EventSource plugins. This maintains operational consistency and enables capability negotiation and graceful degradation when advanced features are unavailable [6].

The collector runtime manages the lifecycle of all registered event sources, aggregates events, and exposes a unified IPC protocol to the agent. This ensures that all monitoring components—procmond (process), netmond (network), fsmond (filesystem), perfmond (performance), and future collectors—share the same operational model [7].

Integration of New Event Sources#

To add a new event source, implement the EventSource trait and register the source with the Collector API. The collector manages runtime, IPC exposure, and lifecycle, enabling seamless integration of new collection domains without modifying core infrastructure [8].

Example:

struct MySource;

#[async_trait]
impl EventSource for MySource {
    fn name(&self) -> &'static str { "my-source" }
    fn capabilities(&self) -> SourceCaps { SourceCaps::PROCESS }
    async fn start(&self, tx: mpsc::Sender<CollectionEvent>, shutdown_signal: Arc<AtomicBool>) -> anyhow::Result<()> { Ok(()) }
    async fn stop(&self) -> anyhow::Result<()> { Ok(()) }
}

let mut collector = Collector::new(CollectorConfig::default());
collector.register(Box::new(MySource))?;

The collector-core framework ensures that new event sources are managed with the same health monitoring, telemetry, batching, and backpressure mechanisms as existing sources [9].

Specification Milestones#

The implementation of collector-core and the extensible monitoring system follows a phased plan [10]:

1. Core Infrastructure Extraction: Create the collector-core library, define the universal EventSource trait, and move IPC, configuration, and logging infrastructure from procmond.
2. Polling Source Creation: Implement the initial process monitoring source as an EventSource.
3. procmond Refactor: Refactor procmond to register the polling source with collector-core, making it a thin shell.
4. Testing and Validation: Develop a comprehensive test suite covering unit, integration, performance, security, property-based, chaos, and compatibility tests.
5. Documentation and Polish: Update documentation, provide extension examples, and maintain architectural diagrams.

This plan spans approximately 3–4 weeks for initial implementation and validation.

Design Rationale#

The design emphasizes clean separation of business logic from collection sources, future-proofing for enterprise extensions, and development efficiency. By abstracting collection methodology from operational infrastructure, collector-core enables:

• Rapid development of new monitoring domains with minimal infrastructure work
• Consistent operational behavior across OSS and enterprise deployments
• Backward IPC compatibility with the agent, requiring no changes on the agent side
• Testing isolation via mock event sources
• Performance flexibility and cross-platform support
• Licensing clarity (Apache-2.0 for collector-core, proprietary for enterprise plugins)
• Low-risk, incremental adoption with rollback strategies and contract tests at each phase [11]

This architecture transforms SentinelD from a monolithic process monitor into a pluggable, multi-domain behavioral monitoring platform, supporting comprehensive threat detection and operational scalability.