Skip to content

[metricbeat] migrate rabbitmq to reporterv2 with error return#12228

Merged
fearful-symmetry merged 4 commits intoelastic:masterfrom
fearful-symmetry:migration/reporterv2error/rabbitmq
May 30, 2019
Merged

[metricbeat] migrate rabbitmq to reporterv2 with error return#12228
fearful-symmetry merged 4 commits intoelastic:masterfrom
fearful-symmetry:migration/reporterv2error/rabbitmq

Conversation

@fearful-symmetry
Copy link
Copy Markdown
Contributor

@fearful-symmetry fearful-symmetry commented May 21, 2019

See #11374

This is definitely one of the most complicated migrations yet, and I ended up doing a lot of refactoring to clean up the error handling. I could have done more, but I decided not to go too overboard.

There's a lot of calling r.Event inside a loop, which means we need to revert to our pre-ReporterV2 error handling.

@fearful-symmetry fearful-symmetry added Metricbeat Metricbeat Team:Integrations Label for the Integrations team technical_debt labels May 21, 2019
@fearful-symmetry fearful-symmetry requested a review from a team May 21, 2019 20:22
@fearful-symmetry fearful-symmetry self-assigned this May 21, 2019
evt, err := eventMapping(node)
if err != nil {
errors = append(errors, err)
m.Logger().Errorf("error in mapping: %s", err)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why do you need to log this here if you are reporting it next?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Reporting the error will not log it. So the error reported is for the UI / Kibana, the one logged for the operator.

Not sure if we should really log this on the error level.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Really? I figured if an event was getting thrown out that would be an error.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

In the past we had the problem that when some fields were missing, the schema.Apply returned an error which caused error logs inside. It meant just the event was not complete but it was not dropped. But since then @jsoriano made a few improvements to the schema handling. Please double check on where the errors come from and if these to an actual error happened (not a missing field) +1 on logging it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Is there a way to do that? The only time eventMapping will return an error is if schema.Apply fails, and that returns a multi-error structure.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Looking around the source, the error from schema.Apply() is handled...inconsistently.

 grep -rn "err := schema\.Apply" . | wc -l
      14
grep -rn "_ := schema\.Apply" . | wc -l
      16

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

So, we can mark certain values in the schema as required, but then that raises the issue of exactly what is required.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

But I suppose we can set FailOnRequired and at least that'll improve things?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just curious how did you pick vhost, host and node in this case? maybe name should be required as well?

@fearful-symmetry
Copy link
Copy Markdown
Contributor Author

Okay, so I just put in another PR to use FailOnRequired for the connections metricset, with the idea being that we're limiting the scope of when we get an actual error back from Apply()

I marked three fields as required:

		"vhost":       c.Str("vhost", s.Required),
		"user":        c.Str("user", s.Required),
		"node":        c.Str("node", s.Required),

As eventMapping touches them. The original author's intention as far as error handling is ambiguous, as eventMapping would return the error if the last of those three fields wasn't found.

Copy link
Copy Markdown
Contributor

@kaiyan-sheng kaiyan-sheng 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 answering my question, looks good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Metricbeat Metricbeat Team:Integrations Label for the Integrations team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants