-
Notifications
You must be signed in to change notification settings - Fork 442
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
[logstash] align mappings with metricbeat #3993
Conversation
🌐 Coverage report
|
That's a really interesting step. Nice work figuring out how to package/distribute the profile. It makes me wonder if there should be something a little more "first class" for automating installation (for example |
Also scratching my head at what coverage counting tool is flagging |
My initial attempt to run your instructions didn't give me the agent package, just the filebeat/metricbeat "instructional" (? not sure if right word) integrations. Trying this:
(I think I'm also warming regional caches this morning, so far 20min in total for all the docker-compose ups 😆 ) Update: I think I broke it Guess I'll use this as an excuse to try to learn more about how the package registry works... |
Looks like that command used a different profile, so kibana was failing to query to refreshed package service:
Trying this now:
Update: error is gone, still no logstash package. I'm gonna retry with default profiles and see if that changes anything. |
While waiting for stacks to do stack things I think I found the coverage report https://beats-ci.elastic.co/job/Ingest-manager/job/integrations/job/main/1196/cobertura/logstash/node/ Looks like it's borrowing the cobertura format so |
So I ended up needing to switch the package to |
I wasn't able to get the elasticsearch package to show up in the UI, so I enabled internal monitoring and was able to see logstash. The setup mode N/A seems to indicate that the data is coming in via agent. To cross check I looked at the health api but I think maybe it doesn't support the new indices yet? Would be nice if there were an easy way to pull a source-clone kibana into the stack to be able to fix and test the code accordingly. (Update: oh nice, you have that in elastic/kibana#138224) |
Okay, so confusion resolved here. Looks like the profile works, but since they're not Aside: the ES logo looks broken, so I opened elastic/kibana#138865 to fix |
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.
After a bit of head-desking this seems to work. I had a couple of questions, so just commenting for now.
I'd also like to see if I can test CFS & config reloading to get the reload counters or pipeline versioning to do something other than just be blank.
version: '2.3' | ||
services: | ||
logstash: | ||
image: "docker.elastic.co/logstash/logstash:8.5.0-SNAPSHOT" |
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.
Any idea if we can parameterize this to the latest stack snapshot? Thinking something like what we do on the beats repos.
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.
Would that be the master-SNAPSHOT image ?
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.
Worth a try at least :) I did the same in https://github.com/elastic/beats/blob/main/docs/devguide/modules-dev-guide.asciidoc#test
I think my ideal would be some sort of automation like elastic/beats#32720 that explicitly bumps to updated versions. That way we avoid spurious main
branch failures on this repo if something is broken in an updated stack version.
Either way I think we can defer that work to a later PR.
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 opened up #4013 to follow up on this and added it to our integration meta.
fields: | ||
- name: number_of_elapsed_periods | ||
type: long | ||
- name: time_throttled_nanos |
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.
Oh, also is there anything I can do with https://github.com/klacabane/metrics-mappings-to-monitoring to cross-check the mapping diffs? |
heh, I ran into another funny "sharp edge" on elastic-package. Looks like I was running an old docker-compose via pip so I removed that figuring v2 might be easier to set cpu quotas with, but that causes the hostnames to change so it's |
Well, I can't seem to get logstash to return any cgroup stats even with a quota set:
|
I can see cpu periods/throttling info in
|
Also confirmed standalone using your instructions from elastic/kibana#138224 - thanks for that! Thinking we should probably start an |
When not GA the integrations won't appear in the UI, but you can still find them with the global search bar. if you type elasticsearch/kibana/logstash it should show an integration option. You can also navigate to the integration through the metricbeat tutorial, they have a link to the agent package.
Ah got bit by that several time and added it to the (still local) docs. profile have their own certificates and CAs so the package-registry needs to be started with the --profile as well to be able to connect back.
Correct, health api does not support metrics-* yet
Let me confirm that on my side and I'll create a ticket
We can implement system tests (https://github.com/elastic/elastic-package/blob/main/docs/howto/system_testing.md) that verifies that the mapped properties are correctly ingested. I wanted to push their implementation a bit later since I expect those to fail and spot properties that are not populated (see cgroup) and increase the scope of the PR. Our testing strategy for now is to rely on Stack Monitoring UI behaving similarly when loaded with agent and metricbeat, then we can add these tests as a mapping testing and optimization ticket, wdyt ? |
Co-authored-by: Mat Schaffer <[email protected]>
ahhh... big TIL on that one for me. Thanks!
Makes sense to me. Looks like #4008 has that covered 👍🏻 |
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.
Good to merge I think. Definitely some outstanding questions, but we can address them as work carries on in the main meta(s).
Summary
Closes #3916
Align the logstash data streams' mappings with the metricbeat ones. The change also defines a logstash service that can be started by running
elastic-package service up
in the logstash directory.Testing
First make sure you have elastic-package installed.
When testing we have to install the elasticsearch package as well otherwise the logstash section in Stack Monitoring won't show up.
Service is up, please use ctrl+c to take it down
elasticsearch
cluster while thestandalone-pipeline
should appear in the Standalone cluster.Note: If the Standalone Cluster is not showing up it means that this change [Stack Monitoring] support logstash datastream in standalone query kibana#138689 is not available in 8.5 snapshot yet. You can follow the Testing steps from this PR [Stack Monitoring] support for integration package kibana#138224 to connect a local kibana containing the changes