nyuuzyou/wikis huggingface dataset:
Add a server

For any MediaWiki app server:
* Install Ubuntu
* Install wikimedia-task-appserver
* Add the hostname to /usr/local/dsh/node_groups/mediawiki-installation on the ssh bastion host
Additionally, for a non-apache batch server:
* Stop apache: /etc/init.d/apache2 stop
* Disable apache by running update-rc.d -f apache2 remove
* Add to ganglia with:
apt-get -y --no-remove install gmond ganglia-metrics
cp -r /home/wikipedia/conf/gmond /etc
rm /etc/gmond.conf
ln -s gmond/misc.conf /etc/gmond.conf
/etc/init.d/gmond restart
/etc/init.d/gmetricd restart
Additionally, for a main pool apache server:
* Add the hostname to /usr/local/dsh/node_groups/apaches
* Add to nagios with cd /home/wikipedia/conf/nagios && ./sync
* Add to ganglia with:
apt-get -y --no-remove install gmond ganglia-metrics
cp -r /home/wikipedia/conf/gmond /etc
rm /etc/gmond.conf
/home/wikipedia/conf/gmond/make-apache-symlink
/etc/init.d/gmond restart
/etc/init.d/gmetricd restart
* Add the server to /etc/pybal/apache on the LVS director for the apaches, currently lvs3. The weight should be proportional to the CPU count.
===List of things that will break if you try to install MediaWiki without following this procedure===
* Not in mediawiki-installation node group: server doesn't get sync-file/scap updates, so misses out on DB server and similar changes. Thus it goes rogue and destroys the cluster.
* No wikimedia-nis-client: non-roots can't sync. Server misses out on updates, goes rogue.
* No sudoers (from wikimedia-task-appserver): non-roots can't sync.
* No upload NFS mounts (from wikimedia-task-appserver): MediaWiki will spew errors when it tries to access uploads, corrupting your data and potentially corrupting the shared caches.
* No latex, djvulibre, ploticus, etc. (from wikimedia-task-appserver): Bad output, corrupted caches.
* Apache not in apaches node group: apache-restart-all etc. fails, unmonitored in nagios.
* Server not in ganglia: by the time you realise you need it, you will have missed hours or days of important performance data.
* Running apt-get -y unattended without the --no-remove option: due to some subtle error in the repository or sources.list, apt-get declares your entire installation "conflicting", right down to glibc, and removes it, bricking the server.
* Apache not in nagios: Tim gets upset.
Category: How-To
Adding Namespaces

Like other configuration changes, adding namespaces is a two-step process: prepare a config change, and deploy it.
The first step can be done by anyone, the second one requires deployment access.
Both can be done by the same person (a deployer), but it’s also common for a volunteer to prepare a change that is then deployed during Backport windows.
== Config change ==
* Go into your clone of the operations/mediawiki-config.git repository:
 cd .../mediawiki-config
* Edit core-Namespaces.php:
 vim wmf-config/core-Namespaces.php
* Inside the file, find the section variable called wgExtraNamespaces.
:* Scroll down in the file and find the existing section for the project you are adding namespaces to.
:* If it doesn't list in that section, create a new entry for it.
:* NOTE: You have to replace spaces with underscores in the new namespace name and add a corresponding talk namespace, or things will break.
* Update the file to list off the namespaces you are adding & save your changes.
:* Try to keep the namespace numbers in some sort of order (For example, Portal is often 100.)
* Commit your changes:
 git commit wmf-config/core-Namespaces.php
:* Don’t forget to mention the associated Phabricator task in the commit message.
* Upload your change:
 git review
* If you’re not going to deploy the change yourself, find someone else to do it, e. g. by adding the change to an upcoming Backport slot in the deployments calendar.
== Deployment ==
* Follow the usual process (+2 on Gerrit, git fetch+log+rebase on deployment, scap pull on debug, verify, scap sync-file on deployment).
* Now you MUST run the following script to clean up any pages that are using the new namespace in the title before it existed:
 mwscript maintenance/namespaceDupes.php --wiki=<wikidbname> --fix
* This will fix all the broken names due to the new namespace.
* If the script lists any unresolved names, run it again with --suffix=/BROKEN or something similar, and report the output on the Phabricator task.
Category:How-To
Adding a file in innodb

edit /etc/my.cnf
at line innodb_data_file_path = /usr/local/mysql/data/ibdata1:20000M:autoextend
add the second file like this :
innodb_data_file_path = /mnt/raid1/ibdata2:60000M;/usr/local/mysql/data/ibdata1:20000M:autoextend
Nota : the autoextend file must be the last on the line
*stop mysql : mysqladmin -u root -p shutdown
*start mysql : mysqld_safe
It could take some time, time to rebuild the innodb space. You can follow the process in .err file
And... it doesnt work
autoextend must be the last file, but a new file must be add in last....
Plan B :
*stop mysql
*note the size of ibdata1, the autoextend file
*convert in MB (size /1024 /1024)
*put innodb_data_file_path = /usr/local/mysql/data/ibdata1:87544M;/mnt/raid1/ibdata2:60000M;/usr/local/mysql/data/ibdata3:50M:autoextend
*restart mysql
Category:How-To
Category:MySQL
Adler

Adler was a database server in Tampa.
=== System ===
Adler has 6 onboard scsi harddrives with another on a second channel through external storage. 
The OS is on the onboard 6 drives in a raid 0. The external array is not attached at this time.
The operating system currently resides on the external six drives in a raid0 configuration through the use of a LSI megaRaid controller 320-2X. LSI Product Info. 
=== Software ===
The operating system is Fedora Core 3 x86_64. It resides with on a 10GB ext3 partition (sda1), with the rest of the disk as a jfs partition (sda2) mounted on /a.
== History ==
* 02/24/07: Added rails and re-racked.
=== Errors === 
 tail -n 50 mcelog
 bit32 = err cpu0
 bit46 = corrected ecc error
 bus error 'local node origin, request didn't time out
 generic read mem transaction
 memory access, level generic'
 STATUS 9410c00176080813 MCGSTATUS 0
 MCE 8
 CPU 1 4 northbridge TSC 33f864e19e624
 ADDR 115990
 Northbridge Chipkill ECC error
 Chipkill ECC syndrome = 7621
 bit32 = err cpu0
 bit46 = corrected ecc error
 bus error 'local node origin, request didn't time out
 generic read mem transaction
 memory access, level generic'
 STATUS 9410c00176080813 MCGSTATUS 0
 MCE 9
 CPU 1 4 northbridge TSC 3402e4c7c5074
 ADDR 115990
 Northbridge Chipkill ECC error
 Chipkill ECC syndrome = 7621
 bit32 = err cpu0
 bit46 = corrected ecc error
 bus error 'local node origin, request didn't time out
 generic read mem transaction
 memory access, level generic'
 STATUS 9410c00176080813 MCGSTATUS 0
 MCE 10
 CPU 1 4 northbridge TSC 340d64ab9fe3c
 ADDR 115990
 Northbridge Chipkill ECC error
 Chipkill ECC syndrome = 7621
 bit32 = err cpu0
 bit46 = corrected ecc error
 bus error 'local node origin, request didn't time out
 generic read mem transaction
 memory access, level generic'
 STATUS 9410c00176080813 MCGSTATUS 0
 MCE 11
 CPU 1 4 northbridge TSC 3417e491c6c5b
 ADDR 115990
 Northbridge Chipkill ECC error
 Chipkill ECC syndrome = 7621
 bit32 = err cpu0
 bit46 = corrected ecc error
 bus error 'local node origin, request didn't time out
 generic read mem transaction
 memory access, level generic'
 STATUS 9410c00176080813 MCGSTATUS 0
== RMA History ==
Alert review

The Alert Review Process is a methodology designed for the systematic evaluation of alert data, aimed at identifying patterns, recurring issues, and opportunities for improvement.
This process aims to:
* Identify recurring patterns and issues that require targeted attention and resolution.
* Generate actionable insights to refine and enhance our alerting framework.
These goals guide our proactive efforts enhance system reliability and efficiency.
== Analysis Framework ==
Alert analysis is primarily conducted through our Logstash instance, using the Alert Review visualization for an in-depth analysis of alert data from multiple sources, including:
* Icinga
* LibreNMS
* Alertmanager
Additionally, Google Apps Script is used to analyze specific datasets:
* Top root@ mail alerts
* Splunk On-Call alert data
Access to the Apps Script codebase is provided via the Gitlab repository at alertreview.
The project environment is hosted on the Alert Review GCP Project.
== Doing an Alert Review ==
=== Data Collection and Analysis ===
==== Logstash and OpenSearch Dashboards Visualization ====
The primary tool for alert analysis is our Logstash instance via the Alert Review visualization. This facilitates the detailed examination of alerts from various sources, including Icinga, LibreNMS, and Alert Manager.
Access to top critical alert data of the past 2 months is available in:
* Icinga alerts
* LibreNMS alerts
* AlertManager alerts
==== Focused Analysis with Google Apps Script ====
Google Apps Script is used to process and analyze the top root@ mail alerts and Splunk On-Call data.
=== Presentation ===
1. Create a copy of the Alert Review template.
2. Create a new Etherpad to gather feedback and ideas.
3. Prioritize targeted actions for noise reduction.
Feedback Loop: Use the feedback collected in the Etherpad to refine the alert analysis process. This iterative approach aims to enhance the precision and effectiveness of data collection, analysis, and presentation.
== Developing Apps Script ==
* For local development of Google Apps Script projects, install Clasp.
* Clone the `alertreview` repository with: `git clone git@gitlab.wikimedia.org:repos/sre/alertreview.git`.
* Use `clasp push` to deploy updates to GCP, managing sensitive information via script properties to avoid public exposure.
==== Key Data Sources ====
The following data sources are integral to the alert review process, each contributing unique insights:
* Alert Manager: Analysis focuses on alert volumes, resolution metrics, and patterns of recurring alerts.
* Icinga: Key metrics include service uptime, response times, and the frequency of critical alerts.
* Splunk On-Call: Data on on-call rotation efficiency, incident categorization, and management of after-hours incidents is crucial.
* Grafana, Graphite, Prometheus, and Thanos: These tools provide valuable metrics on system performance, alerting thresholds, and long-term data trends.
Analytics

Analytics is the systematic computational analysis of data or statistics, for the purposes of discovery, interpretation, and communication of meaningful patterns.
In the context of the Wikimedia Foundation, the term Analytics generally refers to work carried out on the Analytics Cluster and the Data Lake by various WMF staff and volunteers.
The Data Platform Engineering team has responsibility for managing the Analytics Cluster and the Data Lake, so most pages under /Analytics are now of historical interest only.
== Analytics Cluster ==
The Analytics Cluster comprises a number of different systems geared to help researchers, data scientists, machine learning engineers and other authorized parties to access the data lake.
If you believe that you need access to the cluster, please refer to Data Platform/Data access
== Data Lake ==
The term Data Lake refers to the set of data files (also referred to as datasets) that are stored on the Hadoop HDFS file system.
Many of these datasets are managed by the Data Platform Engineering team with pipelines deployed to production and monitored.
However, members of the analytics-privatedata-users group may also create their own data files in Hadoop, enabling custom Hive tables plus manipulation of data from Jupyter and Spark etc.
== See also ==
* https://meta.wikimedia.org/wiki/Research_and_Decision_Science which includes the Movement Insights and Product Analytics teams.
* The Product Analytics style guide has code conventions for SQL, Python, and R. Consider adopting them to make your work more consistent and easier for others in the movement to read!
Category:Portals
Analytics/Archive/AQS -RESTBase

To serve Pageview data via an API, we need to store the data somewhere after it's processed in Hadoop. This page details our options for data stores and our decision.
I (Milimetric) have to fill this in more, but basically:
* We looked at PostgreSQL to store denormalized data in a data warehouse type of schema
* Looked at Cassandra and the way RESTBase integrates with it and creates keyspaces for us
* Looked at Druid and the more advanced analytics it enables
The choice came down to meeting the immediate need with the lowest cost solution. The basic endpoints that we needed to work on as part of project code name {slug} this quarter were very simple. Simple enough to pre-aggregate data easily in Hadoop and load it into Cassandra with relative ease. So, for now, we are going to use RESTBase with its built-in Cassandra support. We decided that more complicated queries would never be pre-aggregated, and that we would deploy Druid when we need to implement something like that. At that point, we would revisit this page.
Analytics/Archive/Alexa

