Craig MacKenzie

> @cmacknz and @jlind23 Are you tracking any issues for the flakiness in the [K8s Autodiscover pipeline](https://beats-ci.elastic.co/job/e2e-tests/job/e2e-testing-k8s-autodiscovery-daily-mbp/)? No, it may make sense to follow up with the Observability Cloudnative monitoring...

> What I'm still not sure about is why this wasn't caught my CI. Do we not have anything in CI that packages agentbeat? Note that hitting this bug requires...

At first glance it doesn't look like CI is actually building agentbeat with these changes. I think we need to update CI to compile x-pack/agentbeat when any of the individual...

One concern I have about this input is that we have seen failures to read permissions outside of the unprivileged agent use case, for example we were unable to read...

Agree we should show the error but I think we'll want to be able to disable certain types of errors to prevent the system integration from making every agent degraded...

There are a few ways to approach this. One would be a configuration option the keeps the errors in the logs, but filters them from marking the agent as degraded...

We are using the agent input health reporting for this. There will be a single info level log when the state changes from healthy to degraded (this state already exists),...

https://github.com/elastic/beats/issues/39737 is an obvious candidate to do alongside this one, but we could also pick a metricset that requires a username/password combination as it will have a much clearer criteria...

Yes this is more of a Beats/input issue. We may want agent to explicitly tell inputs when agent is running as unprivileged so that they do not have to duplicate...

I had tacked it on to https://github.com/elastic/elastic-agent/issues/4683 which is needed to support the user agent changes we want as well.