[AWSX-3190] feat(go-forwarder): log model and parsing logic by ndakkoune · Pull Request #1088 · DataDog/datadog-serverless-functions

ndakkoune · 2026-03-27T13:57:47Z

What does this PR do?

Set up log parsing and model logic.

Motivation

Following the migration of the Lambda Log Forwarder to Go, the log model is a necessary and critical step that will dictate how the data flow.

Testing Guidelines

Additional Notes

The natural divergence of both the log events received by the Lambda and the outbound payload sent to Datadog needs a model as generic as possible. The most noticeable design choices are :

The CloudwatchLogsContext and CloudwatchLogsLogEvent types that closely mimic some of their equivalents in the github.com/aws/aws-lambda-go/events package.
The LogContent interface is responsible to return its own Message(), required in the future steps (e.g. scrubbing) and MarshalFields(), responsible to return the top-level fields to match the intake API format (different for each event source for S3 invocations, especially for CloudTrail).
LogEntry.MarshalJSON() is the custom marshaler that merges Content.MarshalFields() so that each LogEntry is serialized to the correct format.

Types of changes

Bug fix
New feature
Breaking change
Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

This PR's description is comprehensive
This PR contains breaking changes that are documented in the description
This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
This PR impacts documentation, and it has been updated (or a ticket has been logged)
This PR's changes are covered by the automated tests
This PR collects user input/sensitive content into Datadog
This PR passes the integration tests (ask a Datadog member to run the tests)
This PR passes the unit tests
This PR passes the installation tests (ask a Datadog member to run the tests)

ndakkoune · 2026-03-27T13:59:41Z

 	"log/slog"
 )

+var ForwarderVersion = "dev"


Used for ldflags

ndakkoune · 2026-03-27T14:23:08Z

+
+// detectInvokationSource inspects the raw JSON to determine the invokation type.
+func detectInvokationSource(event json.RawMessage) invokationSource {
+	var probe struct {


Even though this is not very clean, I don't see another way to detect the invokation type apart from unmarshalling the whole JSON (way more expensive).

ndakkoune · 2026-03-27T14:24:52Z

+
+	if err := json.Unmarshal(event, &probe); err != nil {
+		slog.Error("failed unmarshal", slog.Any("error", err))
+		return invokationSourceUnknown


Will log a double error from both the unmarshalling + unknown source. Fair ?

ndakkoune · 2026-03-27T14:25:43Z

+	"github.com/DataDog/datadog-serverless-functions/aws/logs_monitoring_go/internal/model"
+)
+
+type invokationSource int


Decided to replace the old AWSEventSource by invokationSource, which is way more explicit.

ndakkoune · 2026-03-28T20:39:09Z

+	Service string
+	Host    string
+	Tags    string
+	AWS     *AWSMetadata


Pointer here because its shared between all log entries.

It doesn't need to be a pointer for this, we can copy it on each LogEntry. it will not escape to the heap and might be more efficient in the end.

ViBiOh · 2026-03-30T07:04:04Z

+	UseFIPS    bool
+	Source     string
+	Host       string
+	CustomTags string


💬 suggestion: ‏ We'll mainly used them as a slice of string, so it might be interesting to convert the string directly to a slice when loading the config.

I agree for CustomTags (and maybe UseFIPS) since we'll append all the specified tags (e.g. env:prod,team:aws) along with other tags such as forwarder_version. However, Source and Host belong other top-level fields (i.e. ddsource:X and host:Y) and I don't see any benefit from that.

ViBiOh · 2026-03-30T07:07:03Z

+	Service string
+	Host    string
+	Tags    string
+	AWS     *AWSMetadata


It doesn't need to be a pointer for this, we can copy it on each LogEntry. it will not escape to the heap and might be more efficient in the end.

ViBiOh · 2026-03-30T07:08:49Z

+	case invocationSourceCloudwatchLogs:
+		parseCloudwatchLogs(ctx, event, cfg, out)
+	default:
+		slog.Error("unsupported invocation source")


💬 suggestion: ‏ Add the event as a log field, otherwise it will be complex to debug.

ViBiOh · 2026-03-30T07:16:19Z

+	if err := json.Unmarshal(event, &probe); err != nil {
+		slog.Error("failed unmarshal", slog.Any("error", err))
+		return invocationSourceUnknown
+	}
+


Benchmark this and try the decoder approach

Will make a separate PR for this. Thank you!

ge0Aja · 2026-03-30T11:52:26Z

+type CloudwatchLogsContent struct {
+	ID        string `json:"id"`
+	Timestamp int64  `json:"timestamp"`
+	Msg       string `json:"message"`


nit: prefer to have complete variable names

ge0Aja · 2026-03-30T11:55:45Z

+func (CloudwatchLogsContext) InvocationKey() string { return "awslogs" }
+
+type CloudwatchLogsContent struct {
+	ID        string `json:"id"`


what's the ID here ?

ge0Aja · 2026-03-30T11:57:11Z

+	return c.Msg
+}
+
+func (c CloudwatchLogsContent) MarshalFields() (map[string]any, error) {


nit: Marshal gives the impression that the output should be a json string, instead we're getting a map. we should either rename the function, or implement as it says

ge0Aja · 2026-03-30T11:58:00Z

+	Service string
+	Host    string
+	Tags    []string
+	AWS     AWSMetadata


please rename the variable to match the type suggestion: Metadata

…ove pointer to AWSMetadata

ndakkoune · 2026-03-31T09:27:13Z

+	ID        string      `json:"id,omitempty"`
+	Timestamp int64       `json:"timestamp,omitempty"`


These two lines are CloudwatchLogs specific. We'll probably have to put them as pointers in the future, so that they won't appear with their zero values when Marshalling. The other possibility would be to detect the zero values in the backend to deal with them properly (e.g. timestamp: 0 => impossible => generate current timestamp).

ndakkoune · 2026-03-31T09:28:45Z

+type AWSMetadata struct {
+	InvokedFunctionARN string                 `json:"invoked_function_arn"`
+	FunctionVersion    string                 `json:"function_version,omitempty"`
+	CloudwatchLogs     *CloudwatchLogsContext `json:"awslogs,omitempty"`


Adding the context here avoids us to write a custom MarshalJSON. Since there is only two invocation sources (i.e. CW and S3), it seems a good compromise.

if this is to be shared then I don't think we should adda a cloudwatch logs specific context here.

ndakkoune · 2026-03-31T09:30:02Z

+}
+
+func detectInvocationSource(event json.RawMessage) invocationSource {
+	var probe struct {


Will benchmark this and probably try the Decoder strategy.

yes, we did that for cloudtrail events if you're looking for specific keywords at the beginning of the raw json

ge0Aja · 2026-03-31T11:57:37Z

+
+type LogEntry struct {
+	ID        string      `json:"id,omitempty"`
+	Timestamp int64       `json:"timestamp,omitempty"`


regarding CloudwatchLogs specific. I thought we agreed to have a separate struct for cloudwatch logs, s3 records, and events. which should remove the need for optional fields.

also , did you check the timestamp format ? is it a linux timestamp or a different format ?

The timestamps provided by AWS are RFC3339, the Datadog intake endpoints ones expect unix epoch times.

Rectifying: Cloudwatch events are also unix epoch time, but S3/SQS/... are still RFC3339

ge0Aja · 2026-03-31T12:03:45Z

+type invocationSource int
+
+const (
+	invocationSourceUnknown invocationSource = iota


could we have this case ? unknown invocation source ? I think the default case in the switch should be enough

Nothing prevent a customer to create a trigger from an event source we do not support (e.g. Alexa, API Gateway, CloudFront, AppSync).

Btw the 0 value of iota would become the Cloudwatch one, which could be thought as a default case (we could _ invocationSource = iota to skip this).

ge0Aja · 2026-04-01T09:34:18Z

+	APIURL     string
+	LogLevel   string
+	UseFIPS    bool
+	Source     string


forwarder level source override (for all logs) if set by the customer

ge0Aja · 2026-04-01T09:50:05Z

+	return invocationSourceUnknown
+}
+
+func parseCloudwatchLogs(ctx context.Context, event json.RawMessage, cfg *config.Config, out chan<- model.CloudwatchLogEntry) {


suggestion: use emit function callback instead of passing the channel explicitly.

…rk (#1093)

github-actions Bot added the aws label Mar 27, 2026

ndakkoune commented Mar 27, 2026

View reviewed changes

ndakkoune commented Mar 28, 2026

View reviewed changes

ViBiOh reviewed Mar 30, 2026

View reviewed changes

ndakkoune marked this pull request as ready for review March 30, 2026 09:09

ndakkoune requested a review from a team as a code owner March 30, 2026 09:09

ndakkoune changed the title ~~parsing~~ [AWSX-3190] feat(go-forwarder): log model and parsing logic Mar 30, 2026

ge0Aja self-assigned this Mar 30, 2026

ge0Aja reviewed Mar 30, 2026

View reviewed changes

ndakkoune added 6 commits March 31, 2026 10:13

parsing

edd83db

perf: unmarshal strategy

bdd095d

rename invokation to invocation

83c7128

model

7cea52e

delete comments, add event logging, refactor Tags to []string and rem…

052f16d

…ove pointer to AWSMetadata

simplification

f9f52b4

ndakkoune force-pushed the nabil.dakkoune/AWSX-2143-1 branch from 49d7d3a to f9f52b4 Compare March 31, 2026 09:13

Time to Timestamp

d7e5e30

ndakkoune commented Mar 31, 2026

View reviewed changes

ndakkoune requested a review from ge0Aja March 31, 2026 09:30

add parsing tests

88eeaff

ge0Aja reviewed Mar 31, 2026

View reviewed changes

change model

9f86a01

ndakkoune requested a review from ge0Aja April 1, 2026 06:45

ge0Aja reviewed Apr 1, 2026

View reviewed changes

[AWSINTS-3377] perf(go-forwarder): from Unmarshal to Decode + benchma…

a2d0477

…rk (#1093)

ge0Aja approved these changes Apr 1, 2026

View reviewed changes

ndakkoune merged commit 5a38306 into nabil.dakkoune/go-forwarder Apr 1, 2026
10 checks passed

ndakkoune deleted the nabil.dakkoune/AWSX-2143-1 branch April 1, 2026 15:43

		ID string `json:"id,omitempty"`
		Timestamp int64 `json:"timestamp,omitempty"`

Conversation

ndakkoune commented Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Testing Guidelines

Additional Notes

Types of changes

Check all that apply

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ndakkoune Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ge0Aja Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ge0Aja Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

ndakkoune commented Mar 27, 2026 •

edited

Loading

ndakkoune Mar 27, 2026 •

edited

Loading

ge0Aja Mar 30, 2026 •

edited

Loading

ge0Aja Mar 31, 2026 •

edited

Loading