Week 51 2024 routine

[kiwixbot]

Check nodes free space

df -h / && df -h /data

• create a report in issue comment

Nodes system upgrades

apt update && apt upgrade

• run systematically the upgrade on bastion, stats, services, storage, demo, mirrors-qa nodes
• check for and apply important security upgrade on worker nodes asap (imager-worker, ondemand, sisyphus)

(regular workers updates are done separately on a monthly basis for worker nodes to not impact production)

Backups

• Ensure all borg repositories are being updated

k8s cluster

• Check Pod errors or in CrashLoopBackoff

k get pods -A -o wide|grep -E 'Error|Crash'

• Check Pod restarts

k get pods -A -o wide | pyp -i 'print("\n".join([line for line in l if re.split(r"\s+", line)[4] != "0"]))'

• Check if k8s should/could be upgraded

curl -s -H "X-Auth-Token: $SCW_SECRET_KEY" https://api.scaleway.com/k8s/v1/regions/fr-par/clusters/$KIWIX_PROD_CLUSTER | jq ".version,.upgrade_available"
curl -s -H "X-Auth-Token: $SCW_SECRET_KEY" https://api.scaleway.com/k8s/v1/regions/fr-par/versions | jq ".versions[].name"

• Upgrade k8s if applicable/possible

Stats

matomo - stats.kiwix.org

• Ensure download.kiwix.org stats are being recorded
• Check whether matomo should be upgraded

Grafana

• Alert list is normal
• Zimfarm dashboard is normal
• Jobs durations dashboard is normal
• There is no abnormal behaviors on cluster resources consumption
• All mdadm RAID arrays are OK (check all instances in the top left combobox)

Projects

• UptimeRobot has no alert
• zimit backlog is reasonable
• Cloud Code Signing Certificate usage is OK (look for Unused Signings under END ENTITY CERTIFICATES): we have 1,200 per year (August to August)
• Analyze zimit failed tasks and document bad domains in our WIP blacklist
• PRs awaiting your review

Security

• Analyze/merge dependabot PRs

Note: this is an automatic reminder intended for the assignee(s).

[rgaudin]

Storage

Machine	Filesystem	Size	Used	Avail	Use%	Use change
bastion	/	37G	16G	20G	44%	-
stats	/	233G	111G	111G	51%	+2G
services	/	456G	220G	213G	51%	+1G
storage	/	33T	9.5T	22T	30%	+200G
imager-worker	/	1.9T	316G	1.5T	18%	don't care
sisyphus	/	233G	15G	206G	-	don't care
ondemand	/	25G	9.8G	14G	42%	+0.1G
ondemand	/data	216G	203M	205G	1%	don't care
demo	/	40G	11G	14G	29%	+1G
demo	/data	1.8T	920G	743G	56%	don't care

misc

• Unused Signings: 898

zimit

• (17) x Main URL returned an unprocessable HTTP code: 403
• (8) x Main URL returned an unprocessable HTTP code: 404
• (3) x Main URL returned an unprocessable HTTP code: 429
• (1) x Main URL returned an unprocessable HTTP code: 503
• (2) x net::ERR_NAME_NOT_RESOLVED (Seed Page Load Failed)
• (1) x net::ERR_ADDRESS_UNREACHABLE (Seed Page Load Failed)
• (1) X net::ERR_CONNECTION_CLOSED (Seed Page Load Failed)
• (1) x net::ERR_CONNECTION_REFUSED (Seed Page Load Failed)
• (1) x net::ERR_TIMED_OUT (Seed Page Load Failed)
• (1) x net::ERR_TOO_MANY_REDIRECTS (Seed Page Load Failed)
• (1) x Mandatory metadata are not all set openzim/warc2zim#427
• (2) x LookupError: unknown encoding: unicode openzim/warc2zim#331 (unicode, u, i)
• (3) x memory consumption (exit code 137) openzim/warc2zim#383
• (1) x crawler timeouts (Seed Page Load Failed). #2b199. Looks like a a Cloudflare-like mechanism.
• (3) x Navigation timeout of 90000 ms exceeded (Seed Page Load Failed)

@benoit74, we have a lot of runs failing in warc2zim due to seed being 40x. Why are we not passing --failOnInvalidStatus alongside --failOnFailedSeed so warc2zim is not even started on such cases?

[benoit74]

Why are we not passing --failOnInvalidStatus alongside --failOnFailedSeed so warc2zim is not even started on such cases?

This is the plan of (part of) openzim/zimit#433

[benoit74]

Note that it will not change the fact that the run will fail, but it will indeed avoid to run a full crawl just to realize that we do not want to create the ZIM