Meeting notes 
Attendees: 
*Nuria
*David Hardcastle from Alexa
== Alexa usage of Wikipedia ==
=== Wikipedia service ===
Example: > "Alexa: Wikipedia white house" (and Alexa reads the White House Wikipedia page to you.)
They pull api and locally cache results, consume an edit feed, and bust cache after 5 minutes of an edit (they observed that is the time after which edits become stable).
=== Fact service ===
Example: > "Alexa: What is the capital of Paris"
Wikipedia's content is part of the knowledge graph that gets built in order to answer these questions. This is done async and because of Wikipedia's reputation as a reliable source, it ranks high in terms of trust, so the info is used more than it might be for other sources. Wikidata infoboxes are used to answer this type of question. 
Images are also displayed on occasion and this work is more tricky, as they have to be aware of licensing for those, they have a licensing module that chooses images with licenses that Alexa can show. 
=== API ===
Alexa wants to be a good web citizen and they try to cache as much as possible on their end so they end up using our resources minimally. The company that did this work was a startup called "ebi" that Amazon bought. User agent on API calls should be "edbi" or "alexa".
Analytics/Archive/DataRequests

The job of the Analytics team is to provide infrastructure and services so you can put/get your statistics into a system via a fairly simple code snippet. We are an infrastructure team that provides analytics infrastructure. Please have in mind that the analytics team does not provide teams with numbers to measure their KPIs against. We will support your data access request, grant access to our systems if it pertains and help you as needed be. You can find us on IRC on #wikimedia-analytics.
Please see the Research FAQ on Meta and Product Analytics team page on Mediawiki.org to understand who at WMF owns research-related processes and resources, and on where to find data or statistics about a specific Product Audience (such as editors or readers).
Analytics/Archive/Doc proposal

== To Do ==
* Data Lake/Edits needs to include productionization
* Root Analytics page (discussed with Dan):
Analytics 
 FAQ
 Team
 Onboarding
 Oncall
 Contact
 Mailing list
 IRC nicknames
 Tutorials
 Data
 By Access System
 Data Lake - explanation and drill down into datasets
 Dumps
 ReportUpdater output
 AQS
 Druid
 Mysql [EventLogging + Mediawiki]
 By data type
 Webrequest
 Pageview
 Mediawiki
 EventLogging
 Edits History
 Reports
 
 Systems
 
 etc...
Something to note about the structure: We are going to use "Access System" as the folder hierarchy to store detailed schemas, and we'll link to those pages from "Data Types" pages
* Data Lake/Traffic page should be revamped
* By Access system pages / folders should be created when needed
* By Data Type pages should be created
== Done ==
*We moved pages accordingly to what was suggested (or close to it)
Analytics/Archive/EventLogging/Architecture

This page explains WMF's EventLogging system topology and how its parts interact. Using the following diagram as a reference:
* varnishkafka sends client-side raw (URL encoded JSON in query string) events from Varnish to eventlogging-client-side Kafka topic.
* An eventlogging-processor consumes and processes these raw events and send them back to Kafka as JSON strings. Once processed and validated, the processed events are produce to Kafka in the topics: eventlogging-valid-mixed and eventlogging_<schemaName>. eventlogging-valid-mixed that contains the valid events from all schemas with the exception of blacklisted high volume schemas. eventlogging_<schemaName> holds all events for each schema.
* eventlogging-valid-mixed is consumed by eventlogging-consumer processes and stored into MySQL and into the eventlogging log files. The eventlogging_<schemaName> topics are consumed by Camus and stored in HDFS partitioned by <schemaName>/<year>/<month>/<day>/<hour>
The EventLogging back-end is comprised of several pieces that consume and produce from/to Kafka, which makes it a single purpose standalone stream processor. The /etc/eventlogging.d file hierarchy contains those process instance definitions. It has a subfolder for each service type. An systemd task, uses this file hierarchy and provisions a job for each instance definition. Instance definition files contain command-line arguments for the service program, one argument per line.
An 'eventloggingctl' shell script provides a convenient wrapper around for managing EventLogging processes.
Category:Data platform
Category:Data platform systems
Analytics/Archive/EventLogging/Data representations

