FAQ - Monitoring Scope & Capabilities
Common questions about what Boomi resources Nodinite can monitor and how failure detection works.
Can I monitor Boomi Cloud Atoms or only on-premise Atoms?
Yes, both Boomi Cloud Atoms and on-premise Atoms are fully supported. The Monitoring Agent polls the Boomi AtomSphere REST API which provides unified access to all Atom types:
- Boomi Cloud Atoms - Fully managed by Boomi, monitoring via API only (no direct server access), includes Atom availability, process execution, execution logs
- Boomi On-Premise Atoms - Customer-managed, monitoring via API + optional JMX for deep JVM metrics (see JMX Monitoring Agent), includes Atom availability, process execution, JVM heap/GC/threads
- Boomi Molecules - Multi-node Atom clusters, monitoring via API per node (each node tracked separately), plus JMX per node for performance metrics
- Boomi Atom Clouds - Elastic scaling Atom groups, monitoring via API (aggregate Atom count, individual Atom status), auto-discovery as Atoms scale up/down
JMX monitoring limitation: Boomi Cloud Atoms do NOT support JMX monitoring (Boomi-managed infrastructure, JMX ports not exposed). JMX monitoring available only for on-premise Atoms/Molecules where you control server infrastructure and can configure JMX ports.
How does Nodinite detect when a Boomi process has failed?
Nodinite tracks Boomi process state via 3 detection mechanisms:
Process execution history analysis - Polls Boomi API every 60 seconds, retrieves last 50 executions per process, analyzes execution status: Success (green), Error (red), Aborted (yellow). Alert triggers when: Error rate exceeds threshold (>5% of executions failed in last hour), consecutive execution failures (3+ errors in row), execution duration outlier (current execution 10× longer than 7-day average, indicates performance degradation).
Process state monitoring - Tracks process deployment state: Running (process deployed and enabled), Stopped (process deployed but disabled), Error (deployment failure or configuration issue), Not Deployed (process exists in AtomSphere but not deployed to any Atom). Alert triggers when: Process stops unexpectedly (Running → Stopped without scheduled maintenance window), deployment error detected (Error state).
Expected execution frequency - Configurable expected execution schedule per process (Payment Processing expected every 15 minutes 24/7, Nightly Batch expected once daily between 2-3 AM). Alert triggers when: Expected execution missed (Payment Processing not executed in 20 minutes = 5 minutes past expected interval), execution outside expected window (Nightly Batch executed 4:30 AM instead of 2-3 AM window).
Example alert: "Process: OrderPaymentProcessing | Status: Error | Last Execution: 2025-01-15 14:23:17 | Error: SocketTimeoutException connecting to payment gateway API | Executions last hour: 4 Success, 3 Error (43% error rate exceeds 5% threshold) | Action: Restart process via Remote Actions"
What's the difference between Nodinite Boomi Monitoring and Boomi's built-in AtomSphere monitoring?
Feature | Nodinite Boomi Monitoring | Boomi AtomSphere Portal | Winner |
---|---|---|---|
Atom availability monitoring | ✅ Auto-discovery, real-time alerts via Email/Slack/PagerDuty, 12-month uptime history | ✅ Manual portal login to check status, no alerts, no historical trends | Nodinite (proactive alerts + trends) |
Process execution monitoring | ✅ Real-time failure alerts, error rate thresholds, execution duration anomaly detection, expected frequency tracking | ✅ Manual portal login to view execution history, no alerts, limited filtering (last 7 days only) | Nodinite (proactive + historical) |
JVM performance monitoring | ✅ Deep JVM metrics via JMX Monitoring Agent (heap trends, GC analysis, thread deadlocks, 12-month history) | ⚠️ Basic snapshot metrics only (current heap usage, no trends, no GC details) | Nodinite (capacity planning) |
Multi-account management | ✅ Single dashboard for unlimited accounts + environments, cross-account dashboards, unified alerting | ❌ Separate login per account, no cross-account views | Nodinite (centralized) |
Delegated management (RBAC) | ✅ Business users restart processes without AtomSphere access, granular RBAC per process/environment, complete audit trail | ❌ Requires AtomSphere Operator/Admin role (excessive privilege), no granular RBAC, limited audit trail | Nodinite (security + compliance) |
Business data extraction | ✅ Configure Message Types + Search Fields to extract business identifiers (Order Numbers, Customer IDs), search by business data across all platforms | ❌ No business data extraction, search by execution ID or date only | Nodinite (business self-service) |
End-to-end correlation | ✅ BPM correlates Boomi + BizTalk + Web Services + Database + File Folder into unified transaction timeline | ❌ Boomi-only visibility, no integration with other platforms | Nodinite (troubleshooting) |
Cost | ✅ 1 Nodinite license monitors unlimited Boomi accounts + unlimited Atoms + includes all other Nodinite agents (50+ integration platforms) | ✅ Included with Boomi subscription (no additional cost) | Tie (both included) |
When to use both: Nodinite provides proactive monitoring, alerting, delegated management, and cross-platform correlation. AtomSphere portal provides process design, deployment, and deep execution log forensics. Most customers use Nodinite for operations monitoring + AtomSphere for development/troubleshooting.
How do I configure alerts for specific Boomi processes only?
Use Monitor Views to filter alerts per team/environment/process type:
Example 1: Production-only alerts to operations team
- Create Monitor View "Production Boomi Processes" filtered by: Environment = "Production", assign to Role "Operations Team"
- Operations team dashboard shows only Production Atoms/processes, alerts only fire for Production failures (Development/Test failures not alerted)
Example 2: Critical payment processes to on-call team
- Create Monitor View "Critical Payment Integrations" filtered by: Process Name contains "Payment" OR "Billing" OR "Invoice", assign to Role "Payments On-Call"
- Configure Alarm Plugin routing: Errors in "Critical Payment Integrations" view → PagerDuty (24/7 on-call), Errors in other views → Email (business hours only)
Example 3: Team-specific process ownership
- Create Monitor View "Billing Team Processes" filtered by: Process Name starts with "BIL-" (naming convention), assign to Role "Billing Team"
- Billing team sees only their 8 processes (BIL-InvoiceGeneration, BIL-PaymentProcessing, etc.), can restart their processes via Remote Actions, cannot see/manage other teams' processes
Granularity: Filter by Boomi account, environment (Dev/Test/Prod), Atom name, process name (exact match or contains), process state (Running/Stopped/Error), execution error rate threshold (>5% for critical processes, >20% for non-critical).
Back to FAQs
← All FAQs | ← Boomi Integrations Monitoring Overview
Related FAQs
- Permissions & API Access → - API roles, service account setup, security best practices
- Performance & Overhead → - API polling overhead, JMX overhead, optimization
- Integration & Advanced → - Power BI, Docker/Kubernetes, Boomi Flow