Monitoring

Emulates a managed metrics and alarms service — the place you push time-series datapoints and define thresholds that flip an alarm between OK and ALARM. You publish metric data under a namespace, define an alarm over one metric, and the alarm re-evaluates itself every time new data lands.

Reach for it in tests when your code emits custom metrics or reacts to alarm state, so you can assert an alarm fired without waiting on a real evaluation cycle. Because the emulator drives evaluation on every write, you control alarm state directly by controlling the datapoints you push.

Drive it with the real SDK#

This is the recommended path: point the AWS SDK at a cloudemu test server and the production cloudwatch client talks to the emulator. PutMetricData ingests datapoints under a namespace; PutMetricAlarm defines a threshold over one of them, and the alarm evaluates as soon as matching data arrives.

import (
    "github.com/aws/aws-sdk-go-v2/service/cloudwatch"
    "github.com/aws/aws-sdk-go-v2/service/cloudwatch/types"
    awsserver "github.com/stackshy/cloudemu/v2/server/aws"
)

cloud := cloudemu.NewAWS()
ts := httptest.NewServer(awsserver.New(awsserver.Drivers{CloudWatch: cloud.CloudWatch}))

client := cloudwatch.NewFromConfig(cfg, func(o *cloudwatch.Options) {
    o.BaseEndpoint = aws.String(ts.URL)
})

client.PutMetricData(ctx, &cloudwatch.PutMetricDataInput{
    Namespace: aws.String("App"),
    MetricData: []types.MetricDatum{
        {MetricName: aws.String("CPU"), Value: aws.Float64(45.2)},
    },
})

client.PutMetricAlarm(ctx, &cloudwatch.PutMetricAlarmInput{
    AlarmName:          aws.String("HighCPU"),
    MetricName:         aws.String("CPU"),
    Namespace:          aws.String("App"),
    Threshold:          aws.Float64(80.0),
    ComparisonOperator: types.ComparisonOperatorGreaterThanThreshold,
    EvaluationPeriods:  aws.Int32(1),
    Period:             aws.Int32(60),
    Statistic:          types.StatisticAverage,
})

Use the Portable Go API#

When you don't need a real SDK client, the same driver is callable directly — the leanest way to seed metric data inside a test. Each MetricDatum carries its own namespace, name, value, and unit.

import mondriver "github.com/stackshy/cloudemu/v2/services/monitoring/driver"

aws.CloudWatch.PutMetricData(ctx, []mondriver.MetricDatum{
    {Namespace: "App", MetricName: "CPU", Value: 45.2, Unit: "Percent"},
})

Behavior & fidelity#

• Alarms auto-evaluate on write. Every PutMetricData runs evaluateAlarms() for each affected namespace+metric, transitioning alarms between OK and ALARM against their threshold — so you assert alarm state by controlling the datapoints you push, not by waiting on a timer.
• Auto-metrics from compute. RunInstances automatically emits five metrics per instance (CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, DiskWriteOps) with five backfilled datapoints at one-minute intervals, so newly launched instances have realistic history to query and alarm on.
• Alarm history. GetAlarmHistory returns each state transition with a timestamp — drive the timestamps deterministically with the fake clock rather than wall time.
• SDK-compat status — Live across all three providers. CloudWatch, Azure Monitor, and Cloud Monitoring all accept their real SDK/REST clients today: CloudWatch PutMetricData, GetMetricStatistics, ListMetrics, PutMetricAlarm, DescribeAlarms, DeleteAlarms; Azure Monitor microsoft.insights/metricAlerts CRUD plus metric ingest/read; Cloud Monitoring time-series ingest/read at /v3/projects/.../ plus alert policies.