-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Heartbeat] One shot mode #25972
[Heartbeat] One shot mode #25972
Conversation
In this mode heartbeat runs a single monitor once, writes all events to its output, then exits.
This pull request doesn't have a |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
While using this I plan to do setup logic outside of the process before telling heartbeat to execute a synthetic suite in one-shot mode. I'm planning on informing the "services" I am starting up in my journeys where ES and Kibana are via the environment, and it seems like https://github.com/elastic/beats/blob/master/x-pack/heartbeat/monitors/browser/synthexec/synthexec.go#L112 suggests this should work well, do you think it's safe to rely on this behavior? |
@Mergifyio update |
Command
|
I don't mean to pester, but are there any plans to move this forward? This would be a really good feature for things like automated CI/CD tests. |
@BenB196 we have some internal use cases for this, but didn't think any external users would have cause to use it. Can you let us know more about what sort of testing you'd use this for? Normally you want tests run on a schedule, which is what heartbeat does. |
@andrewvc sure. The main use case I see from this feature is the ability to abstract some "infrastructure" stuff from people writing test cases, while also giving them access to built in Elastic features; like the browser Observability features in Kibana, and machine learning for things like anomalously long response times on loading specific tests to detect regressions pre-production. All without having to do any custom integrations between playwright/synethics/elastic. A bit more detail on the "infrastructure" part. It's far easier to provide someone a docker-compose file or a Kubernetes manifest with all of the base settings already set for Heartbeat, and then just tell them to insert their inline playwright script, or tell them to replace their zip_url information, than it is to have to essentially reinvent what Heartbeat does minus the scheduled run part. |
That's really helpful @BenB196 , so, as I understand it, you're missing the Kibana side of what synthetics does, and being able to run one-offs would be helpful. IMHO that's a good reason to finish off this PR (which is 80% done really, just needs docs, tests, cleanup etc.). I would say, however, that Kibana/Uptime itself is really oriented around scheduled runs, monitors that occasionally run will be.... weird. How do you handle this? Do you ask your users to pop into Kibana and wait for the monitor to appear? Is this roughness OK? |
@andrewvc yeah, you've pretty much got the gist of it. I think the Kibana roughness is fine honestly. It just requires a small amount of education on the user end about either having to wait a bit for the results to show up, or to expand the timeframe back further to see old/past runs for a monitor id/environment. Also, a bit more of a technical/implementation side, from how I would see this being used. Is it would be more or less part of a jenkins (or similar) pipeline, where this would just be one part of a testing process. So most likely the pipeline would run, and by the time it is complete, the data will already be in Kibana/Elasticsearch for the user to review if needed. It was also allow for the user to use the Heartbeat/synthetic debug logs to track any kind of issues that may arise during the pipeline. |
The one thing that I can't tell from the PR of whether it does this or not, but it would be nice for Heartbeat to exit with a code similar to how the monitor run exited. i.e. If browser run succeeds exit with 0, if it fails exit with 1, etc. That way from a jenkins (or similar) pipeline, it would be easy to tell right away if the test failed without having to do much looking around. |
This pull request does not have a backport label. Could you fix it @andrewvc? 🙏
NOTE: |
Pinging @elastic/uptime (Team:Uptime) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
heartbeat/beater/heartbeat.go
Outdated
} | ||
return nil | ||
} | ||
|
||
groups, _ := syscall.Getgroups() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to care about the permission model in one shot mode? or we are skipping it for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, yes. FYI, that's just a log line, there's no impact on functionality, the actual perms are reset elsewhere. But I'll move the logline up higher.
heartbeat/config/config.go
Outdated
@@ -27,7 +27,7 @@ import ( | |||
|
|||
// Config defines the structure of heartbeat.yml. | |||
type Config struct { | |||
// Modules is a list of module specific configuration data. | |||
OneShot []*common.Config `config:"one_shot"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dont want to deviate this PR in to some other direction, but are we okay with this naming or change it to something like RunOnce
mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea, I think it's more clear, will change to run_once
@@ -109,3 +109,37 @@ include::monitors/monitor-tcp.asciidoc[] | |||
include::monitors/monitor-http.asciidoc[] | |||
|
|||
include::monitors/monitor-browser.asciidoc[] | |||
|
|||
[float] | |||
[[one-shot-mode]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[[one-shot-mode]] | |
[[run-once-mode] |
heartbeat/beater/heartbeat.go
Outdated
logp.Info("Starting run_once run. This is an experimental feature and may be changed or removed in the future!") | ||
cfgs := bt.config.RunOnce | ||
|
||
publishClient, err := core.NewSyncClient(logp.NewLogger("oneshot mode"), b.Publisher, beat.ClientConfig{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
publishClient, err := core.NewSyncClient(logp.NewLogger("oneshot mode"), b.Publisher, beat.ClientConfig{}) | |
publishClient, err := core.NewSyncClient(logp.NewLogger("runonce mode"), b.Publisher, beat.ClientConfig{}) |
@Mergifyio backport 7.x |
(cherry picked from commit 6d09457)
Command
|
Fixes elastic#28437. This is an improvement over elastic#25972 which had a more complicated config interface.
* [Heartbeat] Make run_once syntax a boolean Fixes elastic#28437. This is an improvement over elastic#25972 which had a more complicated config interface. * Fix python tests * Fix python
In this mode heartbeat runs a single monitor once, writes all events to its output, then exits. See the included docs for examples and testing it. This is useful internally mostly as an experiment for now.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
Related issues
Use cases
Screenshots
Logs