-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Do not set require_alias
when sending to indices even if ILM is enabled
#30055
Conversation
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
require_alias
when sending to indices even if ILM is enabled
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks Noemi!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is for 7.17. For stack monitoring, why is 8.0 not also affected?
if v, _ := events.GetMetaStringValue(*event, events.FieldMetaAlias); v != "" { | ||
return true | ||
} | ||
if v, _ := events.GetMetaStringValue(*event, events.FieldMetaIndex); v != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what all the places are where we us this. I thought we also use this in places like k8s do adjust / overwrite the automatically created index name. In these scenarios this would not be correct.
An alternative approach is to introduce events.MetaInternalIndex
or similar that is purely set by the stack monitoring modules so it should not have any side effects.
One more idea, we hardcode that if the index name matches .monitoring-*
we don't do the check.
I'm worried that if we are not very specific with the check, it will have unexpected side effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what all the places are where we us this. I thought we also use this in places like k8s do adjust / overwrite the automatically created index name. In these scenarios this would not be correct.
I am not sure I understand why it would be an issue. If anything overwrites the index
or raw_index
, we do not set require_alias
, so there is no problem during ingestion. If something sets alias
, the target is an alias so require_alias
should be safe.
One more idea, we hardcode that if the index name matches .monitoring-* we don't do the check.
I also considered it, but I discarded the idea because I do not want to write monitoring specific code in a general elasticsearch client code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand why it would be an issue. If anything overwrites the index or raw_index, we do not set require_alias, so there is no problem during ingestion. If something sets alias, the target is an alias so require_alias should be safe.
The initial change was introduced to fix an issue when an index is deleted. Now lets assume for a moment (alias partially made up) the metricset kubernetes.foo_bar
sets the alias name to kubernetes.foo.bar
specifically. This means the alias feature is disabled. Now the user wipes the alias with all indices and we start to ingest data into kuberentes.foo.bar
. If we see a support request for this, our first answer is this is not possible. But turns out, it is in this case. What you have will fix most cases but it creates incosistency. Lets rather revert the previous change and discuss on how we should deal with it.
@@ -93,7 +94,7 @@ func (e *Event) BeatEvent(module, metricSet string, modifiers ...EventModifier) | |||
|
|||
// Set index prefix to overwrite default | |||
if e.Index != "" { | |||
b.Meta = common.MapStr{"index": e.Index} | |||
b.Meta = common.MapStr{events.FieldMetaIndex: e.Index} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above, maybe there are other ways.
The original issue is that sometimes customers accidentally removed the write alias and then it got recreated as an index breaking ILM for Beats (mostly Heartbeat). In 8.x, it is no longer an issue because the data stream manages the alias and its own backing indices for us. There is nothing to be done in Beats, just sending events to the name of the data stream. |
To not block the release, could we revert previous change and instead have a fix into 7.17.1 for example? |
For 8.0, I'm asking about the .monitoring indices no the ones create by us. But I think I got the answer between the lines. We never introduced this "check" in 8.0 so writing to pure indices still works as before. |
Revert previous PR: #30058 |
The x-pack flag was removed in 8.0 and a lot of the behaviour around the monitoring indices changed, here is one of the top level PRs for more context: #24427 |
We agreed that this PR will be merged in the future when we are 100% sure that there are no unintended side effects. |
This pull request is now in conflicts. Could you fix it? 🙏
|
so this has to go into the 7.17 after today's release in order to have metricbeat monitoring work on the snapshots, right? I can confirm that the last BC works fine, while the last snapshot need this fix. |
No, it is not required. The whole feature got reverted in 7.17 that this PR was supposed to fix. In 8.x, we also never used this feature because Beats send to data streams. What is the problem in the last snapshot? |
I just synced with @marius-dr and the issue no longer persist in the latest snapshot of 7.17. |
@kvch can this PR be closed? |
up @kvch |
The PR is outdated. We will need to rework the whole fix. I am closing this and reopen the original issue. |
@kvch could you link to the reopened issue please so we can follow along. The changes are a precondition for elastic/apm-server#7116 |
What does this PR do?
Previously, if ILM was enabled in Metricbeat,
require_alias
was set for all Bulk API requests. However, whenxpack.enabled
is set totrue
inbeat
,logstash
,kibana
orelasticsearch
modules, they overwrite the target indices of the events. So Metricbeat can send the events to the monitoring indices. The monitoring indices are regular indices, not aliases. Hence, we got an error for Bulk API requests as they were not aliases.Why is it important?
Without this fix, Metricbeat cannot send monitoring events to Elasticsearch.
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Enable Beat module in Metricbeat and set the events to the monitoring index:
Start Filebeat with HTTP endpoint enabled:
Start Metricbeat and check if the events can be indexed.
Related issues
Closes #29920
Closes #30044