[receiver/azure_functions] Initial implementation to receive logs from Azure Functions triggered by Event Hub by tetianakravchenko · Pull Request #47050 · open-telemetry/opentelemetry-collector-contrib

tetianakravchenko · 2026-03-19T21:36:26Z

Description

Follow up of #46584
This is the initial implementation of the new azure_functions receiver.
Focus of this PR:

adds support for receiving logs from Azure Functions triggered by Event Hub
generalize the receiver to support trigger types beyond the Event Hub in future

Link to tracking issue

Fixes #43507

Testing

Corresponding Unit Test were added.

Documentation

Readme was adjusted to reflect PR changes

…rt event_hub trigger, only logs signal Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

MichaelKatsoulis · 2026-03-31T12:50:20Z

+
+	mux := http.NewServeMux()
+	// TODO: Refactor so Start() collects path+profile specs from each trigger (logs and, later, metrics) and registers them in one loop; adding a trigger or signal should not duplicate registration logic here.
+	if r.cfg.EventHub != nil && len(r.cfg.EventHub.Logs) > 0 {


Should the server start regardless of this configuration? If EventHub is nil or there are no EventHub.Logs configured there will be no route configured

the server will start if correct http_config configuration is provided, but yes: if EventHub is nil or there are no EventHub.Logs configured, there will be no invoke routes
routes and corresponding profiles are created from the config (event_hub.logs only, for now), there are no default triggers

Should we flag this early in the config Validate()? There's no point in moving forward with the startup sequence if we have zero bindings.

Validate() should require at least one trigger.

@zmoog my initial idea was to keep it this way for now, and when more triggers are added, add validation for at least one trigger with at least 1 binding is configured, to avoid making an event hub configuration required now
I've addressed this in 38fff2e, please have another look

MichaelKatsoulis · 2026-03-31T12:53:54Z

+			p.protocol.Failure(w, fmt.Errorf("read body: %w", err), nil)
+			return
+		}
+		defer r.Body.Close()


This should be defered before body, err := io.ReadAll(r.Body) to catch an early error in io.ReadAll

MichaelKatsoulis · 2026-03-31T13:03:26Z

+			res.Attributes().PutStr(k, v)
+		}
+	}
+}


Is import cycles the only reason for a new package here? It's a bit confusing naming it handler, when there is also a handler.go file.

In my view this just includes types. I don't know if there are future plans for this package to include more functionality.

Yes, it was the main driver, also to place shared behavior used by consumers (not much for now).
Agree the overlap with handler.go is confusing, we can rename to something like internal/invoke, wdyt?

In my view this just includes types. I don't know if there are future plans for this package to include more functionality.

I was trying to keep implementation generic and easy to extend to support trigger types other than the Event Hub as discussed with @zmoog

Yes, it was the main driver, also to place shared behavior used by consumers (not much for now).

Why not internal/common ?
@zmoog do you agree? I am not blocking on this

renamed to common to avoid naming confusion

internal/common fails with the error: avoid meaningless package names, renamed to trigger as it contains common types for all triggers

I like trigger! 👍

MichaelKatsoulis

I just left some nits

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

… error: avoid meaningless package names Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

tetianakravchenko · 2026-04-08T11:11:41Z

@jmacd could you please have a look at this PR?

zmoog

@tetianakravchenko, nice work! I've noted a few minor things we could refine, but I'm happy to ship it in its current state, if needed.

zmoog · 2026-04-14T11:23:38Z

+
+	mux := http.NewServeMux()
+	// TODO: Refactor so Start() collects path+profile specs from each trigger (logs and, later, metrics) and registers them in one loop; adding a trigger or signal should not duplicate registration logic here.
+	if r.cfg.EventHub != nil && len(r.cfg.EventHub.Logs) > 0 {


Should we flag this early in the config Validate()? There's no point in moving forward with the startup sequence if we have zero bindings.

Validate() should require at least one trigger.

zmoog · 2026-04-14T11:24:48Z

+			res.Attributes().PutStr(k, v)
+		}
+	}
+}


I like trigger! 👍

zmoog · 2026-04-14T11:29:06Z

+	if merged.LogRecordCount() == 0 {
+		return errors.New("no logs to consume")
+	}


Suggested change

if merged.LogRecordCount() == 0 {

return errors.New("no logs to consume")

}

if merged.LogRecordCount() == 0 {

// Decision: Log events that result in zero records are treated

// as anomalies and rejected as permanent errors.

return errors.New("no logs to consume")

}

Since this logic is a bit subtle, I'm calling it out explicitly so that reviewers and code-owners can push back if this doesn't align with our standards.

zmoog · 2026-04-14T11:37:59Z

+	w.Header().Set("Content-Type", "application/json")
+	if _, err := w.Write(data); err != nil {
+		http.Error(w, fmt.Sprintf("write response: %v", err), http.StatusInternalServerError)
+	}


