[exporter/sumologic] use generated status header

[codeboten]

This PR updates the component to generate the status table using mdatagen. Questions to the code owners:

Does this component require any of the standard warnings? See list: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/standard-warnings.md

See related issue: #19172

[runforesight]

Foresight Summary

    
Major Impacts

build-and-test-windows duration(7 seconds) has decreased 30 minutes 13 seconds compared to main branch avg(30 minutes 20 seconds).

View More Details

⭕  changelog workflow has finished in 5 seconds (2 minutes 9 seconds less than main branch avg.) and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
changelog	-     🔗	N/A	See Details

---

⭕  build-and-test-windows workflow has finished in 7 seconds (31 minutes 59 seconds less than main branch avg.) and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
windows-unittest-matrix	-     🔗	N/A	See Details
windows-unittest	-     🔗	N/A	See Details

---

✅  telemetrygen workflow has finished in 57 seconds and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
build-dev	-     🔗	N/A	See Details
publish-latest	-     🔗	N/A	See Details
publish-stable	-     🔗	N/A	See Details

---

✅  check-links workflow has finished in 1 minute 31 seconds and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
changed files	-     🔗	N/A	See Details
check-links	-     🔗	N/A	See Details

---

✅  prometheus-compliance-tests workflow has finished in 3 minutes 4 seconds (3 minutes 15 seconds less than main branch avg.) and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
prometheus-compliance-tests	-     🔗	N/A	See Details

---

✅  load-tests workflow has finished in 6 minutes 29 seconds (3 minutes 51 seconds less than main branch avg.) and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
setup-environment	-     🔗	N/A	See Details
loadtest (TestIdleMode)	-     🔗	N/A	See Details
loadtest (TestBallastMemory|TestLog10kDPS)	-     🔗	N/A	See Details
loadtest (TestMetric10kDPS|TestMetricsFromFile)	-     🔗	N/A	See Details
loadtest (TestMetricResourceProcessor|TestTrace10kSPS)	-     🔗	N/A	See Details
loadtest (TestTraceNoBackend10kSPS|TestTrace1kSPSWithAttrs)	-     🔗	N/A	See Details
loadtest (TestTraceBallast1kSPSWithAttrs|TestTraceBallast1kSPSAddAttrs)	-     🔗	N/A	See Details
loadtest (TestTraceAttributesProcessor)	-     🔗	N/A	See Details

---

✅  e2e-tests workflow has finished in 13 minutes 14 seconds and finished at 5th Apr, 2023.

---

Job	Failed Steps	Tests
kubernetes-test (v1.26.0)	-     🔗	N/A	See Details
kubernetes-test (v1.24.7)	-     🔗	N/A	See Details
kubernetes-test (v1.23.13)	-     🔗	N/A	See Details
kubernetes-test (v1.25.3)	-     🔗	N/A	See Details

---

✅  build-and-test workflow has finished in 39 minutes 6 seconds (7 minutes 35 seconds less than main branch avg.) and finished at 11th Apr, 2023.

---

Job	Failed Steps	Tests
unittest-matrix (1.20, receiver-1)	-     🔗	N/A	See Details
unittest-matrix (1.20, processor)	-     🔗	N/A	See Details
unittest-matrix (1.20, exporter)	-     🔗	N/A	See Details
unittest-matrix (1.20, extension)	-     🔗	N/A	See Details
unittest-matrix (1.20, other)	-     🔗	N/A	See Details
unittest-matrix (1.19, receiver-0)	-     🔗	N/A	See Details
unittest-matrix (1.19, receiver-1)	-     🔗	N/A	See Details
unittest-matrix (1.19, processor)	-     🔗	N/A	See Details
unittest-matrix (1.19, exporter)	-     🔗	N/A	See Details
unittest-matrix (1.19, extension)	-     🔗	N/A	See Details
unittest-matrix (1.19, internal)	-     🔗	N/A	See Details
unittest-matrix (1.19, other)	-     🔗	N/A	See Details
unittest (1.20)	-     🔗	N/A	See Details
unittest (1.19)	-     🔗	N/A	See Details
cross-compile (darwin, amd64)	-     🔗	N/A	See Details
cross-compile (darwin, arm64)	-     🔗	N/A	See Details
cross-compile (linux, 386)	-     🔗	N/A	See Details
cross-compile (linux, amd64)	-     🔗	N/A	See Details
cross-compile (linux, arm)	-     🔗	N/A	See Details
cross-compile (linux, arm64)	-     🔗	N/A	See Details
cross-compile (linux, ppc64le)	-     🔗	N/A	See Details
cross-compile (windows, 386)	-     🔗	N/A	See Details
cross-compile (windows, amd64)	-     🔗	N/A	See Details
build-package (deb)	-     🔗	N/A	See Details
build-package (rpm)	-     🔗	N/A	See Details
windows-msi	-     🔗	N/A	See Details
publish-check	-     🔗	N/A	See Details
publish-dev	-     🔗	N/A	See Details
publish-stable	-     🔗	N/A	See Details
rotate-milestone	-     🔗	N/A	See Details

---

🔎 See details on Foresight

^{*You can configure Foresight comments in your organization settings page.}

[dmitryax]

Another Q to code owners: is this exporter needed given that there is https://github.com/SumoLogic/sumologic-otel-collector/tree/main/pkg/exporter/sumologicexporter ? :)

[andrzej-stencel]

Another Q to code owners: is this exporter needed given that there is https://github.com/SumoLogic/sumologic-otel-collector/tree/main/pkg/exporter/sumologicexporter ? :)

This is an excellent question 😅 and a long-running debate in our team. The history is, we originally created the Sumo Logic exporter in contrib, and then switched to keeping the sources together with the Sumo Logic Distribution for OpenTelemetry Collector at https://github.com/sumologic/sumologic-otel-collector. We have a couple other components in the distro repo, some of them more and some of them less fitting for the contrib repo.

The point I think we all agree on in the team is that we want to keep the presence of Sumo Logic components in the contrib repo as much as possible, big part of it being the popularity of the contrib release among end users.

After having another discussion in the team today, we're at a point where we want to move the Sumo Logic exporter back to the contrib repo. For that to make sense, we'd need to put the Sumo Logic extension in contrib repo as well, as it is an important part of the Sumo Logic exporter's functionality. Do you think it makes sense @dmitryax?

[dmitryax]

After having another discussion in the team today, we're at a point where we want to move the Sumo Logic exporter back to the contrib repo. For that to make sense, we'd need to put the Sumo Logic extension in contrib repo as well, as it is an important part of the Sumo Logic exporter's functionality. Do you think it makes sense @dmitryax?

I don't have any objections. I think it's ok to add vendor components other than receivers/exporters. We already have https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/datadogprocessor

cc @open-telemetry/collector-contrib-approvers

[TylerHelmuth]

Agreed, all our existing rules state vendor-specific components and not a specific type of component.