[Heartbeat][Agent] Synthetics deps and Elastic Agent #22932
Comments
botelastic
bot
added
the
needs_team
|
As the Elastic Agent has also the option to download the dependencies if needed, it would be good to know how long it would take to download this additional dependency? |
|
Thanks I assume this isn't just concerning docker and also concerns adding synthetics to the agent installer? If we add 1GB to the main agent image, that would eat a lot of bandwidth & storage across 1000s of hosts. So option 2 sounds better for the majority of users. More generally, we talked about having a minimal docker image for hosts that are internet connected so they can download dependencies on demand, and a full docker image for offline hosts. @ph do you remember where this conversation ended up? I can't seem the find the issue. |
jsoriano
added
Team:Ingest Management
Team:obs-ds-hosted-services
|
Pinging @elastic/ingest-management (Team:Ingest Management) |
|
Pinging @elastic/uptime (Team:Uptime) |
botelastic
bot
removed
the
needs_team
|
@mostlyjason I can't find that issue, we mentioned it in the heartbeat issue some time ago but this use case is different, and I am not sure it fit well with docker. I might ask question that have been already decided, but I don't have enough details about the architecture Now, I think there is multiple question to asks, as @mostlyjason pointed out what is the usecase when there is no docker involved for synthetics. Is Docker a hard requirement on that new feature? Do people that run heartbeat from the tar.gz will be able to use that new behavior? How the execution look like, is heartbeat starting a new container from hearbeat how this work inside the docker images? |
|
@ph docker is not a hard requirement, but it is one initially, mostly because we don't want to support multiple platforms. There's a lot that can go wrong with all the GUI deps, node deps, etc., and it makes more sense to focus on features right now. I expect that will change in the future. However, it sort of ruins the whole "click to add an integration, it just works" aspect, since you can't just do that. You need a box with all the stuff. So, for agent, maybe it should be docker only. That said, I think we practically need to go with the second approach, of two docker images. A regular fleet version and a jumbo version. That also hurts the vision of a single agent, but it's the better compromise IMHO. |
|
It looks like heartbeat with synthetics is actually only ~500MiB. Given that the size isn't so bad, is there any objection to simply merging synthetics into the agent docker image? |
|
Our current image is ~569MB. So adding synthetics would double it. My biggest concern is that if Elastic Agent is deployed across many machines, this will consume now double the bandwidth, 500 is already quite a bit. |
|
@ruflin we're at the point where we need a firm decision relatively soon. The two options I see are either include it in the mainline image or make an alternate |
|
It is a tricky decision here. If we include it and later realise the size is too large, we can't remove it anymore as it is a breaking change. If we go the separate container, my understanding is that a user could not just add synthetics but would need a separate container for it. @alvarolobato @tbragin Would be nice if you could chime in here. |
|
Just the container, and it wouldn't increase by 500 Mib, probably only a few hundred if I had to guess. Metricbeat's docker image is 190MiB today by comparison, so we could call that the base size. |
|
It helps that its just the container. Containers are usually run on servers, not as often on endpoints. Usually there are a smaller number of servers and 500MB of disk isn't a concern. In that case increasing the size shouldn't be as much of an issue. We could always release a minimal image later. Also, does that mean users cannot run synthetics on a regular agent install? If so, we should consider adding that to the blocklist to prevent users from adding it. |
|
Yes, correct on both counts, how do we add it to the blocklist?
…On Tue, Apr 27, 2021 at 6:18 AM Jason Skowronski ***@***.***> wrote:
It helps that its just the container. Containers are usually run on
servers, not as often on endpoints. Usually there are a smaller number of
servers and 500MB of disk isn't a concern. In that case increasing the size
shouldn't be as much of an issue.
Also, does that mean users cannot run synthetics on a regular agent
install? If so, we should consider adding that to the blocklist to prevent
users from adding it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22932 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABACY4UBCMLB3V6V5QD2LTTK2MRHANCNFSM4UNTLEAA>
.
|
|
@ruflin @ph @mostlyjason do we have enough info to come to a decision here? I vote we bundle with docker agent. |
|
+1 to bundle it then. You can add it to the blocklist here #21000 |
|
+1 to bundle it for docker-agent. |
|
@mostlyjason / @ph, irrespective of this being bundled or not, what is the behaviour from a Fleet perspective, if the non-Docker version of the Elastic Agent is used (reason for asking is I wonder if this is a similar flow to if we didn’t bundle Synthetics with the image)? For example, if I install the binary version of the Elastic Agent (non-Docker), and associate this to an Agent Policy which has a Synthetic Integration policy, what happens in that case? Is there some kind of you are running the wrong version of the Agent error? |
|
@paulb-elastic Not much happens today except that you will get an error from the Elastic Agent when rolling out the policy. We should fix this by bringing knowledge about the capabilities of an Elastic Agent to Fleet. There are other features which require this too. |
|
This has been discussed and although simpler for onboarding, we can’t ignore the additional space overhead of bundling Synthetics+dependencies with the Docker build of Elastic Agent. As such, to proceed with this, we will be opting for a separate Docker build of the Elastic Agent+Synthetics+Dependencies and clarify in the documentation and readme that this must be used to try Real Browser Synthetic Integrations. |
|
@paul-tavares I jsut want to answer your question:
If you add synthetics to the blocklist that gets bundled by default in distributions of the agent without synthetics, then the user will see the agent show up as unhealthy on the agents page and they will be able to see an error that synthetics is blocked. Without adding it to the blocklist, the agent will show as healthy when it is not. |
|
Thanks @mostlyjason we've opened an issue around that here #25775 |
We do not yet have a synthetics fleet image available, so, for now, users should not be allowed to create synthetics inputs in fleet. See elastic#22932 (comment)
|
Reopening because we now have an implementation in #27052 |
#27052) Creates a new offline tagged docker image that includes the dependencies required for synthetics. Building elastic-agent docker images will now create additional -offline tagged images with these extras. We may need to do additional work to ensure that these additional images are incorporated into the release process and onto the public website. These changes also set the ELASTIC_SYNTHETICS_CAPABLE env flag, as done in heartbeat, to enable synthetics features in the docker environment. This dovetails with the work @dominiqueclarke is doing in elastic/integrations#1064 and elsewhere Fixes #22932
#27052) Creates a new offline tagged docker image that includes the dependencies required for synthetics. Building elastic-agent docker images will now create additional -offline tagged images with these extras. We may need to do additional work to ensure that these additional images are incorporated into the release process and onto the public website. These changes also set the ELASTIC_SYNTHETICS_CAPABLE env flag, as done in heartbeat, to enable synthetics features in the docker environment. This dovetails with the work @dominiqueclarke is doing in elastic/integrations#1064 and elsewhere Fixes #22932 (cherry picked from commit 4727470)
#27052) (#27324) Creates a new offline tagged docker image that includes the dependencies required for synthetics. Building elastic-agent docker images will now create additional -offline tagged images with these extras. We may need to do additional work to ensure that these additional images are incorporated into the release process and onto the public website. These changes also set the ELASTIC_SYNTHETICS_CAPABLE env flag, as done in heartbeat, to enable synthetics features in the docker environment. This dovetails with the work @dominiqueclarke is doing in elastic/integrations#1064 and elsewhere Fixes #22932 (cherry picked from commit 4727470) Co-authored-by: Andrew Cholakian <andrew@andrewvc.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
#27052) Creates a new offline tagged docker image that includes the dependencies required for synthetics. Building elastic-agent docker images will now create additional -offline tagged images with these extras. We may need to do additional work to ensure that these additional images are incorporated into the release process and onto the public website. These changes also set the ELASTIC_SYNTHETICS_CAPABLE env flag, as done in heartbeat, to enable synthetics features in the docker environment. This dovetails with the work @dominiqueclarke is doing in elastic/integrations#1064 and elsewhere Fixes #22932 (cherry picked from commit 4727470) # Conflicts: # dev-tools/mage/dockerbuilder.go
#27052) (#27324) Creates a new offline tagged docker image that includes the dependencies required for synthetics. Building elastic-agent docker images will now create additional -offline tagged images with these extras. We may need to do additional work to ensure that these additional images are incorporated into the release process and onto the public website. These changes also set the ELASTIC_SYNTHETICS_CAPABLE env flag, as done in heartbeat, to enable synthetics features in the docker environment. This dovetails with the work @dominiqueclarke is doing in elastic/integrations#1064 and elsewhere Fixes #22932 (cherry picked from commit 4727470) Co-authored-by: Andrew Cholakian <andrew@andrewvc.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> (cherry picked from commit f9b2610) # Conflicts: # dev-tools/mage/dockerbuilder.go
|
Tested with Working as expected for both inline and zip url tests. |
|
Re closing as opened by Zube |
This picks up part of the discussion from #22837 where we agreed to include an extra gigabyte of deps for synthetics in the main heartbeat image. The remaining question is what to do about agent? There are essentially two paths forward:
I propose that we make a new 'centralized' agent docker distribution with the extra deps. It won't be intended for use as a side car, and will only be put in place on the few machines where running agent is the main purpose, rather than say, every server or k8s pod etc.
The text was updated successfully, but these errors were encountered: