როგორ წაიკითხო სერვერის კონსოლი და იპოვო ნამდვილი მიზეზი

კონსოლი სერვერის პირდაპირი მოყოლაა იმისა, რაც მოხდა, და სწორედ ამიტომ არის ის პირველი, რასაც ნებისმიერი მხარდაჭერის გუნდი ითხოვს: თითქმის ყოველთვის საკმარისია. პრობლემა ისაა, რომ კონსოლი ათასი ხაზის თხრობაა, სადაც ოთხი მნიშვნელოვანი შუაშია ჩაფლული და ყველა ერთნაირადაა ფორმატირებული. მისი სწორად წაკითხვა უნარია, რომელიც ოც წუთს ღირს ასათვისებლად და შემდეგ ყოველ გაფუჭებაზე ერთ საათს დაგიზოგავს. ოთხი ხერხია: იპოვო ხაზი, რომელიც ამბობს, რომ სერვერი ჩაირთო; გაარკვიო, რა სიმძიმის ხაზს უყურებ; წაიკითხო წარუმატებლობიდან ზემოთ და არა თავად მასზე; და ამოიცნო ათიოდე ხაზი, რომელიც კატასტროფულად გამოიყურება და არაფერს ნიშნავს.

ლოგის ხაზის აგებულება#

სერვერის ლოგების უმეტესობა ერთი და იგივე ხუთი ველია სხვადასხვა თანმიმდევრობით.

[21:14:07] [Server thread/INFO]: Done (11.402s)! For help, type "help"[21:16:44] [Server thread/WARN]: Can't keep up! Is the server overloaded?[21:19:02] [Craft Scheduler Thread #3/ERROR]: Could not pass event to ShopPlus v3.2

დრო, thread-ი, დონე, შეტყობინება. thread-ი უფრო სასარგებლოა, ვიდრე ჩანს: Minecraft-ში Server thread მთავარი tick-ის ციკლია და იქ მომხდარი ნებისმიერი წარუმატებლობა ყველას ეხება, ხოლო Craft Scheduler Thread-ის წარუმატებლობა plugin-ის ფონური დავალებაა და ჩვეულებრივ ერთ ფუნქციაზე მოქმედებს. Paper-ის ახალი build-ები მოკლე ფორმას ბეჭდავს, სადაც დონე დროის ფრჩხილშია ჩაწერილი, ამიტომ არ გაგიკვირდეს, თუ ფორმა ვერსიებს შორის ოდნავ განსხვავდება.

ორი რამ კონსოლზე, როგორც მის უკან მდგომი ლოგ ფაილისგან განსხვავებით:

• ეს stdout და stderr ერთადაა შერეული. ორ ნაკადს შორის თანმიმდევრობა ავარიის ირგვლივ შეიძლება ოდნავ არასწორი იყოს, რადგან ისინი ცალ-ცალკე იბუფერება. თუ შეცდომა თითქოს მას ხაზს მოსდევს, რომელმაც ის უნდა გამოიწვიოს, ეს არის მიზეზი.
• დრო სერვერის საათისაა და არა შენი. ჰოსტზე ეს ძალიან ხშირად UTC-ა. როცა მოთამაშე ამბობს "ცხრაზე გაფუჭდა", ძებნამდე დაადგინე, ვისი ცხრა.

პანელზე კონსოლი სერვერის საკუთარი გაუფილტრავი გამოტანაა და ის, რასაც პანელი ჩართვა-გამორთვის ქმედებებზე ბეჭდავს. RE:NODE-ზე ხმაური, რომელსაც ვებ სერვერები წარმოქმნის - ინტერნეტის ყველა ბოტი, რომელიც /wp-login.php-ს ეძებს - დაკეცილია მრიცხველის უკან, რომლის გამორთვაც შეგიძლია, და ეს არის განსხვავება წასაკითხ ლოგსა და ჩამოსაგორებელ კედელს შორის.

ჯერ იპოვე ready ხაზი#

