Volume 3 · Chapter 3 — Enterprise Reference Architecture, New Relic Observability & Monitoring Platform
The Technical Blueprint
The target-state architecture for enterprise observability — FMCG reference architecture, the full New Relic and OpenTelemetry strategy, Kubernetes and database monitoring, dashboards, alerting, and AI-assisted operations.
Executive Summary
The enterprise monitoring vision
A modern FMCG enterprise operates hundreds of interconnected technology components. Every customer order, warehouse movement, production schedule, dealer transaction, and financial posting depends on applications performing reliably. Monitoring only servers or databases is no longer enough.
Kamiti Labs proposes a unified observability platform where infrastructure, applications, cloud services, Kubernetes, APIs, databases, business transactions, and user experience are monitored through a single operational framework.
The goal is one source of operational truth for both technical teams and business stakeholders.
Business objectives
- Achieve end-to-end visibility across the digital landscape.
- Detect incidents before users report them.
- Reduce Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR).
- Improve application availability and customer experience.
- Enable proactive capacity planning and performance optimization.
- Support business continuity and executive reporting.
Enterprise observability vision
- 1
Business users
- 2
Digital applications
- 3
Infrastructure & cloud
- 4
Unified observability platform
- 5
AI-assisted operations
- 6
Reliable business services
Customer Perspective
The typical FMCG technology landscape
Understanding the customer’s ecosystem is essential before onboarding monitoring. A large FMCG organization typically operates five clusters of business systems.
Customer & sales
- Consumer mobile app
- Dealer portal
- Distributor portal
- Retail ordering portal
- E-commerce platform
- CRM
Manufacturing
- Manufacturing Execution System (MES)
- Production planning
- Quality control
- IoT sensors
- SCADA interfaces
Supply chain
- Warehouse Management System (WMS)
- Transportation Management System (TMS)
- Inventory management
- Barcode systems
- Vendor portal
Enterprise systems
- SAP ERP / Oracle ERP
- HRMS
- Finance
- Procurement
- Payroll
Analytics
- Data warehouse
- Business intelligence
- AI/ML
- Forecasting
- Executive dashboards
Reference architecture
- 1
Consumers, dealers, retailers & employees
- 2
Internet
- 3
CDN + WAF
- 4
API Gateway
- 5
Load balancer
- 6
Kubernetes platform
- 7
Microservices
- 8
Business APIs
- 9
ERP, CRM, WMS, Finance
- 10
Databases
- 11
Cloud infrastructure
Architecture
New Relic reference architecture
New Relic provides a unified observability platform that combines infrastructure monitoring, APM, distributed tracing, browser and mobile monitoring, Kubernetes monitoring, synthetic monitoring, logs, dashboards, and alert intelligence. Instead of stitching together disconnected tools, New Relic becomes the single operational platform.
Logical architecture
- 1
Applications, VMs, containers, Kubernetes, databases & cloud services
The full estate under management.
- 2
OpenTelemetry
Vendor-neutral instrumentation layer.
- 3
New Relic agents
Language and infrastructure agents collect telemetry.
- 4
Telemetry pipeline
Metrics, logs, and traces are ingested centrally.
- 5
New Relic platform
Data is stored, correlated, and made queryable.
- 6
Dashboards, alerts, NRQL, AI & incident intelligence
The operational surface teams work from daily.
Standards & Best Practices
Monitoring layers
Monitoring is implemented in five layers, from the infrastructure up to the business outcomes it exists to protect.
Layer 1 — Infrastructure
- CPU
- Memory
- Disk
- Filesystems
- Network
- Processes
- OS health
Layer 2 — Platform
- Kubernetes cluster
- Nodes
- Pods
- Services
- Ingress
- Namespaces
- Autoscaling
- Persistent volumes
Layer 3 — Applications
- Response time
- Throughput
- Error rate
- JVM/.NET runtime
- API performance
- Exceptions
Layer 4 — Databases
- Connections
- Slow queries
- Locks
- Replication
- Buffer cache
- Storage growth
Layer 5 — Business
- Orders processed
- Dealer transactions
- Consumer logins
- Payment success rate
- Inventory synchronization
Implementation Guidance
OpenTelemetry strategy
OpenTelemetry provides a vendor-neutral way to collect telemetry. Kamiti Labs recommends it as the standard instrumentation framework across Java, .NET, Node.js, Python, and Go — for standardized telemetry, future portability, consistent traces across microservices, and easier troubleshooting.
Telemetry flow
- 1
Application
- 2
OpenTelemetry SDK
- 3
Metrics, logs & traces
- 4
Collector
- 5
New Relic
- 6
Dashboards & alerts
Architecture
Kubernetes monitoring
Modern FMCG applications increasingly run on Kubernetes. Coverage spans cluster health, node health, workloads, networking, and autoscaling.
Cluster health
- API server
- Scheduler
- etcd
- Controller manager
Node health
- CPU
- Memory
- Disk
- Node availability
Workloads
- Pods
- Deployments
- ReplicaSets
- StatefulSets
- DaemonSets
Networking
- Ingress
- Services
- DNS
- Load balancers
Autoscaling
- HPA
- Cluster autoscaler
- Node pools
Monitoring objectives
- Detect unhealthy nodes.
- Identify pod crashes.
- Monitor restart frequency.
- Track resource utilization.
- Prevent capacity bottlenecks.
Standards & Best Practices
Database observability
Every production database should have a monitoring baseline appropriate to its engine.
Oracle
- Sessions
- Tablespaces
- ASM
- Wait events
- AWR indicators
PostgreSQL
- Active connections
- Vacuum health
- Replication lag
- Index usage
- Slow queries
SQL Server
- Blocking
- Deadlocks
- TempDB
- Buffer cache
MySQL
- Replication
- Query performance
- InnoDB health
KPI & SLA Examples
Business transaction monitoring
Technical metrics alone do not tell the full story. Every critical business transaction needs to be watched end to end, not just the infrastructure underneath it.
Transactions to monitor
- Dealer login
- Product search
- Order creation
- Payment processing
- Invoice generation
- Warehouse dispatch
- Shipment confirmation
Tracked for every transaction
- Availability
- Response time
- Error rate
- Success percentage
- User journey
Deliverables
Dashboard architecture
Different audiences need different dashboards — an executive and an on-call engineer should never be staring at the same screen.
Executive dashboard
- Availability
- SLA compliance
- MTTR
- Critical incidents
- Business KPIs
Operations dashboard
- Open alerts
- Active incidents
- Infrastructure health
- Application health
SRE dashboard
- SLO compliance
- Error budget
- Deployment frequency
- Service reliability
Application dashboard
- Response time
- Throughput
- Errors
- JVM health
- API latency
Common Challenges
Alert strategy
Alerting must be actionable. Every alert is classified by severity, and every alert definition carries the same set of fields — otherwise alert fatigue sets in and real incidents get lost in the noise.
Severity classification
- Critical (P1)
- High (P2)
- Medium (P3)
- Informational (P4)
Every alert defines
- Trigger condition
- Business impact
- Notification targets
- Escalation path
- Runbook
- Auto-remediation options
Avoid alert fatigue by tuning thresholds and suppressing duplicate events.
Kamiti Recommendations
AI-assisted operations
New Relic’s AI capabilities assist operations teams rather than replace their judgment.
- Correlating related alerts.
- Detecting anomalies.
- Highlighting probable root causes.
- Reducing duplicate incidents.
- Prioritizing customer-impacting events.
Kamiti Labs treats AI recommendations as decision support, with production changes remaining subject to operational controls and approvals.
KPI & SLA Examples
Success metrics
Measurable targets are defined from day one, not retrofitted after go-live.
| KPI | Target |
|---|---|
| Platform availability | ≥99.9% (or customer-agreed SLA) |
| Critical alert acknowledgement | ≤15 minutes |
| P1 initial response | ≤15 minutes |
| Dashboard coverage | 100% of production applications |
| Instrumented services | 100% of in-scope microservices |
| Synthetic monitoring | All customer-facing applications |
| Monthly availability report | 100% delivery |
Deliverables
What Volume 3 produces
By the end of the observability implementation, Kamiti Labs delivers architecture, New Relic configuration, and documentation as three distinct, handover-ready packages.
Architecture
- Enterprise monitoring architecture
- Application instrumentation standards
- Kubernetes monitoring design
- Database monitoring design
- Business transaction monitoring design
New Relic
- Agent deployment plan
- Dashboard catalogue
- Alert catalogue
- NRQL query library
- Service map
- Entity inventory
Documentation
- Monitoring standards
- Instrumentation guide
- Dashboard user guide
- Alert response guide
- Operations handover document
Consultant Tips
Consultant’s note
They aren’t buying a tool
Enterprise customers rarely buy a monitoring tool — they buy confidence that their business-critical services will remain available and that issues will be detected and resolved quickly. Position New Relic as the foundation of a broader observability strategy that combines technology, governance, and operational excellence.
The value lies not just in dashboards, but in the processes, people, and continuous improvement practices that surround them.