تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

أداة لتحسين أداء تطبيقك في Go (الجزء 2: المحلّل)

1. مقدمة

تاريخ آخر تعديل: 2022-07-14

إمكانية تتبّع بيانات التطبيق

إمكانية تتبّع البيانات وContinuous Profiler

إمكانية تتبّع البيانات هي المصطلح المستخدَم لوصف إحدى سمات النظام. يتيح النظام الذي يتضمّن إمكانية تتبّع البيانات للفرق تصحيح أخطاء نظامهم بشكل نشط. في هذا السياق، تشكّل أركان المراقبة الثلاثة، أي السجلّات والمقاييس وعمليات التتبُّع، أدوات القياس الأساسية التي يحتاج إليها النظام لإتاحة المراقبة.

بالإضافة إلى الأركان الأساسية الثلاثة لإمكانية تتبّع البيانات، يُعدّ التوصيف المستمر أحد المكوّنات الرئيسية الأخرى لإمكانية تتبّع البيانات، وهو يوسّع قاعدة المستخدمين في الصناعة. ‫Cloud Profiler هي إحدى الأدوات الأصلية، وتوفّر واجهة سهلة للتعمّق في مقاييس الأداء في حِزم استدعاء التطبيقات.

هذا الدرس التطبيقي حول الترميز هو الجزء الثاني من السلسلة ويتناول إعداد وكيل أداة تحليل الأداء المستمر. يتناول الجزء 1 التتبُّع الموزَّع باستخدام OpenTelemetry وCloud Trace، وسنتعرّف فيه على كيفية تحديد المشاكل التي تؤدي إلى بطء الأداء في الخدمات المصغّرة بشكل أفضل.

ما ستنشئه

في هذا الدرس التطبيقي حول الترميز، ستستخدم أداة "أداة إنشاء الملفات الشخصية المتواصلة" في خدمة الخادم الخاصة بـ "تطبيق شكسبير" (المعروف أيضًا باسم Shakesapp) الذي يعمل على مجموعة Google Kubernetes Engine. بنية Shakesapp هي كما هو موضح أدناه:

يرسل Loadgen سلسلة طلب بحث إلى العميل عبر HTTP
ينقل العملاء طلب البحث من أداة إنشاء الحمل إلى الخادم في gRPC
يقبل الخادم طلب البحث من العميل، ويستردّ جميع أعمال شكسبير بتنسيق نصي من Google Cloud Storage، ويبحث عن الأسطر التي تحتوي على طلب البحث ويعرض رقم السطر المطابق للعميل

في الجزء 1، تبيّن لك أنّ عنق الزجاجة يقع في مكان ما في خدمة الخادم، ولكن لم تتمكّن من تحديد السبب الدقيق.

ما ستتعلمه

كيفية تضمين أداة Profiler
كيفية التحقيق في المشاكل التي تؤدي إلى بطء الأداء في Cloud Profiler

يوضّح هذا الدرس التطبيقي حول الترميز كيفية إعداد أداة تتبُّع أداء مستمر في تطبيقك.

المتطلبات

معرفة أساسية بلغة Go
معرفة أساسية بمنصة Kubernetes

2. الإعداد والمتطلبات

إعداد البيئة بالسرعة التي تناسبك

إذا لم يكن لديك حساب Google (Gmail أو Google Apps)، عليك إنشاء حساب. سجِّل الدخول إلى "وحدة تحكّم Google Cloud Platform" (console.cloud.google.com) وأنشِئ مشروعًا جديدًا.

إذا كان لديك مشروع، انقر على القائمة المنسدلة لاختيار المشروع في أعلى يمين وحدة التحكّم:

وانقر على الزر "مشروع جديد" في مربّع الحوار الناتج لإنشاء مشروع جديد:

إذا لم يكن لديك مشروع بعد، من المفترض أن يظهر لك مربّع حوار مشابه لما يلي لإنشاء مشروعك الأول:

يتيح لك مربّع حوار إنشاء المشروع اللاحق إدخال تفاصيل مشروعك الجديد:

تذكَّر رقم تعريف المشروع، وهو اسم فريد في جميع مشاريع Google Cloud (الاسم أعلاه مستخدَم حاليًا ولن يكون متاحًا لك، نأسف لذلك). سيُشار إليه لاحقًا في هذا الدرس التطبيقي حول الترميز باسم PROJECT_ID.

بعد ذلك، إذا لم يسبق لك إجراء ذلك، عليك تفعيل الفوترة في Developers Console من أجل استخدام موارد Google Cloud وتفعيل Cloud Trace API.

لن تكلفك تجربة هذا الدرس التطبيقي حول الترميز أكثر من بضعة دولارات، ولكن قد تكون التكلفة أعلى إذا قررت استخدام المزيد من الموارد أو إذا تركتها قيد التشغيل (راجِع قسم "التنظيف" في نهاية هذا المستند). تتوفر أسعار Google Cloud Trace وGoogle Kubernetes Engine وGoogle Artifact Registry في المستندات الرسمية.

يمكن لمستخدمي Google Cloud Platform الجدد الاستفادة من فترة تجريبية مجانية بقيمة 300 دولار أمريكي، ما يجعل هذا الدرس العملي مجانيًا تمامًا.

إعداد Google Cloud Shell

