სერვერის ლოგები, რომლებიც ღირს შენახვად: რა და რამდენ ხანს

შეინახე ყველაფერი warning დონიდან და ზემოთ, ყოველი გაშვების banner, ყოველი crash report სრულად და ყოველი ადმინისტრაციული მოქმედება. წაშალე თითო მოთხოვნის access ლოგები ერთი-ორი კვირის შემდეგ, წაშალე debug გამოტანა იმავე დღეს, როცა ბაგი დაიხურება, და შეწყვიტე ყველაფრის წერა, რაც ყოველ tick-ზე იბეჭდება. სულ ეს არის პოლიტიკა და ოთხ ხაზში ეტევა, რადგან რთული ის არ არის, რომ გადაწყვიტო, რა შეინახო - რთულია, გადაწყვეტილება გადარჩეს სერვერთან შეხვედრას, რომელსაც დისკის ლიმიტი აქვს, ლოგ სერვერი არ აქვს და ჩვევა აქვს დღეში 500 MB ცარიელი ლაპარაკი აწარმოოს, რომელსაც არავინ წაიკითხავს.

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

რისთვის არის ლოგები სინამდვილეში#

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

• რა მუშაობდა? რომელი ვერსია, რომელი Java, რომელი მოდები და plugin-ები რომელი ვერსიებით, რომელი კონფიგურაციის ფაილი წაიკითხა, რომელი პორტები დაიკავა.
• რა შეიცვალა და როდის? plugin განახლდა, კონფიგურაცია შეიცვალა, ვიღაცამ სხვა flag-ებით გადატვირთა.
• რა თქვა პროცესმა სიკვდილამდე? ბოლო რამდენიმე ასეული ხაზი და stack trace, თანმიმდევრობით, დროის ნიშნულებით.
• ვინ რა გააკეთა? ban-ები, kick-ები, უფლებების მინიჭება, ნივთების spawn, სამყაროს რედაქტირება, deploy-ები.

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

შეინახე ეს ოთხი რამ#

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

გაშვების გამოტანა, სრულად. ეს ნებისმიერ ლოგ ფაილში ყველაზე ნაკლებად დაფასებული ბლოკია. ის ინახავს სერვერის პროგრამის ზუსტ ვერსიას, Java-ს ან runtime-ის ვერსიას, მოდების ან plugin-ების სრულ სიას, რომლებიც ნამდვილად ჩაიტვირთა, მათი ვერსიების ნომრებით, სამყაროს ან ბაზას, რომელიც გაიხსნა, და პორტებს, რომლებიც დაიკავა. როცა ვინმე გეუბნება, რომ არაფერი შეცვლილა, ადრინდელი და შემდგომი გაშვების banner არის გზა, ოცდაათ წამში დაამტკიცო საპირისპირო. Minecraft სერვერზე ეს არის ბლოკი, რომელიც იწყება Starting minecraft server version-ით და მთავრდება Done (12.481s)! For help, type "help"-ით. მოდიან სერვერზე ეს არის მოდების სია. შეინახე ისიც კი, როცა დანარჩენ დღეს გადააგდებ.

Crash report-ები, სრულად, მათაც, რომლებიც გგონია, რომ გესმის. stack trace, რომელიც "საინტერესო ნაწილამდეა" შეკვეცილი, არის stack trace, რომელსაც საინტერესო ნაწილი ამოაკლდა. Minecraft მათ წერს crash-reports/crash-<date>-server.txt-ში და კონსოლშიც. JVM, რომელიც native დონეზე კვდება, სამუშაო დირექტორიაში წერს hs_err_pid<pid>.log-ს, რომელიც გეუბნება, რომ ეს იყო ბირთვის out-of-memory killer და არა შენი კოდი. ეს ფაილები პატარაა. არ არსებობს ვარიანტი, რომელშიც მათი წაშლა სწორი გადაწყვეტილება იქნებოდა.

ადმინისტრაციული მოქმედებები. ban-ები, kick-ები, უფლებების ცვლილებები, ფასების რედაქტირება, ნივთების გაცემა, კონფიგურაციის deploy-ები. ამ საკითხებზე კამათობენ, და კამათობენ კვირების შემდეგ, ვიღაც screenshot-ით ხელში. შეინახე ისინი ყველაფერზე დიდხანს და იქ, სადაც გამოძიების ქვეშ მყოფ ადამიანს მათი რედაქტირება არ შეუძლია.

წაშალე ეს და ზოგიერთის წერაც შეწყვიტე#

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

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

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

Chat ლოგებსა და IP მისამართებს ცალკე, არასასიამოვნო აბზაცი ეკუთვნის. ორივე პერსონალური მონაცემია მსოფლიოს უმეტეს ნაწილში, ორივე ნამდვილად სასარგებლოა მოდერაციისთვის, და რომელიმეს სამუდამოდ შენახვა მოდერაციის ხელსაწყოს ვალად აქცევს, რომელსაც იმ ადამიანების სახელით ინახავ, ვისაც ეს არ უთხოვია. ოცდაათიდან ოთხმოც დღემდე chat საკმარისია ნებისმიერი კამათის მოსაგვარებლად, რომელიც ჯერ კიდევ ღირს მოგვარებად. vanilla Minecraft სერვერის ახალ ვერსიებს სწორედ ამისთვის დაემატა log-ips გადამრთველი server.properties-ში; შეამოწმე, გაქვს თუ არა ის შენს ვერსიაში, სანამ ივარაუდებ, რომ მისამართები იწერება.

რამდენ ხანს შეინახო რა#

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

ცხრილის უკან მდგარი წესი: შეინახე ლოგი იმდენ ხანს, რამდენ ხანსაც ვინმეს შეიძლება გონივრულად მოვიდეს შენთან კითხვით ამ პერიოდზე. crash-ებისთვის ეს სამუდამოდაა, რადგან ერთი და იგივე crash ბრუნდება. access ლოგებისთვის ეს დაახლოებით ბოლო ინვოისის ხანგრძლივობაა.

Rotation, შეკუმშვა და დისკი, რომელიც გაქვს#

ერთხელ გაითვალე, რადგან ეს ინტუიციური არ არის. ტიპური ლოგის ხაზი დაახლოებით 120 ბაიტია. სერვერი, რომელიც წამში 50 ხაზს წერს - საკმაოდ ჩვეულებრივი დატვირთული Minecraft ან ვებ სერვერი - აწარმოებს დაახლოებით 6 KB/s-ს, ანუ დაახლოებით 500 MB დღეში, ან 15 GB თვეში. 15 GB გეგმაზე ეს ოცდაათ დღეში მთელი დისკია და ჩავარდნა ლოგირების პრობლემად არ გამოჩნდება. ის გამოჩნდება როგორც სამყაროს save, რომელიც ვერ სრულდება, ბაზაში ჩაწერა, რომელიც შეცდომას იძლევა, ან backup, რომელიც ვერ სრულდება.

ტექსტური ლოგები დაახლოებით ათჯერ იკუმშება, ამიტომ rotation-ისას შეკუმშვა თითქმის უფასო 90 პროცენტია. Linux-ზე სტანდარტული ხელსაწყო logrotate-ია და აპლიკაციისთვის, რომელიც საკუთარ ფაილებს წერს, კონფიგურაცია ასე გამოიყურება:

/home/app/logs/*.log {    daily    rotate 14    compress    delaycompress    missingok    notifempty    copytruncate}

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

თუ სერვისი systemd-ის ქვეშ მუშაობს და stdout-ში წერს, journal უკვე აკეთებს rotation-ს და დისკზე ფაილი შენი სამართავი არ არის. შეზღუდე ის /etc/systemd/journald.conf-ში:

Storage=persistentSystemMaxUse=500MSystemMaxFileSize=50MMaxRetentionSec=1month

გეიმ სერვერები თითოეული ოდნავ სხვანაირად იქცევა და ერთი ქცევა ხალხს განმეორებით ატყუებს. Minecraft და მისი fork-ები rotation-ს ტაიმერით კი არა, გაშვებისას აკეთებენ: მიმდინარე ფაილია logs/latest.log, წინა კი შეიკუმშება logs/2026-09-20-1.log.gz-ად, როცა სერვერი შემდეგ ჯერზე დაიწყებს. სერვერს, რომელიც ექვსი კვირა გადატვირთვის გარეშე მუშაობს, აქვს ერთი latest.log, რომელიც მთელი ამ ხნის განმავლობაში იზრდებოდა და გადატვირთვამდე მას არაფერი დაატრიალებს. ეს კიდევ ერთი პატარა არგუმენტია ყოველკვირეული გადატვირთვის სასარგებლოდ, რომელიც აღწერილია პოსტში გადატვირთვის განრიგები, რომლებიც ეხმარება.

Project Zomboid საპირისპირო გზით მიდის და ყოველ გაშვებაზე Logs/-ში წერს თარიღიანი ფაილების ახალ ნაკრებს, სახეობის მიხედვით დაყოფილს: _DebugLog-server.txt, _chat.txt, _admin.txt, _user.txt, _pvp.txt, _map.txt, _item.txt. ეს შესანიშნავია რაღაცების საპოვნელად და საშინელი დისკისთვის, რადგან მას არაფერი ასუფთავებს. მიაბი მას დაგეგმილი ამოცანა, თორემ საქაღალდე სამყაროს გადაიტანს.

ხმაურის შემცირება წყაროსთან#

Rotation სიმპტომს მართავს. ნამდვილი მოგება ის არის, რომ ხაზი საერთოდ არ დაიწეროს.

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

map $status $loggable {    ~^[23]  0;    default 1;}access_log /var/log/nginx/access.log combined if=$loggable;error_log  /var/log/nginx/error.log warn;

ეს ინახავს ყველა 4xx-სა და 5xx-ს და გადაყრის დანარჩენს, რაც დატვირთულ საიტზე მოცულობის 95 პროცენტია. დააყენე error_log warn-ზე და დატოვე ასე; nginx-ზე debug მოითხოვს debug მოდულით აწყობას და დისკს ამ პოსტის ნებისმიერ სხვა რამეზე უფრო სწრაფად გაავსებს.

Node აპლიკაციაში გამოიყენე დონეებიანი logger, მაგალითად pino, console.log-ის ნაცვლად, დონე გარემოს ცვლადიდან მართე და request body-ები ნაგულისხმევად არასოდეს ჩაწერო. Python-ში სტანდარტული ბიბლიოთეკა საკმარისია და ყველაზე ეფექტური ხაზი არის ბიბლიოთეკის გაჩუმება, რომელსაც ჰგონია, რომ ეს შენ გაინტერესებს:

import logginglogging.basicConfig(level=logging.INFO)logging.getLogger("urllib3").setLevel(logging.WARNING)logging.getLogger("botocore").setLevel(logging.WARNING)

Java გეიმ სერვერზე logger არის Log4j2, დონეს კი აყენებს კონფიგურაციის ფაილი, რომელზეც JVM -Dlog4j.configurationFile=-ით იყო მიმართული. მისი შეცვლა შესაძლებელია, მაგრამ დამაბნეველია, და პრაქტიკაში Minecraft სერვერზე ხმაური მოდის ერთი-ორი plugin-იდან, რომელთა საკუთარ კონფიგურაციაში debug: true წერია. ჯერ ისინი იპოვე. ნამდვილად სანერვიულო ხაზი, Can't keep up! Is the server overloaded? Running 2154ms or 43 ticks behind, ხმაური არ არის, რამდენიც არ უნდა ჩნდებოდეს; ეს სერვერი გეუბნება, რომ სიმულაციის ორი წამი გამოტოვა.

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

საჭირო ხაზის პოვნა#

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

$ grep -n -C 3 -iE "error|exception|warn" logs/latest.log | less$ zgrep -h "Exception" logs/*.log.gz | sort | uniq -c | sort -rn | head -20$ journalctl -u myapp -p warning --since "2026-09-20 18:00" --until "2026-09-20 19:30"

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

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

ადმინის მოქმედებები და ლოგები, რომლებზეც კამათობენ#

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

უმეტეს თამაშს დანიშნულებისამებრ შექმნილი პასუხი აქვს. Project Zomboid წერს _admin.txt-სა და _pvp.txt-ს, როგორც ზემოთ აღვწერე. Minecraft-ზე CoreProtect წერს ბლოკებისა და კონტეინერების ცვლილებებს საკუთარ ბაზაში და კვირების შემდეგაც პასუხობს /co lookup და /co rollback კითხვებს, ხოლო LuckPerms ინახავს უფლებების ყოველი ცვლილების საკუთარ action ლოგს, რომელიც /lp log recent-ით იძებნება. txAdmin-ით მომუშავე FiveM სერვერებს აქვთ ადმინის ბრძანებების action ლოგი, რომელიც სახელიან ანგარიშებზეა მიბმული და არა იმაზე, ვინც კონსოლთან აღმოჩნდა.

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

ლოგების მანქანიდან გატანა#

ლოგი, რომელიც მხოლოდ დამწვარ სერვერზე არსებობს, მტკიცებულება კი არა, იმედია. ამას ლოგირების სტეკი არ სჭირდება. ძალისხმევის მიხედვით:

1. ხელით ჩამოტვირთე საინტერესოები ნებისმიერი ინციდენტის შემდეგ, სანამ რამე დატრიალდება. ხუთი წუთი, დაყენება არ არის და crash report-ის შემთხვევას სრულად ფარავს.
2. დაგეგმილი ამოცანა, რომელიც გუშინდელ ლოგებს ჩააკუმშავს და არქივს იქ დადებს, საიდანაც წამოიღებ. cron გამოსახულება, კონსოლის ბრძანება და ფაილი, რომელსაც SFTP-ით მოიტან - გეგმიური ამოცანები, რომლებიც ღირს შეიცავს ნიმუშებს.
3. Webhook მხოლოდ warning-ებისთვის. არა ლოგის ნაკადი - ფილტრი, რომელიც შეცდომებს არხში აგზავნის. დისციპლინა ისაა, რომ ის საკმარისად ჩუმი უნდა დარჩეს, რომ ხალხმა ისევ წაიკითხოს. მონიტორინგი, რომელიც რამეს გეუბნება მთლიანად ამ გაცვლაზეა.
4. ბაზა ადმინისა და მოდერაციის მოქმედებებისთვის, რაც ერთადერთი კატეგორიაა, რომელიც სტრუქტურას იმსახურებს. თამაშის ბაზის slot ან პატარა მართული instance სრულიად საკმარისია.

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

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

FAQ#

რამდენ ხანს უნდა შევინახო სერვერის ლოგები?

Crash report-ები განუსაზღვრელი ვადით, warning-ები და შეცდომები 30-დან 90 დღემდე, ადმინის მოქმედებები ექვსიდან თორმეტ თვემდე, access ლოგები ერთიდან ორ კვირამდე, chat დაახლოებით ოცდაათი დღე. თუ მხოლოდ ერთი რიცხვი დაგამახსოვრდება, დაიმახსოვრე თოთხმეტი დღე დიდი ფაილებისთვის და სამუდამოდ პატარებისთვის.

ანელებს თუ არა ლოგირება სერვერს?

ჩვეულებრივი ლოგირება - არა. Debug ლოგირება დატვირთულ სერვერზე - დიახ, გაზომვადად, რადგან ჩაწერა ხშირად იმ thread-ზე ხდება, რომელიც საქმეს აკეთებს, და რადგან ის იმავე დისკს ეჯიბრება, რასაც შენი save-ები. ლოგის ხაზი, რომელიც ყოველ tick-ზე იბეჭდება, პერფორმანსის ბაგია, სადაც არ უნდა იწერებოდეს.

latest.log არის ერთადერთი ფაილი, რომელიც მჭირდება?

არა. latest.log მხოლოდ მიმდინარე გაშვებას ფარავს, Minecraft სერვერზე კი ის შემდეგ გაშვებამდე არ ტრიალდება, ამიტომ შეიძლება ერთდროულად უზარმაზარი და არასრული იყოს. მის გვერდით მყოფი დატრიალებული .log.gz ფაილები წინა გაშვებებს ინახავს, ხოლო crash-reports/ ინახავს იმას, რაც ზედმეტად ცუდი იყო სათანადოდ ჩასაწერად.

შემიძლია უბრალოდ ყველაფერი სამუდამოდ შევინახო?

crash report-ები და გაშვების banner-ები სამუდამოდ შეგიძლია შეინახო, რადგან ისინი პაწაწინაა. ნედლი access ლოგების, chat-ისა და IP მისამართების სამუდამოდ შენახვა რეალურ დისკს ხარჯავს, ძებნას ანელებს და ნიშნავს, რომ სხვა ადამიანების პერსონალურ მონაცემებს ინახავ გეგმის გარეშე. შეინახე პატარა რამეები და დაატრიალე დიდები.

რა უნდა დავურთო მხარდაჭერის ბილეთს?

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

ჩემი დისკი ღამით გაივსო. საიდან დავიწყო?

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