-
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] Use service.name not service_name in configs #20330
Conversation
Using the nesting this way lets us handle future fields like `service.environment` more cleanly if/when they become available. See https://github.com/elastic/ecs/blob/master/rfcs/text/0002-rfc-environment.md for the proposal to add service.environment
Pinging @elastic/uptime (Team:Uptime) |
Pinging @elastic/ingest-management (Team:Ingest Management) |
@andrewvc I don't think this is linked to Fleet so i've removed the team label, I've looked at the PR I think there are some debugger traces that you left in that PR. |
Hello @andrewvc,
# EXPERIMENT - NOT SUPPORTED CONFIGURATION SNIPPET
heartbeat.monitors:
- type: http
id: www-frontend-monitor
name: Website Frontend Monitor
service:
name: www-frontend
environment: production
urls: ["https://www.my-ecommerce-company.com/status"]
schedule: '@every 10s'
check.response.status: 200
timeout: 2s
- type: http
id: www-frontend-monitor-staging
name: Website Frontend Monitor - Staging
service:
name: www-frontend
environment: staging
urls: ["https://www.staging.my-ecommerce-company.com/status"]
schedule: '@every 10s'
check.response.status: 200
timeout: 5s |
@cyrille-leclerc apologies, this fell through the cracks. It won't make 7.10.0 but it can make 7.10.1. I 100% agree we should also add an environment field (that would go in 7.11.0) I've created a separate issue for the env stuff here: elastic/uptime#272 |
Many thanks @andrewvc |
I've updated this PR to handle both |
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
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.
Looks good, like the fallback to old setting.
Using the nesting this way lets us handle future fields like service.environment more cleanly if/when they become available. See https://github.com/elastic/ecs/blob/master/rfcs/text/0002-rfc-environment.md for the proposal to add service.environment This is a follow-up to elastic#19932 which has not yet been released, so this is not a breaking change. (cherry picked from commit 425271b)
…2574) Using the nesting this way lets us handle future fields like service.environment more cleanly if/when they become available. See https://github.com/elastic/ecs/blob/master/rfcs/text/0002-rfc-environment.md for the proposal to add service.environment This is a follow-up to #19932 which has not yet been released, so this is not a breaking change. (cherry picked from commit 425271b)
Thanks @andrewvc |
Using the nesting this way lets us handle future fields like
service.environment
more cleanly if/when they become available.See https://github.com/elastic/ecs/blob/master/rfcs/text/0002-rfc-environment.md
for the proposal to add service.environment
This is a follow-up to #19932 which has not yet been released, so this is not a breaking change.
CC @cyrille-leclerc who pointed out that this would be better.