على الرغم من إمكانية تشغيل Google Cloud وGoogle Cloud Trace عن بُعد من جهاز الكمبيوتر المحمول، سنستخدم في هذا الدرس التطبيقي حول الترميز Google Cloud Shell، وهي بيئة سطر أوامر تعمل في السحابة الإلكترونية.

يتم تحميل هذا الجهاز الظاهري المستند إلى Debian بجميع أدوات التطوير التي تحتاج إليها. توفّر هذه الخدمة دليلًا منزليًا دائمًا بسعة 5 غيغابايت وتعمل في Google Cloud، ما يؤدي إلى تحسين أداء الشبكة والمصادقة بشكل كبير. يعني ذلك أنّ كل ما تحتاج إليه لهذا الدرس التطبيقي حول الترميز هو متصفّح (نعم، يمكن استخدامه على جهاز Chromebook).

لتفعيل Cloud Shell من Cloud Console، ما عليك سوى النقر على "تفعيل Cloud Shell" gcLMt5IuEcJJNnMId-Bcz3sxCd0rZn7IzT_r95C8UZeqML68Y1efBG_B0VRp7hc7qiZTLAF-TXD7SsOadxn8uadgHhaLeASnVS3ZHK39eOlKJOgj9SJua_oeGhMxRrbOg3qigddS2A (يستغرق توفير البيئة والاتصال بها بضع لحظات فقط).

JjEuRXGg0AYYIY6QZ8d-66gx_Mtc-_jDE9ijmbXLJSAXFvJt-qUpNtsBsYjNpv2W6BQSrDc1D-ARINNQ-1EkwUhz-iUK-FUCZhJ-NtjvIEx9pIkE-246DomWuCfiGHK78DgoeWkHRw Screen Shot 2017-06-14 at 10.13.43 PM.png

بعد الاتصال بـ Cloud Shell، من المفترض أن يظهر لك أنّه تم إثبات هويتك وأنّ المشروع تم ضبطه على PROJECT_ID.

gcloud auth list

ناتج الأمر

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

gcloud config list project

ناتج الأمر

[core]
project = <PROJECT_ID>

إذا لم يتم ضبط المشروع لسبب ما، ما عليك سوى تنفيذ الأمر التالي:

gcloud config set project <PROJECT_ID>

هل تبحث عن PROJECT_ID؟ يمكنك الاطّلاع على المعرّف الذي استخدمته في خطوات الإعداد أو البحث عنه في لوحة بيانات Cloud Console:

158fNPfwSxsFqz9YbtJVZes8viTS3d1bV4CVhij3XPxuzVFOtTObnwsphlm6lYGmgdMFwBJtc-FaLrZU7XHAg_ZYoCrgombMRR3h-eolLPcvO351c5iBv506B3ZwghZoiRg6cz23Qw

يضبط Cloud Shell أيضًا بعض متغيرات البيئة تلقائيًا، ما قد يكون مفيدًا عند تنفيذ الأوامر المستقبلية.

echo $GOOGLE_CLOUD_PROJECT

ناتج الأمر

<PROJECT_ID>

أخيرًا، اضبط المنطقة التلقائية وإعدادات المشروع.

gcloud config set compute/zone us-central1-f

يمكنك اختيار مجموعة متنوعة من المناطق المختلفة. لمزيد من المعلومات، يُرجى الاطّلاع على المناطق والأقاليم.

الانتقال إلى إعدادات اللغة

في هذا الدرس التطبيقي حول الترميز، نستخدم لغة Go لجميع الرمز المصدر. نفِّذ الأمر التالي على Cloud Shell وتأكَّد من أنّ إصدار Go هو 1.17 أو إصدار أحدث.

go version

ناتج الأمر

go version go1.18.3 linux/amd64

إعداد مجموعة Google Kubernetes

في هذا الدرس التطبيقي حول الترميز، ستشغّل مجموعة من الخدمات المصغّرة على Google Kubernetes Engine (GKE). تتضمّن هذه التجربة العملية الخطوات التالية:

تنزيل المشروع الأساسي إلى Cloud Shell
إنشاء خدمات مصغّرة في حاويات
تحميل الحاويات إلى Google Artifact Registry (GAR)
نشر الحاويات على GKE
تعديل رمز المصدر للخدمات من أجل تتبُّع الأجهزة
الانتقال إلى الخطوة 2

تفعيل Kubernetes Engine

أولاً، نضبط مجموعة Kubernetes حيث يتم تشغيل Shakesapp على GKE، لذا علينا تفعيل GKE. انتقِل إلى القائمة "Kubernetes Engine" واضغط على الزر "تفعيل".

أنت الآن جاهز لإنشاء مجموعة Kubernetes.

إنشاء مجموعة Kubernetes

في Cloud Shell، نفِّذ الأمر التالي لإنشاء مجموعة Kubernetes. يُرجى التأكّد من أنّ قيمة المنطقة تقع ضمن المنطقة التي ستستخدمها لإنشاء مستودع Artifact Registry. غيِّر قيمة المنطقة us-central1-f إذا كانت منطقة المستودع لا تغطي المنطقة.

gcloud container clusters create otel-trace-codelab2 \
--zone us-central1-f \
--release-channel rapid \
--preemptible \
--enable-autoscaling \
--max-nodes 8 \
--no-enable-ip-alias \
--scopes cloud-platform

ناتج الأمر

Note: Your Pod address range (`--cluster-ipv4-cidr`) can accommodate at most 1008 node(s).
Creating cluster otel-trace-codelab2 in us-central1-f... Cluster is being health-checked (master is healthy)...done.     
Created [https://container.googleapis.com/v1/projects/development-215403/zones/us-central1-f/clusters/otel-trace-codelab2].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-f/otel-trace-codelab2?project=development-215403
kubeconfig entry generated for otel-trace-codelab2.
NAME: otel-trace-codelab2
LOCATION: us-central1-f
MASTER_VERSION: 1.23.6-gke.1501
MASTER_IP: 104.154.76.89
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.23.6-gke.1501
NUM_NODES: 3
STATUS: RUNNING

إعداد Artifact Registry وskaffold

لدينا الآن مجموعة Kubernetes جاهزة للنشر. بعد ذلك، نستعد لإنشاء سجلّ حاويات لإرسال الحاويات ونشرها. في هذه الخطوات، علينا إعداد Artifact Registry (GAR) وskaffold لاستخدامه.

إعداد Artifact Registry

انتقِل إلى قائمة Artifact Registry واضغط على الزر "تفعيل" (ENABLE).

بعد بضع لحظات، سيظهر لك متصفّح مستودع GAR. انقر على الزر "إنشاء مستودع" (CREATE REPOSITORY) وأدخِل اسم المستودع.

في هذا الدرس العملي، سأسمّي المستودع الجديد trace-codelab. تنسيق العنصر هو "Docker" ونوع الموقع الجغرافي هو "المنطقة". اختَر المنطقة القريبة من المنطقة التلقائية التي ضبطتها في Google Compute Engine. على سبيل المثال، تم اختيار "us-central1-f" في المثال أعلاه، لذا سنختار هنا "us-central1 (آيوا)". بعد ذلك، انقر على الزر "إنشاء".

يظهر الآن "trace-codelab" في متصفّح المستودع.

سنعود إلى هنا لاحقًا للتحقّق من مسار التسجيل.

إعداد Skaffold

Skaffold هي أداة مفيدة عند العمل على إنشاء خدمات مصغّرة تعمل على Kubernetes. يتعامل مع سير عمل إنشاء حاويات التطبيقات ونقلها ونشرها باستخدام مجموعة صغيرة من الأوامر. تستخدم Skaffold تلقائيًا Docker Registry كسجلّ حاويات، لذا عليك ضبط Skaffold للتعرّف على GAR عند نشر الحاويات.

افتح Cloud Shell مرة أخرى وتأكَّد من تثبيت Skaffold. (تثبِّت Cloud Shell أداة Skaffold في البيئة تلقائيًا). نفِّذ الأمر التالي واطّلِع على إصدار Skaffold.

skaffold version

ناتج الأمر

v1.38.0

يمكنك الآن تسجيل المستودع التلقائي الذي سيستخدمه Skaffold. للحصول على مسار السجلّ، انتقِل إلى لوحة بيانات Artifact Registry وانقر على اسم المستودع الذي أعددته في الخطوة السابقة.

بعد ذلك، ستظهر مسارات شريط التنقّل في أعلى الصفحة. انقر على رمز لنسخ مسار التسجيل إلى الحافظة.

عند النقر على زر النسخ، يظهر مربّع الحوار في أسفل المتصفّح مع رسالة مثل:

تم نسخ "us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab"

ارجع إلى Cloud Shell. نفِّذ الأمر skaffold config set default-repo مع القيمة التي نسختها للتو من لوحة البيانات.

skaffold config set default-repo us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab

ناتج الأمر

set value default-repo to us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab for context gke_stackdriver-sandbox-3438851889_us-central1-b_stackdriver-sandbox

عليك أيضًا ضبط قاعدة بيانات المسجّلين على إعدادات Docker. نفِّذ الأمر التالي:

gcloud auth configure-docker us-central1-docker.pkg.dev --quiet

ناتج الأمر

{
  "credHelpers": {
    "gcr.io": "gcloud",
    "us.gcr.io": "gcloud",
    "eu.gcr.io": "gcloud",
    "asia.gcr.io": "gcloud",
    "staging-k8s.gcr.io": "gcloud",
    "marketplace.gcr.io": "gcloud",
    "us-central1-docker.pkg.dev": "gcloud"
  }
}
Adding credentials for: us-central1-docker.pkg.dev

أنت الآن جاهز للانتقال إلى الخطوة التالية لإعداد حاوية Kubernetes على GKE.

ملخّص

في هذه الخطوة، عليك إعداد بيئة الدرس العملي:

إعداد Cloud Shell
تم إنشاء مستودع Artifact Registry لسجلّ الحاويات
إعداد Skaffold لاستخدام سجلّ الحاويات
تم إنشاء مجموعة Kubernetes حيث يتم تشغيل الخدمات المصغّرة للدرس التطبيقي حول الترميز

في الخطوة التالية، ستفعّل أداة Continuous Profiler في خدمة الخادم.

3- إنشاء الخدمات المصغّرة ونشرها

تنزيل مواد الدرس التطبيقي حول الترميز

في الخطوة السابقة، أعددنا جميع المتطلبات الأساسية لهذا الدرس البرمجي. أنت الآن جاهز لتشغيل الخدمات المصغّرة الكاملة فوقها. يتم استضافة مواد الدرس التطبيقي حول الترميز على GitHub، لذا نزِّلها إلى بيئة Cloud Shell باستخدام أمر git التالي.

cd ~
git clone https://github.com/ymotongpoo/opentelemetry-trace-codelab-go.git
cd opentelemetry-trace-codelab-go

تكون بنية دليل المشروع على النحو التالي:

.
├── README.md
├── step0
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
├── step1
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
├── step2
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
├── step3
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
├── step4
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
├── step5
│   ├── manifests
│   ├── proto
│   ├── skaffold.yaml
│   └── src
└── step6
    ├── manifests
    ├── proto
    ├── skaffold.yaml
    └── src

ملفات البيانات: ملفات بيانات Kubernetes
proto: تعريف proto للتواصل بين العميل والخادم
src: أدلة للرمز المصدر لكل خدمة
skaffold.yaml: ملف الإعداد الخاص بـ Skaffold

في هذا الدرس التطبيقي حول الترميز، ستعدّل الرمز المصدر الموجود في المجلد step4. يمكنك أيضًا الرجوع إلى رمز المصدر في مجلدات step[1-6] للاطّلاع على التغييرات منذ البداية. (يغطّي الجزء 1 الخطوات من 0 إلى 4، ويغطّي الجزء 2 الخطوتين 5 و6)

تنفيذ أمر skaffold

أخيرًا، أنت جاهز لإنشاء المحتوى الكامل ونشره وتوزيعه على مجموعة Kubernetes التي أنشأتها للتو. يبدو أنّ هذا يتضمّن خطوات متعددة، ولكن في الواقع، ينفّذ Skaffold كل شيء نيابةً عنك. لنجرِّب ذلك باستخدام الأمر التالي:

cd step4
skaffold dev

بعد تنفيذ الأمر مباشرةً، سيظهر لك ناتج السجلّ الخاص بـ docker build، ويمكنك التأكّد من أنّه تم إرساله بنجاح إلى السجلّ.

ناتج الأمر

...
---> Running in c39b3ea8692b
 ---> 90932a583ab6
Successfully built 90932a583ab6
Successfully tagged us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice:step1
The push refers to repository [us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice]
cc8f5a05df4a: Preparing
5bf719419ee2: Preparing
2901929ad341: Preparing
88d9943798ba: Preparing
b0fdf826a39a: Preparing
3c9c1e0b1647: Preparing
f3427ce9393d: Preparing
14a1ca976738: Preparing
f3427ce9393d: Waiting
14a1ca976738: Waiting
3c9c1e0b1647: Waiting
b0fdf826a39a: Layer already exists
88d9943798ba: Layer already exists
f3427ce9393d: Layer already exists
3c9c1e0b1647: Layer already exists
14a1ca976738: Layer already exists
2901929ad341: Pushed
5bf719419ee2: Pushed
cc8f5a05df4a: Pushed
step1: digest: sha256:8acdbe3a453001f120fb22c11c4f6d64c2451347732f4f271d746c2e4d193bbe size: 2001

بعد إرسال جميع حاويات الخدمة، تبدأ عمليات نشر Kubernetes تلقائيًا.

ناتج الأمر

sha256:b71fce0a96cea08075dc20758ae561cf78c83ff656b04d211ffa00cedb77edf8 size: 1997
Tags used in deployment:
 - serverservice -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/serverservice:step4@sha256:8acdbe3a453001f120fb22c11c4f6d64c2451347732f4f271d746c2e4d193bbe
 - clientservice -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/clientservice:step4@sha256:b71fce0a96cea08075dc20758ae561cf78c83ff656b04d211ffa00cedb77edf8
 - loadgen -> us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab/loadgen:step4@sha256:eea2e5bc8463ecf886f958a86906cab896e9e2e380a0eb143deaeaca40f7888a
Starting deploy...
 - deployment.apps/clientservice created
 - service/clientservice created
 - deployment.apps/loadgen created
 - deployment.apps/serverservice created
 - service/serverservice created

بعد عملية النشر، ستظهر لك سجلّات التطبيق الفعلية التي تم إرسالها إلى stdout في كل حاوية على النحو التالي:

ناتج الأمر

[client] 2022/07/14 06:33:15 {"match_count":3040}
[loadgen] 2022/07/14 06:33:15 query 'love': matched 3040
[client] 2022/07/14 06:33:15 {"match_count":3040}
[loadgen] 2022/07/14 06:33:15 query 'love': matched 3040
[client] 2022/07/14 06:33:16 {"match_count":3040}
[loadgen] 2022/07/14 06:33:16 query 'love': matched 3040
[client] 2022/07/14 06:33:19 {"match_count":463}
[loadgen] 2022/07/14 06:33:19 query 'tear': matched 463
[loadgen] 2022/07/14 06:33:20 query 'world': matched 728
[client] 2022/07/14 06:33:20 {"match_count":728}
[client] 2022/07/14 06:33:22 {"match_count":463}
[loadgen] 2022/07/14 06:33:22 query 'tear': matched 463

يُرجى العِلم أنّه في هذه المرحلة، عليك الاطّلاع على أي رسائل من الخادم. حسنًا، أنت الآن جاهز لبدء تتبُّع تطبيقك باستخدام OpenTelemetry من أجل التتبُّع الموزّع للخدمات.

قبل بدء تسجيل بيانات الخدمة، يُرجى إيقاف مجموعتك باستخدام Ctrl-C.

ناتج الأمر

...
[client] 2022/07/14 06:34:57 {"match_count":1}
[loadgen] 2022/07/14 06:34:57 query 'what's past is prologue': matched 1
^CCleaning up...
 - W0714 06:34:58.464305   28078 gcp.go:120] WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.
 - To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
 - deployment.apps "clientservice" deleted
 - service "clientservice" deleted
 - deployment.apps "loadgen" deleted
 - deployment.apps "serverservice" deleted
 - service "serverservice" deleted

ملخّص

في هذه الخطوة، أعددت مواد الدرس التطبيقي حول الترميز في بيئتك وتأكّدت من أنّ أداة Skaffold تعمل على النحو المتوقّع.

في الخطوة التالية، ستعدّل رمز المصدر لخدمة loadgen من أجل إعداد معلومات التتبُّع.

4. أدوات موظف دعم Cloud Profiler

مفهوم إنشاء الملفات الشخصية المستمر

قبل شرح مفهوم إنشاء الملفات الشخصية المستمر، علينا أولاً فهم مفهوم إنشاء الملفات الشخصية. تُعدّ عملية إنشاء الملفات الشخصية إحدى طرق تحليل التطبيق بشكل ديناميكي (تحليل البرامج الديناميكية)، ويتم تنفيذها عادةً أثناء تطوير التطبيق في عملية اختبار التحميل وما إلى ذلك. وهو نشاط لمرة واحدة لقياس مقاييس النظام، مثل استخدام وحدة المعالجة المركزية والذاكرة، خلال فترة زمنية محدّدة. بعد جمع بيانات الملف الشخصي، يحلّلها المطوّرون خارج الرمز البرمجي.

التسجيل المستمر للبيانات هو الأسلوب الموسّع للتسجيل العادي للبيانات: فهو ينفّذ عمليات تسجيل بيانات قصيرة المدة مقابل التطبيق الذي يعمل لفترة طويلة بشكل دوري، ويجمع مجموعة من بيانات التسجيل. بعد ذلك، يتم إنشاء التحليل الإحصائي تلقائيًا استنادًا إلى سمة معيّنة للتطبيق، مثل رقم الإصدار ومنطقة النشر ووقت القياس وما إلى ذلك. يمكنك العثور على مزيد من التفاصيل حول هذا المفهوم في مستنداتنا.

بما أنّ الهدف هو تطبيق قيد التشغيل، هناك طريقة لجمع بيانات الملف الشخصي بشكل دوري وإرسالها إلى بعض الأنظمة الخلفية التي تعالج البيانات الإحصائية بعد ذلك. هذا هو عامل Cloud Profiler، وسيتم تضمينه في خدمة الخادم قريبًا.

تضمين وكيل Cloud Profiler

افتح Cloud Shell Editor من خلال النقر على الزر في أعلى يسار Cloud Shell. افتح step4/src/server/main.go من "المستكشف" في اللوحة اليمنى وابحث عن الوظيفة الرئيسية.

step4/src/server/main.go

func main() {
        ...
        // step2. setup OpenTelemetry
        tp, err := initTracer()
        if err != nil {
                log.Fatalf("failed to initialize TracerProvider: %v", err)
        }
        defer func() {
                if err := tp.Shutdown(context.Background()); err != nil {
                        log.Fatalf("error shutting down TracerProvider: %v", err)
                }
        }()
        // step2. end setup

        svc := NewServerService()
        // step2: add interceptor
        interceptorOpt := otelgrpc.WithTracerProvider(otel.GetTracerProvider())
        srv := grpc.NewServer(
                grpc.UnaryInterceptor(otelgrpc.UnaryServerInterceptor(interceptorOpt)),
                grpc.StreamInterceptor(otelgrpc.StreamServerInterceptor(interceptorOpt)),
        )
        // step2: end adding interceptor
        shakesapp.RegisterShakespeareServiceServer(srv, svc)
        healthpb.RegisterHealthServer(srv, svc)
        if err := srv.Serve(lis); err != nil {
                log.Fatalf("error serving server: %v", err)
        }
}

في الدالة main، سترى بعض تعليمات الإعداد الخاصة بـ OpenTelemetry وgRPC، والتي تم تنفيذها في الجزء 1 من الدرس التطبيقي. ستضيف الآن أدوات Cloud Profiler هنا. كما فعلنا مع initTracer()، يمكنك كتابة دالة باسم initProfiler() لتسهيل القراءة.

step4/src/server/main.go

import (
        ...
        "cloud.google.com/go/profiler" // step5. add profiler package
        "cloud.google.com/go/storage"
        ...
)

// step5: add Profiler initializer
func initProfiler() {
        cfg := profiler.Config{
                Service:              "server",
                ServiceVersion:       "1.0.0",
                NoHeapProfiling:      true,
                NoAllocProfiling:     true,
                NoGoroutineProfiling: true,
                NoCPUProfiling:       false,
        }
        if err := profiler.Start(cfg); err != nil {
                log.Fatalf("failed to launch profiler agent: %v", err)
        }
}

لنلقِ نظرة فاحصة على الخيارات المحدّدة في العنصر profiler.Config{}.

الخدمة: اسم الخدمة الذي يمكنك اختياره والتبديل إليه في لوحة بيانات أداة تحليل الأداء
ServiceVersion: اسم إصدار الخدمة. يمكنك مقارنة مجموعات بيانات الملفات الشخصية استنادًا إلى هذه القيمة.
‫NoHeapProfiling: لإيقاف تحليل استهلاك الذاكرة
‫NoAllocProfiling: لإيقاف تحليل تخصيص الذاكرة
‫NoGoroutineProfiling: لإيقاف تحليل goroutine
NoCPUProfiling: لإيقاف تحليل وحدة المعالجة المركزية

في هذا الدرس العملي، سنفعّل فقط إمكانية تسجيل بيانات وحدة المعالجة المركزية.

الآن، ما عليك فعله هو استدعاء هذه الدالة في الدالة main. احرص على استيراد حزمة Cloud Profiler في قسم الاستيراد.

step4/src/server/main.go

func main() {
        ...
        defer func() {
                if err := tp.Shutdown(context.Background()); err != nil {
                        log.Fatalf("error shutting down TracerProvider: %v", err)
                }
        }()
        // step2. end setup

        // step5. start profiler
        go initProfiler()
        // step5. end

        svc := NewServerService()
        // step2: add interceptor
        ...
}

لاحظ أنّك تستدعي الدالة initProfiler() باستخدام الكلمة الرئيسية go. لأنّ profiler.Start() يحظر، لذا عليك تشغيله في روتين فرعي آخر. أصبحت الآن جاهزة للإنشاء. احرص على تشغيل go mod tidy قبل عملية النشر.

go mod tidy

يمكنك الآن نشر مجموعتك باستخدام خدمة الخادم الجديدة.

skaffold dev

يستغرق ظهور الرسم البياني الشعلة على Cloud Profiler عادةً بضع دقائق. اكتب "profiler" في مربّع البحث في أعلى الصفحة وانقر على رمز Profiler.

سيظهر لك بعد ذلك الرسم البياني التالي.

ملخّص

في هذه الخطوة، عليك تضمين وكيل Cloud Profiler في خدمة الخادم والتأكّد من أنّه ينشئ رسمًا بيانيًا للنشاط.

في الخطوة التالية، ستتحقّق من سبب الاختناق في التطبيق باستخدام الرسم البياني الشعلة.

5- تحليل الرسم البياني المفصّل لأداء الرموز في Cloud Profiler

ما هو "الرسم البياني المفصّل لأداء الرموز"؟

"الرسم البياني الشعلة" هو إحدى الطرق لتصوُّر بيانات الملف الشخصي. للحصول على شرح مفصّل، يُرجى الرجوع إلى المستند، ولكن إليك ملخّصًا موجزًا:

يمثّل كل شريط استدعاء الطريقة/الدالة في التطبيق
الاتجاه العمودي هو حزمة الاتصال، وتزداد حزمة الاتصال من أعلى إلى أسفل
الاتجاه الأفقي هو استخدام الموارد، وكلما كان أطول، كان أسوأ.

في ضوء ذلك، لنلقِ نظرة على الرسم البياني الشعلة الذي تم الحصول عليه.

تحليل "الرسم البياني المفصَّل لأداء الرموز"

في القسم السابق، تعرّفت على أنّ كل شريط في الرسم البياني الشعلة يعبّر عن استدعاء الدالة/طلب إجراء، وأنّ طوله يعني استخدام الموارد في الدالة/طلب إجراء. يرتّب الرسم البياني الشريطي في Cloud Profiler الشريط بترتيب تنازلي أو حسب الطول من اليسار إلى اليمين، ويمكنك البدء بالنظر إلى أعلى يسار الرسم البياني أولاً.

في حالتنا، من الواضح أنّ grpc.(*Server).serveStreams.func1.2 يستهلك معظم وقت وحدة المعالجة المركزية، ومن خلال الاطّلاع على حزمة التنفيذ من الأعلى إلى الأسفل، نجد أنّ معظم الوقت يتم استخدامه في main.(*serverService).GetMatchCount، وهو معالج خادم gRPC في خدمة الخادم.

ضمن GetMatchCount، سترى سلسلة من دوال regexp: regexp.MatchString وregexp.Compile. وهي من الحزمة العادية، أي يجب أن يتم اختبارها جيدًا من عدة وجهات نظر، بما في ذلك الأداء. لكنّ النتيجة هنا توضّح أنّ معدّل استخدام موارد وقت وحدة المعالجة المركزية مرتفع في regexp.MatchString وregexp.Compile. في ضوء هذه الحقائق، نفترض أنّ استخدام regexp.MatchString مرتبط بمشاكل الأداء. لذا، لنقرأ الرمز المصدري الذي يتم فيه استخدام الدالة.

step4/src/server/main.go

func (s *serverService) GetMatchCount(ctx context.Context, req *shakesapp.ShakespeareRequest) (*shakesapp.ShakespeareResponse, error) {
        resp := &shakesapp.ShakespeareResponse{}
        texts, err := readFiles(ctx, bucketName, bucketPrefix)
        if err != nil {
                return resp, fmt.Errorf("fails to read files: %s", err)
        }
        for _, text := range texts {
                for _, line := range strings.Split(text, "\n") {
                        line, query := strings.ToLower(line), strings.ToLower(req.Query)
                        isMatch, err := regexp.MatchString(query, line)
                        if err != nil {
                                return resp, err
                        }
                        if isMatch {
                                resp.MatchCount++
                        }
                }
        }
        return resp, nil
}

