Introduction
Why need ISS ¶
The Internal Service Status project is designed to provide a comprehensive, at-a-glance view of the health of critical product features of Webex for all internal stakeholders, including engineers and leadership. The initiative stems from the need to centralize the status information that is currently scattered across various monitoring tools and to enable proactive issue resolution by facilitating quicker response times to alerts and outages.
By auto-capturing alerts and transforming them into a coherent status view, Internal Service Status ensures that all internal parties have access to real-time, actionable intelligence regarding our technical ecosystem. This view will focus on high-level Core Feature View of system health (granular views Microservice View will be in long term plan), enabling users to drill down into specific issues or maintain an overall picture of service performance.
What ISS Is Not ¶
- Not Another Monitoring Tool: ISS is not an additional failure capture monitoring tool. Instead, it leverages data from existing, registered monitoring tools.
- Not a New Data Repository: ISS does not serve as a new storage location for alarm data. It utilizes data from LMA, MCT, and ThousandEyes for visualization purposes.
- Not Generating New Alarms: ISS does not create new alarms. All alarms displayed within ISS originate from existing monitoring tools.
- Not for All Product Features: ISS is not designed to monitor every product feature. It focuses exclusively on the most critical features, serving as a reference for the Webex Status page.
There are two statuses available in ISS to tell the Health situation of each microservice:
| Status | Image | Description |
|---|---|---|
| Operational | Everything functions as expected. | |
| Degraded | Some functionality might be impaired. | |
| Down | The service is unavailable or experiencing critical issues. |
Each microservice's organizational structure is aligned with the service catalog definitions showcased in Backstage.
Regardless of the view you choose, you have the ability to delve deeper into granular details at the region or cluster level, along with access to proposed historical data.
Monitoring Suite ¶
The Internal Service Status (ISS) serves as a centralized platform, amalgamating alerts from diverse monitoring utilities to offer a unified perspective on the health status of all Webex services. This centralization facilitates early detection of irregularities, potentially averting service disruptions before they affect customers. Additionally, ISS provides detailed data for incident resolution, leveraging Apdex scores to gauge customer impact.
Envision ISS as the pivotal layer of a monitoring triangle: at the apex, Apdex scores assess user experience; ISS resides at the core, synthesizing insights; while at the base, specific monitoring tools such as MCT, LMA, and TE perform targeted health checks of the service infrastructure.
Real User Monitoring (RUM) ¶
Real User Monitoring (RUM) leverages logs generated by end users interacting with Webex Services to assess the quality of our services. This data provides insights into the user experience, highlighting both strengths and weaknesses. Apdex is the tool utilized for consolidating and visualizing these metrics.
End-to-End Synthetic Monitoring ¶
End-to-End Synthetic Monitoring simulates real user interactions with Webex Services, focusing on the primary usage paths that most users follow within our product suite. This approach represents the fundamental health status of our products.
MCT is the tool employed for this measurement, offering two methodologies to meet these requirements: TaP cases and UX Simulator.
Internal State Monitoring ¶
This layer provides fundamental data through multiple monitoring tools such as LMA, MCT, ThousandEyes, EMS, and others, covering both infrastructure and application layers. Each monitoring tool offers a unique and specialized perspective across different layers, providing essential support for troubleshooting activities.
Screenshot ¶
Home page:
Historical data page:
More core feature information could be found in Core Feature
Architecture ¶
The criteria to define core features is based on the measurement from end-user of that service will be get degraded if such core features are not working.
Where to visit ¶
- Development: https://status-portal.int.wfraint-gen-a.int.infra.webex.com
- Stage: https://stage-iss.webex.com/
- Prod: https://iss.webex.com/