ყველა სერვერი რაღაცას ბეჭდავს, როცა გაშვებას ამთავრებს. მისი პოვნა მთელი პროცესის ყველაზე ღირებული ქმედებაა, რადგან ლოგს ორ ნაწილად ყოფს და გეუბნება, რომელი წაიკითხო.

თუ ეს ხაზი არსებობს, სერვერი ჩაირთო და შენი პრობლემა ყველაფერია, რაც მას მოჰყვება. თუ არ არსებობს, ყველაფერი დაბეჭდილი გაშვებაა და დასასრულამდე ბოლო რამდენიმე ხაზი მიზეზია, რის გამოც ის გაჩერდა. ეს ერთი განსხვავება "ჩემი სერვერი არ მუშაობს" ტიპის მოთხოვნების დიდ ნაწილს სხვა ფიქრამდეც წყვეტს.

როგორ გამოიყურება ჯანსაღი გაშვება#

გაშვების ბლოკი ყოველთვის ერთსა და იმავე ეტაპებს ერთსა და იმავე თანმიმდევრობით გადის და მათი ცოდნა ნიშნავს, რომ წერტილი, სადაც შენი ლოგი წყდება, თავად დიაგნოზია. Minecraft სერვერი, ოდნავ შემოკლებული:

[21:13:52] [ServerMain/INFO]: Starting minecraft server version 1.21.1[21:13:52] [ServerMain/INFO]: Loading properties[21:13:52] [ServerMain/INFO]: Default game type: SURVIVAL[21:13:53] [ServerMain/INFO]: Generating keypair[21:13:53] [Server thread/INFO]: Starting Minecraft server on *:25565[21:13:53] [Server thread/INFO]: Using epoll channel type[21:13:54] [Server thread/INFO]: This server is running Paper version 1.21.1[21:13:55] [Server thread/INFO]: [LuckPerms] Enabling LuckPerms v5.4[21:13:56] [Server thread/INFO]: Preparing level "world"[21:14:01] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld[21:14:04] [Server thread/INFO]: Preparing spawn area: 62%[21:14:07] [Server thread/INFO]: Time elapsed: 11123 ms[21:14:07] [Server thread/INFO]: Done (11.402s)! For help, type "help"

ხუთი ეტაპია: კონფიგის იდენტიფიკაცია და წაკითხვა, port-ზე მიბმა, plugin-ების ჩატვირთვა, სამყაროს ჩატვირთვა, დასრულება. სად წყდება, ის გეუბნება, რომელი ჩავარდა.

Preparing spawn area სტრიქონი ახალი სამყაროს პირველ გაშვებაზე იჭერს ხალხს, განსაკუთრებით დიდი ხედვის დისტანციისას ან გენერაციის mod-ის შემთხვევაში. მას კანონიერად შეუძლია რამდენიმე წუთით ერთ პროცენტზე გაჩერდეს. ათ წუთს მიეცი, სანამ გაჭედილად გამოაცხადებ, და თუ პროცენტი საერთოდ არ იცვლება, დისკი შეამოწმე.

სიმძიმე, თანმიმდევრობით#

ერთი გამონაკლისი, რომელსაც მნიშვნელობა აქვს: დონეს ხაზის დამწერი ირჩევს და არა რომელიმე ავტორიტეტი. plugin-ების ავტორები ჩვეულებრივ გაშვების ჟღურტულს ERROR-ზე წერენ, ნამდვილ კატასტროფებს კი INFO-ზე, სამწუხარო სიხშირით. დონე ჩათვალე მინიშნებად, საიდან დაიწყო, და არა განაჩენად. იგივე ეხება ნაკადს: ბევრი კარგად მოქცეული პროგრამა banner-ებს, ვერსიის შეტყობინებებს და garbage collection ლოგებს stderr-ში წერს, ამიტომ იქ ხაზის გამოჩენა თავისთავად არაფრის მტკიცებულებაა.

მეორე სასარგებლო წესი: სესიის პირველი ERROR მეასეზე მეტს ღირს. შეცდომები კასკადურად მოდის. ერთი plugin-ის ჩატვირთვის წარუმატებლობა მის დამოკიდებულ ყველაფერში ორმოც შემდგომ წარუმატებლობას იწვევს, და ეს ორმოცი ხმაურია. ამოძებნე ყველაზე ადრეული.

წაიკითხე წარუმატებლობიდან ზემოთ#

ბოლო ხაზი ის ადგილია, სადაც სერვერმა დანებდა და არა ის, სადაც არასწორად წავიდა. მიზეზი ჩვეულებრივ მასზე ათიდან ორმოც ხაზამდე ზემოთაა და ეს არის პირველი ხაზი, რომელიც შენ დაყენებულ რამეს ასახელებს და არა თამაშის შემადგენელს.

ჩასვი წარუმატებლობამდე ორმოცდაათი ხაზი და არა ბოლო ერთი. ბოლო ხაზი ნებისმიერი ავარიის ყველაზე ნაკლებ ინფორმატიული ნაწილია.

როცა ზუსტად არ იცი, რას ეძებ, ეძებე ეს ბრძანებები ამ თანმიმდევრობით:

$ grep -n -iE "fatal|exception|caused by|error" logs/latest.log | head -40$ sed -n '/Done (/,$p' logs/latest.log | head -100     # everything after startup$ tail -n 200 logs/latest.log

მეორე ყველაზე ნაკლებად გამოყენებულია. მხოლოდ ready ხაზის შემდგომის დაბეჭდვა ერთბაშად აქრობს გაშვების ყველა გაფრთხილებას, გაშვების გაფრთხილებები კი ის მთავარი რამაა, რაც ხალხს აბნევს.

Java stack trace-ის კითხვა#

გეიმ სერვერების უმეტესობა Java-ზეა და Java trace-ს აქვს სტრუქტურა, რომლის ცოდნა ანაზღაურდება.

[21:19:02] [Server thread/ERROR]: Could not pass event PlayerInteractEvent to ShopPlus v3.2org.bukkit.event.EventException: null    at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:306)    at org.bukkit.plugin.EventExecutor.execute(EventExecutor.java:70)    at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70)    ... 24 moreCaused by: java.lang.NullPointerException: Cannot read field "price" because "shop" is null    at net.example.shopplus.ShopListener.onInteract(ShopListener.java:128)    ... 27 more

ხუთი წესი ამას დაახლოებით ათ წამში კითხულობს:

1. პირველი ხაზი შეჯამებაა და ხშირად უკვე ასახელებს დამნაშავეს. მასში ShopPlus v3.2 წერია. trace-ების ნახევარი აქვე იხსნება.
2. ჩარჩოები ყველაზე ახალი პირველია. ზედა at ხაზი ადგილია, სადაც შესრულება წარუმატებლობისას იმყოფებოდა.
3. გამოტოვე თამაშის საკუთარი პაკეტების ჩარჩოები. org.bukkit, net.minecraft, java.util - ესენი შუამავლებია. ეძებე პირველი პაკეტი, რომელიც ვინმეს plugin-ს ან mod-ს ეკუთვნის.
4. მიჰყევი `Caused by:`-ს ბოლომდე. ჯაჭვი სიმპტომიდან ძირისკენ მიდის, ამიტომ ბოლო Caused by ნამდვილი მიზეზია. ხალხი პირველს კითხულობს და არასწორ რამეს ასწორებს.
5. `... 27 more` ნიშნავს, რომ იდენტური ჩარჩოები გამოტოვებულია. ეს შეკვეცა არ არის და აღდგენა არ გჭირდება.

ხშირად გამონაკლისის ტიპი მარტო მთელი დიაგნოზია:

UnsupportedClassVersionError ორივე რიცხვს ასახელებს, რაც სუფთად იშიფრება: class ფაილის ვერსია 52 არის Java 8, 61 არის Java 17, 65 კი Java 21. შეტყობინება, რომელიც ამბობს, რომ jar ვერსია 65-ია და runtime-ი 61-მდე ესმის, ნიშნავს, რომ Java 21 გჭირდება. Minecraft-ის JVM flag-ები და Java-ს ვერსიები-ში Minecraft-ის ყველა რელიზის შესაბამისობაა.

სხვა runtime-ები, სხვა ფორმები#

კითხვის მიმართულება ყველგან ერთი არ არის და მისი შეცდომით აღება რეალურ დროს კარგავს.

Node.js შეცდომას პირველ ადგილას სვამს, ჩარჩოებს კი მის ქვემოთ, ყველაზე ახალი პირველად, და Caused by ჯაჭვი არ არსებობს, თუ ბიბლიოთეკა არ ააგებს. სასარგებლო ხაზი ზედაა.

Error: listen EADDRINUSE: address already in use :::3000    at Server.setupListenHandle [as _listen2] (node:net:1872:16)    at listenInCluster (node:net:1920:12)

ოთხი, რომელსაც რეალურად შეხვდები: EADDRINUSE (port დაკავებულია, ხშირად წინა ინსტანციით), MODULE_NOT_FOUND და Cannot find module (დამოკიდებულებები არ დაყენდა ან რეგისტრზე მგრძნობიარე გზა შენს Mac-ზე მუშაობს და Linux-ზე - არა), ECONNREFUSED (რაღაც, რაზეც დამოკიდებული ხარ, არ მუშაობს) და დამუშავებელი promise rejection, რომელიც Node-ის მიმდინარე ვერსიებში პროცესს ნაგულისხმევად წყვეტს. Node.js-ის მეხსიერების ლიმიტები ახსნილი მეხსიერებასთან დაკავშირებულებს ფარავს.

Python Java-ს საპირისპიროა: traceback-ის ჩარჩოები ყველაზე ძველიდან იწყება და გამონაკლისი ბოლო ხაზია. Python-ში ბოლო ხაზი მართლაც პასუხია.

Source engine სერვერებს ლოგის დონეები საერთოდ არ აქვთ - ყოველი ხაზი უბრალო print-ია. გაშვება ძირითადად Steam-სა და breakpad-ის შესახებ ხმაურია, ავარია კი ჩვეულებრივ signal-ით სრულდება და მოწვევით, გაშვების ბრძანებაში -debug დაამატო, რომ debug.log შეიქმნას. სწორედ ამ ლოგშია სასარგებლო ნაწილი; კონსოლი მხოლოდ იტყვის, რომ მოკვდა.

Unreal-ზე დაფუძნებული სერვერები (Satisfactory, Squad, The Isle) ხაზებს ქვესისტემის პრეფიქსით იწყებენ, მაგალითად LogNet: Warning:, და მოკვდომისას საკუთარი ლოგით ცალკე crash საქაღალდეს წერენ. წაიკითხე crash საქაღალდე და არა კონსოლი.

ხაზები, რომლებიც ფატალურს ჰგავს და არ არის#

ეს სია პოსტის ყველაფერზე მეტ დროს გიზოგავს. ყველა ეს რუტინულია:

• Can't keep up! Is the server overloaded? Running 2500ms or 50 ticks behind - ანგარიში იმისა, რომ სერვერი წამით ნელი იყო და არა ავარია. ის ჩნდება ყოველი გადატვირთვის, ყოველი დიდი შენახვისა და chunk-ების გენერაციის ყოველი აფეთქების შემდეგ. მნიშვნელობა აქვს მხოლოდ მაშინ, როცა მუდმივია, და მაშინ მოქმედებს რატომ ეცემა TPS და რა ვქნა.
• --- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH --- - Paper-ის watchdog-ის ადრეული გაფრთხილება, იბეჭდება, რადგან tick დიდხანს გრძელდება. ის ლაგზე გეუბნება და banner სწორედ იმიტომ არსებობს, რომ crash ანგარიშს ჰგავს.
• WARNING: An illegal reflective access operation has occurred - JDK-ის გაფრთხილება ბიბლიოთეკაზე, რომელიც ძველ მექანიზმს იყენებს. უვნებელია Java-ს იმ ვერსიებზე, რომლებიც მას ბეჭდავენ.
• Picked up JAVA_TOOL_OPTIONS: - JVM ადასტურებს გარემოს ცვლადს. საინფორმაციოა.
• Setting breakpad minidump AppID - Source engine სერვერი გაშვებისას საკუთარ crash დამმუშავებელს აყენებს. ეს ნიშნავს, რომ არაფერი გაფუჭებულა.
• plugin-ების შეტყობინებები არასავალდებულო დამოკიდებულების არარსებობაზე, მაგალითად permissions ან economy API, რომლის გარეშეც plugin-ს შეუძლია იმუშაოს.
• ვებ აპლიკაციის ლოგში ერთეული კავშირის შეცდომები: ვიღაცის ბრაუზერმა მოთხოვნის შუაში კავშირი დახურა ან ბოტმა არარსებული გზა შეამოწმა. ერთი არაფერია. წუთში ათასი კი rate limit-ები და abuse-ია.

და საპირისპირო - ხაზები, რომლებიც მსუბუქად გამოიყურება და არ არის: ერთი WARN კონფიგის მნიშვნელობის ნაგულისხმევზე დაბრუნებაზე (შენს ფაილში რაღაც არასწორია და უხმოდ უგულებელყოფილია), WARN სამყაროს განახლებაზე ან მონაცემების გასწორებაზე, რომელიც მიმდინარეობს (შენი save გარდაიქმნება და უკან გზა არ არის), და ყველაფერი, რაც backup-ის გამოტოვებას ახსენებს.

კონსოლი როგორც შესასვლელი და სად ინახება ლოგები#

კონსოლი ორმხრივი მოწყობილობაა. RE:NODE-ზე მას აქვს ბრძანების ხაზი ისტორიითა და tab-ით შევსებით, და ყველაფერი, რასაც აკრეფ, სერვერის სტანდარტულ შეყვანაზე ზუსტად ისე მიდის, თითქოს მანქანასთან აკრიფე. stop Minecraft-ში, quit Source სერვერზე და თამაშის საკუთარი ადმინის ბრძანებები ყველა მუშაობს. ეს ასევე გეიმ სერვერის გამორთვის სწორი გზაა: სუფთა stop სამყაროს ინახავს, Kill - არა.

ორი გაფრთხილება. პირველი, ყველაფერი, რასაც აკრეფ, ლოგში ხვდება, ამიტომ პაროლებს, token-ებსა და RCON-ის მონაცემებს ნუ ჩასვამ - ცვლადებისთვის Startup ჩანართი გამოიყენე და იხილე გარემოს ცვლადები და საიდუმლოები და RCON-ის უსაფრთხოდ გამოყენება. მეორე, კონსოლის გადახვევის ისტორია სასრულია და გადატვირთვისას ისუფთავება. დისკზე ფაილი არც სასრულია და არც იშლება.

$ zgrep -i "outofmemory\|fatal" logs/*.log.gz$ ls -lht logs/ | head

ჩამოტვირთე ლოგი გადატვირთვამდე და არა მის შემდეგ. დიაგნოზის დაკარგვის ყველაზე გავრცელებული გზაა Restart-ის დაჭერა, რომ "ვნახოთ, განმეორდება თუ არა", რაც განმეორდება და პირველი შემთხვევის მტკიცებულებას მოაშორებს. ამის ჩვევა ლოგები, რომლებიც შესანახად ღირს-შია.

როცა ticket-ს ხსნი, გამოგზავნე ოთხი რამ: წარუმატებლობამდე ორმოცდაათი ხაზი ტექსტად და არა ეკრანის სურათად, exit კოდი, თუ გაქვს, დრო დროის სარტყელით და ის, რა შეიცვალა იმ დღეს. RE:NODE-ზე პანელიდან გაგზავნილი ticket ყველა თანამშრომელს აღწევს და კერძო დანართებს იღებს, სადაც token-იანი ლოგის ადგილია. თუ კონსოლი უეცრად, შეცდომის გარეშე წყდება, ეს თავისთავად დიაგნოზია და რატომ იტვირთება შენი გეიმ სერვერი განუწყვეტლივ მას ფარავს, ჩვეულებრივ მეხსიერების გრაფიკის გვერდით.

FAQ#

კონსოლი ცარიელია. ეს რას ნიშნავს?

იმას, რომ პროცესს გამოტანა არ ჰქონია, რაც ჩვეულებრივ ნიშნავს, რომ არასოდეს ჩართულა. შეამოწმე Startup ჩანართი ან გაშვების ბრძანება, შეამოწმე, რომ მთავარი ფაილი არსებობს და ნახევრად ატვირთული არ არის, და შეამოწმე დისკის სივრცე. კონტეინერი, რომელსაც შესასვლელი წერტილის შესრულება არ შეუძლია, რაიმეს ჩაწერამდე გამოდის.

რა განსხვავებაა ERROR-სა და FATAL-ს შორის?

ERROR ერთი ოპერაციაა, რომელიც ჩავარდა, სერვერმა კი გააგრძელა; FATAL სერვერის გაჩერებაა. ლოგი შეიძლება ასობით შეცდომას შეიცავდეს და მაინც ჯანსაღი სერვერი იყოს, სწორედ ამიტომ "შეცდომებს ვხედავ" თავისთავად დიაგნოზი არ არის. შეხედე, ready ხაზი მათ შემდეგ მოვიდა თუ არა.

რამდენად შორს უნდა წავიკითხო ავარიამდე?

ნაგულისხმევად ორმოცდაათი ხაზი და უფრო შორს, თუ ეს ორმოცდაათი ერთი და იმავე კასკადისაა. შენ ეძებ პირველ ხაზს, რომელიც შენ დაყენებულ რამეს ასახელებს. თუ მთელი ორმოცდაათი თამაშის საკუთარი პაკეტებია, ზემოთ გააგრძელე.

ჩემი სერვერი ყოველ რამდენიმე წამში გაფრთხილებებს ბეჭდავს, მაგრამ კარგად მუშაობს. უგულებელვყო?

წაიკითხე თითოეული ერთხელ და მერე გადაწყვიტე. განმეორებადი გაფრთხილებები ჩვეულებრივ plugin-ია, რომელიც კონფიგის მნიშვნელობაზე ან არასავალდებულო დამოკიდებულებაზე ჩივის. ისინი, რომლებიც არ უნდა უგულებელყო, ისაა, რომლებიც ამბობს, რომ პარამეტრი ნაგულისხმევზე დაბრუნდა, რადგან ეს ნიშნავს, რომ შენ დაყენებული რაღაც არ მოქმედებს.

რატომ წყვეტს კონსოლი გადახვევას, როცა არ ვუყურებ?

პანელების უმეტესობა ცოცხალ ბუფერს ზღუდავს, რომ ბრაუზერი სწრაფი დარჩეს, ბუფერი კი გადატვირთვისას ისუფთავება. დისკზე ფაილი ყველაფერს ინახავს. თუ ისტორია გჭირდება, აიღე ფაილ მენეჯერიდან ან SFTP-ით და არა გადახვევის ისტორიიდან.

შეიძლება კონსოლის გამოტანა Discord-ში მივიღო?

შეიძლება, თუმცა არა თავად პანელიდან - ეს სერვერის მხარეს plugin-ით ან mod-ით კეთდება, რომელიც webhook-ზე აგზავნის და გაფილტრულია იმ ხაზებზე, რაც რეალურად გინდა. გაგზავნე შესვლები, გასვლები, სიკვდილები და შეცდომები; ყველაფრის გაგზავნა ტექსტის იმ კედელს ხელახლა შექმნის, რომლისგანაც გაქცევა გინდოდა.