هذا هو المكان الذي يتم فيه استدعاء regexp.MatchString. من خلال قراءة رمز المصدر، قد تلاحظ أنّه يتم استدعاء الدالة داخل حلقة for المتداخلة. لذلك قد يكون استخدام هذه الدالة غير صحيح. لنبحث عن GoDoc الخاص بـ regexp.

وفقًا للمستند، تعمل الدالة regexp.MatchString على تجميع نمط التعبير العادي في كل عملية استدعاء. إليك السبب المحتمل لاستهلاك الموارد بشكل كبير.

ملخّص

في هذه الخطوة، افترضت سبب استهلاك الموارد من خلال تحليل الرسم البياني الشعلة.

في الخطوة التالية، ستعدّل رمز المصدر لخدمة الخادم وتؤكّد التغيير من الإصدار 1.0.0.

6. تعديل الرمز المصدر ومقارنة الرسوم البيانية الشعلية

تعديل رمز المصدر

في الخطوة السابقة، افترضت أنّ استخدام regexp.MatchString مرتبط باستهلاك الموارد بشكل كبير. لذلك، لنحلّ هذه المشكلة. افتح الرمز وغيِّر هذا الجزء قليلاً.

step4/src/server/main.go

func (s *serverService) GetMatchCount(ctx context.Context, req *shakesapp.ShakespeareRequest) (*shakesapp.ShakespeareResponse, error) {
        resp := &shakesapp.ShakespeareResponse{}
        texts, err := readFiles(ctx, bucketName, bucketPrefix)
        if err != nil {
                return resp, fmt.Errorf("fails to read files: %s", err)
        }

        // step6. considered the process carefully and naively tuned up by extracting
        // regexp pattern compile process out of for loop.
        query := strings.ToLower(req.Query)
        re := regexp.MustCompile(query)
        for _, text := range texts {
                for _, line := range strings.Split(text, "\n") {
                        line = strings.ToLower(line)
                        isMatch := re.MatchString(line)
                        // step6. done replacing regexp with strings
                        if isMatch {
                                resp.MatchCount++
                        }
                }
        }
        return resp, nil
}

كما ترى، تم الآن استخراج عملية تجميع نمط التعبير العادي من regexp.MatchString ونقلها خارج حلقة for المتداخلة.

قبل نشر هذا الرمز، احرص على تعديل سلسلة الإصدار في الدالة initProfiler().

step4/src/server/main.go

func initProfiler() {
        cfg := profiler.Config{
                Service:              "server",
                ServiceVersion:       "1.1.0", // step6. update version
                NoHeapProfiling:      true,
                NoAllocProfiling:     true,
                NoGoroutineProfiling: true,
                NoCPUProfiling:       false,
        }
        if err := profiler.Start(cfg); err != nil {
                log.Fatalf("failed to launch profiler agent: %v", err)
        }
}

لنطّلع الآن على طريقة عملها. انشر المجموعة باستخدام أمر skaffold.

skaffold dev

وبعد مرور بعض الوقت، أعِد تحميل لوحة بيانات Cloud Profiler واطّلِع على شكلها.

احرص على تغيير الإصدار إلى "1.1.0" لكي تظهر لك الملفات الشخصية من الإصدار 1.1.0 فقط. كما تلاحظ، تم تقليل طول شريط GetMatchCount وانخفضت نسبة استخدام وقت وحدة المعالجة المركزية (أي أصبح الشريط أقصر).

لا يمكنك الاكتفاء بالنظر إلى الرسم البياني الشعلة لإصدار واحد، بل يمكنك أيضًا مقارنة الاختلافات بين إصدارين.

غيِّر قيمة القائمة المنسدلة "المقارنة مع" إلى "الإصدار"، وغيِّر قيمة "الإصدار الذي تتم مقارنته" إلى "1.0.0"، وهو الإصدار الأصلي.

سيظهر لك هذا النوع من الرسومات البيانية. شكل الرسم البياني هو نفسه في الإصدار 1.1.0، ولكن الألوان مختلفة. في وضع المقارنة، يشير اللون إلى ما يلي:

الأزرق: القيمة (استهلاك الموارد) التي تم تخفيضها
اللون البرتقالي: القيمة (استهلاك الموارد) التي تم تحقيقها
الرمادي: محايد

بعد التعرّف على وسيلة الإيضاح، لنلقِ نظرة عن كثب على الدالة. من خلال النقر على الشريط الذي تريد تكبيره، يمكنك الاطّلاع على مزيد من التفاصيل داخل الحزمة. يُرجى النقر على الشريط main.(*serverService).GetMatchCount. يمكنك أيضًا تمرير مؤشر الماوس فوق الشريط للاطّلاع على تفاصيل المقارنة.

ويشير إلى أنّ إجمالي وقت وحدة المعالجة المركزية قد انخفض من 5.26 ثانية إلى 2.88 ثانية (الإجمالي هو 10 ثوانٍ = فترة أخذ العيّنات). هذا تحسُّن كبير!

يمكنك الآن تحسين أداء تطبيقك من خلال تحليل بيانات الملف الشخصي.

ملخّص

في هذه الخطوة، أجريت تعديلاً في خدمة الخادم وأكّدت التحسين في وضع المقارنة في Cloud Profiler.

في الخطوة التالية، ستعدّل رمز المصدر لخدمة الخادم وتؤكّد التغيير من الإصدار 1.0.0.

7. خطوة إضافية: تأكيد التحسّن في "مخطط تسلسل تنفيذ التتبُّع"

الفرق بين التتبُّع الموزّع والتحليل المستمر

في الجزء 1 من الدرس التطبيقي حول الترميز، تأكّدت من أنّه يمكنك تحديد الخدمة التي تشكّل مؤثِّرًا سلبيًا في جميع الخدمات المصغّرة لمسار الطلب، وأنّه لا يمكنك تحديد السبب الدقيق للمؤثِّر السلبي في الخدمة المحدّدة. في الجزء 2 من هذا الدرس التطبيقي حول الترميز، تعلّمت أنّ ميزة "التسجيل المستمر للبيانات" تتيح لك تحديد المشاكل في الأداء داخل الخدمة الفردية من حِزم استدعاء الدوال البرمجية.

في هذه الخطوة، لنراجع الرسم البياني الشلالي من التتبُّع الموزّع (Cloud Trace) ونرى الفرق بينه وبين إنشاء الملفات المتواصلة.

هذا الرسم البياني للشلال هو أحد التتبّعات التي تتضمّن طلب البحث "حب". يستغرق ذلك حوالي 6.7 ثانية (6700 ملي ثانية) إجمالاً.

وهذا هو الأداء بعد التحسين لطلب البحث نفسه. كما تلاحظ، أصبح إجمالي وقت الاستجابة الآن 1.5 ثانية (1500 ملي ثانية)، وهو تحسّن كبير مقارنةً بالتنفيذ السابق.

النقطة المهمة هنا هي أنّه في الرسم البياني الشريطي المتتالي للتتبُّع الموزّع، لا تتوفّر معلومات حزمة التنفيذ ما لم يتم قياس حالة التطبيق في كل مكان. بالإضافة إلى ذلك، تركّز التتبُّعات الموزَّعة على وقت الاستجابة في جميع الخدمات، بينما يركّز التوصيف المستمر على موارد الكمبيوتر (وحدة المعالجة المركزية والذاكرة وسلاسل نظام التشغيل) لخدمة واحدة.

من ناحية أخرى، يكون التتبُّع الموزّع مستندًا إلى الأحداث، بينما يكون الملف الشخصي المستمر إحصائيًا. يحتوي كل تتبُّع على رسم بياني مختلف لوقت الاستجابة، وتحتاج إلى تنسيق مختلف، مثل التوزيع، للحصول على مؤشر لتغييرات وقت الاستجابة.

ملخّص

في هذه الخطوة، تحقّقت من الفرق بين التتبُّع الموزّع والقياس المتواصل للأداء.

8. تهانينا

لقد أنشأت عمليات تتبُّع موزّعة بنجاح باستخدام OpenTelemery وأكّدت وقت استجابة الطلبات في جميع الخدمات المصغّرة على Google Cloud Trace.

بالنسبة إلى التمارين الموسّعة، يمكنك تجربة المواضيع التالية بنفسك.

ترسل عملية التنفيذ الحالية جميع الفترات الزمنية التي تم إنشاؤها من خلال عملية التحقّق من الصحة. (grpc.health.v1.Health/Check) كيف يمكن فلترة هذه الفترات من Cloud Trace؟ يمكنك الاطّلاع على التلميح هنا.
ربط سجلّات الأحداث بالنطاقات والاطّلاع على طريقة عملها في Google Cloud Trace وGoogle Cloud Logging يمكنك الاطّلاع على التلميح هنا.
استبدِل بعض الخدمات بالخدمات المتوفّرة بلغة أخرى وحاوِل تفعيلها باستخدام OpenTelemetry لهذه اللغة.

إذا أردت التعرّف على أداة تحليل الأداء بعد ذلك، يُرجى الانتقال إلى الجزء 2. في هذه الحالة، يمكنك تخطّي قسم التنظيف أدناه.

إخلاء مساحة

بعد الانتهاء من هذا الدرس العملي، يُرجى إيقاف مجموعة Kubernetes وحذف المشروع لكي لا يتم تحصيل رسوم غير متوقّعة منك في Google Kubernetes Engine وGoogle Cloud Trace وGoogle Artifact Registry.

أولاً، احذف المجموعة. إذا كنت تشغّل المجموعة باستخدام skaffold dev، ما عليك سوى الضغط على Ctrl-C. إذا كنت تشغّل المجموعة باستخدام skaffold run، نفِّذ الأمر التالي:

skaffold delete

ناتج الأمر

Cleaning up...
 - deployment.apps "clientservice" deleted
 - service "clientservice" deleted
 - deployment.apps "loadgen" deleted
 - deployment.apps "serverservice" deleted
 - service "serverservice" deleted

بعد حذف المجموعة، اختَر "إدارة الهوية وإمكانية الوصول (IAM) والإدارة" > "الإعدادات" من لوحة القائمة، ثمّ انقر على الزر "إيقاف".

بعد ذلك، أدخِل رقم تعريف المشروع (وليس اسم المشروع) في النموذج في مربّع الحوار وأكِّد عملية الإيقاف.