Goals & Metrics
Goals and metrics provide a framework for defining success criteria and measuring service performance in PrioStack. While the full monitoring infrastructure is planned for future releases, the goals framework establishes the foundation for observable and accountable services.
💡 Key Concept: Goals define what "good" looks like for your services, while metrics provide the data to measure whether you're achieving those goals.
⚠️ Current Status: Goals and metrics are currently declarative only. Full monitoring, alerting, and dashboard capabilities are planned for future releases.
Understanding Goals
Goals represent the success criteria for your services. They define measurable objectives that indicate whether your service is performing as expected. Goals make your service requirements explicit and accountable.
Why Define Goals?
- Clarity: Goals make service expectations explicit
- Accountability: Goals provide measurable success criteria
- Monitoring Foundation: Goals establish what to monitor
- Continuous Improvement: Goals guide optimization efforts
Goal Configuration
Goals are defined in service YAML files under the goals section.
Each goal specifies a metric, target value, and description.
Basic Goal Structure
goals:
- name: apiResponseTime
metric: latency
target: "< 200ms"
description: API responses should be under 200ms for good user experience
Goal Fields
| Field | Type | Required | Description |
|---|---|---|---|
name |
string | Yes | Unique identifier for the goal within the service |
metric |
string | Yes | The metric to measure (latency, throughput, errorRate, etc.) |
target |
string | Yes | Target value or range (e.g., "< 200ms", "> 99.9%", "0") |
description |
string | No | Human-readable explanation of the goal |
Available Metrics
PrioStack supports several standard metrics that cover common service performance aspects. These metrics provide comprehensive coverage of service health and performance.
Performance Metrics
latency
Measures response time for operations. Critical for user experience and identifying performance bottlenecks.
- name: apiResponseTime
metric: latency
target: "< 500ms"
description: API responses should be under 500ms
throughput
Measures the rate of successful operations per unit time. Important for capacity planning and scaling decisions.
- name: requestThroughput
metric: throughput
target: "> 1000 req/min"
description: Service should handle at least 1000 requests per minute
Reliability Metrics
errorRate
Measures the percentage of failed operations. Critical for service reliability and identifying problematic areas.
- name: apiErrorRate
metric: errorRate
target: "< 0.1%"
description: Error rate should be below 0.1%
availability
Measures the percentage of time the service is operational. Essential for SLA compliance and user trust.
- name: serviceAvailability
metric: availability
target: "> 99.9%"
description: Service should be available 99.9% of the time
Resource Metrics
cpuUsage
Measures CPU utilization. Helps identify compute-intensive operations and scaling needs.
- name: cpuUtilization
metric: cpuUsage
target: "< 80%"
description: CPU usage should stay below 80%
memoryUsage
Measures memory utilization. Important for preventing memory leaks and ensuring stable operation.
- name: memoryUtilization
metric: memoryUsage
target: "< 85%"
description: Memory usage should stay below 85%
Business Metrics
custom
Allows defining custom business-specific metrics. Useful for tracking domain-specific KPIs and business outcomes.
- name: conversionRate
metric: custom
target: "> 3.5%"
description: Shopping cart conversion rate should exceed 3.5%
Target Expressions
Target values use simple comparison expressions to define acceptable ranges. These expressions will be evaluated against actual metric values.
Comparison Operators
| Operator | Example | Description |
|---|---|---|
< |
"< 500ms" |
Less than (upper bound) |
> |
"> 99.9%" |
Greater than (lower bound) |
<= |
"<= 1000" |
Less than or equal |
>= |
">= 0.1%" |
Greater than or equal |
= |
"= 0" |
Equal to (exact match) |
!= |
"!= null" |
Not equal to |
Range Expressions
For more complex requirements, you can use range expressions:
# Between two values
target: "100ms..500ms"
# Outside a range
target: "< 100ms || > 2000ms"
Goal Categories
Goals can be categorized to help organize and prioritize different aspects of service performance and business objectives.
Technical Goals
Focus on system performance and reliability:
- Response time and latency
- Error rates and availability
- Resource utilization
- Throughput and capacity
Business Goals
Focus on business outcomes and user experience:
- User satisfaction metrics
- Conversion rates
- Business process efficiency
- Customer retention indicators
Operational Goals
Focus on operational excellence:
- Deployment frequency
- Incident response time
- Mean time between failures
- Mean time to recovery
Resource Contracts
Goals can include resource contracts that declare the service's resource requirements and quality-of-service expectations. Resource contracts separate business logic from resource economics.
🔗 Integration with Goals
Resource contracts attach to goals to define how success should be achieved, not just what success looks like.
Contract Structure
Resource contracts are optional fields added to goal definitions:
goals:
- name: apiResponseTime
metric: latency
target: "< 200ms"
resourceContract:
priority: high
computeUnits: 100
maxWaitTime: "5s"
futuresEnabled: true
fallbackBehavior: retry
costCeiling: 10
Contract Fields
| Field | Type | Description |
|---|---|---|
priority |
string | Priority level: low, normal, high, critical |
computeUnits |
integer | Estimated compute units needed |
maxWaitTime |
duration | Maximum acceptable queue wait time |
futuresEnabled |
boolean | Allow futures-based resource reservation |
fallbackBehavior |
string | What to do when resources unavailable |
costCeiling |
integer | Maximum credits for future bidding |
Priority Levels
- Critical: System stability, payments, security (never fails)
- High: User-facing APIs, real-time features
- Normal: Background processing, standard operations
- Low: Batch jobs, cleanup, analytics
Fallback Behaviors
When resource contracts cannot be fulfilled:
- queue: Wait in queue (default)
- retry: Retry with backoff
- degrade: Execute with reduced quality
- fail: Return error immediately
🎯 Best Practice
Start with conservative resource contracts and increase priority/compute units based on actual usage patterns.
Goal Validation
While full runtime validation is planned for future releases, you can currently validate goal syntax and structure during bundle deployment.
Syntax Validation
PrioStack validates that:
- Goal names are unique within the service
- Metric names are recognized
- Target expressions are syntactically valid
- Required fields are present
Future Runtime Validation
Planned features include:
- Continuous monitoring against goals
- Automated alerts when goals are violated
- Historical trend analysis
- Goal-based autoscaling triggers
Example Service with Goals
Here's a complete example of a service with comprehensive goals covering different aspects of performance and reliability.
name: user-service
description: User management and authentication service
version: 1.0.0
api:
basePath: "/api/v1/users"
endpoints:
- name: getUser
method: GET
path: "/:id"
to: wasm:users:getUser
- name: createUser
method: POST
path: "/"
to: wasm:users:createUser
goals:
# Performance goals
- name: apiLatency
metric: latency
target: "< 300ms"
description: API responses should be under 300ms for good UX
- name: throughput
metric: throughput
target: "> 500 req/min"
description: Handle at least 500 requests per minute
# Reliability goals
- name: errorRate
metric: errorRate
target: "< 0.5%"
description: Keep error rate below 0.5%
- name: availability
metric: availability
target: "> 99.5%"
description: Service should be available 99.5% of the time
# Resource goals
- name: cpuUsage
metric: cpuUsage
target: "< 75%"
description: CPU utilization should stay under 75%
- name: memoryUsage
metric: memoryUsage
target: "< 80%"
description: Memory usage should stay under 80%
Best Practices
Goal Setting
- Start Simple: Begin with 3-5 key goals per service
- Be Specific: Use concrete, measurable targets
- Be Realistic: Set achievable goals based on your requirements
- Focus on Impact: Prioritize goals that matter to users and business
Goal Categories
- Balance: Include goals for performance, reliability, and resources
- Hierarchy: Have primary goals and secondary goals
- Evolution: Review and adjust goals as your service matures
Measurement
- Consistency: Use consistent measurement periods
- Context: Consider seasonal variations and special circumstances
- Trends: Look at trends over time, not just snapshots
✅ Pro Tip: Goals should drive behavior. Well-defined goals help teams make better decisions about architecture, optimization, and feature priorities.