-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Logs onboarding] Determine if logs are being shipped to elastic #159387
Comments
Pinging @elastic/apm-ui (Team:APM) |
I think it's a good idea to have some filters such as path, @timestamp etc. |
Would it be possible to report the I initially wanted to comment that we should always only query for the last 15min. But this might not provide the expected result. In case someone starts to tail a file with logs from the past few days and we extract the timestamp, only older data will be shipped first. |
Fleet uses the agent id to query data for the last 5 minutes here. Is this issue related to all shippers? |
We've decided in today's meeting to go with this proposal for now, adding it to the |
…g agent Id (#170124) Closes #159387. ### Changes - `POST /internal/observability_onboarding/flow/{id}/step/{name}` endpoint now accept conditionally a `payload` param that contains an `agentId`. - `standalone_agent_setup.sh` is now getting the `agentId` of the `elastic-agent` installed in the host. - `get_has_logs.ts` now uses `agentId` to match documents coming from the installed elastic_agent instance in the host.
…g agent Id (elastic#170124) Closes elastic#159387. ### Changes - `POST /internal/observability_onboarding/flow/{id}/step/{name}` endpoint now accept conditionally a `payload` param that contains an `agentId`. - `standalone_agent_setup.sh` is now getting the `agentId` of the `elastic-agent` installed in the host. - `get_has_logs.ts` now uses `agentId` to match documents coming from the installed elastic_agent instance in the host.
At the moment we are determining whether logs are being shipped or not to elastic by performing the following search
This search could give users false positives in regards to the data, What if this index already exists when users are onboarding their logs?
@grabowskit, @ruflin, @gbamparop
Will this be a common scenario for us? Could we assume this scenario to be an edge case and proceed with the current check?
Is there a more robust way to check this? For example, in addition to the index, check for file paths (the ones the user configured in the previous step) as part of determining logs arrival?
The text was updated successfully, but these errors were encountered: