Tutorial

This tutorial section will guide you through setting up and understanding the core components of EMS2.0. We'll start by introducing the underlying open-source platform, keephq/keep, and then detail the environment configurations for development, staging, and production.

Send alerts to EMS2.0

Introduction to keephq/keep Community Edition ¶

EMS2.0 is built upon keephq/keep, a powerful open-source AIOps and alert management platform. The community edition of keephq/keep provides a robust foundation for alert aggregation, correlation, and automated incident response, forming the backbone of our new Enterprise Monitoring System.

Key Concepts in keephq/keep: ¶

• Providers: These are integrations that allow keep to ingest alerts (e.g., Datadog, Prometheus, Slack Incoming Webhooks) or send out notifications/trigger actions (e.g., Jira, Slack Outgoing Webhooks, PagerDuty).

• Rules: Logic defined in YAML that determines how incoming alerts are processed. Rules can filter, enrich, or correlate alerts.

• Workflows: Sequences of automated actions triggered by specific alert conditions. These are defined in YAML and can execute complex multi-step processes.

• Alerts: The core entities representing an event from a monitoring system.

• Incidents: Groups of related alerts that represent a single, actionable problem.

While EMS2.0 provides a pre-configured setup, understanding the basics of keephq/keep can be highly beneficial for advanced customization and troubleshooting.

You can explore the official keephq/keep documentation for in-depth information and examples: https://docs.keephq.dev/

For more information on keephq/keep, you can refer to the introduction vidcast of keep + n8n Introduction(8m27s)

MAS Hosted Environment Information ¶

EMS2.0 is deployed across three distinct environments: Development (Dev), Staging, and Production (Prod). Each environment serves a specific purpose in the software development lifecycle, with varying access controls, data sensitivity, and resource allocations.

For each environment, it's crucial to understand the endpoint URLs, access mechanisms, and any specific configurations relevant to EMS2.0.

QA ¶

- Purpose:

• Development and testing of new EMS2.0 features, providers, rules, and workflows.
• Local testing of integrations with other services.
• Rapid iteration and debugging.

- Access:

• EMS Console (keep) URL: https://keep.int.wfraint-gen-a.int.infra.webex.com/incidents
• API Endpoint: https://keep.int.wfraint-gen-a.int.infra.webex.com/v2
• n8n Workflow Editor: https://n8n-staging.int.wjfkgen-p-1.prod.infra.webex.com/

Staging ¶

- Purpose

• End-to-end testing of new features and bug fixes in an environment similar to production.
• Performance testing and scalability validation.
• Integration testing with other critical systems (e.g., Jira, PagerDuty, Slack) using realistic configurations.

- Access:

• EMS Console (keep) URL: https://csgems.stage.webex.com
• Internal API Endpoint: https://csgems.stage.webex.com/v2
• Public API Endpoint(only for alerts receiving): https://csgems.stage.ext.webex.com/v2/alerts/event/ (new, recommended)
  https://alerttrans.webex.com/stage/v2/alerts/event/ (old, still working)

Prod ¶

- Purpose

• Live operation of the Enterprise Monitoring System.
• Processing real-time alerts and incidents.
• Providing critical alert notifications and automated responses to operational teams.

- Access:

• EMS Console (keep) URL: https://csgems.prod.webex.com
• Internal API Endpoint: https://csgems.prod.webex.com/v2
• Public API Endpoint(only for alerts receiving): https://csgems.prod.ext.webex.com/v2(new, recommended)
  https://alerttrans.webex.com/prod/v2/alerts/event/ (old,still working)

API Docs ¶

https://api.keephq.dev/redoc#tag/