Support for APM service.name in Heartbeat/Uptime #220
Comments
|
Trivial effort and high return - I am in favour of prioritising this. Can we elaborate a bit more with some user stories to really bring home the value of it @andrewvc and then discuss with the team when to bring it in? |
|
As a user of both APM and Uptime, I'd like to more easily navigate between the two apps. Being able to jump from an uptime outage to an APM analysis of the same outage is something I expect. I'd like to be able to view a discrete error, then easily view that time segment in the relevant service in APM. |
|
+1 on this effort. Aligning and using most important ECS fields across our apps is so important. cc @elastic/observability-pm @roncohen @alvarolobato |
|
+1 on this initiative. @andrewvc minor comment: I think that the ECS field name is The next integration between APM and Uptime my wishlist is the usage of |
|
@cyrille-leclerc great ideas for @katrin-freihofner any input on this? Adding the menu item to the integrations list should be very straightforward to the uptime UI. |
|
I think this a great initiative. Linking to the service from the integrations menu should work. I think this could even work better with the new integrations menu. A shared component for this is already available. |
Adds a new standard service_name option to the heartbeat config file. While possible with fields already, adding this as a first class option encourages use of this important field for integration. First step toward elastic/uptime#220 This PR also refactors some internal bits where we were passing too many parameters already, and adding service_name would just be too much. We now pass a single larger struct for common monitor options which cleans up a lot of the code.
Adds a new standard service_name option to the heartbeat config file. While possible with fields already, adding this as a first class option encourages use of this important field for integration. First step toward elastic/uptime#220 This PR also refactors some internal bits where we were passing too many parameters already, and adding service_name would just be too much. We now pass a single larger struct for common monitor options which cleans up a lot of the code. (cherry picked from commit 6197850)
) Adds a new standard service_name option to the heartbeat config file. While possible with fields already, adding this as a first class option encourages use of this important field for integration. First step toward elastic/uptime#220 This PR also refactors some internal bits where we were passing too many parameters already, and adding service_name would just be too much. We now pass a single larger struct for common monitor options which cleans up a lot of the code. (cherry picked from commit 6197850)
With elastic/beats#19932 coming in 7.10 adding the `service.name` ECS field is very easy. We should prefer this field when cross linking to APM, hence this PR. Resolves elastic/uptime#220
#73618) With elastic/beats#19932 coming in 7.10 adding the `service.name` ECS field is very easy. We should prefer this field when cross linking to APM, hence this PR. Resolves elastic/uptime#220
elastic#73618) With elastic/beats#19932 coming in 7.10 adding the `service.name` ECS field is very easy. We should prefer this field when cross linking to APM, hence this PR. Resolves elastic/uptime#220 # Conflicts: # x-pack/plugins/uptime/public/lib/helper/observability_integration/get_apm_href.ts
#73618) (#73666) With elastic/beats#19932 coming in 7.10 adding the `service.name` ECS field is very easy. We should prefer this field when cross linking to APM, hence this PR. Resolves elastic/uptime#220 # Conflicts: # x-pack/plugins/uptime/public/lib/helper/observability_integration/get_apm_href.ts
Adds a new standard service_name option to the heartbeat config file. While possible with fields already, adding this as a first class option encourages use of this important field for integration. First step toward elastic/uptime#220 This PR also refactors some internal bits where we were passing too many parameters already, and adding service_name would just be too much. We now pass a single larger struct for common monitor options which cleans up a lot of the code.
justinkambic
added
the
test-plan-ok
Today, linking between Uptime / APM is done only via URL. It would be trivial to add a common option to heartbeat monitor options
service_name, that added the appropriate field for APM. This could then be used by the integrations links on the monitor overview/detail page to cross-link to APM.The text was updated successfully, but these errors were encountered: