Ачааллж байна...
10.1 дүгээр хичээлд бид print()-ийн хязгааруудыг нэрлэсэн бөгөөд тэдгээрийн хоёр нь энэ Бүлгийн дараагийн хичээлүүдийн шалтгаан болно гэж хэлсэн. Эхнийх нь, "зөвхөн таамагласан зүйлээ л хардаг", debugger-ээр шийдэгдсэн. Энэ хичээл хоёр дахийг нь шийднэ: түр хэвлэлтүүдийг нэмж, устгах, мартах асуудал. Гэхдээ үүнээс илүү чухал асуулт бий. Debugger таны компьютер дээр, таны нүдний өмнө ажиллаж буй программд л тустай. Харин программ сервер дээр, шөнө дунд, хэн ч харахгүй үед ажиллаж байгаад алдаа гарвал юу болсныг хэрхэн мэдэх вэ? Үүний хариу бол logging: программын өөрийнх нь ажлын тухай тасралтгүй бүртгэл.
Энэ хичээлд бид Python-ий стандарт сангийн logging модулийг сурна. Эхлээд print яагаад logging биш болохыг тодорхой болгоно. Дараа нь logging-ийн таван түвшинг, модуль бүрт logger үүсгэх дадлыг, программын эхлэлд нэг удаа хийх энгийн тохиргоог сурна. Түвшинг өөрчилж нарийн мэдээллийг асааж, унтраах, бүртгэлийг файлд бичих, алдааг traceback-тэй нь бүртгэлд хадгалах аргуудыг өмнөх хичээлийн report_app.py дээр алхам алхмаар харна. Эцэст нь FastAPI сургалтыг үзсэн бол тэнд харсан бүртгэлийн мөрүүдтэй холбоно.
Онгоц бүрт хар хайрцаг гэдэг төхөөрөмж бий. Нислэгийн туршид тэр бүх зүйлийг тасралтгүй бүртгэдэг: өндөр, хурд, хөдөлгүүрийн байдал, нисгэгчдийн яриа. Хэвийн нислэгийн үед хэн ч түүнийг уншдаггүй. Харин ямар нэг юм буруу болбол шинжээчид хар хайрцгийг нээж, юу болсныг цаг хугацааны дарааллаар, секунд бүрээр сэргээдэг. Хар хайрцаг онгоцны жолоодлогод огт оролцдоггүй: тэр зөвхөн бүртгэдэг. Мөн тэр бүх зүйлийг ижил чухалчлалтайгаар бүртгэдэггүй: хэвийн мэдээлэл, анхааруулга, ноцтой дохио өөр өөр түвшинтэй.
logging бол таны программын хар хайрцаг. Программ ажиллах явцдаа юу хийж байгаагаа бүртгэдэг: ямар файл ачаалсан, хэдэн бараа уншсан, ямар анхааруулга гарсан, ямар алдаа гарсан. Хэвийн үед та түүнийг уншихгүй байж болно. Харин хэрэглэгч "өчигдөр баримт буруу гарсан" гэж мэдэгдвэл бүртгэл юу болсныг сэргээх боломж өгнө. Мөн мессеж бүр чухалчлалын түвшинтэй тул та яг тэр мөчид хэрэгтэй түвшний мэдээллийг л харж болно.
10.1 дүгээр хичээлд бид print(f"DEBUG {name=} {subtotal=}") гэсэн түр хэвлэлт нэмж, алдааг олсны дараа устгасан. Энэ аргыг байнгын бүртгэл болгох гэвэл хэд хэдэн асуудал гарна. print-д чухалчлалын түвшин байхгүй: нарийн мэдээлэл ба ноцтой алдаа хоёр ижил харагдаж, нарийн мэдээллийг түр унтраах боломжгүй, зөвхөн кодоос устгах. print-д цаг байхгүй: мессеж хэзээ гарсныг мэдэхгүй. print-д эх сурвалж байхгүй: мессеж аль файлаас гарсныг мэдэхгүй. print-ийн гаралт программын жинхэнэ гаралттай, жишээ нь хэрэглэгчид зориулсан баримттай, холилдоно. Мөн гаралтыг файлд бичүүлэх гэвэл бүх print-ийг өөрчлөх хэрэгтэй.
logging энэ бүх асуудлыг шийддэг. Мессеж бүр түвшинтэй бөгөөд кодоо өөрчлөлгүйгээр, нэг тохиргоогоор аль түвшнийг харуулахыг сонгоно. Цаг, эх сурвалж автоматаар нэмэгдэнэ. Бүртгэл программын жинхэнэ гаралтаас тусдаа урсгалаар явдаг. Нэг тохиргоогоор бүх бүртгэлийг файл руу чиглүүлнэ. Мөн нарийн бүртгэлийн мөрүүдийг устгах шаардлагагүй: тэдгээр нь кодонд үлдэж, хэрэгтэй үед л асаагддаг.
Энэ нь print-ийг муу гэсэн үг биш. print бол программын хэрэглэгчид зориулсан гаралтыг хэвлэх зөв хэрэгсэл: баримт, хариу, хураангуй. logging бол программын ажлын тухай хөгжүүлэгчид зориулсан мэдээлэл. Энгийн дүрэм: хэрэглэгч үүнийг харах ёстой юу? Тийм бол print. Үгүй, гэхдээ асуудал гарвал хөгжүүлэгч мэдэх хэрэгтэй юу? Тийм бол logging.
logging мессеж бүрт таван түвшний аль нэгийг өгдөг, багаас их рүү.
DEBUG бол хамгийн нарийн мэдээлэл: алдаа хайх үед л хэрэгтэй. Жишээ нь “0 дүгээр бараа: ('талх', 2000, 2)”. Хэвийн үед энэ нь хэтэрхий их.
INFO бол хэвийн ажлын тухай мэдээлэл: программ юу хийж байгааг ерөнхийд нь харуулна. Жишээ нь “items.json-оос 2 бараа ачааллаа”.
WARNING бол анхааруулга: ямар нэг юм хачин байна, гэхдээ программ үргэлжилж чадна. Жишээ нь “items.json хоосон байна, баримт хоосон гарна”.
ERROR бол алдаа: тодорхой нэг ажил бүтэлгүйтсэн. Жишээ нь "баримт гаргаж чадсангүй".
CRITICAL бол хамгийн ноцтой: программ бүхэлдээ үргэлжлэх боломжгүй. Жижиг программд ховор хэрэглэгддэг.
Түвшингийн гол утга нь шүүлтүүр: тохиргоонд “INFO-оос дээш” гэж заавал DEBUG мессежүүд харагдахгүй, бусад нь харагдана. “WARNING-оос дээш” гэж заавал зөвхөн анхааруулга ба алдаа. Тохиргоо заагаагүй үед анхдагч түвшин WARNING: энэ нь шинэ хүмүүсийн хамгийн их гайхдаг зүйлийн нэг бөгөөд удахгүй өөрийн нүдээр харна.
Алхам 1: Модульд logger үүсгэх
VS Code-д pytest-dadlaga фолдероо нээж, venv идэвхтэй эсэхийг шалгаарай. Өмнөх хичээлийн items.json зөв хэлбэртэй байх ёстой: хоёр үнэ хоёулаа хашилтгүй тоо. storage.py-г нээж, дээд хэсэгт хоёр мөр нэмнэ үү.
python
import json
import logging
logger = logging.getLogger(__name__)logging.getLogger() нь нэртэй logger буюу бүртгэгч объект буцаана. Нэр нь __name__: Python-ий тусгай хувьсагч бөгөөд модуль бүрт тэр модулийн нэрийг агуулдаг, энд “storage”. Ингэснээр энэ logger-ийн бүх мессеж “storage”-оос гарсныг бүртгэлд харуулна. Модуль бүрийн эхэнд яг энэ мөрийг бичих нь Python-ий тогтсон заншил.
Одоо load_items-д бүртгэлийн мөрүүд нэмье. Функцийг дараах байдлаар өөрчилнө үү.
python
def load_items(path):
with open(path, encoding="utf-8") as f:
items = [tuple(item) for item in json.load(f)]
for i, (name, price, qty) in enumerate(items):
logger.debug("Item %d: %r", i, (name, price, qty))
if not isinstance(price, int):
raise ValueError(f"Item {i}: price must be a number, got {price!r}")
logger.info("Loaded %d items from %s", len(items), path)
return itemsХоёр шинэ мөр. Давталтын доторх logger.debug нь бараа бүрийг DEBUG түвшинд бүртгэнэ: энэ бол 10.1 дүгээр хичээлийн DEBUG print-ийн байнгын хувилбар. Давталтын дараах logger.info нь хэдэн бараа, аль файлаас ачаалсныг INFO түвшинд бүртгэнэ.
Мессежийн бичлэгийг анхааралтай хараарай. f-string биш, “%d”, “%s”, “%r” гэсэн орлуулах тэмдэгтүүдтэй текст, араас нь утгууд тусдаа аргумент болж өгөгдсөн. “%d” бүхэл тоо, “%s” текст, “%r” 10.1 дүгээр хичээлийн !r-тэй ижил код хэлбэр. logging-ийн энэ хэлбэрийн давуу тал нь мессеж харагдахгүй түвшинд байвал текстийг огт бүтээхгүй. Хэрвээ мянган бараатай давталтад DEBUG унтраалттай бол мянган текст бүтээх ажил хийгдэхгүй. Жижиг программд f-string ч ажиллана, гэхдээ logging-д энэ хэлбэрийг ашиглах нь салбарын тогтсон заншил.
Алхам 2: Тохиргоогүйгээр ажиллуулах
Command:
python report_app.pyГаралт:
талх x2: 4,000₮
сүү x1: 3,000₮
Нийт: 7,700₮Зөвхөн баримт. INFO мессеж, “Loaded 2 items” харагдсангүй. Энэ бол дээр дурдсан гайхшрал: тохиргоогүй үед анхдагч түвшин WARNING тул INFO ба DEBUG мессежүүд шүүгдэж хаягдсан. Энэ нь санаатай зохион байгуулалт: ямар нэг модуль logging ашигладаг ч таныг хүсээгүй бол таны программ мессежээр дүүрэхгүй.
Алхам 3: Программын эхлэлд тохиргоо хийх
logging-ийг программын эхлэлд, зөвхөн нэг газар тохируулдаг. Энэ бол чухал дүрэм: storage.py, receipt.py зэрэг модулиуд зөвхөн logger үүсгэж, мессеж бичнэ. Харин хаана, ямар түвшинд, ямар хэлбэрээр харуулахыг программын эхлэл, энд report_app.py, шийднэ. report_app.py-г дараах байдлаар өөрчилнө үү.
python
import logging
from receipt import receipt_text
from storage import load_items
logging.basicConfig(
level=logging.INFO,
format="%(asctime)s %(levelname)s %(name)s: %(message)s",
)
items = load_items("items.json")
print(receipt_text(items))logging.basicConfig() нь бүртгэлийн үндсэн тохиргоог нэг дор хийдэг. “level=logging.INFO” нь “INFO-оос дээш бүх мессежийг харуул” гэсэн утгатай. “format” бол бүртгэлийн мөр бүрийн хэлбэр: “%(asctime)s” цаг, “%(levelname)s” түвшин, “%(name)s” logger-ийн нэр, “%(message)s” мессеж өөрөө. Энэ дөрвөн хэсэг бол олон программд ашиглагддаг тохиромжтой эхлэлийн хэлбэр.
Command:
python report_app.pyГаралт:
2026-10-08 20:45:12,345 INFO storage: Loaded 2 items from items.json
талх x2: 4,000₮
сүү x1: 3,000₮
Нийт: 7,700₮Эхний мөрийг хэсэгчлэн уншъя. “2026-10-08 20:45:12,345” бол цаг, таслалын дараах тоо миллисекунд. “INFO” бол түвшин. “storage” бол мессеж гарсан logger, Алхам 1-ийн __name__. Хоёр цэгийн дараа мессеж, орлуулах тэмдэгтүүд утгуудаар солигдсон: “2” ба “items.json”. Нэг мөр, бүрэн мэдээлэл: хэзээ, хэр чухал, хаанаас, юу. Таны цаг өөр байна.
DEBUG мөрүүд харагдаагүйг анзаараарай: түвшин INFO тул тэд шүүгдсэн. Үлдсэн гурван мөр бол print-ийн гаралт, хэрэглэгчид зориулсан баримт.
Алхам 4: Түвшинг өөрчлөх
Одоо бараа бүрийн нарийн мэдээллийг харахыг хүсье, жишээ нь алдаа хайж байна гэж бодъё. Кодын нэг ч мөрийг өөрчлөхгүй, зөвхөн тохиргоог. report_app.py-д “level=logging.INFO”-г “level=logging.DEBUG” болгоно уу.
Command:
python report_app.pyГаралт:
2026-10-08 20:47:03,112 DEBUG storage: Item 0: ('талх', 2000, 2)
2026-10-08 20:47:03,112 DEBUG storage: Item 1: ('сүү', 3000, 1)
2026-10-08 20:47:03,113 INFO storage: Loaded 2 items from items.json
талх x2: 4,000₮
сүү x1: 3,000₮
Нийт: 7,700₮Бараа бүрийн DEBUG мөр гарч ирлээ. Тэдгээр нь 10.1 дүгээр хичээлийн DEBUG print-тэй ижил мэдээлэл, гэхдээ цаг, эх сурвалжтай, мөн хамгийн чухал нь: тэдгээрийг устгах шаардлагагүй. Алдаа хайж дууссаны дараа түвшинг INFO руу буцаахад тэд алга болно, гэхдээ кодонд хадгалагдаж, дараагийн удаа хэрэг болох үед хүлээж байна. “level=logging.WARNING” болговол INFO мөр ч алга болж, зөвхөн баримт үлдэнэ.
Түвшинг INFO руу буцаана уу.
Алхам 5: Файлд бүртгэх
Хар хайрцгийн гол утга нь бүртгэл хадгалагддагт оршино. Terminal-ийн гаралт цонхыг хаахад алга болдог. Бүртгэлийг файлд бичье. report_app.py-ийн basicConfig-д хоёр мөр нэмнэ үү.
python
logging.basicConfig(
filename="app.log",
encoding="utf-8",
level=logging.INFO,
format="%(asctime)s %(levelname)s %(name)s: %(message)s",
)“filename” бүртгэлийг terminal-ийн оронд файл руу чиглүүлнэ. “encoding” нь 9.1 дүгээр хичээлийн дүрэм: Windows дээр кирилл үсэгтэй файлд UTF-8 заавал. Бүртгэлд бараануудын монгол нэр орох тул энэ нь чухал.
Command:
python report_app.pyГаралт:
талх x2: 4,000₮
сүү x1: 3,000₮
Нийт: 7,700₮Terminal-д зөвхөн баримт. Бүртгэл программын гаралтаас бүрэн тусгаарлагдлаа. Бүртгэл хаана байна вэ?
Command:
Get-Content app.log -Encoding utf8Гаралт:
2026-10-08 20:49:30,551 INFO storage: Loaded 2 items from items.jsonapp.log файл үүсч, INFO мөр тэнд бичигдсэн. Get-Content нь PowerShell-ийн файл унших command, “-Encoding utf8” нь кирилл үсгийг зөв харуулна. Мөн файлыг VS Code-ийн Explorer-оос нээж харж болно. report_app.py-ийг дахин ажиллуулбал шинэ мөр файлын төгсгөлд нэмэгдэнэ: basicConfig анхдагчаар файлыг дарж бичдэггүй, нэмж бичдэг. Хар хайрцаг бүх нислэгийг хадгална.
Алдааг traceback-тэй нь бүртгэх
Хар хайрцгийн хамгийн чухал үүрэг бол осол гарах үед бүх зүйлийг бүртгэх. Программ алдаа гарах үед хэрэглэгчид урт traceback харуулахын оронд ойлгомжтой мессеж харуулж, харин бүрэн мэдээллийг бүртгэлд хадгалах нь мэргэжлийн программын хэв маяг. report_app.py-ийн доод хэсгийг дараах байдлаар өөрчилнө үү.
python
logger = logging.getLogger(__name__)
try:
items = load_items("items.json")
print(receipt_text(items))
except ValueError:
logger.exception("Could not build receipt")
print("Баримт гаргаж чадсангүй. Дэлгэрэнгүйг app.log файлаас харна уу.")Script өөрийн logger-ийг үүсгэсэн, энд __name__ нь “main” болно, учир нь энэ бол шууд ажиллуулсан файл. try блок өмнөх хоёр мөрийг агуулна. ValueError гарвал logger.exception() дуудагдана: энэ нь ERROR түвшний мессеж бичээд, тэр мөчид барьж буй алдааны бүрэн traceback-ийг автоматаар хавсаргадаг. Дараа нь хэрэглэгчид энгийн мессеж хэвлэнэ.
Өмнөх хичээлийн алдааг items.json-д дахин оруулъя: талхны үнийг “2000” гэж хашилтад хийж хадгална уу.
Command:
python report_app.pyГаралт:
Баримт гаргаж чадсангүй. Дэлгэрэнгүйг app.log файлаас харна уу.Хэрэглэгч traceback-ийн оронд нэг ойлгомжтой өгүүлбэр харлаа.
Command:
Get-Content app.log -Encoding utf8Гаралт (сүүлийн мөрүүд):
2026-10-08 20:52:40,201 ERROR __main__: Could not build receipt
Traceback (most recent call last):
File "C:\Users\Bat\pytest-dadlaga\report_app.py", line 15, in <module>
items = load_items("items.json")
File "C:\Users\Bat\pytest-dadlaga\storage.py", line 18, in load_items
raise ValueError(f"Item {i}: price must be a number, got {price!r}")
ValueError: Item 0: price must be a number, got '2000'Бүртгэлд ERROR мөр, “main”-аас, араас нь 10.3 дугаар хичээлд уншиж сурсан бүрэн traceback. Хөгжүүлэгч энэ файлыг нээгээд хэзээ, юу, яг хаана болсныг өмнөх хичээлийн аргаар уншина. Хэрэглэгчийн дэлгэц цэвэр, хөгжүүлэгчийн бүртгэл бүрэн. Таны мөрийн дугаарууд өөр байж болно. items.json-ийг зөв хэлбэрт нь буцаана уу.
Анхааруулгын түвшин
WARNING-ийг хэзээ хэрэглэх вэ? Программ үргэлжилж чадах ч ямар нэг юм хүлээгдээгүй байх үед. Жишээ нь хоосон файл: алдаа биш, баримт хоосон гарна, гэхдээ магадгүй хэн нэгэн санамсаргүй файлыг хоослосон байж болно. load_items-ийн info мөрийн өмнө нэмж болно.
python
if not items:
logger.warning("No items in %s", path)Ингэвэл INFO түвшинд ч, WARNING түвшинд ч энэ мөр бүртгэлд гарч, хэн нэгэн бүртгэлийг гүйлгэж харахад анзаарагдана. Түвшинг зөв сонгох нь бүртгэлийг уншигдахуйц болгодог: бүх зүйлийг WARNING-ээр бичвэл жинхэнэ анхааруулгууд олон мөрийн дунд живнэ.
FastAPI-ийн бүртгэлтэй холбох
Хэрвээ та “FastAPI — Вэб API бүтээх” сургалтыг үзсэн бол uvicorn сервер ажиллуулахад terminal-д дараах мэт мөрүүд харагддагийг санаж байгаа байх.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
INFO: 127.0.0.1:52341 - "GET /expenses HTTP/1.1" 200 OKМөрийн эхний “INFO” одоо танд танил: энэ бол яг энэ хичээлийн logging модулийн түвшин. uvicorn дотооддоо logging ашиглаж, хүсэлт бүрийг INFO түвшинд бүртгэдэг. Хоёр дахь мөр бол сервер хүлээн авсан нэг хүсэлтийн бүртгэл: хаанаас, ямар хүсэлт, ямар хариу код. Сервер бол хэн ч харахгүй, тасралтгүй ажилладаг программын жишээ, тиймээс бүртгэл түүний цорын ганц нүд. Хэрвээ сервер дээр алдаа гарвал хөгжүүлэгч эхлээд эдгээр бүртгэлийг уншдаг. Тэр сургалтыг үзээгүй бол энэ хэсэг таныг ирээдүйд вэб сервертэй ажиллахад хүлээж буй зүйлийн урьдчилсан харагдац.
pytest ба бүртгэл
pytest бүртгэлийг ч барьдаг. Хэрвээ тест унавал pytest уналтын блокийн доор “Captured log call” гэсэн хэсэгт тэр тестийн үеэр бичигдсэн бүртгэлийн мөрүүдийг харуулна. Энэ нь унасан тестийн үеэр программ юу хийж байсныг харах тохиромжтой арга. Давсан тестийн бүртгэл харуулагдахгүй тул тайлан цэвэр хэвээр. pytest-д бүртгэлийг тестэд шалгах caplog гэдэг бэлэн fixture ч бий, гэхдээ энэ сургалтад түүнийг гүнзгийрүүлэхгүй.
Хүсвэл receipt.py-д logger нэмж үзээрэй: файлын эхэнд logger = logging.getLogger(__name__), receipt_total-ийн дотор нийт дүнг DEBUG түвшинд бүртгэх мөр. Дараа нь report_app.py-ийн түвшинг DEBUG болгоод ажиллуулж, app.log-д “storage” болон “receipt” хоёр өөр logger-ийн мөрүүд гарч байгааг харцгаа. Logger-ийн нэр мөр бүр аль модулиас гарсныг хэрхэн хэлж байгааг ажиглаарай. Мөн items.json-ийг “[]” болгож хоослоод WARNING мөр бүртгэлд гарч байгааг шалгаарай. Дууссаны дараа items.json-ийг сэргээгээрэй.
logger.info юу ч харуулахгүй байх. Хамгийн түгээмэл асуудал. Шалтгаан нь бараг үргэлж анхдагч WARNING түвшин: basicConfig дуудагдаагүй, эсвэл level заагаагүй. Программын эхлэлд logging.basicConfig(level=logging.INFO) байгаа эсэхийг шалгаарай. Хэрвээ filename заасан бол мессежүүд terminal-д биш, файлд байгаа гэдгийг санаарай.
basicConfig ажиллахгүй байх. basicConfig зөвхөн анхны удаад ажилладаг: хэрвээ logging аль хэдийн тохируулагдсан бол дараагийн дуудлагууд юу ч хийхгүй. Нэгэн нарийн урхи бий: хэрвээ аль нэг модуль basicConfig-оос өмнө logger-ийн оронд logging.info(...) гэж модулийн функцийг шууд дуудвал Python автоматаар анхдагч тохиргоо хийдэг, тэгээд таны basicConfig үл тоогдоно. Үүнээс сэргийлэхийн тулд модулиудад үргэлж logger = logging.getLogger(__name__) ба logger.info(...) хэлбэрийг ашигла. Хэрвээ заавал дахин тохируулах шаардлагатай бол basicConfig-д force=True нэмж болно.
basicConfig-ийг модулиудад дуудах. Хэрвээ storage.py, receipt.py тус бүр өөрийн basicConfig-тэй бол аль нь эхэлж ачаалагдсанаас хамаараад тохиргоо өөр өөр болж, ойлгомжгүй зан төлөв үүснэ. Дүрэм: модулиуд зөвхөн getLogger, тохиргоо зөвхөн программын эхлэлд, нэг газар.
Бүртгэлийн мессежийн аргументын тоо зөрөх. Хэрвээ мессеж “%d” ба “%s” гэсэн хоёр орлуулах тэмдэгттэй хэрнээ нэг утга өгвөл программ унахгүй, харин terminal-д дараах мэт мессеж гарна.
--- Logging error ---
Traceback (most recent call last):
...
TypeError: not enough arguments for format string“--- Logging error ---” нь "бүртгэлийн алдаа" гэсэн утгатай: logging мессежийг бүтээх гэж оролдоод чадаагүй. “not enough arguments for format string” нь "хэлбэрийн текстэд хангалттай аргумент алга" гэсэн утгатай. logging программыг зогсоолгүй алдаагаа мэдээлдэг, гэхдээ таны мессеж бүртгэлд ороогүй. Орлуулах тэмдэгт бүрт нэг утга байгаа эсэхийг тоолж шалгаарай.
Бүртгэлийн файл кирилл үсгийг буруу харуулах. Хэрвээ app.log-д бараануудын нэр утгагүй тэмдэгтээр харагдвал хоёр шалтгаан байж болно. basicConfig-д encoding="utf-8" байхгүй бол файл буруу кодчилолоор бичигдсэн: тохиргоог засна уу. Хэрвээ encoding байгаа бол асуудал уншихад байна: Get-Content-д “-Encoding utf8” нэмнэ үү, эсвэл файлыг VS Code-д нээнэ үү.
Бүртгэлийн файлыг commit хийх. app.log бол программ ажиллах бүрт өсдөг автомат файл бөгөөд хувийн мэдээлэл агуулж болно: 2.4 дүгээр хичээлийн дүрмээр тэр цомогт орох ёсгүй. Зарлагын бүртгэлийн .gitignore-д 4.2 дугаар хичээлд “.log” мөр нэмсэн нь яг энэ зорилготой. Шинэ төсөлд logging нэмэх бүрт .gitignore-д “.log” байгаа эсэхийг шалгаарай.
logging бол программын хар хайрцаг: ажлынхаа тухай тасралтгүй бүртгэл бөгөөд хэн ч харахгүй үед юу болсныг сэргээх боломж олгодог. print нь хэрэглэгчид зориулсан гаралтад, logging нь хөгжүүлэгчид зориулсан ажлын мэдээлэлд. logging-д таван түвшин бий: DEBUG нарийн мэдээлэл, INFO хэвийн ажил, WARNING анхааруулга, ERROR тодорхой ажлын бүтэлгүйтэл, CRITICAL программын бүтэлгүйтэл. Анхдагч түвшин WARNING тул тохиргоогүйгээр INFO ба DEBUG харагдахгүй. Модуль бүрт logger = logging.getLogger(__name__) үүсгэж, logger.info("... %s", утга) хэлбэрээр бичнэ. Тохиргоог зөвхөн программын эхлэлд нэг удаа logging.basicConfig(level=..., format=..., filename=..., encoding="utf-8")-ээр хийнэ. Түвшинг өөрчлөхөд кодыг хөндөлгүйгээр DEBUG мөрүүд асаж, унтардаг тул тэдгээрийг устгах шаардлагагүй. logger.exception() except блокт ERROR мессеж ба бүрэн traceback-ийг бүртгэдэг бөгөөд хэрэглэгчид энгийн мессеж, хөгжүүлэгчид бүрэн мэдээлэл өгөх хэв маягийг боломжтой болгодог. uvicorn-ийн “INFO:” мөрүүд ижил модулиар бүтээгддэг. Бүртгэлийн файлыг .gitignore-д “*.log”-оор нууна.
Ингээд Бүлэг 10 дууслаа. Та одоо алдааг аргачлалтайгаар хайж, debugger-ээр программыг удаашруулж, гүн traceback-ийг уншиж, программд хар хайрцаг суулгаж чадна. Дараагийн Бүлэгт алдаа гарахаас нь өмнө урьдчилан сэргийлэх хэрэгслүүд рүү шилжинэ: кодын чанар. Бүлэг 11-ийн эхний хичээлд black-ийг сурна: кодын хэлбэр загварыг автоматаар нэг стандартад оруулж, хэлбэрийн тухай бүх маргааныг дуусгадаг хэрэгсэл.
Бүртгэлтэй болсноор энэ сургалтын бүх хичээлд хандах эрх авна.