Migration Path

Hi team!

We use synthetics for a long time and know we are moving for the last stable version.

But we are getting a lot of changes without any proper guide to follow.

For example, we before can configure a Heartbeat to run using tags.
Now, the push command don't follow that behavior (Ref Make tags behave consistently · Issue #780 · elastic/synthetics · GitHub)

We can schedule any frequency, now we have a limitation based in some rule I don't fully understand and didn't find any doc talking about (Reference: [Synthetics] Project monitors - prevent project monitors from being saved with Synthetics-UI incompatible schedules (consolidate) · Issue #142655 · elastic/kibana · GitHub)

I saw this topic but is really shallow for the differences, and the CHANGELOG don't have a jump to see all changes in 1.0.0 just betas (maybe I didn't look in the right place).

Is there any central place to see what is dropped in the beta -> stable version?

Hi @Rogerio_Angeliski, thanks for using Elastic Synthetics!!

If you are interested in keeping pace with the latest changes to the Synthetics Agent, you can see the GitHub release page for the project. In addition to the release, any notable changes with the project's API or usage should be noted here on a per-version basis.

If you're using Kibana, there are detailed release notes for every version as well, and this will include release notes for the Synthetics UI as well. Likewise, there's a Beats release notes page as well, and this should include any Heartbeat changes. I'd recommend reviewing those any time you're upgrading.

From time to time, we are confronted with challenges while maintaining the many software components that go into our Synthetics offering. Internally we spend a lot of time evaluating options, and maintaining feature stability for our users is always a consideration in those discussions. That being said, we sometimes have to make difficult choices that end up requiring adjustment in the way our products are used.

If there's anything specific we can help you with, or if we can improve our communication please feel free to let us know. Thanks again for using Synthetics!

1 Like

Thanks @jkambic, this will help. I was expecting a migration guide from beta to 1.0.0, but I will dig a little in the CHANGELOG.

Maybe you can help me find more information about the agent policy/private locations.

In the past we deploy heartbeats in our infrastructure to run the tests, but now we need to use Private Locations. I can't find a doc how I can deploy multiple pods in or kubernetes without use a DaemonSet. I tried to look into this doc, but I don't really want to monitor our infrastructure. Furthermore, I just want multiple deployments to run or tests (we have a lot of tests).

And worse, to not stop the migration we created the DaemonSet to run, but now I have multiple just stuck in pending state forever.

Can you help me find the docs about those deployments and how the agent handle the tests for not stuck in pending?

Hi @Rogerio_Angeliski,

Synthetics public release has substantially changed the support matrix, browser monitors have been impacted especially. I can see in the screenshot that you're likely running some of these.

After GA, there're two supported options to run browser monitors:

  1. Through private locations, as you linked. This would involve:
    • Creating a private location policy,
    • Enrolling one (and only one) elastic-agent-complete instance on said policy,
    • Managing monitors from Synthetics UI, private locations will be made available as a Location. Any change to a monitor targeting a private location will be automatically updated through the agent integration.

Please note private locations are subject to horizontal scalability constraints, although it is on the roadmap there's no ETA yet. As of now, if vertical scalability is not an option, we recommend splitting the load among multiple private location policies.
Deploying these as a Daemonset is likely not recommended, as those are deployed to every node and it'd be generating multiple results per execution.

  1. Run in elastic-agent standalone mode. This setup involves running the agent with a hardcoded policy, and therefore updates to the any of the monitors will require updating the policy via an external process and restarting the agent manually. We consider this to be advanced setup that is only applicable in certain scenarios.

Please let us know if you'd like to know anything else in particular.

Hope this helps!

1 Like

Thanks @emilioalvap this was very helpful

We have some issues because we have a lot of tests running, so we are going to split those in private locations.

Thanks for the support

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.