New component: Named Pipe Receiver

[sinkingpoint]

The purpose and use-cases of the new component

It's sometimes useful to be able to sends telemetry to a collector running on a node over a named pipe, rather than having to deal with the overhead of network protocols, or the inherent disk buffering of writing to a file. I'd like to propose a receiver that has the ability to create a named pipe, and then read logs off of it, similar to https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/tcplogreceiver or https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filereceiver

Example configuration for the component

receivers:
  pipes:
    - path: /pipes/logs1
    - path: /pipes/logs2
      mode: 0600
  encoding: utf-8
  multiline: # A split.Config
    line_end_pattern: "\n"
  preserve_trailing_whitespaces: false # A trim.Config

I suspect the complete config would end up looking something like the filereceiver one, with multiline config etc.

Telemetry data types supported

Logs

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

@sinkingpoint

Sponsor (optional)

@djaglowski

Additional context

No response

[bryan-aguilar]

Hey, @sinkingpoint

Thank you for the new component proposal. If you have not already please make sure you review the new component guidelines.

If you have not found a volunteer sponsor yet then I encourage you to come to our weekly collector sig meetings. You can add an item to the agenda to discuss this new component proposal.

[atoulme]

We discussed during the APAC SIG - idea looks good, no objections. @djaglowski it seems this would build best on stanza, do you see any trouble with this approach? Would you be interested to sponsor perhaps?

[djaglowski]

I think it makes a lot of sense as a stanza input operator, which is then wrapped into a receiver. I'm willing to sponsor this.

@sinkingpoint, are you good with first writing the stanza input operator only? From there it should be fairly straightforward to create the receiver.

[sinkingpoint]

Thanks @djaglowski , appreciate it. Happy to write the stanza operator - I'll work on it next week

[sinkingpoint]

Looking around the code, would it make sense to follow the same pattern as the file receiver and further abstract the logic into a namedpipeconsumer (or adapt the existing fileconsumer), or keep it self contained as an input module?

[djaglowski]

I definitely don't think we should add anything to fileconsumer package, as it's already complicated enough trying to do one thing. There may be some functionality we need to pull out of there and share, but I'm not convinced this is the case.

I think it probably makes sense to first try a full implementation within pkg/stanza/operator/input/namedpipe. If there's a specific reason we can't do a fully separate implementation there (e.g. duplicating complex code), let's talk about those details.

Off the top of my head, I think the biggest area of duplication is going to be in splitting, trimming, flushing, etc. However, all of this functionality is already separated into distinct packages which can be composed as needed. I think there may be a little bit of copying the way these are configured and the order of composition from fileconsumer, but ultimately I'm not convinced this functionality should be packed into a monolithic package, since other use cases only need a subset of it.