This document aims to capture the metrics we will use to measure performance of the Wikifunctions project. The metrics are divided into a few categories:
- Performance Service-level objectives (SLOs)
- Resource saturation metrics
- Wikifunctions-specific metrics
Note that not all metrics will be implemented pre-launch. They are in fact listed with descending order of urgency. Some of the goals will take additional support from the backend services and iterations of change. This document simply provides a road map for the future performance monitoring setup.
Another thing to note is that most metrics will be separated by service. That means the function orchestrator and function evaluator will each have their own separate metrics.
Performance SLOs (current phase)
The performance SLOs are the service level objectives the project should meet before launching to production. Note that we outlined the SLIs (indicators), but the SLOs (objectives) in the table are arbitrary placeholders gathered from other Wikimedia services. The exact numbers need to be decided with consideration of user needs and organizational standards.
Since the staging environment of the beta cluster does not support metric export, we cannot observe the current level of performance until it “goes live”.
|SLI||SLO (per service)||Definition||Collection method|
|Request latency (server side)||Known simple function: 100ms
|Time it takes to return a response to a request||Existing Prom metric (express_router_request_duration_seconds)|
|Error rate||1%||Error percentage of all requests received||Existing Prom metric|
|System Throughput Capacity||500 req/s||Rate of successful request||Load testing framework (e.g. apache bench)|
Resource Saturation Metrics (current phase)
The resource saturation metrics help us see how much of the allocated resources are used. This will guide throttling thresholds and additional resource upgrade requests. These metrics do not require additional setup as they are supported by default.
|Metrics||Upper Limit||Definition||Collection method|
|CPU||100%||The percentage of total CPU allocated||Container Default (e.g. container_cpu_user_seconds_total)|
|Memory||90%||The percentage of total memory allocated||Container Default (e.g. container_memory_*)|
Wikifunctions-Specific Metrics (future phase)
In addition to system-level SLOs and performance metrics, we’d like visibility for how Wikifunctions is used. The following metrics provide insights for function popularity, connectivity, and their resource consumption.
Note that the current and historic WikiLambda content is stored in blobs, and querying the live content databases (DBs) for some of the metrics would be impossibly expensive. In order to support performant direct queries on WikiLambda, we can set up alternative data storage solutions, or set up secondary indexes in existing DBs.
Alternatively, instead of reading real time values, we could set up periodic scans that run daily or weekly. This mechanism can be implemented on Toolforge like the Wikidata stats, with the intermediate data saved in replica DBs (see Data Services). A benefit of this approach is that the queries can be crowdsourced with volunteers. Here is an example of the query configuration.
|Traffic||Time series (request per day)||Existing Prometheus metric|
|Number of functions||Time series (accumulated)||Replica DB|
|Number of function implementations||Time series (accumulated)||Replica DB|
|Number of implementations per function||Daily average, median, top ten||Replica DB|
|Number of Languages||Daily lists||Replica DB|
|Number of function calls||Time series (per day)||Additional metrics event hook and additional storage solution needed|
|Most called implementations||Daily top 10||Additional metrics event hook and additional storage solution needed|
|Most frequently referenced functions from other implementations||Current most-linked||Replica DB (will need an implementations calls to functions link table)|
|Function connectivity||Connectivity graph of the current top 100 referenced functions||Replica DB (will need an implementations calls to functions link table)|
To confirm the liveness and correctness of the WikiLambda API, we will implement periodic health checks that ping the API with basic requests and check the response against expected outcomes. These health checks are embedded in the WikiLambda API. A Prometheus blackbox check will invoke the health-check endpoint. Alerts will be triggered if any of the checks fails the test.
The performance SLOs, resource saturation metrics, as well as traffic info will be presented as dashboards on grafana.
All the Wikifunctions specific metrics, sans traffic, will be hosted elsewhere, as they are not production critical. Metrics like function call graphs are more complicated and potentially require custom graph drawing, like the wikidata-todo.toolforge.org charts.
Although most metrics will be separated by service, we will group function orchestrator and evaluator metrics side-by-side to provide insight into any potential performance bottleneck.
In addition to Grafana, we expect a stats.wikimedia.org page for the Wikifunctions project that will display viewership, contributor, and content information. In order to be included in the Analytics Query Service (AQS), we will need to edit the MW history include list and the Pageviews include list.
Alerting is supported by Alertmanager, part of the Prometheus ecosystem. Current alerts can be browsed through alerts.wikimedia.org (NDA access only). Of the three metric categories, the performance SLOs and the resource saturation metrics should be equipped with alerting rules, but it is optional for the Wikifunctions specific metrics.
Currently the Abstract Wikipedia team’s alert receiver is defined in alertmanager.yml.erb in the puppet repository.
There are multiple ways to implement alerts. The alerting rules can either be added to the wikimedia alerts repository with alert routing setup (example), or added directly to the grafana dashboards. Alerts are defined as prometheus alerting rules.
- Timing of the alert: after threshold has been crossed for 5 mins
immediately after threshold is crossed(noisy to start with, adjust as we go)
- Who to alert: AW team
- Severity: warning for the initial phase, critical after user base grows
The main metric reporting mechanism is backed by Prometheus. It supports production critical metric reporting and alerting, with builtin integration with Grafana. To be exact, this project’s interface with Prometheus is provided by the Service Template Node’s Service Runner component’s Prometheus client for node.js. It exposes a node-statsd interface. The workflow and syntax for metric reporting can be found in the abovementioned frameworks’ README. As an example, this is part of Citoid's metric logging setup.
The built-in Prometheus JS client already provides the necessary endpoints for the basic metrics such as general request latency and error rate. In order to log more advanced metrics (such as usage per function implementation), custom event metric hooks will need to be implemented.
For metrics that are not production critical (i.e. most Wikifunctions specific metrics), Prometheus is not the ideal solution. These metrics require different sampling rates, storage space, and retention periods. For example, records of function invocations would require a large keyspace and short retention period. Additional data storage options need to be set up to accommodate such data. It is an ongoing discussion tracked in T309792.
Many of the SLOs come from concrete user stories, which are captured below.
As a WMF Ops team member, I want to…
- access current and historical information and patterns of how the orchestrator and evaluator services are performing / have performed, using the tools I am familiar with, so that I can enable my team to make better decisions about resource requirements, capacity planning, and configuration changes
- be confident that orchestrator and evaluator services emit logging and monitoring signals in a way that complies with established Foundation standards, so that I can enable my team to manage Wikifunctions services in a consistent manner
- be alerted as soon as possible when the orchestrator or evaluator service has failed or is in a degraded state, so that I can enable my team to respond to restore the failed or degraded service
- understand, in the event of a service failure or degradation, what events as captured in logs led up to that state, so that I can enable my team to conduct root cause analysis and prevent or mitigate similar issues in the future
- understand how to respond to a service failure or degradation in a way that addresses the unique needs of the orchestrator or evaluator service, so that I can enable my team to be context aware and reduce time to resolution
- understand and access current and prior security signals with or without alerts, so that I can enable my team to perform threat pattern analysis
- identify calls from suspicious origins, so that I can alert my team to suspicious load and decide whether or not to block
- identify and (automatically) respond to resource hogging orchestrator calls, so that I can prevent usage that could degrade the service's performance
- enact lockdown to the desired level of granularity (Wikifunctions application, orchestrator or evaluator service, individual function), so that I can prevent abusive usage