Support Shipper monitoring in elastic-agent#2427
Support Shipper monitoring in elastic-agent#2427fearful-symmetry merged 3 commits intoelastic:mainfrom
Conversation
|
This pull request does not have a backport label. Could you fix it @fearful-symmetry? 🙏
NOTE: |
🌐 Coverage report
|
|
/test |
blakerouse
left a comment
There was a problem hiding this comment.
Code-wise I don't see any issue with the PR other than my one inline comment.
Outside of the code, I am sad to see that we are still modifying Elastic Agent code to support collecting metrics from components that Elastic Agent runs. I was hoping that with the shipper being a newly built component that we would not follow the same path that we did with beats.
I would prefer to see effort put in to use something like open telemetry that is a unified protocol that the Elastic Agent could collect from all components. We need this for a nice developer experience for components with the Elastic Agent.
@cmacknz ^ for visibility
Agreed and this keeps adding friction for new inputs being added that are not based on Beats, like the Universal profiling agent. We just couldn't take the hit to the shipper schedule to absorb redesigning this as part of the shipper project. We'll have to do it separately. |
| name := "shipper" // in other beats this is the binary name, but we can hard-code it here. | ||
| if comp.ShipperSpec.Spec.Name != "" { | ||
| name = comp.ShipperSpec.Spec.Name | ||
| } |
There was a problem hiding this comment.
Why are you placing this in an if? A spec must always have a name and is validated by the Elastic Agent.
There was a problem hiding this comment.
Alright, wasn't sure if that field could be blank, so decided to err on the side of caution.
What does this PR do?
See elastic/elastic-agent-shipper#267
This requires elastic/elastic-agent-shipper#289
This adds shipper monitoring support to elastic-agent. Right now I'm opening this as a draft PR for a few reasons:
indexfield in the config doesn't seem to do anything, and we just create a datastream, and I'm not sure if it needs to be there at alldatasetand variousidfields are set correctly.Right now, when run with monitoring enabled, this results in two documents-per-period: one with queue metrics, and one with system resource metrics
The complete document for resource metrics
The complete document for shipper metrics
Why is it important?
We need monitoring for the shipper
Checklist
./changelog/fragmentsusing the changelog toolHow to test this PR locally
EXTERNAL=false mage dev:packageshipper.spec.ymlfile fromspecs/over to thecomponents/subdirectory in the unpacked tarballelastic-agent-shippertoshipperagent.monitoring.enabledmust be set totrue.ds-metrics-elastic_agent.shipper-default-*events to ingest