Conversation
natnayr
changed the title
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af462a6e0a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if !re.is_match(&cw_event.log_stream)? { | ||
| info!( | ||
| "Skipping log stream '{}' - doesn't match filter", | ||
| cw_event.log_stream | ||
| ); | ||
| return Ok(vec![]); | ||
| } |
There was a problem hiding this comment.
This early-return path skips export but leaves cw.log.group / cw.log.stream / cw.owner already written into the shared MetadataContext, which is reused across records in the Kinesis loop (src/logs/mod.rs). If a later record in the same invocation falls back to raw text (non-CloudWatch JSON), it can be exported with CloudWatch metadata from the previously filtered record, producing incorrect metadata when ADD_METADATA includes CloudWatch fields. Move CW metadata insertion after the filter match (or clear it before returning) to prevent cross-record contamination.
Useful? React with 👍 / 👎.
4 participants
Description
Add
LogStreamFilterparameter to filter CloudWatch log events by log stream name before shipping to Coralogix.Closes #170
Use Case
AWS Amplify Hosting (SSR/WEB_COMPUTE) writes all branch logs to a single CloudWatch log group (
/aws/amplify/<app-id>), with each branch writing to its own log stream using the pattern<branch-name>/<instance-id>.Previously, there was no way to ship
developbranch logs to Stage andmainbranch logs to Prod - both shippers would receive all events, resulting in duplicated ingestion.With
LogStreamFilter, users can deploy two shipper stacks pointing to the same log group with different filters:LogStreamFilter: ^develop/LogStreamFilter: ^main/Changes
log_stream_filter: Option<Regex>field, pre-compiled at cold start for zero overhead when unsetprocess_cloudwatch_logs()when stream doesn't matchLogStreamFilterparameter, condition, and environment variableChecklist: