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

Logging: Configure the node name when we have it #32983

Merged
merged 18 commits into from
Sep 7, 2018

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Aug 20, 2018

Change the logging infrastructure to handle when the node name isn't
available in elasticsearch.yml. In that case the node name is not
available until long after logging is configured. The biggest change is
that the node name logging no longer fixed at pattern build time.
Instead it is read from a SetOnce on every print. If it is unset it is
printed as unknown so we have something that fits in the pattern.
On normal startup we don't log anything until the node name is available
so we never see the unknowns but we will see if if something fails
catastrophically before the we've recovered the node id or if you set
the log level to DEBUG or TRACE.

Closes #32793

Change the logging infrastructure to handle when the node name isn't
available in `elasticsearch.yml`. In that case the node name is not
available until long after logging is configured. The biggest change is
that the node name logging no longer fixed at pattern build time.
Instead it is read from a `SetOnce` on every print. If it is unset it is
printed as `-----` so we have something that fits in the pattern.
On normal startup we don't log anything until the node name is available
so we never see the `-----`s.
@nik9000 nik9000 added >bug blocker :Core/Infra/Logging Log management and logging utilities v7.0.0 v6.5.0 labels Aug 20, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@nik9000 nik9000 requested a review from rjernst August 20, 2018 12:07
@nik9000
Copy link
Member Author

nik9000 commented Aug 20, 2018

Failure is legit a thing I hadn't properly fixed up.

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

This contains a lot of hacks that muck up node initialization ordering. For example, we have slowly been removing places where we initialize temporary copies of environment/settings, yet this adds to it.

Instead, I think we could move nodeid reading/generation out of NodeEnvironment? It is a trivial method, and it could be passed into NodeEnvironment once we have read it at the beginning of Node construction.

NodeNamePatternConverter.setNodeName(nodeName);
/*
* Initialize the node name early if was set in elasticsearch.yml.
* If it wasn't, we'll set it further in startup.
Copy link
Member

Choose a reason for hiding this comment

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

nit: further in startup -> later in startup?

* This is ok because we don't generally log anything before
* we have the node name.
*/
nodeName = "-------";
Copy link
Member

Choose a reason for hiding this comment

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

maybe something like notset or unknown would be more obvious to users what is going on?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah. I'll see if I can do that.

