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 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#

Run cloudemu as a server and the production cloudwatch client talks to the emulator. Start it with cloudemu serve (or docker run --rm -p 4566:4566 ghcr.io/stackshy/cloudemu), which serves the AWS API on http://localhost:4566:

cloudemu serve   # AWS API on http://localhost:4566

Then point the CloudWatch client at that endpoint. 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"
)

client := cloudwatch.NewFromConfig(cfg, func(o *cloudwatch.Options) {
    o.BaseEndpoint = aws.String("http://localhost:4566")
})

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,
})

In-process (Go unit tests)#

For Go unit tests written inside cloudemu-aware code, stand the same wire server up in-process with httptest.NewServer and point the client at ts.URL. The Drivers you pass name exactly the drivers this service needs:

import (
    "github.com/stackshy/cloudemu/v2"
    awsserver "github.com/stackshy/cloudemu/v2/server/aws"
)

cloud := cloudemu.NewAWS()
ts := httptest.NewServer(awsserver.New(awsserver.Drivers{CloudWatch: cloud.CloudWatch}))
defer ts.Close()
// point the same cloudwatch client at ts.URL instead of the running endpoint

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#

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.