You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devlake.apache.org by "sandesvitor (via GitHub)" <gi...@apache.org> on 2023/09/11 15:02:38 UTC

[GitHub] [incubator-devlake] sandesvitor opened a new issue, #6055: [Feature][Plugin] Opsgenie Plugin

sandesvitor opened a new issue, #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055

   ### Search before asking
   
   - [X] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and found no similar feature requirement.
   
   
   ### Use case
   
   Within our development team, we have implemented an abstraction layer atop Devlake for seamless integration with our applications and incident management. As part of our operational strategy, we have chosen Opsgenie as our primary alerting and incident response tool (for now we are using PagerDuty, but it will be discontinued in the coming months.). Consequently, we recognize the necessity of establishing a plugin connection with Opsgenie in the near future.
   
   ### Description
   
   Following the guidelines presented in the Developer Manual for creating plugins, available at [Dev Manual](https://github.com/apache/incubator-devlake/blob/main/backend/DevelopmentManual.md), I have extended Devlake's functionality to interact with the Opsgenie API in a manner analogous to the Pagerduty Plugin. At present, this plugin is configured to operate within the context of a Service scope. It performs data collection, extraction, and convertion of Opsgenie Incidents to domain ticket.Issue and service convertion to domain ticket.Board (as Pagerduty does).
   
   I haven't been able to effectively associate users as Assignees in domain ticket.IssueAssignee, because Opsgenie's API doesn't establish a strong link between Incident entity and users (it only provides a list of responders with type and ID), since this domain have domainIssue.AssigneeId and domainIssue.AssigneeName, and I only had the Id.
   
   In the frontend's config-ui folder, the new plugin has been registered using the "token" key for establishing communication with the Opsgenie API. I'm using a placeholder icon in config-ui/src/plugins/register/opsgenie/assets/icon.png, don't know how to comply to logo standard
   
   ### Related issues
   
   https://github.com/apache/incubator-devlake/issues/5247
   
   ### Are you willing to submit a PR?
   
   - [X] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] Startrekzky commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "Startrekzky (via GitHub)" <gi...@apache.org>.
Startrekzky commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1723418177

   Hi @sandesvitor , thanks for the updates. I'm curious why there were so many invalid responders on the list. It seems only the `Oloko Meu` is a real name, is it?
   ![image](https://github.com/apache/incubator-devlake/assets/14050754/a0e2253b-b512-4780-a73d-b7e41e8f2f4d)
   
   If an incident (incident-1) doesn't have any responder(or assignee), you can leave the issues.assignee_id and issues.assignee_name empty. Also, this incident-1 will not have a single record in the table.issue_assignees, since it doesn't have an assignee.
   
   As for the incidents with responders or assignees,  @keon94 can you help answer how to populate the value to the domain layer? Thank you.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] Startrekzky commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "Startrekzky (via GitHub)" <gi...@apache.org>.
Startrekzky commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1714881955

   Hi @sandesvitor , this is amazing. 
   1. All the entity conversions seem correct. (Service as the data scope, Opsgenie incidents to domain layer issues, Opsgenie services to domain layer boards)
   2. How can I help you with the Opsgenie users and ticket.IssueAssignee association?
   3. The logo is usually drawn by the maintainer team to avoid any ASF compliances. I'll send you the file once it's finished.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] keon94 commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "keon94 (via GitHub)" <gi...@apache.org>.
