Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

port servicegraph processor code to connector #26092

Closed

Conversation

rlankfo
Copy link
Contributor

@rlankfo rlankfo commented Aug 24, 2023

Description:
This PR ports the deprecated servicegraph processor code to continue support on the connector.

Link to tracking Issue:
#26091

Testing:
make test

Documentation:
TODO: Documentation should be updated to include the new names of the featuregates which are changed from processor.servicegraph.* to connector.servicegraph.*

@github-actions github-actions bot requested review from jpkrohling and mapno August 24, 2023 05:15
@rlankfo rlankfo force-pushed the rlankfo/servicegraphconnector branch 2 times, most recently from 9d867c6 to 4d7c3fc Compare August 24, 2023 05:31
Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a question about the metrics consumer when creating a new connector, but other than that, LGTM. I verified that the business of this connector matches the one from the processor.

type Config struct {

// MetricsExporter is the name of the metrics exporter to use to ship metrics.
MetricsExporter string `mapstructure:"metrics_exporter"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this as a connector? Won't the connector get a metrics consumer on its TracesToMetrics constructor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this anymore. Good catch!

func (p *serviceGraphConnector) Start(_ context.Context, host component.Host) error {
p.store = store.NewStore(p.config.Store.TTL, p.config.Store.MaxItems, p.onComplete, p.onExpire)

if p.metricsConsumer == nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks odd: as a traces to metrics connector, I'd expect the metrics consumer to always be set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should always be set -- this is also left over from the processor logic. I removed these nil checks in another place but missed this one.

connector/servicegraphconnector/factory.go Outdated Show resolved Hide resolved
connector/servicegraphconnector/connector.go Outdated Show resolved Hide resolved
Copy link
Contributor Author

@rlankfo rlankfo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review @jpkrohling

The leftover MetricsExporter on the config and the nil checks on the metricsConsumer were leftover behavior from the processor. I removed some of this behavior initially but missed these spots you called out.

I also removed the legacy metric name feature gate.

type Config struct {

// MetricsExporter is the name of the metrics exporter to use to ship metrics.
MetricsExporter string `mapstructure:"metrics_exporter"`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this anymore. Good catch!

func (p *serviceGraphConnector) Start(_ context.Context, host component.Host) error {
p.store = store.NewStore(p.config.Store.TTL, p.config.Store.MaxItems, p.onComplete, p.onExpire)

if p.metricsConsumer == nil {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should always be set -- this is also left over from the processor logic. I removed these nil checks in another place but missed this one.

@rlankfo rlankfo force-pushed the rlankfo/servicegraphconnector branch from 3997a00 to 6d81c76 Compare September 8, 2023 06:28
@rlankfo rlankfo marked this pull request as ready for review September 8, 2023 06:28
@rlankfo rlankfo requested a review from a team September 8, 2023 06:28
@rlankfo rlankfo requested a review from jpkrohling September 8, 2023 06:33
@rlankfo rlankfo force-pushed the rlankfo/servicegraphconnector branch from 8279de5 to 4a9d497 Compare September 8, 2023 16:17
Copy link
Contributor

@mapno mapno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

When is the processor removed?

Comment on lines +30 to +35
virtualNodeFeatureGate = featuregate.GlobalRegistry().MustRegister(
virtualNodeFeatureGateID,
featuregate.StageAlpha,
featuregate.WithRegisterDescription("When enabled, when the edge expires, connector checks if it has peer attributes(`db.name, net.sock.peer.addr, net.peer.name, rpc.service, http.url, http.target`), and then aggregate the metrics with virtual node."),
featuregate.WithRegisterReferenceURL("https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/17196"),
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, it's a good opportunity to remove this gate and instead default to a smaller number of attributes or none

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @mapno that sounds good to me. I will make these changes and request another review.

Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the feature gate, this looks good. I have a question about the future of this component though: should we strive to combine this with the span metrics connector? If this is something to consider for the future, do we need this connector here as an intermediary step between the processor and the span metrics connector?

connector/servicegraphconnector/config.go Outdated Show resolved Hide resolved
@rlankfo
Copy link
Contributor Author

rlankfo commented Sep 11, 2023

When is the processor removed?

I didn't have a plan to remove the processor yet, but once this is merged I suppose there's no reason not to remove it? cc @jpkrohling

@rlankfo
Copy link
Contributor Author

rlankfo commented Sep 11, 2023

I have a question about the future of this component though: should we strive to combine this with the span metrics connector? If this is something to consider for the future, do we need this connector here as an intermediary step between the processor and the span metrics connector?

@jpkrohling I'd like to see this functionality combined with the span metrics connector. I think this code change probably makes sense still given that the connector already exists and the processor is deprecated. What do you think?

@jpkrohling
Copy link
Member

I'd like to see this functionality combined with the span metrics connector.

Let's get it there then. The current connector is in alpha state, we can still easily deprecate/remove it. I'll open an issue to discuss that with the current code owner (@albertteoh).

@jpkrohling
Copy link
Member

Opened #26648 to discuss this.

@github-actions
Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions bot added the Stale label Sep 27, 2023
@rlankfo rlankfo closed this Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants