Анхаарна уу. орчуулга.: Энэ материалын зохиогч нь API хөгжүүлэлт, ялангуяа бичил үйлчилгээний туршилтаар мэргэшсэн imgix-ийн инженер Синди Сридхаран юм. Энэ материалд тэрээр тархсан мөшгих талбарт тулгарч буй асуудлуудын талаархи нарийвчилсан алсын хараагаа хуваалцаж байгаа бөгөөд түүний бодлоор тулгамдсан асуудлыг шийдвэрлэх үнэхээр үр дүнтэй хэрэгсэл дутагдаж байна.
[Зургийг авсан тархсан мөрдөх тухай.]
Үүнийг итгэж байна хэрэгжүүлэхэд хүндрэлтэй, түүний өгөөж . Хүсэлт бүрд тохирох толгойг дамжуулахын тулд системийн бүрэлдэхүүн хэсэг бүрийг тохируулахад зарцуулсан хөдөлмөрийг дурдаж, мөрдөх нь яагаад асуудалтай байдаг олон шалтгаан байдаг. Хэдийгээр энэ асуудал байгаа ч үүнийг даван туулах боломжгүй юм. Дашрамд дурдахад, хөгжүүлэгчид яагаад мөшгих ажилд үнэхээр дургүй байдаг (энэ нь аль хэдийн ажиллаж байсан ч) тайлбарлахгүй.
Тархсан мөшгихтэй холбоотой гол бэрхшээл нь өгөгдөл цуглуулах, үр дүнг түгээх, танилцуулах форматыг стандартчилах, хэзээ, хаана, хэрхэн түүвэрлэхийг тодорхойлох явдал биш юм. Би төсөөлөхийг оролдоогүй байна өчүүхэн Эдгээр "ойлгомжтой асуудлууд" нь үнэн хэрэгтээ техникийн нэлээд чухал бөгөөд (хэрэв бид үнэхээр Нээлттэй эх сурвалжийг авч үзэх юм бол) ) эдгээр асуудлыг шийдсэн гэж үзэхийн тулд даван туулах шаардлагатай улс төрийн сорилтууд.
Гэсэн хэдий ч, хэрэв бид эдгээр бүх асуудал шийдэгдсэн гэж төсөөлвөл, юу ч мэдэгдэхүйц өөрчлөгдөхгүй байх магадлал өндөр байна. эцсийн хэрэглэгчийн туршлага. Мөшгих нь дибаг хийх хамгийн түгээмэл тохиолдлуудад хэрэглэгдэж дууссаны дараа ч ашиггүй хэвээр байж магадгүй.
Ийм өөр ул мөр
Тархсан мөрдөх нь хэд хэдэн ялгаатай бүрэлдэхүүн хэсгүүдийг агуулдаг:
- програмууд болон дунд програмыг хяналтын хэрэгслээр тоноглох;
- тархсан контекст дамжуулалт;
- ул мөр цуглуулах;
- ул мөр хадгалах;
- тэдгээрийн олборлолт, дүрслэл.
Тархсан мөшгих тухай олон яриа үүнийг нэг төрлийн үйл ажиллагаа гэж үзэх хандлагатай байдаг бөгөөд цорын ганц зорилго нь системийг бүрэн оношлоход туслах явдал юм. Энэ нь тархсан мөшгих тухай санаанууд түүхэнд хэрхэн бий болсонтой ихээхэн холбоотой юм. IN , Zipkin эх сурвалжийг нээх үед хийсэн, гэж дурдсан Энэ нь [Зипкин] Twitter-ийг илүү хурдан болгодог. Мөшгих анхны арилжааны саналуудыг мөн адил сурталчилсан .
Анхаарна уу. орчуулга.: Цаашдын текстийг ойлгоход хялбар болгохын тулд хоёр үндсэн нэр томъёог дараах байдлаар тодорхойлно :
- Span - тархсан мөрдөх үндсэн элемент. Энэ нь нэр, эхлэх, дуусах цаг, шошго, бүртгэл, контекст бүхий тодорхой ажлын урсгалын тайлбар (жишээлбэл, мэдээллийн сангийн асуулга) юм.
- Өргөдлүүд нь ихэвчлэн бусад зайтай холбоосуудыг агуулж байдаг бөгөөд энэ нь олон зайг нэгтгэх боломжийг олгодог Ул мөр үлдээ - тархсан системээр дамжуулж буй хүсэлтийн амьдралыг дүрслэн харуулах.
Мөр нь үйлдвэрлэлийн туршилт, гамшгийн үед сэргээн босгох туршилт, алдааны сорилт гэх мэт ажлуудад туслах гайхалтай үнэ цэнэтэй өгөгдлийг агуулдаг. Үнэн хэрэгтээ зарим компаниуд ижил төстэй зорилгоор мөшгих аргыг аль хэдийн ашигладаг. -ээс эхэлье Хадгалах систем рүү зайг зөөхөөс гадна бусад хэрэглээтэй:
- Жишээлбэл, Uber туршилтын урсгал болон үйлдвэрлэлийн урсгалыг ялгахын тулд үр дүнг хянах.
- Facebook-ийн гамшгаас хамгаалах байнгын туршилтын үед чухал замд дүн шинжилгээ хийх, замын хөдөлгөөнд шилжихэд зориулсан өгөгдлийг хянах.
- Мөн нийгмийн сүлжээ Хөгжүүлэгчид үр дүнгийн мөрөөр дурын асуулга явуулах боломжийг олгодог Jupyter дэвтэр.
- Дагагчид (Удам угсаагаар хөтлөгдсөн алдааны тарилга) алдааны тарилга бүхий туршилтын ул мөрийг тараасан.
Дээр дурдсан сонголтуудын аль нь ч тухайн хувилбарт бүрэн хамаарахгүй дибаг хийх, энэ үеэр инженер ул мөрийг хараад асуудлыг шийдэхийг оролддог.
Ирэх үед хараахан дибаг хийх скриптэд хүрэхэд үндсэн интерфейс нь диаграмм хэвээр байна traceview (хэдийгээр зарим нь үүнийг бас нэрлэдэг "Гант диаграм" буюу "хүрхрээний диаграм"). Доод traceview я ул мөрийг бүрдүүлдэг бүх хүрээ болон дагалдах мета өгөгдөл. Нээлттэй эх сурвалжийн мөрдөх систем бүр, түүнчлэн арилжааны мөрдөх шийдэл бүр нь a traceview ул мөрийг дүрслэн харуулах, нарийвчилсан, шүүх хэрэглэгчийн интерфэйс.
Миний харж байсан бүх мөрдөх системтэй холбоотой асуудал бол үүнээс үүдэн гарсан явдал юм дүрслэл (traceview) ул мөр үүсгэх үйл явцын онцлогийг бараг бүрэн тусгасан байдаг. Дулааны зураг, үйлчилгээний топологи, хоцрогдлын гистограм зэрэг өөр дүрслэлийг санал болгож байсан ч эцсийн дүндээ тэдгээр нь traceview.
Өнгөрсөн хугацаанд би UI/UX мөшгих дэх ихэнх "шинэлэг зүйл" нь үүгээр хязгаарлагдаж байх шиг байна нэмэлт мета өгөгдлүүдийг мөшгиж, тэдгээрт өндөр ач холбогдолтой мэдээлэлд хөрөнгө оруулах (өндөр кардинал) эсвэл тодорхой зайд өрөмдөх эсвэл асуулга явуулах боломжийг олгох хоорондын ба доторхи ул мөр... Үүнд traceview дүрслэх үндсэн хэрэгсэл хэвээр байна. Энэ байдал үргэлжилсээр л байвал тархсан мөшгих нь (хамгийн сайндаа) хэмжигдэхүүн, лог, стекийн ул мөрийн дараа дибаг хийх хэрэгсэл болгон 4-р байрыг эзэлнэ, хамгийн муудаа энэ нь мөнгө, цагийг дэмий үрэх болно.
Traceview-тэй холбоотой асуудал
Зорилго traceview - нэг хүсэлтийн холбогдох тархсан системийн бүх бүрэлдэхүүн хэсгүүдийн хөдөлгөөний талаархи бүрэн дүр зургийг гаргах. Зарим илүү дэвшилтэт мөрдөх систем нь танд тус тусад нь өрөмдөж, цаг хугацааны явцад эвдрэлийг харах боломжийг олгодог дотор байна нэг процесс (хэрэв зай нь функциональ хил хязгаартай байх үед).
Микро үйлчилгээний архитектурын үндсэн зарчим нь байгууллагын бүтэц нь компанийн хэрэгцээ шаардлагад нийцүүлэн өсдөг гэсэн санаа юм. Бичил үйлчилгээг дэмжигчид бизнесийн янз бүрийн даалгавруудыг хувь хүний үйлчилгээнд хуваарилах нь жижиг, бие даасан хөгжлийн багуудад ийм үйлчилгээний амьдралын мөчлөгийг бүхэлд нь хянах боломжийг олгодог бөгөөд эдгээр үйлчилгээг бие даан бүтээх, турших, ашиглах боломжийг олгодог гэж үздэг. Гэсэн хэдий ч энэ хуваарилалтын сул тал нь үйлчилгээ тус бүр бусадтай хэрхэн харьцдаг тухай мэдээлэл алдагдах явдал юм. Ийм нөхцөлд тархсан мөшгих нь зайлшгүй шаардлагатай хэрэгсэл гэж мэдэгддэг дибаг хийх үйлчилгээ хоорондын нарийн төвөгтэй харилцан үйлчлэл.
Хэрэв та үнэхээр , тэгвэл нэг ч хүн толгойдоо хадгалж чадахгүй полную зураг. Үнэн хэрэгтээ, энэ нь бүр боломжтой гэсэн таамаглал дээр үндэслэн хэрэгсэл боловсруулах нь эсрэг загвар (үр дүнгүй, бүтээмжгүй арга) юм. Хамгийн тохиромжтой нь дибаг хийхэд туслах хэрэгсэл шаардлагатай хайлтын талбараа нарийсга, ингэснээр инженерүүд хэлэлцэж буй асуудлын хувилбарт хамаарах хэмжигдэхүүнүүдийн дэд бүлэгт (үйлчилгээ/хэрэглэгч/хостууд гэх мэт) анхаарлаа төвлөрүүлж чадна. Гэмтлийн шалтгааныг тодорхойлохдоо инженерүүд энэ үеэр юу болсныг ойлгох шаардлагагүй бүх үйлчилгээ нэг дор, учир нь ийм шаардлага нь микро үйлчилгээний архитектурын санаатай зөрчилдөх болно.
Гэсэн хэдий ч traceview байна тухайлбал Энэ. Тиймээ, зарим мөрийн систем нь мөр дэх зайны тоо маш их байх тул тэдгээрийг нэг дүрслэлд харуулах боломжгүй үед шахсан трассыг санал болгодог. Гэсэн хэдий ч ийм задарсан дүрслэлд ч гэсэн их хэмжээний мэдээлэл агуулагдаж байгаа тул инженерүүд хэвээр байна албадан Асуудлын эх үүсвэр болох үйлчилгээний багц болгон сонголтыг гараар нарийсгаж, үүнийг "шүүрнэ". Харамсалтай нь энэ салбарт машинууд хүнээс хамаагүй хурдан, алдаа гаргах нь бага, үр дүн нь илүү давтагдах боломжтой байдаг.
Traceview нь буруу гэж бодож байгаа бас нэг шалтгаан нь таамаглалд тулгуурласан дибаг хийхэд тохиромжгүй байдагтай холбоотой. Үүний гол утга нь дибаг хийх явдал юм давталттай Таамаглалаас эхэлж, дараа нь янз бүрийн векторын дагуу системээс олж авсан янз бүрийн ажиглалт, баримтуудыг баталгаажуулах, дүгнэлт/дүгнэлт хийх, таамаглалын үнэнийг цаашид үнэлэх үйл явц.
Боломж хурдан бөгөөд хямд таамаглалыг шалгах, үүний дагуу сэтгэцийн загварыг сайжруулах явдал юм тулгын чулуу дибаг хийх Аливаа дибаг хийх хэрэгсэл байх ёстой интерактив Хайлтын орон зайг нарийсгах, эсвэл хуурамч хар тугалгатай тохиолдолд хэрэглэгч буцаж очоод системийн өөр хэсэгт анхаарлаа төвлөрүүлэх боломжийг олгоно. Төгс хэрэгсэл нь үүнийг хийх болно идэвхтэй, нэн даруй хэрэглэгчийн анхаарлыг болзошгүй асуудлын талбарт хандуулах.
Харамсалтай нь traceview интерактив интерфейстэй хэрэгсэл гэж нэрлэж болохгүй. Үүнийг ашиглахдаа хамгийн сайн найдаж болох зүйл бол хоцрогдол ихэссэн эх сурвалжийг олж, үүнтэй холбоотой бүх боломжит шошго, бүртгэлийг үзэх явдал юм. Энэ нь инженерийг тодорхойлоход тус болохгүй хэв маяг саатлын хуваарилалтын онцлог гэх мэт замын хөдөлгөөнд, эсвэл янз бүрийн хэмжилтийн хоорондын хамаарлыг илрүүлэх. Эдгээр асуудлуудын заримыг даван туулахад тусалж магадгүй юм. Үнэхээр, хэвийн бус зайг тодорхойлох, хэвийн бус зан үйлтэй холбоотой байж болох шошгын дэд багцыг тодорхойлохын тулд машин сургалтыг ашиглан амжилттай дүн шинжилгээ хийх. Гэсэн хэдий ч би traceview эсвэл DAG (чиглүүлсэн циклийн график) -аас эрс ялгаатай зайд ашигласан машин сургалтын эсвэл өгөгдөл олборлолтын үр дүнгийн гайхалтай дүрслэлийг хараахан хараагүй байна.
Хэмжээ хэт бага байна
Traceview-ийн гол асуудал бол үүнд оршино зайтай хоцрогдлын шинжилгээ болон үндсэн шалтгааны шинжилгээнд хэт бага түвшний командууд юм. Энэ нь ажиллахад илүү тохиромжтой backtrace гэх мэт өндөр түвшний хэрэгслүүд байдгийг мэдэхийн тулд үл хамаарах зүйлийг шийдвэрлэхийн тулд процессорын бие даасан командуудыг задлан шинжлэхтэй адил юм.
Түүгээр ч барахгүй би дараахь зүйлийг батлах эрх чөлөөг авах болно: хамгийн тохиромжтой нь бидэнд хэрэггүй бүрэн зураг орчин үеийн мөрдөх хэрэглүүрээр илэрхийлэгддэг хүсэлтийн амьдралын мөчлөгийн үед үүссэн. Үүний оронд юуны талаарх мэдээллийг агуулсан дээд түвшний хийсвэрлэлийн зарим хэлбэр шаардлагатай буруу явсан (буцахтай төстэй), зарим контекстийн хамт. Би ул мөрийг бүхэлд нь үзэхийн оронд харахыг илүүд үздэг хэсэг нь, ямар нэгэн сонирхолтой эсвэл ер бусын зүйл тохиолдоход. Одоогийн байдлаар хайлтыг гараар хийж байна: инженер нь ул мөрийг хүлээн авч, сонирхолтой зүйлийг хайж олохын тулд бие даасан дүн шинжилгээ хийдэг. Сэжигтэй үйл ажиллагааг илрүүлэх найдлагатайгаар тус тусын мөрийг ширтэх хүмүүсийн арга нь огтхон ч масштабтай байдаггүй (ялангуяа span ID, RPC аргын нэр, span үргэлжлэх хугацаа гэх мэт өөр өөр хүрээнд кодлогдсон бүх мета өгөгдлүүдийг ойлгох шаардлагатай үед). 'a, лог, шошго гэх мэт).
Traceview-н өөр хувилбарууд
Системийн хоорондоо холбоотой хэсгүүдэд болж буй үйл явдлын талаарх өчүүхэн ойлголтыг өгөх байдлаар дүрслэн харуулах боломжтой бол ул мөрийн үр дүн хамгийн ашигтай байдаг. Энэ болтол дибаг хийх процесс үндсэндээ хэвээр байна идэвхгүй Хэрэглэгчийн зөв хамаарлыг анзаарах, системийн зөв хэсгүүдийг шалгах, эсвэл эвлүүлдэг тоглоомын хэсгүүдийг нийлүүлэх чадвараас хамаарна. хэрэгсэл, хэрэглэгчдэд эдгээр таамаглалыг боловсруулахад тусалдаг.
Би визуал дизайнер эсвэл UX мэргэжилтэн биш, гэхдээ дараагийн хэсэгт эдгээр дүрслэл ямар харагдах талаар цөөн хэдэн санааг хуваалцахыг хүсч байна.
Тодорхой үйлчилгээнд анхаарлаа хандуулаарай
Салбар санаагаа нэгтгэж байгаа энэ үед , тус бүр багууд өөрсдийн үйлчилгээгээ эдгээр зорилгод нийцүүлэхийг чухалчлах нь үндэслэлтэй юм шиг санагдаж байна. Үүнийг дагадаг үйлчилгээнд чиглэсэн Ийм багуудад дүрслэл хамгийн тохиромжтой.
Мөр, ялангуяа дээж авахгүй бол тархсан системийн бүрэлдэхүүн хэсэг бүрийн талаарх мэдээллийн эрдэнэсийн сан юм. Энэ мэдээллийг хэрэглэгчдэд нийлүүлэх зальтай процессорт өгч болно үйлчилгээнд чиглэсэн Хэрэглэгч ул мөрийг харахаас өмнө тэдгээрийг урьдчилан тодорхойлж болно.
- Зөвхөн онцгой анхаарал татахуйц хүсэлтүүдэд зориулсан саатлын хуваарилалтын диаграммууд (хэт өндөр хүсэлт);
- Үйлчилгээний SLO-ийн зорилгод хүрэхгүй байгаа тохиолдлуудын саатлын хуваарилалтын диаграмм;
- Асуулт дахь хамгийн "ерөнхий", "сонирхолтой" болон "хачин" шошгууд давтагддаг;
- Тохиолдлуудын хоцрогдлын задаргаа хамаарал үйлчилгээ нь SLO зорилгодоо хүрэхгүй байх;
- Төрөл бүрийн доод урсгалын үйлчилгээний хоцрогдлын задаргаа.
Эдгээр асуултын заримыг нь суурилагдсан хэмжүүрээр хариулдаггүй тул хэрэглэгчдийг зайг сайтар нягталж үзэхийг шаарддаг. Үүний үр дүнд бид хэрэглэгчдэд хэт дайсагнасан механизмтай болсон.
Эндээс асуулт гарч ирнэ: янз бүрийн багуудын хяналтанд байдаг олон төрлийн үйлчилгээнүүдийн нарийн төвөгтэй харилцан үйлчлэлийн талаар юу хэлэх вэ? Тийм биш гэж үү traceview ийм нөхцөл байдлыг тодруулах хамгийн тохиромжтой хэрэгсэл гэж үзэхгүй байна уу?
Мобайл хөгжүүлэгчид, харьяалалгүй үйлчилгээний эзэд, удирддаг төрийн үйлчилгээний эзэд (мэдээллийн сан гэх мэт) болон платформ эзэмшигчид өөр зүйлийг сонирхож магадгүй юм. танилцуулга тархсан систем; traceview нь эдгээр үндсэн өөр хэрэгцээнд зориулсан хэтэрхий ерөнхий шийдэл юм. Маш нарийн төвөгтэй бичил үйлчилгээний архитектурт ч гэсэн үйлчилгээний эзэд хоёроос гурваас илүү дээд болон доод урсгалын үйлчилгээний талаар гүнзгий мэдлэг шаарддаггүй. Үндсэндээ ихэнх хувилбарт хэрэглэгчид зөвхөн холбоотой асуултанд хариулах хэрэгтэй хязгаарлагдмал үйлчилгээний багц.
Энэ нь нарийн ширийн зүйлийг шалгахын тулд томруулдаг шилээр жижиг хэсэг үйлчилгээг харахтай адил юм. Энэ нь хэрэглэгчдэд эдгээр үйлчилгээнүүдийн хоорондын нарийн төвөгтэй харилцан үйлчлэл болон тэдгээрийн шууд хамаарлын талаар илүү хурц асуулт асуух боломжийг олгоно. Энэ нь инженерийн мэддэг үйлчилгээний ертөнцөд буцаж ирсэнтэй адил юм гэж буруу, мөн түүнчлэн ойлгохын тулд эргэн тойрны үйлчилгээнд юу болж байгаа талаар тодорхой ойлголттой байдаг яагаад.
Миний сурталчилж буй арга нь дээрээс доош, traceview-д суурилсан арга барилын яг эсрэг талынх бөгөөд шинжилгээ нь бүхэл бүтэн ул мөрөөс эхэлж, дараа нь аажмаар хувь хүний хүрээ хүртэл ажилладаг. Үүний эсрэгээр, доороос дээш чиглэсэн арга нь ослын боломжит шалтгаантай ойролцоо жижиг талбайг шинжилж эхэлдэг бөгөөд дараа нь шаардлагатай бол хайлтын орон зайг өргөжүүлдэг (илүү өргөн хүрээний үйлчилгээнд дүн шинжилгээ хийхийн тулд бусад багийг татан оролцуулах боломжтой). Хоёрдахь арга нь анхны таамаглалыг хурдан шалгахад илүү тохиромжтой. Тодорхой үр дүн гарсны дараа илүү зорилтот, нарийвчилсан шинжилгээнд шилжих боломжтой болно.
Топологи бүтээх
Хэрэв хэрэглэгч мэддэг бол үйлчилгээнд зориулсан харагдац нь үнэхээр хэрэгтэй байж болно аль нь үйлчилгээ эсвэл бүлэг үйлчилгээ нь хоцролтыг нэмэгдүүлэх эсвэл алдаа гаргах үүрэгтэй. Гэсэн хэдий ч нарийн төвөгтэй системд алдаатай үйлчилгээг тодорхойлох нь алдаа гарсан үед, ялангуяа үйлчилгээнүүдээс алдааны мэдэгдэл ирүүлээгүй тохиолдолд чухал биш ажил байж болно.
Үйлчилгээний топологийг бий болгох нь ямар үйлчилгээнд алдааны түвшин нэмэгдэж, хоцролт нэмэгдэж байгаа нь үйлчилгээг мэдэгдэхүйц доройтуулж байгааг олж мэдэхэд ихээхэн тус болно. Би топологи бүтээх тухай ярихдаа би хэлэхгүй байна үйлчилгээний газрын зураг, системд байгаа үйлчилгээ бүрийг харуулах бөгөөд үүгээрээ алдартай . Энэ харагдац нь чиглүүлсэн ациклик график дээр үндэслэсэн traceview-ээс илүү сайн зүйл биш юм. Үүний оронд би хармаар байна динамикаар үүсгэгдсэн үйлчилгээний топологи, алдааны түвшин, хариу өгөх хугацаа эсвэл тодорхой сэжигтэй үйлчилгээний нөхцөл байдлыг тодруулахад туслах хэрэглэгчийн тодорхойлсон параметр зэрэг тодорхой шинж чанарууд дээр үндэслэсэн.
Нэг жишээ татъя. Таамагласан мэдээллийн сайтыг төсөөлье. Нүүр хуудасны үйлчилгээ (өмнөх хуудас) Редис, зөвлөмжийн үйлчилгээ, сурталчилгааны үйлчилгээ, видео үйлчилгээтэй мэдээлэл солилцдог. Видео үйлчилгээ нь S3-аас видео, DynamoDB-ээс мета өгөгдлийг авдаг. Зөвлөмжийн үйлчилгээ нь DynamoDB-ээс мета өгөгдлийг хүлээн авч, Redis болон MySQL-ээс өгөгдлийг ачаалж, Кафка руу мессеж бичдэг. Зар сурталчилгааны үйлчилгээ нь MySQL-ээс өгөгдөл хүлээн авч, Кафка руу мессеж бичдэг.
Энэ топологийн бүдүүвч дүрслэлийг доор үзүүлэв (олон арилжааны чиглүүлэлтийн програмууд топологийг бүтээдэг). Хэрэв та үйлчилгээний хамаарлыг ойлгох шаардлагатай бол энэ нь ашигтай байж болох юм. Гэсэн хэдий ч үеэр дибаг хийх, тодорхой үйлчилгээ (видео үйлчилгээ гэх мэт) хариу өгөх хугацааг ихэсгэх үед ийм топологи нь тийм ч ашигтай биш юм.
Таамагласан мэдээллийн сайтын үйлчилгээний диаграмм
Доорх диаграм нь илүү тохиромжтой байх болно. Үйлчилгээнд асуудал байна (Видео) яг голд нь дүрсэлсэн. Хэрэглэгч үүнийг шууд анзаардаг. Энэхүү дүрслэлээс харахад S3-ийн хариу өгөх хугацаа ихэссэнээс видео үйлчилгээ хэвийн бус ажиллаж байгаа нь үндсэн хуудасны хэсгийг ачаалах хурдад нөлөөлдөг.
Зөвхөн "сонирхолтой" үйлчилгээг үзүүлдэг динамик топологи
Динамик байдлаар үүсгэгдсэн топологи нь статик үйлчилгээний газрын зураг, ялангуяа уян харимхай, автомат масштабтай дэд бүтцээс илүү үр дүнтэй байж болно. Үйлчилгээний топологийг харьцуулах, ялгах чадвар нь хэрэглэгчдэд илүү хамааралтай асуултуудыг асуух боломжийг олгодог. Системийн талаар илүү нарийн асуултууд нь систем хэрхэн ажилладаг талаар илүү сайн ойлголттой болоход хүргэдэг.
Харьцуулсан дэлгэц
Өөр нэг ашигтай дүрслэл бол харьцуулсан дэлгэц байх болно. Одоогоор мөрүүд нь зэрэгцүүлэн харьцуулахад тийм ч тохиромжтой биш байгаа тул харьцуулалтыг ихэвчлэн хийдэг. зайтай. Мөн энэ өгүүллийн гол санаа бол ул мөрийн үр дүнгээс хамгийн үнэ цэнэтэй мэдээллийг гаргаж авахад хэт доогуур түвшний интервалууд юм.
Хоёр ул мөрийг харьцуулах нь үндсэндээ шинэ дүрслэл шаарддаггүй. Үнэн хэрэгтээ, traceview-тэй ижил мэдээллийг харуулсан гистограм гэх мэт зүйл хангалттай. Гайхалтай нь, энэ энгийн арга ч гэсэн хоёр ул мөрийг тусад нь судлахаас хамаагүй илүү үр жимс авчирдаг. Бүр илүү хүчирхэг боломж байх болно дүрслэн харуулах ул мөрийг харьцуулах Нийтдээ. GC (хог цуглуулах)-ийг идэвхжүүлэхийн тулд саяхан байршуулсан мэдээллийн сангийн тохиргооны өөрчлөлт нь хэд хэдэн цагийн масштабтай доод урсгалын үйлчилгээний хариу өгөх хугацаанд хэрхэн нөлөөлж байгааг харах нь маш ашигтай байх болно. Хэрэв миний энд тайлбарлаж байгаа зүйл бол дэд бүтцийн өөрчлөлтийн нөлөөллийн A/B шинжилгээ шиг сонсогдож байвал олон үйлчилгээнд ул мөр үр дүнг ашиглан, тэгвэл та үнэнээс тийм ч хол биш юм.
дүгнэлт
Мөшгих нь ашиг тустай эсэх талаар би эргэлздэггүй. Мөрд агуулагдах шиг баялаг, учир шалтгааны болон контекстээс өөр мэдээлэл цуглуулах арга байхгүй гэдэгт би чин сэтгэлээсээ итгэдэг. Гэсэн хэдий ч, бүх мөрдөх шийдлүүд энэ өгөгдлийг маш үр ашиггүй ашигладаг гэдэгт би итгэдэг. Мөшгих хэрэгслүүд нь ул мөрийн дүрслэл дээр гацсан хэвээр байгаа тохиолдолд тэдгээр нь ул мөр дотор агуулагдах өгөгдлөөс гаргаж авч болох үнэ цэнэтэй мэдээллийг хамгийн их ашиглах чадвараараа хязгаарлагдах болно. Нэмж дурдахад, хэрэглэгчийн програм дахь алдааг олж засварлах чадварыг эрс хязгаарлах бүрэн тохиромжгүй, ойлгомжгүй харагдах интерфейсийг цаашид хөгжүүлэх эрсдэлтэй.
Хамгийн сүүлийн үеийн хэрэгслүүдтэй ч гэсэн нарийн төвөгтэй системийг дибаг хийх нь үнэхээр хэцүү байдаг. Хэрэгсэл нь хөгжүүлэгчид таамаглал дэвшүүлж, шалгахад туслах ёстой. идэвхтэй хангаж байна Холбогдох мэдээлэл, хэтийн утгыг тодорхойлох, саатлын хуваарилалтын онцлогийг тэмдэглэх. Үйлдвэрлэлийн алдааг олж засварлах эсвэл олон үйлчилгээнд хамаарах асуудлуудыг шийдвэрлэхэд мөшгих нь хөгжүүлэгчдийн сонгох хэрэгсэл болохын тулд эдгээр үйлчилгээг бүтээж, ажиллуулдаг хөгжүүлэгчдийн оюун санааны загварт илүү нийцсэн анхны хэрэглэгчийн интерфэйс, дүрслэл хэрэгтэй.
Шинжилгээ, дүгнэлт гаргахад хялбар болгох үүднээс ул мөрийн үр дүнд байгаа янз бүрийн дохиог илэрхийлэх системийг зохион бүтээхэд оюун санааны ихээхэн хүчин чармайлт шаардагдана. Та дибаг хийх явцад системийн топологийг хэрхэн хийсвэрлэх талаар бодох хэрэгтэй бөгөөд ингэснээр хэрэглэгч тус бүрийн ул мөр, зайг харахгүйгээр сохор толбыг даван туулахад тусалдаг.
Бидэнд сайн хийсвэрлэх, үелэх чадвар хэрэгтэй (ялангуяа UI дээр). Таамаглалд тулгуурласан дибаг хийх процесст маш сайн тохирох бөгөөд та давтагдах асуултуудыг асууж, таамаглалыг шалгах боломжтой. Эдгээр нь ажиглалтын бүх асуудлыг автоматаар шийдэхгүй ч хэрэглэгчид зөн совингоо хурцалж, илүү ухаалаг асуултуудыг боловсруулахад туслах болно. Би дүрслэлд илүү анхааралтай, шинэлэг хандлагыг уриалж байна. Энд хүрээгээ тэлэх бодит хэтийн төлөв бий.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Эх сурвалж: www.habr.com