Valheim სერვერზე დაკვირვების ყველაზე იაფი სასარგებლო გზა მისთვის Steam-ის query პროტოკოლით იმის კითხვაა, რამდენი მოთამაშე ჰყავს. სერვერი A2S მოთხოვნებს თამაშის პორტს პლუს ერთზე პასუხობს - ნაგულისხმევად UDP 2457 - და ნებისმიერი A2S ხელსაწყო რამდენიმე მილიწამში აბრუნებს სერვერის სახელსა და მოთამაშეების რაოდენობას. ეს ფარავს "ჩართულია თუ არა" და "ვინმე თამაშობს თუ არა". იმისთვის, ვინ შემოვიდა, ვინ გავიდა და ვინ მოკვდა, წაიკითხე სერვერის ლოგი, რადგან ის ყოველ კავშირს წერს. დაამატე გარე შემოწმება, რომელიც გაფრთხილებას გიგზავნის, როცა query ზედიზედ ორ-სამჯერ აღარ პასუხობს, და სერვერის ჩამოვარდნის შესახებ შენს ჯგუფზე ადრე გაიგებ.
ქვემოთ თითოეული ფენაა: query, ლოგი, uptime შემოწმებები, რომლებიც UDP-ს ნამდვილად ესმით, რესურსების მონიტორინგი და როგორ არ გადაიქცეს შეტყობინებები ხმაურად, რომელსაც ყველა გამორთავს.
რისი თვალყურის დევნებაა ღირებული#
მონიტორინგი სასარგებლოა მხოლოდ მაშინ, თუ ყოველი სიგნალი კითხვას პასუხობს, რომლის მიხედვითაც იმოქმედებდი. Valheim სერვერისთვის ოთხია:
| კითხვა | სიგნალი | საიდან მოდის |
|---|---|---|
| სერვერი ხელმისაწვდომია? | A2S query პასუხობს | UDP query პორტი, გარედან |
| ვინმე თამაშობს? | მოთამაშეების რაოდენობა | A2S query ან ლოგი |
| ვინ შემოვიდა, გავიდა ან მოკვდა? | კავშირისა და პერსონაჟის ხაზები | სერვერის ლოგი |
| მალე დაეცემა? | მეხსიერება და CPU ლიმიტთან შედარებით | ჰოსტი ან პანელი |
გაშვებული პროცესი იგივე არ არის, რაც სერვერი, რომელშიც ხალხს შესვლა შეუძლია. პროცესი შეიძლება ცოცხალი იყოს, მაგრამ სამყაროს ჩატვირთვაში იყოს გაჭედილი, firewall-ის წესი პორტს ბლოკავდეს ან მოდს ელოდებოდეს, რომელიც ვერ ჩაიტვირთა. გარედან გაკეთებული query ის შემოწმებაა, რაც მოთამაშეების გამოცდილებას შეესაბამება, ამიტომ სწორედ მასზე უნდა გაფრთხილება. დანარჩენი დიაგნოსტიკისთვისაა.
სიმპტომებზე და არა მიზეზებზე გაფრთხილების ზოგადი არგუმენტი არის მონიტორინგი, რომელიც რამეს გეუბნება. Valheim-ისთვის კონკრეტულად ეს ნიშნავს: გააფრთხილე, როცა query ვერ მუშაობს, მერე დაუკვირდი მეხსიერებას და ლოგს.
Steam-ის query პორტი და A2S#
Valheim-ის dedicated server ორ UDP პორტს იყენებს. თამაშის პორტი (-port, ნაგულისხმევად 2456) გეიმფლეის ტრაფიკს ატარებს. მის ზემოთ მდებარე პორტი Steam-ის სერვერულ მოთხოვნებს ატარებს - A2S პროტოკოლს, რომელსაც სერვერების ბრაუზერები სერვერის ჩამოსათვლელად და მოთამაშეების რაოდენობის საჩვენებლად იყენებენ.
| პორტი | პროტოკოლი | რა პასუხობს იქ |
|---|---|---|
2456 | UDP | თამაშის ტრაფიკი |
2457 | UDP | A2S მოთხოვნები: info, players, rules |
თუ -port-ს შეცვლი, query პორტიც მასთან ერთად მოძრაობს: -port 2466 ნიშნავს query-ს 2467-ზე. ორივე უნდა იყოს ღია ყველა firewall-ში მონიტორინგის ხელსაწყოსა და სერვერს შორის. query, რომელიც გარედან დრო ამოიწურება, მაგრამ თვითონ მანქანიდან პასუხობს, firewall-ის პრობლემაა და არა სერვერისა.
A2S-ს სამი მოთხოვნა აქვს. A2S_INFO აბრუნებს სერვერის სახელს, რუკას, მოთამაშეების რაოდენობასა და მაქსიმუმს. A2S_PLAYER აბრუნებს დაკავშირებული მოთამაშეების სიას სახელით, ქულითა და დაკავშირების დროით. A2S_RULES აბრუნებს გასაღებ-მნიშვნელობის წყვილებს, რომლებსაც სერვერი აქვეყნებს. Valheim-ისთვის სანდოა A2S_INFO. მოთამაშეების სია ნაკლებად სასარგებლოა, ვიდრე ჟღერს - სახელები ვერსიისა და პლატფორმის მიხედვით შეიძლება ცარიელი ან ზოგადი იყოს - ამიტომ რაოდენობა სიმართლედ მიიჩნიე, სია კი ბონუსად. Query ports and A2S პროტოკოლს განმარტავს და იმასაც, რატომ პასუხობენ ზოგი თამაშები სხვაგვარად.
query python-a2s-ითა და GameDig-ით#
ორი ხელსაწყო თითქმის ყველა საჭიროებას ფარავს. python-a2s პატარა Python ბიბლიოთეკაა, რომელიც A2S მოთხოვნებს აგზავნის და დამუშავებულ შედეგს აბრუნებს:
$ pip install python-a2simport a2sADDRESS = ("203.0.113.10", 2457) # query port, not game portinfo = a2s.info(ADDRESS, timeout=3.0)print(f"{info.server_name}: {info.player_count}/{info.max_players}")for player in a2s.players(ADDRESS, timeout=3.0): print(player.name or "(no name)", round(player.duration / 60), "min")timeout გამონაკლისს ტოვებს, რაც სწორედ ის არის, რაც გინდა: მონიტორინგის სკრიპტს "გამონაკლისი" შეუძლია "ჩამოვარდნილად" მიიჩნიოს. ერთხელ დაბეჭდე მთელი info ობიექტი, რომ ნახო, რას აბრუნებს შენი სერვერის ვერსია - ველები ყველა A2S თამაშისთვის ერთნაირია, მაგრამ რას დებს მათში Valheim, დროთა განმავლობაში შეიცვალა.
GameDig Node.js ხელსაწყოა, რომელმა ასობით თამაშის თავისებურებები იცის, მათ შორის რომელ პორტს უნდა მიმართოს:
$ npm install -g gamedig$ gamedig --type valheim 203.0.113.10:2456GameDig-ის Valheim-ის პროფილი query პორტის წანაცვლებას ითვალისწინებს, ამიტომ თამაშის პორტს აძლევ. თუ დრო ამოიწურება, შეამოწმე ვერსიის დოკუმენტაცია, როგორ ეპყრობა პორტს, და სცადე query პორტი პირდაპირ. ის აბრუნებს JSON-ს name, numplayers, maxplayers და ping-ით, რაც ნებისმიერ სხვა რამეში გადაცემას ამარტივებს.
არსებობს Steam Web API-ის IGameServersService/GetServerList-იც, რომელიც Steam-ის master server-ზე რეგისტრირებულ სერვერებს ჩამოთვლის და Steam Web API გასაღებს საჭიროებს. ის აჩვენებს იმას, რასაც საზოგადოებრივი ბრაუზერი ხედავს, რაც გამოსადეგია, როცა კითხვაა "რატომ აკლია ჩემი სერვერი სიიდან". ის ჯანმრთელობის შემოწმება არ არის: რეგისტრაცია რეალობას წუთებით ჩამორჩება. ეს შემთხვევა განმარტებულია Valheim სერვერი სიაში არ ჩანს სტატიაში.
მოთამაშეების თვალყური ლოგიდან#
ლოგი ერთადერთი წყაროა, რომელმაც იცის, ვინ რა გააკეთა. ყოველი კავშირი, პერსონაჟის გაჩენა და გათიშვა ხაზს ქმნის. ზუსტი ფორმულირება ვერსიებს შორის იცვლება და crossplay სერვერები უბრალო SteamID-ების ნაცვლად PlayFab-ით პლატფორმის ID-ებს წერენ, ამიტომ შაბლონზე დაყრდნობამდე შენს ლოგს შეადარე. ბოლო Steam-only სერვერზე სასარგებლო ხაზები ასე გამოიყურება:
Got connection SteamID 76561198012345678Got character ZDOID from Ragnar : 1234567890:1Got character ZDOID from Ragnar : 0:0Closing socket 76561198012345678World saved ( 412.338ms )რას ამბობს თითოეული ხაზი:
Got connection SteamID- კლიენტი დაუკავშირდა, პერსონაჟის არჩევამდე. ID გამოიყენე ადმინისა და ban სიებისთვის.Got character ZDOID from <name> : <id>- მოთამაშის პერსონაჟი გაჩნდა, ამიტომ ეს ნამდვილი "შემოვიდა" მომენტია, პერსონაჟის სახელით.- იგივე ხაზი
0:0-ით დასრულებული - პერსონაჟი მოკვდა. ამ ხაზზეა აგებული Discord-ის სიკვდილის გამცხადებლები. Closing socket- კლიენტი წავიდა.World saved- შენახვა დასრულდა, ხანგრძლივობით. შენახვის დრო, რომელიც იზრდება, მძიმდება სამყაროს ადრეული ნიშანია.
systemd დაყენებაზე ლოგი ცოცხლად journalctl -u valheim -f-ით გაჰყევი. -logFile-ით ფაილს tail -F გაუშვი; -F ფაილს როტაციის გავლით მიჰყვება. პატარა ციკლი საკმარისია შესვლისა და გასვლის ნაკადისთვის:
#!/usr/bin/env bashjournalctl -u valheim -f -o cat | while read -r line; do case "$line" in *"Got character ZDOID from"*": 0:0"*) echo "DEATH ${line#*from }" ;; *"Got character ZDOID from"*) echo "JOIN ${line#*from }" ;; *"Closing socket"*) echo "LEAVE ${line##* }" ;; esacdoneსიკვდილის შაბლონი უნდა შემოწმდეს შესვლისაზე ადრე, რადგან ორივეს ერთი პრეფიქსი აქვს. echo Discord webhook-ის გამოძახებით ჩაანაცვლე და მოდების გარეშე ძირითადი გამცხადებელი გაქვს. ლოგის სრული გავლა, გაშვების ხაზებისა და შეცდომების ჩათვლით, რომლებიც მოქმედებას იმსახურებს, არის Valheim სერვერის ლოგის განმარტებაში.
თუ სკრიპტის მოვლა არ გინდა, Discord Connector მოდი იგივეს სერვერის შიგნიდან აკეთებს და crossplay-ის ID-ებსაც ამუშავებს - იხილე Discord Connector for Valheim.
uptime შემოწმებები, რომლებსაც UDP ესმით#
uptime სერვისების უმეტესობა ვებგვერდებს ამოწმებს: HTTP მოთხოვნა ან TCP კავშირი პორტზე. არც ერთი Valheim-ზე არ მუშაობს. სერვერი HTTP-ს არ ლაპარაკობს და მისი ორივე პორტი UDP-ა, ამიტომ 2456-ზე TCP პორტის შემოწმება მარცხდება მაშინაც, როცა სერვერი სრულიად ჯანმრთელია. უბრალო ICMP ping მხოლოდ იმას ამტკიცებს, რომ მანქანა ჩართულია და არა თამაში.
რა მუშაობს:
- თვითჰოსტირებული შემმოწმებელი, რომელიც A2S-ს ლაპარაკობს. Uptime Kuma, გავრცელებული თვითჰოსტირებული ვარიანტი, თამაშის სერვერის მონიტორის ტიპებს შეიცავს; ბოლო ვერსიებში GameDig-ზე აგებულია. მიუთითე თამაშის სერვერის მისამართზე Valheim-ის ტიპით და ის Discord-ით, ელფოსტით, Telegram-ითა და უმეტეს სხვა არხზე აფრთხილებს. უფრო ძველი ვერსიები გვთავაზობდნენ Steam-ის თამაშის სერვერის ტიპს, რომელსაც Steam Web API გასაღები სჭირდებოდა, ამიტომ შეამოწმე, რა აქვს შენს ვერსიას.
- cron სამუშაო სხვა მანქანაზე. ზემოთ მოცემული Python სკრიპტი ყოველ წუთში გაუშვი სხვა სერვერიდან, დათვალე ზედიზედ მარცხები, გააფრთხილე მესამეზე. თხუთმეტი ხაზი კოდი და
python-a2s-ის გარდა არავითარი დამოკიდებულება. - სტატუსის endpoint შენი კონტეინერიდან.
lloesche/valheim-serverDocker image-ს შეუძლია პატარა სტატუსის ვებსერვერი გაუშვას, რომელიც query-ს შედეგს JSON-ად აქვეყნებს (STATUS_HTTPცვლადები მის README-ში). ჩვეულებრივ HTTP uptime შემმოწმებელს მერე მისი დაკვირვება შეუძლია. გაითვალისწინე, რომ ის იმავე კონტეინერში მუშაობს, ამიტომ ვერ გეტყვის, რომ გარე სამყაროს თამაშის პორტამდე მისვლა არ შეუძლია.
გაუშვი შემოწმება სერვერის საკუთარი ქსელის გარედან. იმავე მანქანიდან შემოწმება არაფერს ამბობს firewall-ზე, მარშრუტიზაციაზე ან პროვაიდერზე, რაც სწორედ ის რამეებია, რაც პროცესის შეუმჩნევლად ტყდება.
მეხსიერება, CPU და დისკი#
query გეუბნება, რომ რაღაც არასწორია; რესურსების გრაფიკები ჩვეულებრივ გეუბნება, რა. სამ რიცხვს დააკვირდი.
| მეტრიკა | ჯანსაღი | რა მოითხოვს მოქმედებას |
|---|---|---|
| მეხსიერება | სტაბილური სამყაროს ჩატვირთვის შემდეგ, დღეების განმავლობაში ნელა იზრდება | ლიმიტიდან 10-15%-ში, ან ნახტომი მოდის შემდეგ |
| CPU | მწვერვალები, როცა მოთამაშეები იბრძვიან, აშენებენ ან ახალ ზონებში ჩადიან | ლიმიტზე მიკრული ცოტა მოთამაშესთან |
| დისკი | ნელა იზრდება სამყაროს ზომასთან და backup-ებთან ერთად | backup-ები დისკს ავსებენ, ან სამყაროს .db კვირაში ორჯერ იზრდება |
მეხსიერება ის არის, რაც სესიებს ასრულებს. Valheim-ის გამოყენება გამოკვლეულ და აშენებულ ფართობთან ერთად იზრდება, სერვერი, რომელიც მეხსიერების ლიმიტს აღწევს, ძალით ჩერდება, შენახვის გარეშე. ნიმუში, რომელსაც უნდა დააკვირდე, დღეების განმავლობაში ნელი აღმავალი დახრილობაა გაჩერების გარეშე - სწორედ ამას ასწორებს დაგეგმილი restart, რაც განმარტებულია Valheim-ის დაგეგმილ restart-ებში. რეალისტური რიცხვები ჯგუფის ზომის მიხედვით იხილე რამდენი RAM სჭირდება Valheim სერვერს.
შენს Linux მანქანაზე systemctl status valheim unit-ის მიმდინარე მეხსიერებას აჩვენებს, ps -o rss,cmd -C valheim_server.x86_64 კი პროცესის რეზიდენტულ მეხსიერებას გაძლევს კილობაიტებში. ისტორიისთვის ნებისმიერი ხელსაწყო, რომელიც მეტრიკებს ინახავს, გამოდგება - node_exporter და Prometheus, Netdata ან ჰოსტის საკუთარი გრაფიკები.
RE:NODE-ზე კონსოლი მეხსიერების, CPU-სა და დისკის ცოცხალ გრაფიკებს გეგმის ლიმიტებთან ერთად აჩვენებს, ამიტომ კითხვა "რამდენად ახლოს ვარ" არაფრის დაყენების გარეშე გაქვს პასუხგაცემული. watcher ასევე ყოველ ორ წუთში ამოწმებს სერვერს, რომელიც გაითიშა ან რომლის uptime უკან წავიდა. შენ მოთხოვნილი restart-ები არ ითვლება; საათში სამი მოულოდნელი restart სერვერის გვერდზე გაფრთხილებას აჩენს და ავტომატურად ტიკეტს ხსნის, ამიტომ crash loop შენც რომ გძინავდეს, შეიმჩნევა. გზამკვლევების console განყოფილება აჩვენებს, სად არის გრაფიკები.
შეტყობინებები, რომლებსაც ხალხი არ აჩუმებს#
შეტყობინება, რომელიც ყოველ ჯერზე ირთვება, როცა მოთამაშის ping ირყევა, ერთ კვირაში ჩუმდება და შემდეგ ნამდვილ გაუმართაობას აკლდება. რამდენიმე წესი შეტყობინებებს აზრიანს ინარჩუნებს:
- მოითხოვე ზედიზედ მარცხები. ერთი დაკარგული UDP პაკეტი ნორმალურია. გააფრთხილე სამი წარუმატებელი შემოწმების შემდეგ, ერთი წუთის ინტერვალით, და არა ერთის შემდეგ.
- გააფრთხილე აღდგენისასაც. "ისევ ჩართულია 4 წუთის შემდეგ" გეუბნება, გამოიკვლიო თუ უგულებელყო.
- ადმინის შეტყობინებები მოთამაშეების ახალი ამბებისგან გაყავი. შესვლისა და სიკვდილის შეტყობინებები არხს ეკუთვნის, რომელსაც მოთამაშეები კითხულობენ. გაჩერება და მეხსიერების გაფრთხილებები იქ, სადაც მხოლოდ ადმინები ხედავენ.
- დაგეგმილი სამუშაო გაჩუმე. თუ სერვერი ყოველდღე 05:00-ზე გადაიტვირთება, შემმოწმებელმა 05:01-ზე არავინ უნდა გააფრთხილოს. ან დაპაუზე ფანჯრის დროს, ან მოითხოვე მარცხები, რომლებიც restart-ზე დიდხანს გრძელდება.
- ჩართე ის, რაც იცი. შეტყობინება, რომელიც ამბობს "query ვერ მუშაობს Frankfurt-იდან, ბოლო მოთამაშეების რაოდენობა 3, მეხსიერება ლიმიტის 92%", ისეთია, რომლის მიხედვითაც ტელეფონიდან იმოქმედებ.
მინიმალური ზედიზედ მარცხების შემმოწმებელი:
import a2s, json, pathlib, sys, urllib.requestADDRESS = ("203.0.113.10", 2457)WEBHOOK = "https://discord.com/api/webhooks/REPLACE/ME"STATE = pathlib.Path("/var/tmp/valheim_failures")def notify(text): body = json.dumps({"content": text}).encode() req = urllib.request.Request(WEBHOOK, body, {"Content-Type": "application/json"}) urllib.request.urlopen(req, timeout=5)fails = int(STATE.read_text()) if STATE.exists() else 0try: a2s.info(ADDRESS, timeout=3.0) if fails >= 3: notify("Valheim is answering again.") fails = 0except Exception: fails += 1 if fails == 3: notify("Valheim has not answered queries for 3 minutes.")STATE.write_text(str(fails))გაუშვი ყოველ წუთში cron-ით სხვა მანქანაზე. ის მესამე მარცხზე ერთხელ აფრთხილებს და აღდგენისას ერთხელ და არა შუალედში ყოველ წუთს. Discord webhooks for server status განმარტავს ფორმატირებასა და Discord-ის rate limit-ებს.
მონიტორინგის გავრცელებული პრობლემები#
query-ს დრო ეწურება, მაგრამ მოთამაშეებს შესვლა შეუძლიათ. მონიტორინგის ხელსაწყო თამაშის პორტს ურტყამს query პორტის ნაცვლად, query პორტი firewall-ში დაკეტილია, ან სერვერი crossplay-ია და Steam-ის მოთხოვნებს ისე არ პასუხობს, როგორც შენი ხელსაწყო ელის. გამოიყენე query თვითონ მანქანიდან, რომ შემთხვევები გაარჩიო.
მოთამაშეების რაოდენობა ნულზეა გაჭედილი, სანამ ხალხი თამაშობს. იგივე მიზეზები, ან ხელსაწყო, რომელიც იმავე მისამართზე სხვა სერვერს ეკითხება. შეამოწმე სერვერის სახელი პასუხში.
რაოდენობა სწორია, მაგრამ სახელები აკლია. Valheim-ის ბევრ ვერსიაზე მოსალოდნელია. სახელებისთვის ლოგი გამოიყენე.
uptime შემოწმება ყოველ დილით ამბობს, რომ სერვერი გათიშულია. დაგეგმილი restart. შემოწმება ფანჯრის დროს დაპაუზე ან მოითხოვე, რომ მარცხები restart-ზე დიდხანს გაგრძელდეს.
ლოგის შაბლონებმა განახლების შემდეგ დამთხვევა შეწყვიტეს. Iron Gate ხანდახან ლოგის ფორმულირებას ცვლის. ყოველი მთავარი პატჩის შემდეგ შეხედე ახალ ლოგს და განაახლე შაბლონები.
FAQ#
რომელ პორტს ვეკითხები Valheim სერვერის მოთამაშეების რაოდენობის მისაღებად?
თამაშის პორტს პლუს ერთს, UDP-ზე. ნაგულისხმევი -port 2456-ით ეკითხე 2457-ს. GameDig იღებს თამაშის პორტს და წანაცვლებას თვითონ ამატებს; python-a2s-სა და უმეტეს სხვა A2S ბიბლიოთეკას query პორტი სჭირდება.
შემიძლია მოდის გარეშე ვნახო, რომელი მოთამაშეები არიან ონლაინ?
დიახ, სერვერის ლოგიდან. პერსონაჟის ყოველი გაჩენა ჩაიწერება პერსონაჟის სახელით, ყოველი გათიშვა კი მოთამაშის ID-ით, ამიტომ სკრიპტს, რომელიც ლოგს მიჰყვება, ცოცხალი სიის შენახვა შეუძლია. A2S-ის მოთამაშეების სია ვერსიის მიხედვით შეიძლება შეიცავდეს სახელებს, ან არა.
რატომ მეუბნება TCP პორტის შემოწმება, რომ ჩემი Valheim სერვერი გათიშულია?
იმიტომ, რომ Valheim TCP-ს არ იყენებს. მისი ორივე პორტი UDP-ა, ამიტომ TCP კავშირის მცდელობა ყოველთვის მარცხდება. გამოიყენე შემმოწმებელი, რომელიც A2S მოთხოვნებს UDP-ზე აგზავნის.
რამდენად ხშირად უნდა გაეშვას uptime შემოწმება?
წუთში ერთხელ, სამი ზედიზედ მარცხის შემდეგ გაფრთხილებით. ეს ნამდვილ გაუმართაობას დაახლოებით სამ წუთში იჭერს და ვინმეს გაგდებულ პაკეტზე არ აღვიძებს.
ანელებს მონიტორინგი სერვერს?
არა. A2S query ერთი პატარა UDP პაკეტი და პასუხია, რომელიც თამაშის მთავარი ნაკადის გარეთ მუშავდება. წამში ერთიც კი ერთი მოთამაშის ტრაფიკთან შედარებით უხილავი იქნებოდა.