This page gives an overview over the various representations of EventLogging data available on the WMF production cluster, and expectations around those representations.
== Hadoop & Hive ==
EventLogging analytics data is imported from Kafka into Hadoop as raw JSON, and then 'refined' into Parquet backed Hive tables. These tables are in the Hive event and event_sanitized databases. The refined data is stored in HDFS in the hdfs:///wmf/data/event directory. And the sanititized data is stored under hdfs:///wmf/data/event_sanitized.
See: Analytics/Systems/EventLogging#Hadoop_.26_Hive for info on how to access this data.
== 'all-events' JSON log files ==
Use this data source only to debug issues around ingestion into the m2 database (data ingested only on hadoop does not go through these files)
Entries are JSON objects.
Only validated events get written.
In case of bugs, historic data does not get fixed.
Those files are available as:
* stats1004:/srv/log/eventlogging/archive/all-events.log-$DATE.gz
* stats1005:/srv/log/eventlogging/archive/all-events.log-$DATE.gz
* eventlog1002:/var/log/eventlogging/...
== Raw 'client' side log files ==
Use this data source only to debug issues around ingestion into the m2 database.
Entries are parameters to the /beacon/event HTTP request. They are not decoded at all.
In case of bugs, historic data does not get fixed. Neither need hot-fixes reach those files.
Those files are available as:
* stats1004:/srv/log/eventlogging/archive/client-side-events.log-$DATE.gz
* stats1005:/srv/log/eventlogging/archive/client-side-events.log-$DATE.gz
* 
* eventlog1002:/var/log/eventlogging/...
== Kafka ==
EventLogging now feeds the following topics in Kafka:
* eventlogging-valid-mixed: This topic exists for ingestion into MariaDB and contains most of the live EventLogging analytics data. Some schemas are blacklisted.
* eventlogging_<schemaName>: All events from the specified schema. Each schema has its own deditcated topic.
== Varnish pipeline ==
Since EventLogging data is extracted at the bits caches, and the EventLogging payload is encoded in the URL, EventLogging data is available in all log targets from the caches.
In case of bugs, historic data does not get fixed. Neither need hot-fixes reach this pipeline.
Category:Data platform
Category:Data platform systems
Analytics/Archive/EventLogging/EventCapsule

This page will document EventLogging's EventCapsule, a wrapper that stores meta information about EventLogging events. The EventCapsule is stored in the EventLogging source code in eventlogging/capsule.py. Before February 2018, it was stored with other schemas on meta wiki. As part of https://phabricator.wikimedia.org/T179836, it was moved to source code, as the codebase's operation is highly dependent on the EventCapsule structure. Changes to EventCapsule need to be coordinated with source code deployments.
https://meta.wikimedia.org/wiki/Schema:EventCapsule will be maintained for documentation purposes, but the canonical EventCapsule schema lives at https://github.com/wikimedia/eventlogging/blob/master/eventlogging/capsule.py eventlogging/capsule.py.
Category:Data platform
Category:Data platform systems
Analytics/Archive/EventLogging/Monitoring

== Grafana ==
Here's some really cool Grafana dashboards that display our Graphite metrics:
* EventLogging Dashboard, shows hitrates of all events by schema, status of Kafka brokers, error counts and more.
* EventLogging-schema Dashboard, focus on an individual schema. Useful for embedding and inter-dashboard links from graphs showing the actual EventLogging data. Example: performance-metrics.
== Graphite ==
Raw metrics can be browsed at https://graphite.wikimedia.org/ (under Metrics -> eventlogging).
We publish 4 types of counts to graphite:
* Overall counts
* Per schema counts
* Server side counts
* Client side counts
Within the overall counts, there are 4 submetrics:
* Raw counts: Number of all events that reach the system.
* Valid counts: Number of events that pass validation.
* insertAttempted: Number of events that get queued up for insertion to MySQL database.
* inserted: Number of events that get actually inserted into MySQL database.
Category:Data platform
Category:Data platform systems