keon94 commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1716900362

   @sandesvitor 
   1. I think it's ok to skip the Name and just set the ID on the assignee if that's all the API gives you.
   2. What's exactly the difference between alerts and incidents? Do you want alerts to be treated differently to incidents? Currently domain layer only recognizes an Incident issue type. So unless these two are very different things conceptually, I think the domain layaer should treat them both the same way.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1725548766

   Nice @Startrekzky ! I'll follow your approach, keepping the `assignee_name` empty for now and updating the dashboard.
   
   ![image](https://github.com/apache/incubator-devlake/assets/62914690/9831dd92-9ea0-4a3b-af07-dec26113bf05)
   
   ```sql
   select 
     i.title as incident_name,
     group_concat(a.assignee_id separator ', ') as responder_id
   from issues as i
     inner join issue_assignees as a on (substring_index(i.id, ":", -1) = substring_index(a.issue_id, ":", -1))
   group by i.title;
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1726359656

   Quick update @Startrekzky : I was able to find the name of each responder =)
   
   I had to create new models for "users" and "teams" (each have it's own API) and run for a collect, extract and convert task for each, before the incident tasks. After that I was able to update my input cursor to include the name of user and team.
   
   ![image](https://github.com/apache/incubator-devlake/assets/62914690/e682356f-218e-4626-8aa7-83871ff2edfa)
   
   I also include them in crossdomain.User and crossdomain.Team domains


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1721891578

   Hello everyone, here's an update:
   
   I've created the responder and assignment models, integrating them with the ticket.IssueAssignee domain. However, I encountered a limitation within the Opsgenie API. It doesn't provide information about the date of assignment. Consequently, I couldn't populate the domainIssue.AssigneeId and domainIssue.AssigneeName values in the ticket.Issue object with a single responder/assignee (the last to acknowledge it), as the PagerDuty plugin does it. I think this is because Opsgenie's "Incident" entity doesn't include the concept of a single responder acknowledging it; instead, it lists the responders associated with that incident. I attempted to address the issue in the example Grafana Dashboard for the Opsgenie plugin by adding a table view of each incident's responder list.
   
   ![image](https://github.com/apache/incubator-devlake/assets/62914690/7c608f85-8e7f-48ef-839b-92ffd5d3afe2)
   
   In addition to this, I've completed the end-to-end data flow tests.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1715777995

   Hey @Startrekzky! Thanks for the reply =)
   
   So, actually, I have 2 questions xD 
   
   1. Using PagerDuty as a reference, I understand that its API has an "assignments" key in the response body containing the reference for "assignee.id" and "assignee.summary":
   
   ```json
   (...)
   "assignments": [
         {
           "at": "2023-09-06T13:23:05Z",
           "assignee": {
             "id": "P1THAEX",
             "type": "user_reference",
             "summary": "Vitor Sandes",
             "self": "https://api.pagerduty.com/users/P1THAEX",
             "html_url": "https://example.pagerduty.com/users/P1THAEX"
           }
         }
       ],
   (...)
   ```
   In Opsgenie, the incident API contains the "responder" key:
   
   ```json
   (...)
   "responders": [
         {
           "type": "team",
           "id": "c0259fb8-2068-48c5-ae09-1b116e3579b1"
         },
         {
           "type": "user",
           "id": "b3948a43-fee8-4adc-b7bd-3ac58919f4eb"
         }
       ],
   (...)
   ```
   
   My question is if it's mandatory to use Id and Name for the ticket.IssueAssignee, such as:
   
   ```go
   issueAssignee := &ticket.IssueAssignee{
     IssueId:      domainIssue.Id,
     AssigneeId:   domainIssue.AssigneeId,
     AssigneeName: domainIssue.AssigneeName,
   }
   ```
   
   2. My other question is that Opsgenie has a different approach to Incidents than PagerDuty. In PagerDuty, an Incident is one or more events (same or different alert triggers from monitoring tools), which generate an action in the notification pipe (Service/Escalation/Schedule/User). Opsgenie Incident is a dedicated object for an operational incident and can be related to a service and/or stakeholders (PD does not have a similar object, I think). Opsgenie also has an "Alert" entity that works in a similar way as PagerDuty Incidents.
   
   I tried to collect "alert" metrics, but Opsgenie API has some limitations, such as:
   - To collect the incident-id associated with that alert, you have to GET a specific alert (this information does not exist in the get alerts list API).
   - This is also true for alert description.
   
   Another issue that I couldn't resolve was how to separate these two entities. If I send them to the board_issues table, they will be considered as the same. I could create another column named "type" in each model (type = alert and type = incident), but I don't think it's the most elegant solution hehe
   
   ---
   
   That is it, sorry for the long comment =)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1723482783

   Sorry @Startrekzky , the column "name" is confusing =).
   
   The column  "name" refers to the "incident" name (I should update it to "incident name" or just "incident").  
   
   The column "responders" is the one to show the list of responders in JSON format. Since I couldn't retrieve the name of the responder via API (only its type and id), I passed the domainIssue.AssigneeName as the responder type (in this case only "team" or "user"). In summary, "#Updated At", "Oloko Meu", "Test#4", etc, are the names of the mock incidents that I created, and the responders, the list of responders associated with them =)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] klesh commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "klesh (via GitHub)" <gi...@apache.org>.
klesh commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1734767637

   @sandesvitor @Startrekzky is on vacation and sure you could open the PR anytime you like, you don't need permission for that.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [Feature][Plugin] Opsgenie Plugin [incubator-devlake]

Posted by "abeizn (via GitHub)" <gi...@apache.org>.
abeizn closed issue #6055: [Feature][Plugin] Opsgenie Plugin
URL: https://github.com/apache/incubator-devlake/issues/6055


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] Startrekzky commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "Startrekzky (via GitHub)" <gi...@apache.org>.
Startrekzky commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1724706656

   @sandesvitor Thanks for the clarification. Well, using the responder's type as the assignee name is acceptable if you think it's reasonable from a user's perspective.
   
   Or, you can leave the `assignee_name` empty for now, wrap up the code, and investigate how to get the responder names by responder keys in the next phase.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1733677187

   Hey @Startrekzky ! Just wondering if I can open the PR for review? =)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] klesh commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "klesh (via GitHub)" <gi...@apache.org>.
klesh commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1716879569

   @keon94 Can you help with the question?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [incubator-devlake] sandesvitor commented on issue #6055: [Feature][Plugin] Opsgenie Plugin

Posted by "sandesvitor (via GitHub)" <gi...@apache.org>.
sandesvitor commented on issue #6055:
URL: https://github.com/apache/incubator-devlake/issues/6055#issuecomment-1717572105

   Thanks @keon94 ! 
   
   1. Sure thing, I'll do that! (I could pass the responder.type to Name, only if Name is not a unique key... I think types are: user, team, schedule,...)
   2. Actually I was wrong about the alerts in my last comment, they are not at all associated with services. They could be indirectly associated with a service if they were generated by a incident (every incident generates a alert), but I guess in this case it'll be redundant. So, if it's ok for you, I think collecting only the incidents suffices when using services as Data Scopes. And, answering  your question, I think is safe to assume a Opsgenie Alert as a Incident issue type also.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@devlake.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org