Meteorlog
CloudWatch LogsManage CloudWatch Logs groups, streams, and metric filters as code
- Manages
- Amazon CloudWatch Logs
- Language
- Ruby
- Package
- meteorlog
- CLI
- meteorlog
- Config file
- Logsfile
log_group "/var/log/maillog" do
log_stream "my-stream2"
metric_filter "MyAppAccessCount" do
filter_pattern '[..., status_code, bytes]'
metric :name=>"EventCount3", :namespace=>"YourNamespace", :value=>"1"
end
metric_filter "MyAppAccessCount2" do
filter_pattern '[ip, user, username, timestamp, request = *html*, status_code = 4*, bytes]'
metric :name=>"EventCount4", :namespace=>"YourNamespace2", :value=>"2"
end
end
Meteorlog is a Ruby command-line tool that manages Amazon CloudWatch Logs as code. It exports your log groups, log streams, and metric filters into one file called a Logsfile. You review changes in Git, preview them with a dry-run, then apply them idempotently.
What is Meteorlog?
Meteorlog is a small Ruby command-line tool from the codenize-tools family. It manages Amazon CloudWatch Logs as code. You write the log setup you want in one file, and Meteorlog makes AWS match it. That is the idea behind codenization.
Log settings tend to pile up by hand. Someone adds a filter in the console to count errors. Someone else edits a pattern. Months later, nobody knows which filter feeds which alarm. Meteorlog fixes this by keeping three things in one text file:
- Log groups - the buckets that hold your logs.
- Log streams - the individual sources inside a group.
- Metric filters - rules that scan log text and turn matches into numbers you can alarm on.
Once that file lives in Git, every change becomes a diff you can review. It suits teams who already run other codenize tools, like Monosasi for CloudWatch Events, and want the same workflow for logs.
- Manages CloudWatch Logs log groups, log streams, and metric filters in one account.
- The whole setup lives in a single Ruby DSL file, the Logsfile.
- Metric filters turn log matches into numbers that can feed Radiosonde alarms.
- A dry-run shows every change first, and applies are idempotent.
- The project is archived with no updates since 2017, so treat it as legacy.
Install and run Meteorlog
Install
Install the meteorlog gem (Ruby required).
$ gem install meteorlogExport current state
Pull the live CloudWatch Logs configuration into a Logsfile.
$ meteorlog -e -o LogsfileDry-run, then apply
Preview the diff, then apply the change for real.
$ meteorlog -a --dry-runMeteorlog runs the export, review, apply loop. You start in export mode (the -e flag), which reads your live account and writes it into the Logsfile. Commit that file to Git and it becomes your source of truth.
To change the setup, edit the Logsfile in a branch and open a pull request. Run the apply with --dry-run first. It prints every create, update, and delete without touching AWS. After review, apply for real. The apply is idempotent, so a second run changes nothing. Schedule the dry-run and it turns into simple drift detection for console edits.
Wire the dry-run into a scheduled CI job. A non-empty diff is your early warning that someone edited a log group or metric filter by hand.
What Meteorlog can do
Full CloudWatch Logs coverage
Log groups, log streams, and metric filters all live in one Logsfile. The whole logging setup for an account reads as a single document.
One-command export
Export mode dumps your current CloudWatch Logs state into the DSL. You can adopt Meteorlog on an old account without rebuilding anything by hand.
Metric filters as code
Each filter pattern and its metric mapping sits right next to its log group. It stays clear which filters feed which custom metrics.
Dry-run before every apply
The dry-run prints exactly what will be created, updated, or deleted. Reviewers see the real change set before it touches AWS.
Idempotent apply
Running the apply again brings CloudWatch Logs back to the Logsfile. If nothing changed, nothing runs.
When teams reach for Meteorlog
Version-control the filters behind your alarms
Metric filters often power production alarms, yet people add them in the console. Meteorlog keeps each pattern and metric mapping in Git, so alert inputs get real code review.
Copy a logging setup between accounts
Export the Logsfile from staging, tweak the names, and apply it to production. Both accounts then define the same log groups and filters.
Catch drift in your log config
Run the dry-run in a scheduled job. Any non-empty diff means someone changed a group or filter outside the file, and the output shows exactly what.