'pidfile' : node.pidFile,
'path.repo' : "${node.sharedDir}/repo",
'path.shared_data' : "${node.sharedDir}/",
// Define a node attribute so we can test that it exists
'node.attr.testattr' : 'test'
]
if (node.config.addStandardNodeName) {
Copy link
Member

Choose a reason for hiding this comment

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

Could we do this without any new setting by changing the injection of settings to remove/omit when the value is null? This would then generally allow any settings to be removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that sounds more confusing then adding the setting. I mean, it is more flexible but I don't know that we need that flexibility.

Copy link
Member

Choose a reason for hiding this comment

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

Fewer settings on NodeConfiguration is better, IMO. It makes less logic on node setup.

@nik9000
Copy link
Member Author

nik9000 commented Aug 20, 2018

I think we could move nodeid reading/generation out of NodeEnvironment?

I'll investigate that.

@nik9000
Copy link
Member Author

nik9000 commented Aug 21, 2018

I think we could move nodeid reading/generation out of NodeEnvironment?

I'll investigate that.

A few of us talking and settled on a way to do move the automatic node name generation way earlier in the startup process but that way can't be backported to 6.5 and something must be backported because we're broken now if node name isn't in elasticsearch.yml. So we said that we were ok with the Consumer<String> hack that I used here, at least for now. With the intent that I'll propose something that'll remove it in master and it'll stay in 6.x forever.

public class NodeNamePatternConverter extends LogEventPatternConverter {
private static final SetOnce<String> NODE_NAME = new SetOnce<>();
public final class NodeNamePatternConverter extends LogEventPatternConverter {
/**
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not happy with this at all but it is another thing that I think we'll be able to remove it master in a follow up.

Copy link
Member Author

Choose a reason for hiding this comment

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

@jasontedor could you take a look at this when you get a chance? I'm well aware it isn't good but I'm not clear on whether it is disastrous or simply "something we shouldn't keep around for long".

Copy link
Member Author

Choose a reason for hiding this comment

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

I talked with @jasontedor and he'd prefer the volatile read over this so I'm switching back to it.

@nik9000
Copy link
Member Author

nik9000 commented Aug 24, 2018

@jasontedor this is ready for you to have a look now.

@nik9000
Copy link
Member Author

nik9000 commented Sep 5, 2018

@jasontedor could you have a look at this when you get a chance? I'm going to resolve the merge conflict on it now.

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

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

LGTM. One nit, I'm sorry.

* under the License.
*/

package org.elasticsearch.unconfigurednodename;
Copy link
Member

Choose a reason for hiding this comment

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

One nit, so sorry, can you change the suffix on this package name to unconfigured_node_name.

Copy link
Member Author

Choose a reason for hiding this comment

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

I always thought package names with underscores was somehow discouraged but I checked around and that doesn't seem to be the case. Adding the underscores makes it easier to read too so I'm just going to have to get used to them. I'll switch it like you ask.

@nik9000 nik9000 merged commit 190ea9a into elastic:master Sep 7, 2018
nik9000 added a commit that referenced this pull request Sep 8, 2018
Change the logging infrastructure to handle when the node name isn't
available in `elasticsearch.yml`. In that case the node name is not
available until long after logging is configured. The biggest change is
that the node name logging no longer fixed at pattern build time.
Instead it is read from a `SetOnce` on every print. If it is unset it is
printed as `unknown` so we have something that fits in the pattern.
On normal startup we don't log anything until the node name is available
so we never see the `unknown`s.
@nik9000
Copy link
Member Author

nik9000 commented Sep 8, 2018

Thanks for reviewing @jasontedor! I've finished the backport. I'll start work on the master-only clean up follow up to this on Monday.

@jasontedor
Copy link
Member

Thanks a lot @nik9000, this is great work and I am sorry that it took some time for me to get to a review.

@nik9000
Copy link
Member Author

nik9000 commented Sep 8, 2018

Good things take time.

jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Sep 8, 2018
* master: (30 commits)
  Include fallback settings when checking dependencies (elastic#33522)
  [DOCS] Fixing formatting issues in breaking changes
  CRUD: Disable wait for refresh tests with delete
  Test: Fix test name (elastic#33510)
  HLRC: split ingest request converters (elastic#33435)
  Logging: Configure the node name when we have it (elastic#32983)
  HLRC: split xpack request converters (elastic#33444)
  HLRC: split watcher request converters (elastic#33442)
  HLRC: add enable and disable user API support (elastic#33481)
  [DOCS] Fixes formatting error
  TEST: Ensure merge triggered in _source retention test (elastic#33487)
  [ML] Add a file structure determination endpoint (elastic#33471)
  HLRC: ML Forecast Job (elastic#33506)
  HLRC: split migration request converters (elastic#33436)
  HLRC: split snapshot request converters (elastic#33439)
  Make Watcher validation message copy/pasteable
  Removes redundant test method in SQL tests (elastic#33498)
  HLRC: ML Post Data (elastic#33443)
  Pass Directory instead of DirectoryService to Store (elastic#33466)
  Collapse package structure for metrics aggs (elastic#33463)
  ...
nik9000 added a commit that referenced this pull request Oct 15, 2018
Back in #32983 I broke running the integ-test-zip tests against an
external cluster by adding a test that reads the contents of the log
file. This fixes running against an external cluster by explicitly
skipping that test if running against an external cluster.
nik9000 added a commit that referenced this pull request Oct 15, 2018
Back in #32983 I broke running the integ-test-zip tests against an
external cluster by adding a test that reads the contents of the log
file. This fixes running against an external cluster by explicitly
skipping that test if running against an external cluster.
kcm pushed a commit that referenced this pull request Oct 30, 2018
Back in #32983 I broke running the integ-test-zip tests against an
external cluster by adding a test that reads the contents of the log
file. This fixes running against an external cluster by explicitly
skipping that test if running against an external cluster.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

If node name isn't in elasticsearch.yml we'll never log it
5 participants