I did setup service dependencies as document in the docs
https://support.atlassian.com/opsgenie/docs/create-a-service-relationship/
but it seems it doesn't add any value to the monitoring!
I have a setup as follow:
The Service A that depends on Service B.
I was expecting it would prevent duplicate incidents when Service B fails and an incident are created for Service B, but Service A would also fail, because it depends on Service B, and now there are 2 incidents, where I would expect only one incident, and have both services linked to the incident.
If the service relationship doesn't do this kind of check, why would we use it?
Service dependencies currently are really just for "Visibility", so it shows it on the service status page, but not on the incident itself.
It also is used in the Incident Investigation feature with Bitbucket Cloud workspaces to services in Opsgenie. So you can map repositories to Services, and if an incident occurs on ServiceA that has a relationship with ServiceB, you can pull in any deployments from the repository mapped to ServiceB that could be a potential cause for the incident.
A more detailed response on this can also be found on this community article here https://community.atlassian.com/t5/Opsgenie-questions/Services-relationship-and-teams-How-it-works/qaq-p/1382317
Hope this helps!
Thanks,
Connor
Hi Connor,
Thanks for the answer. Not what I was expecting to hear but clarified my doubts.
It would be really helpful if OpsGenie could aggregate the incidents to centralise to escalation and communication into a single incident.
When a core service that affects everything else fails, we wouldn't want to wake up the entire company at night knowing only a specific team could sort this out.
Is there anything in the roadmap to cover this scenario?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So from my understanding and please correct me if I am wrong, If Service A dies only because Service B died, only wake up the folks that will fix Service B (since Service A will get fixed by proxy). Ideally you would want just the one Incident for this right?
You can't aggregate Incidents however you can assign more than 1 service to an Incident, for example Service B is real cause of the issue here have just the service B responder teams added to the Incident and assign the multiple affected services.
If you are worried about the owner team for each of these services being notified about the Incident then I would suggest just having the 1 service added to the incident that needs to be fixed.
For visibility on the affected services you can dive into the affected service to see its relationships without it having to notify your entire company.
I hope this helps and happy to elaborate further.
Thanks,
Connor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.