npm - blockmine - Versions diffs - 1.24.0 → 1.25.0 - Mend

blockmine 1.24.0 → 1.25.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (346) hide show

package/.claude/skills/general-it-engineering/resources/enterprise-monitoring.md DELETED Viewed

@@ -1,729 +0,0 @@
-# Enterprise Monitoring
-Enterprise monitoring tools, dashboards, capacity management, performance metrics, and proactive monitoring strategies.
-## Table of Contents
-- [Monitoring Overview](#monitoring-overview)
-- [Monitoring Tools](#monitoring-tools)
-- [Monitoring Metrics](#monitoring-metrics)
-- [Dashboards](#dashboards)
-- [Alerting](#alerting)
-- [Capacity Management](#capacity-management)
-- [Best Practices](#best-practices)
-## Monitoring Overview
-### Purpose
-Enterprise monitoring provides:
-- Real-time visibility into IT infrastructure
-- Proactive issue detection
-- Performance optimization
-- Capacity planning
-- Service level compliance
-- Root cause analysis
-### Monitoring Layers
-```
-┌─────────────────────────────────────────┐
-│ Business Monitoring                      │
-│ - Transaction success rate              │
-│ - Revenue per minute                    │
-│ - Customer experience                   │
-└──────────────┬──────────────────────────┘
-               ↓
-┌─────────────────────────────────────────┐
-│ Application Monitoring (APM)            │
-│ - Response times                        │
-│ - Error rates                           │
-│ - Database query performance            │
-└──────────────┬──────────────────────────┘
-               ↓
-┌─────────────────────────────────────────┐
-│ Infrastructure Monitoring               │
-│ - Server CPU/memory                     │
-│ - Network bandwidth                     │
-│ - Storage capacity                      │
-└──────────────┬──────────────────────────┘
-               ↓
-┌─────────────────────────────────────────┐
-│ Network Monitoring                      │
-│ - Link availability                     │
-│ - Latency                               │
-│ - Packet loss                           │
-└─────────────────────────────────────────┘
-```
-## Monitoring Tools
-### Enterprise Monitoring Stack
-**Infrastructure Monitoring:**
-```yaml
-Tools:
-  - Nagios/Icinga: Traditional monitoring
-  - Zabbix: Enterprise monitoring
-  - PRTG: Network monitoring
-  - SolarWinds: Comprehensive suite
-Capabilities:
-  - Server monitoring (CPU, memory, disk)
-  - Network device monitoring
-  - Service checks (HTTP, SMTP, etc.)
-  - SNMP monitoring
-  - Alerting
-```
-**Application Performance Monitoring (APM):**
-```yaml
-Tools:
-  - New Relic: Full-stack observability
-  - Dynatrace: AI-powered APM
-  - AppDynamics: Application intelligence
-  - Datadog: Cloud-scale monitoring
-Capabilities:
-  - Application performance
-  - Transaction tracing
-  - Code-level diagnostics
-  - User experience monitoring
-  - Error tracking
-```
-**Log Management:**
-```yaml
-Tools:
-  - Splunk: Enterprise log analysis
-  - ELK Stack: Open-source (Elasticsearch, Logstash, Kibana)
-  - Graylog: Log management
-  - Sumo Logic: Cloud-native logs
-Capabilities:
-  - Centralized logging
-  - Log aggregation
-  - Search and analysis
-  - Correlation
-  - Compliance
-```
-**Cloud Monitoring:**
-```yaml
-AWS:
-  - CloudWatch: Metrics and logs
-  - X-Ray: Distributed tracing
-  - CloudTrail: Audit logs
-Azure:
-  - Azure Monitor: Unified monitoring
-  - Application Insights: APM
-  - Log Analytics: Log management
-GCP:
-  - Cloud Monitoring: Metrics
-  - Cloud Logging: Logs
-  - Cloud Trace: Distributed tracing
-```
-## Monitoring Metrics
-### Infrastructure Metrics
-**Server Metrics:**
-```yaml
-CPU:
-  - CPU utilization (%)
-  - Load average (1m, 5m, 15m)
-  - Context switches
-  - CPU steal time (virtual)
-  Thresholds:
-    Warning: >70%
-    Critical: >90%
-Memory:
-  - Memory utilization (%)
-  - Swap usage
-  - Memory available
-  - Page faults
-  Thresholds:
-    Warning: >80%
-    Critical: >95%
-Disk:
-  - Disk utilization (%)
-  - Disk I/O (read/write IOPS)
-  - Disk latency
-  - Disk queue depth
-  Thresholds:
-    Utilization Warning: >80%
-    Utilization Critical: >90%
-    Latency Warning: >20ms
-    Latency Critical: >50ms
-Network:
-  - Bandwidth utilization (%)
-  - Packets in/out
-  - Errors
-  - Dropped packets
-  Thresholds:
-    Bandwidth Warning: >70%
-    Bandwidth Critical: >90%
-```
-### Application Metrics
-```yaml
-Availability:
-  - Uptime (%)
-  - Error rate (%)
-  - Success rate (%)
-  Targets:
-    Uptime: 99.9% (SLA)
-    Error Rate: <1%
-Performance:
-  - Response time (p50, p95, p99)
-  - Transactions per second (TPS)
-  - Throughput
-  - Apdex score
-  Targets:
-    Response Time p95: <500ms
-    Response Time p99: <1000ms
-    TPS: >1000
-Resource Usage:
-  - Connection pool usage
-  - Thread pool usage
-  - Cache hit rate
-  - Queue depth
-  Targets:
-    Connection Pool: <80%
-    Cache Hit Rate: >90%
-Database:
-  - Query response time
-  - Slow queries
-  - Connection count
-  - Deadlocks
-  Targets:
-    Query Time p95: <100ms
-    Slow Queries: <10/hour
-```
-### Business Metrics
-```yaml
-E-Commerce Example:
-Revenue Metrics:
-  - Orders per minute
-  - Revenue per minute
-  - Cart abandonment rate
-  - Conversion rate
-User Experience:
-  - Page load time
-  - Time to first byte
-  - Search results time
-  - Checkout time
-Operational:
-  - Inventory accuracy
-  - Order fulfillment time
-  - Customer support tickets
-  - Failed payments
-```
-## Dashboards
-### Executive Dashboard
-```yaml
-Executive IT Dashboard:
-Service Health:
-  ┌──────────────────────────────────────┐
-  │ Service Status                        │
-  ├──────────────────────────────────────┤
-  │ Email:            ✅ Operational      │
-  │ Customer Portal:  ✅ Operational      │
-  │ VPN:              ✅ Operational      │
-  │ File Shares:      ⚠️ Degraded        │
-  │ ERP System:       ✅ Operational      │
-  └──────────────────────────────────────┘
-SLA Compliance (This Month):
-  ┌──────────────────────────────────────┐
-  │ Overall SLA: 99.7% ✅ (Target: 99.5%)│
-  │                                       │
-  │ Email:           99.95% ✅            │
-  │ Portal:          99.80% ✅            │
-  │ VPN:             99.50% ✅            │
-  │ File Shares:     99.40% ⚠️            │
-  └──────────────────────────────────────┘
-Incidents:
-  ┌──────────────────────────────────────┐
-  │ Open: 15 (▼ 25% vs last month)       │
-  │ P1: 0                                 │
-  │ P2: 2                                 │
-  │ P3: 8                                 │
-  │ P4: 5                                 │
-  │                                       │
-  │ MTTR: 2.5 hours ✅ (Target: 4 hours) │
-  └──────────────────────────────────────┘
-Costs:
-  ┌──────────────────────────────────────┐
-  │ Cloud Spend: $145,000                │
-  │ Trend: ▼ 5% vs budget ✅             │
-  │ Top Costs:                           │
-  │   1. Compute: $65,000 (45%)          │
-  │   2. Storage: $35,000 (24%)          │
-  │   3. Network: $25,000 (17%)          │
-  └──────────────────────────────────────┘
-```
-### Operations Dashboard
-```yaml
-NOC (Network Operations Center) Dashboard:
-Infrastructure Overview:
-  ┌──────────────────────────────────────┐
-  │ Servers: 245 ✅ / 3 ⚠️ / 0 ❌        │
-  │ Network: 45 ✅ / 1 ⚠️ / 0 ❌         │
-  │ Storage: 15 ✅ / 0 ⚠️ / 0 ❌         │
-  │ Applications: 32 ✅ / 1 ⚠️ / 0 ❌    │
-  └──────────────────────────────────────┘
-Active Alerts:
-  ┌──────────────────────────────────────┐
-  │ Critical: 0                          │
-  │ Warning: 5                           │
-  │                                       │
-  │ 1. File Server Disk 85% (Warning)    │
-  │ 2. Web01 CPU 75% (Warning)           │
-  │ 3. Network Link Latency 25ms (Warn)  │
-  │ 4. Database Slow Queries (Warning)   │
-  │ 5. Backup Job Delayed (Warning)      │
-  └──────────────────────────────────────┘
-Performance:
-  ┌──────────────────────────────────────┐
-  │ Application Response Time (p95)      │
-  │ ████████████░░░░░░░░  485ms ✅       │
-  │ Target: <500ms                       │
-  │                                       │
-  │ Network Latency (avg)                │
-  │ ████░░░░░░░░░░░░░░░░  18ms ✅        │
-  │ Target: <50ms                        │
-  │                                       │
-  │ Database Query Time (p95)            │
-  │ ██████░░░░░░░░░░░░░░  85ms ✅        │
-  │ Target: <100ms                       │
-  └──────────────────────────────────────┘
-```
-### Application Dashboard
-```yaml
-Application Performance Dashboard:
-Customer Portal:
-Response Time Trend (24 hours):
-  ┌──────────────────────────────────────┐
-  │ p50  ▁▂▃▂▁▂▃▂▁▂▃▂▁▂▃▂▁▂▃▂▁▂▃▂  250ms│
-  │ p95  ▃▅▆▅▃▅▆▅▃▅▆▅▃▅▆▅▃▅▆▅▃▅▆▅  480ms│
-  │ p99  ▆▇█▇▆▇█▇▆▇█▇▆▇█▇▆▇█▇▆▇█▇  920ms│
-  │                                       │
-  │ 00:00    06:00    12:00    18:00    │
-  └──────────────────────────────────────┘
-Error Rate (24 hours):
-  ┌──────────────────────────────────────┐
-  │ 2%  █                                 │
-  │ 1%  █  ▆     ▃                        │
-  │ 0%  ▅▃▂▁▂▃▂▁▂▃▂▁▂▃▂▁▂▃▂▁▂▃▂▁▂        │
-  │                                       │
-  │ Current: 0.3% ✅ (Target: <1%)       │
-  └──────────────────────────────────────┘
-Top Endpoints:
-  ┌──────────────────────────────────────┐
-  │ Endpoint          | Requests | p95   │
-  ├──────────────────────────────────────┤
-  │ /api/orders       | 15,000   | 320ms │
-  │ /api/products     | 12,500   | 280ms │
-  │ /api/customers    | 8,000    | 450ms │
-  │ /api/search       | 6,000    | 650ms │
-  │ /api/checkout     | 3,500    | 890ms │
-  └──────────────────────────────────────┘
-Database Queries:
-  ┌──────────────────────────────────────┐
-  │ Slow Queries (>1s): 12 ⚠️            │
-  │                                       │
-  │ Top Slow Queries:                    │
-  │ 1. SELECT * FROM orders... (2.5s)    │
-  │ 2. JOIN customers... (1.8s)          │
-  │ 3. UPDATE inventory... (1.2s)        │
-  └──────────────────────────────────────┘
-```
-## Alerting
-### Alert Levels
-```yaml
-Alert Severity Levels:
-Critical:
-  Description: Service down, immediate action required
-  Examples:
-    - Production database down
-    - Website unreachable
-    - Data loss detected
-  Response: Page on-call, all hands on deck
-  SLA: Response within 15 minutes
-Warning:
-  Description: Threshold exceeded, may impact service
-  Examples:
-    - Disk 85% full
-    - CPU 80% for 10 minutes
-    - Backup job delayed
-  Response: Investigate within 1 hour
-  SLA: Acknowledge within 30 minutes
-Info:
-  Description: Informational, no action required
-  Examples:
-    - Backup completed successfully
-    - Deployment finished
-    - Certificate renewed
-  Response: Review during business hours
-  SLA: No SLA
-```
-### Alert Rules
-```yaml
-Server CPU Alert:
-Metric: cpu.utilization
-Condition: Average > 80% for 10 minutes
-Severity: Warning
-Actions:
-  - Send email to ops-team@company.com
-  - Create Slack notification in #ops-alerts
-  - Create ServiceNow ticket
-Escalation:
-  If CPU > 90% for 10 minutes:
-    - Upgrade to Critical
-    - Page on-call engineer
-    - Notify manager
-Auto-remediation:
-  If CPU > 95% for 5 minutes:
-    - Scale up (add server instance)
-    - Restart stuck processes (if configured)
-```
-### Alert Best Practices
-```yaml
-Alert Design:
-1. Actionable:
-   ❌ Bad: "Server CPU high"
-   ✅ Good: "Web01 CPU >90% for 15min. Check runaway processes or scale up."
-2. Contextual:
-   Include:
-     - Current value
-     - Threshold
-     - Duration
-     - Impact
-     - Runbook link
-3. Threshold Tuning:
-   - Start conservative (avoid alert fatigue)
-   - Adjust based on normal patterns
-   - Different thresholds for different times
-   - Use anomaly detection
-4. Alert Routing:
-   - Route to responsible team
-   - Escalate if not acknowledged
-   - Different channels per severity
-   - On-call rotation
-5. Alert Deduplication:
-   - Group related alerts
-   - Suppress dependent alerts
-   - Cooldown periods
-   - Flapping detection
-```
-## Capacity Management
-### Capacity Planning Process
-```yaml
-Capacity Planning Cycle:
-1. Monitor Current Usage (Ongoing):
-   - Track resource utilization
-   - Identify trends
-   - Collect metrics
-2. Forecast Future Demand (Quarterly):
-   - Business growth projections
-   - Seasonal variations
-   - New initiatives
-   - Historical trends
-3. Analyze Capacity (Quarterly):
-   - Current vs forecasted demand
-   - Time to resource exhaustion
-   - Bottlenecks
-   - Optimization opportunities
-4. Plan Capacity Changes (Quarterly):
-   - Procurement requirements
-   - Budget approval
-   - Implementation timeline
-   - Risk mitigation
-5. Implement Changes (As needed):
-   - Procure resources
-   - Deploy infrastructure
-   - Validate capacity
-   - Document changes
-6. Review and Optimize (Monthly):
-   - Actual vs plan
-   - Cost efficiency
-   - Performance impact
-   - Lessons learned
-```
-### Capacity Metrics
-```yaml
-Server Capacity:
-Current State:
-  Total Servers: 250
-  Average CPU: 45%
-  Average Memory: 60%
-  Average Disk: 55%
-Trend (6 months):
-  CPU: ▲ 5% increase
-  Memory: ▲ 8% increase
-  Disk: ▲ 12% increase
-Forecast (Next 6 months):
-  Expected CPU: 55% (10% headroom)
-  Expected Memory: 75% (adequate)
-  Expected Disk: 75% (adequate)
-Action Required:
-  - None for CPU/Memory
-  - Monitor disk growth
-  - Plan storage expansion in Q2
-Storage Capacity:
-Current: 500 TB used / 750 TB total (67%)
-Growth Rate: 15 TB/month
-Forecast: 590 TB in 6 months (79%)
-Threshold: 80% (warning)
-Action:
-  - Procure additional 250 TB
-  - Timeline: Q2 2025
-  - Budget: $50,000
-Network Capacity:
-Current: 1 Gbps links
-Peak Usage: 650 Mbps (65%)
-Growth: 5% per quarter
-Forecast: 850 Mbps in 12 months (85%)
-Action:
-  - Upgrade to 10 Gbps in Q3
-  - Cost: $25,000
-  - Provides 10x headroom
-```
-### Capacity Reporting
-```yaml
-Monthly Capacity Report:
-Executive Summary:
-  - All systems within capacity targets
-  - Storage requiring expansion in 6 months
-  - Network upgrade planned Q3
-  - No immediate concerns
-Current Utilization:
-  Compute: 45% (Low ✅)
-  Memory: 60% (Moderate ✅)
-  Storage: 67% (Moderate ✅)
-  Network: 65% (Moderate ✅)
-Trends:
-  - Steady 5% quarterly compute growth
-  - Storage growth accelerating (cleanup needed)
-  - Network stable
-Forecasts:
-  Next 6 Months:
-    - Compute: Adequate capacity
-    - Storage: Approaching limit (action required)
-    - Network: Adequate capacity
-  Next 12 Months:
-    - Compute: Adequate capacity
-    - Storage: Expansion required
-    - Network: Upgrade recommended
-Actions:
-  - Storage procurement initiated
-  - Network upgrade planning started
-  - Cost: $75,000 (approved)
-```
-## Best Practices
-### 1. Monitoring Coverage
-```yaml
-Ensure Comprehensive Coverage:
-Infrastructure:
-  - All production servers
-  - Network devices
-  - Storage systems
-  - Virtualization platforms
-Applications:
-  - All critical applications
-  - Key transactions
-  - Dependencies
-  - APIs
-Business:
-  - Revenue metrics
-  - User experience
-  - SLA compliance
-  - Customer satisfaction
-```
-### 2. Baseline Establishment
-```yaml
-Establish Performance Baselines:
-Process:
-  1. Collect metrics for 30 days
-  2. Analyze patterns (daily, weekly)
-  3. Calculate normal ranges
-  4. Set thresholds above baseline
-  5. Review quarterly
-Example:
-  Metric: Application response time
-  Baseline (p95): 450ms
-  Warning: 600ms (133% of baseline)
-  Critical: 900ms (200% of baseline)
-```
-### 3. Alert Fatigue Prevention
-```yaml
-Avoid Alert Fatigue:
-Strategies:
-  - Tune thresholds (reduce false positives)
-  - Use intelligent alerting (anomaly detection)
-  - Implement alert aggregation
-  - Regular alert review and cleanup
-  - Auto-remediation where possible
-Metrics:
-  - Alert volume: <100/day
-  - Alert-to-incident ratio: >50%
-  - False positive rate: <10%
-  - Time to acknowledge: <5 minutes
-```
-### 4. Correlation and Root Cause
-```yaml
-Use Correlation for RCA:
-Approach:
-  - Correlate metrics across layers
-  - Identify cascading failures
-  - Trace requests end-to-end
-  - Link logs to metrics
-  - Use dependency mapping
-Example:
-  Symptom: Application slow
-  Correlation:
-    - Application response time ↑
-    - Database query time ↑
-    - Database disk I/O ↑
-    - Storage latency ↑
-  Root Cause: Storage array degraded disk
-```
-### 5. Continuous Improvement
-```yaml
-Monitoring Improvement Process:
-Monthly:
-  - Review alert effectiveness
-  - Tune thresholds
-  - Add missing metrics
-  - Update dashboards
-Quarterly:
-  - Capacity planning review
-  - Tool evaluation
-  - Process optimization
-  - Team training
-Annually:
-  - Technology refresh
-  - Tool consolidation
-  - Architecture review
-  - Strategy planning
-```
----
-**Related Resources:**
-- [incident-service-management.md](incident-service-management.md) - Incident response
-- [business-continuity.md](business-continuity.md) - DR monitoring
-- [automation-orchestration.md](automation-orchestration.md) - Automated remediation