Suggested change

w.Header().Set("Content-Type", "application/json")

if _, err := w.Write(data); err != nil {

http.Error(w, fmt.Sprintf("write response: %v", err), http.StatusInternalServerError)

}

w.Header().Set("Content-Type", "application/json")

_, _ = w.Write(data) // headers are flushed on Write; nothing useful we can do on error

}

zmoog · 2026-04-14T11:47:27Z

+// profile binds a method name (binding/path) to a Protocol and Consumer.
+// The generic HTTP handler uses it to: parse request with protocol, then consume with consumer.
+type profile struct {
+	method   string


I think we should consider calling this binding instead of method.

My current understanding is the Function Host sets the Data.<name> in the HTTP request using the binding name from the <function-name/function.json:

{ "bindings": [ { "type": "eventHubTrigger", "name": "logs", // <———— 👀 "direction": "in", "eventHubName": "logs", "connection": "EventHubConnectionString", "cardinality": "many", "consumerGroup": "ecf", "dataType": "binary" } ] }

zmoog · 2026-04-14T11:48:46Z

  azure_functions:
    # HTTP server configuration
-    http:
+    http_config:


Since this PR contains the very first azure functions receiver working implementation, I don't think we need to handle a formal breaking change.

IMO no actions needed here.

zmoog · 2026-04-14T12:00:15Z

The Azure Functions host is the only client here, but the request size depends on the trigger — for Event Hub it's (max message size × batch count × base64 overhead).

Consider adding a max_request_body_size field to the top-level config with a generous
default (e.g. 100 MB) and wrapping the read:

    body, err := io.ReadAll(io.LimitReader(r.Body, maxRequestBodySize))

100 MB covers the worst realistic Event Hub scenario (20 MB premium messages ×
a few dozen batch size × 1.33 base64 overhead) while protecting against unbounded reads.

Future triggers should evaluate their own payload characteristics and document whether
the default is appropriate or needs to be adjusted.

And the config change would look like:

type Config struct {
      HTTP     *confighttp.ServerConfig `mapstructure:"http_config"`
      Auth     component.ID             `mapstructure:"auth"`
      EventHub *EventHubTriggerConfig   `mapstructure:"event_hub"`

      // MaxRequestBodySize is the maximum allowed size of an incoming invoke request body.
      // Defaults to 100 MB, which covers premium Event Hub tiers (20 MB messages)
      // with large batch sizes and base64 encoding overhead.
      // Future trigger types should verify this default fits their payload profile.
      MaxRequestBodySize int64 `mapstructure:"max_request_body_size"`
}

With the default set in the factory:

func createDefaultConfig() component.Config {
      return &Config{
              MaxRequestBodySize: 100 * 1024 * 1024, // 100 MB
      }
}

This keeps it simple — one field, one LimitReader, and a comment trail for whoever adds the next trigger type.

tetianakravchenko · 2026-04-20T10:46:20Z

@zmoog thank you for the review!

The Azure Functions host is the only client here, but the request size depends on the trigger — for Event Hub it's (max message size × batch count × base64 overhead).

Consider adding a max_request_body_size field to the top-level config with a generous
default (e.g. 100 MB) and wrapping the read:
  body, err := io.ReadAll(io.LimitReader(r.Body, maxRequestBodySize))
100 MB covers the worst realistic Event Hub scenario (20 MB premium messages ×
a few dozen batch size × 1.33 base64 overhead) while protecting against unbounded reads.

in this case we might end up processing a truncated payload without noticing, additionally there is another existing max request body: https://pkg.go.dev/go.opentelemetry.io/collector/config/confighttp#ServerConfig:

// MaxRequestBodySize sets the maximum request body size in bytes. Default: 20MiB.
	MaxRequestBodySize [int64](https://pkg.go.dev/builtin#int64) `mapstructure:"max_request_body_size,omitempty"`

I think it is better to avoid two competing limits, wdyt?

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

tetianakravchenko · 2026-04-21T08:14:00Z

@constanca-m @jmacd could you please have a look at this PR?

constanca-m

Thanks! Looks very good. I am relying a bit on @zmoog review here, even though I have read the whole code now. Just two question, but LGTM

constanca-m · 2026-04-20T10:20:25Z

-
-	// Logs defines configuration for log records received from Azure Functions.
-	Logs EncodingConfig `mapstructure:"logs"`
+	HTTP *confighttp.ServerConfig `mapstructure:"http_config"`


http_config name is a bit awkward. Usually it is just squashed or called http. Is there a reason why you changed it?

For context, here's what the current config.yaml looks like:

azure_functions: http_config: endpoint: test:123 auth: azureauth event_hub: logs: # signal (logs, metrics, traces) - name: logs # event hub name encoding: azure_encoding - name: raw_logs # event hub name encoding: beats_encoding

In the above example, event_hub is the trigger type, then we have logs for the signal type, and the actual event hub name/encoding with the mapping to the encoding extension to use.

Since this is an Azure Functions receiver, in the future we'll possibly have more trigger types, like timer or http triggers. So, if we keep the trigger type at the root level we can't use http.

The alternative is to make the trigger explicit, like this:

azure_functions: http: endpoint: test:123 auth: azureauth triggers: event_hub: logs: # signal (logs, metrics, traces) - name: logs # event hub name encoding: azure_encoding - name: raw_logs # event hub name encoding: beats_encoding

@constanca-m, how does this look?

Adding triggers feels a bit redundant now, but having all the trigger types in one bucket seems tidier. I’m going to make this change and revert to the idiomatic config option. Sorry for the back-and-forth, @tetianakravchenko!

@zmoog I've changed it in c6862fe

constanca-m · 2026-04-21T10:31:19Z

+		errs = append(errs, errors.New("at least one configured trigger with at least one binding is required"))
+	}
+
+	if cfg.EventHub != nil {


Is it possible for event hub to be nil? I thought it was mandatory for the receiver to work properly, but maybe I am wrong

Since the event hub is the only trigger now, we can simply aassume it's required. WDYT?

for now only event hub trigger is supported, but I tried to keep it generic - so instead of making event hub required, there is a check above: "at least one configured trigger with at least one binding is required"

This works for me.

zmoog · 2026-04-21T15:08:35Z

in this case we might end up processing a truncated payload without noticing, additionally there is another existing max request body: https://pkg.go.dev/go.opentelemetry.io/collector/config/confighttp#ServerConfig:
// MaxRequestBodySize sets the maximum request body size in bytes. Default: 20MiB.
	MaxRequestBodySize [int64](https://pkg.go.dev/builtin#int64) `mapstructure:"max_request_body_size,omitempty"`
I think it is better to avoid two competing limits, wdyt?

LGTM.

tetianakravchenko · 2026-04-22T09:28:33Z

Hi @jmacd, all required codeowner approvals are in - is there anything else needed from my side before this is ready to merge?

…ger types in one bucket Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

tetianakravchenko added 4 commits March 17, 2026 16:14

add azure_functions implementation, make configuration generic; suppo…

e98acda

…rt event_hub trigger, only logs signal Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

fix readme; add handler and logs+consumer test

9e5ddae

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

clean up; address linter issues

7de58f2

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

add changelog record

c25e046

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

tetianakravchenko requested review from a team and jmacd as code owners March 19, 2026 21:36

github-actions Bot assigned VihasMakwana Mar 19, 2026

github-actions Bot added the receiver/azurefunctions label Mar 19, 2026

tetianakravchenko added 4 commits March 19, 2026 22:46

fix encoding name in test

807958c

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

fix make checkapi errors

29083c9

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

run make goporto

f994fd9

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Merge branch 'main' into azurefunctions-eventhub

4543086

tetianakravchenko mentioned this pull request Mar 30, 2026

New component: azure functions receiver #43507

Open

MichaelKatsoulis reviewed Mar 31, 2026

View reviewed changes

address review comment

641786c

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

github-actions Bot requested a review from constanca-m April 2, 2026 10:45

MichaelKatsoulis approved these changes Apr 2, 2026

View reviewed changes

tetianakravchenko added 3 commits April 2, 2026 19:25

rename handler package to common

2bdc83e

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Merge branch 'main' into azurefunctions-eventhub

0ecb5b0

run generate-schemas; rename common package to trigger to fix linting…

3dafa18

… error: avoid meaningless package names Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Merge branch 'main' into azurefunctions-eventhub

fcc47a8

zmoog reviewed Apr 14, 2026

View reviewed changes

tetianakravchenko added 2 commits April 20, 2026 12:49

address review comments

38fff2e

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Merge branch 'main' into azurefunctions-eventhub

ef9075c

constanca-m approved these changes Apr 21, 2026

View reviewed changes

tetianakravchenko added 2 commits April 22, 2026 17:08

replace http_config with http; add triggers section to group all trig…

c6862fe

…ger types in one bucket Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

add _ struct{} to TriggersConfig struct to pass make checkapi

15acf15

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

Conversation

tetianakravchenko commented Mar 19, 2026

Description

Link to tracking issue

Testing

Documentation

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!

tetianakravchenko Apr 20, 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!

MichaelKatsoulis left a comment

Choose a reason for hiding this comment

Uh oh!

tetianakravchenko commented Apr 8, 2026

Uh oh!

zmoog left a comment

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!

zmoog Apr 14, 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!

zmoog commented Apr 14, 2026

Uh oh!

tetianakravchenko commented Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tetianakravchenko commented Apr 21, 2026

Uh oh!

constanca-m left a comment

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

tetianakravchenko Apr 20, 2026 •

edited

Loading

zmoog Apr 14, 2026 •

edited

Loading

tetianakravchenko commented Apr 20, 2026 •

edited

Loading