New component: sflow receiver

[Ishmeet]

The purpose and use-cases of the new component

Is your feature request related to a problem? Please describe.

I need to intake sflow data from device vendor switches like juniper qfx switches. And be able to export it to any suitable backend.

Describe the solution you'd like

Create a sflow receiver that translates the sflow packets OpenTelemetry format that is suitable for any exporter.

Example configuration for the component

 receivers:
  sflow:
    endpoint: 0.0.0.0:9995
    labels:
      mylabel1: value1
      mylabel2: value2

Telemetry data types supported

logs

Describe alternatives you've considered

Using Elastiflow to get sflow data. But we can't add custom logic in elastiflow, that we can have in Otel processors.

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)

@Ishmeet

Sponsor (optional)

No response

Additional context

Will be using google/gopacket Go library for API support. This makes serialization of the sflow protocols easy.

[Ishmeet]

PR: #28578

[fatsheep9146]

I think you should provide more info about this component in this pr or on the sig meeting in order to help reviewers to decide if they are willing to sponsor your component. @Ishmeet

[Ishmeet]

I think you should provide more info about this component in this pr or on the sig meeting in order to help reviewers to decide if they are willing to sponsor your component. @Ishmeet

Hi there @fatsheep9146 ,
I have updated with issue description with more info. Also, I will be maintaining this sflow receiver.
And who can or can't I assign a sponsor ? Can I assign the team lead from my organisation to be the sponsor...

[fatsheep9146]

@open-telemetry/collector-contrib-approvers @open-telemetry/collector-contrib-triagers Do you have any suggestions?

[atoulme]

Your sponsor is an approver or maintainer of the repository. Thank you for providing more information. Is your receiver vendor specific? If so, we will assign a sponsor to you.

[Ishmeet]

Your sponsor is an approver or maintainer of the repository. Thank you for providing more information. Is your receiver vendor specific? If so, we will assign a sponsor to you.

Hi there @atoulme ,
It is a vendor specific receiver.

[Ishmeet]

We plan on using it in a SAS based platform in production and juniper qfx switches emitting sflow data.
QFX device -> open telemetry sflow receiver -> transform processor -> suitable backends

[djaglowski]

@Ishmeet, my understanding of sFlow is that it is not a vendor specific protocol. If I'm mistaken, can you clarify which vendor the protocol is associated with and confirm that you are a representative of that vendor?

Otherwise, I don't think we can consider this a vendor-specific component according to our definition: A vendor-specific component directly interfaces with a vendor-specific API and is expected to be maintained by a representative of the same vendor.

This is important so we can determine whether or not a sponsor must be assigned, or whether a volunteer sponsor is required.

[Ishmeet]

@Ishmeet, my understanding of sFlow is that it is not a vendor specific protocol. If I'm mistaken, can you clarify which vendor the protocol is associated with and confirm that you are a representative of that vendor?

Otherwise, I don't think we can consider this a vendor-specific component according to our definition: A vendor-specific component directly interfaces with a vendor-specific API and is expected to be maintained by a representative of the same vendor.

This is important so we can determine whether or not a sponsor must be assigned, or whether a volunteer sponsor is required.

Hi there @djaglowski ,
You're correct, sflow is vendor neutral. I understood incorrectly, I thought it meant with which vendor I am using this sflow receiver till now. So, my response to that would have been with juniper qfx switch, that is a specific vendor. But sflow is not vendor specific, there are no vendor specific API's invoked. I apologise for causing a confusion.

I am trying to understand the sponsors, and what can I do getting that and getting this PR merged. If anything is needed from me, let me know.
Happy to help.

[djaglowski]

No worries @Ishmeet, thanks for clarifying.

Since it doesn't meet our definition for vendor neutral component, an approver or maintainer on this repo will have to volunteer to help maintain the component. Unfortunately, even some good components go unsponsored due to lack of bandwidth. If you are unable to find a sponsor, I encourage you to develop and host the component in another repository and include it in custom build of the collector using the collector builder.

[Ishmeet]

No worries @Ishmeet, thanks for clarifying.

Since it doesn't meet our definition for vendor neutral component, an approver or maintainer on this repo will have to volunteer to help maintain the component. Unfortunately, even some good components go unsponsored due to lack of bandwidth. If you are unable to find a sponsor, I encourage you to develop and host the component in another repository and include it in custom build of the collector using the collector builder.

Hi there @djaglowski ,

I didn't fully understood what you meant there. Can you please elaborate a bit more or point me to an already existing project.
My understanding was all the receivers exists here in opentelemetry-collector-contrib repo and using collector builder it creates a binary containing all components and releases it. And this sflowreceiver will be another additional component to the existing receivers.

Do you mean, creating a new repo in my personal GitHub profile and use the collector builder to host all components along with this sflowreceiver ?

[crobert-1]

Do you mean, creating a new repo in my personal GitHub profile and use the collector builder to host all components along with this sflowreceiver ?

Yes, that's the general idea. The contrib repository has specific requirements for components to be included whereas you're welcome to create your own repository with existing components (or your own created components), without having to worry about the rules of this repository.

[Ishmeet]

Do you mean, creating a new repo in my personal GitHub profile and use the collector builder to host all components along with this sflowreceiver ?

Yes, that's the general idea. The contrib repository has specific requirements for components to be included whereas you're welcome to create your own repository with existing components (or your own created components), without having to worry about the rules of this repository.

ok,
this repo has the sflowreceiver https://github.com/Ishmeet/opentelemetry-collector-custom-components.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.