1. परिचय
पिछली बार अपडेट किए जाने की तारीख: 14-07-2022
ऐप्लिकेशन को जांचने की क्षमता
ऑब्ज़र्वेबिलिटी और कंटिन्यूअस प्रोफ़ाइलर
निगरानी करने की क्षमता का इस्तेमाल किसी सिस्टम के एट्रिब्यूट के बारे में बताने के लिए किया जाता है. मॉनिटर करने की क्षमता वाले सिस्टम की मदद से, टीमें अपने सिस्टम को लगातार डीबग कर सकती हैं. इस हिसाब से, निगरानी करने के तीन मुख्य आधार हैं; लॉग, मेट्रिक, और ट्रेस, सिस्टम को मॉनिटर करने की क्षमता पाने के बुनियादी इंस्ट्रुमेंट हैं.
निगरानी करने के तीन मुख्य पहलुओं के अलावा, लगातार प्रोफ़ाइल बनाना, पता लगाने की एक अहम वजह है. साथ ही, इसकी मदद से इंडस्ट्री में उपयोगकर्ताओं की संख्या बढ़ाई जा सकती है. Cloud Profiler, शुरुआत करने वालों में से एक है. यह ऐप्लिकेशन के कॉल स्टैक में परफ़ॉर्मेंस मेट्रिक को ड्रिल-डाउन करने के लिए, आसान इंटरफ़ेस उपलब्ध कराता है.
यह कोडलैब इस सीरीज़ का दूसरा हिस्सा है. इसमें लगातार प्रोफ़ाइलर एजेंट को इंस्ट्रुमेंट करने के बारे में बताया गया है. पहले हिस्से में OpenTelemetry और Cloud Trace की मदद से, डिस्ट्रिब्यूटेड ट्रेसिंग की सुविधा दी गई है. साथ ही, पहले हिस्से की मदद से, माइक्रोसेवाओं की मुश्किलों की बेहतर तरीके से पहचान करने के बारे में बताया गया है.
आपको क्या बनाना होगा
इस कोडलैब में, आपको "Shakespeare ऐप्लिकेशन" की सर्वर सेवा में इंस्ट्रुमेंट लगातार प्रोफ़ाइलर एजेंट मिलेगा (जिसे शेक्स ऐप भी कहते हैं). यह Google Kubernetes Engine क्लस्टर पर चलता है. शेक्स ऐप का आर्किटेक्चर नीचे बताया गया है:
- Loadgen, एचटीटीपी में क्लाइंट को क्वेरी स्ट्रिंग भेजता है
- क्लाइंट, gRPC में लोडजेन से सर्वर तक क्वेरी को पास करते हैं
- सर्वर, क्लाइंट की क्वेरी को स्वीकार करता है, Google Cloud Storage से शेक्सपियर के सभी कामों को टेक्स्ट फ़ॉर्मैट में फ़ेच करता है, क्वेरी वाली लाइनों में खोज करता है, और क्लाइंट से मेल खाने वाली लाइन की संख्या दिखाता है
पहले हिस्से में, आपको पता चला कि सर्वर सेवा में समस्या कहीं-न-कहीं मौजूद है, लेकिन इसकी सटीक वजह का पता नहीं लगाया जा सका.
आपको इनके बारे में जानकारी मिलेगी
- प्रोफ़ाइलर एजेंट को एम्बेड करने का तरीका
- Cloud Profiler पर बॉटल नेक की जांच करने का तरीका
यह कोडलैब आपके आवेदन में, लगातार प्रोफ़ाइलर एजेंट से संपर्क करने का तरीका बताता है.
आपको इन चीज़ों की ज़रूरत होगी
- Go के बारे में बुनियादी जानकारी
- Kubernetes की बुनियादी जानकारी
2. सेटअप और ज़रूरी शर्तें
अपने हिसाब से एनवायरमेंट सेटअप करना
अगर आपके पास पहले से Google खाता (Gmail या Google Apps) नहीं है, तो एक खाता बनाएं. Google Cloud Platform कंसोल ( console.cloud.google.com) में साइन इन करें और एक नया प्रोजेक्ट बनाएं.
अगर आपके पास पहले से कोई प्रोजेक्ट है, तो कंसोल के ऊपर बाईं ओर मौजूद, प्रोजेक्ट चुनने के लिए पुल डाउन मेन्यू पर क्लिक करें:
और 'नया प्रोजेक्ट' पर क्लिक करें बटन:
अगर आपके पास पहले से कोई प्रोजेक्ट नहीं है, तो आपको अपना पहला प्रोजेक्ट बनाने के लिए इस तरह का डायलॉग दिखेगा:
इसके बाद, प्रोजेक्ट बनाने वाले डायलॉग बॉक्स की मदद से अपने नए प्रोजेक्ट की जानकारी डाली जा सकती है:
वह प्रोजेक्ट आईडी याद रखें जो Google Cloud के सभी प्रोजेक्ट के लिए एक यूनीक नाम होता है. ऊपर दिया गया नाम पहले ही किसी दूसरे प्रोजेक्ट के लिए इस्तेमाल किया जा चुका है. इसलिए, यह आपके लिए काम नहीं करेगा! बाद में, इस कोडलैब में इसे PROJECT_ID के तौर पर दिखाया जाएगा.
इसके बाद, अगर आपने पहले से ऐसा नहीं किया है, तो आपको Google Cloud के संसाधनों का इस्तेमाल करने के लिए, Developers Console में बिलिंग चालू करनी होगी. साथ ही, Cloud Trace API को चालू करना होगा.
इस कोडलैब को आज़माने के लिए आपको कुछ डॉलर से ज़्यादा खर्च नहीं करना चाहिए. हालांकि, अगर आप ज़्यादा संसाधनों का इस्तेमाल करने का फ़ैसला करते हैं या उन्हें बंद कर देते हैं, तो यह ज़्यादा हो सकता है (इस दस्तावेज़ के आखिर में "क्लीनअप" सेक्शन देखें). Google Cloud Trace, Google Kubernetes Engine, और Google Artifact Registry की कीमतों की जानकारी आधिकारिक दस्तावेज़ में दी गई है.
- Google Cloud के ऑपरेशंस सुइट की कीमत | ऑपरेशंस सुइट
- कीमत | Kubernetes Engine के दस्तावेज़
- Artifact Registry की कीमत | Artifact Registry का दस्तावेज़
Google Cloud Platform के नए उपयोगकर्ता 300 डॉलर के मुफ़्त में आज़माने की ज़रूरी शर्तें पूरी करते हैं. इसके तहत, कोडलैब का यह वर्शन बिना किसी शुल्क के इस्तेमाल किया जा सकता है.
Google Cloud Shell का सेटअप
Google Cloud और Google Cloud Trace को आपके लैपटॉप से दूर से भी ऑपरेट किया जा सकता है. हालांकि, इस कोडलैब में हम Google Cloud Shell का इस्तेमाल करेंगे. यह क्लाउड में चलने वाला कमांड लाइन एनवायरमेंट है.
Debian आधारित इस वर्चुअल मशीन में ऐसे सभी डेवलपमेंट टूल मौजूद हैं जिनकी आपको ज़रूरत पड़ेगी. यह पांच जीबी की स्थायी होम डायरेक्ट्री उपलब्ध कराता है और Google Cloud में चलता है. यह नेटवर्क की परफ़ॉर्मेंस और पुष्टि करने की प्रोसेस को बेहतर बनाता है. इसका मतलब है कि इस कोडलैब के लिए आपको सिर्फ़ एक ब्राउज़र की ज़रूरत होगी. हां, यह Chromebook पर काम करता है.
Cloud Console से Cloud Shell को चालू करने के लिए, Cloud Shell को चालू करें 
पर क्लिक करें. प्रावधान करने और एनवायरमेंट से कनेक्ट होने में कुछ ही समय लगेगा.
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 के डैशबोर्ड में देखें:
Cloud Shell, डिफ़ॉल्ट रूप से कुछ एनवायरमेंट वैरिएबल सेट करता है. ये वैरिएबल, आने वाले समय में कमांड चलाने के दौरान काम आ सकते हैं.
echo $GOOGLE_CLOUD_PROJECT
कमांड आउटपुट
<PROJECT_ID>
आखिर में, डिफ़ॉल्ट ज़ोन और प्रोजेक्ट कॉन्फ़िगरेशन सेट करें.
gcloud config set compute/zone us-central1-f
आपके पास कई तरह के ज़ोन चुनने का विकल्प होता है. ज़्यादा जानकारी के लिए, क्षेत्र और ज़ोन.
Go लैंग्वेज सेटअप
इस कोडलैब में, हम सभी सोर्स कोड के लिए 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 (जीकेई) पर कंटेनर डिप्लॉय करना
- ट्रेस इंस्ट्रुमेंटेशन के लिए सेवाओं का सोर्स कोड बदलें
- दूसरे चरण पर जाएं
Kubernetes इंजन चालू करना
सबसे पहले, हम Kubernetes क्लस्टर सेट अप करते हैं. इसमें 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 और स्केफ़ोल्ड का सेटअप
अब हमारे पास Kubernetes क्लस्टर है, जो डिप्लॉयमेंट के लिए तैयार है. इसके बाद, हम कंटेनर को पुश और डिप्लॉय करने के लिए, एक कंटेनर रजिस्ट्री की तैयारी करते हैं. इन चरणों के लिए, हमें एक Artifact Registry (GAR) और स्कैफ़ोल्ड सेट अप करना होगा, ताकि वे इसका इस्तेमाल कर सकें.
Artifact Registry का सेटअप करना
"Artifact Registry" के मेन्यू पर जाएं और 'चालू करें' बटन दबाएं.
कुछ देर बाद, आपको GAR का डेटा स्टोर करने की जगह वाला ब्राउज़र दिखेगा. "डेटा स्टोर करने की जगह बनाएं" पर क्लिक करें बटन पर क्लिक करें और रिपॉज़िटरी का नाम डालें.
इस कोडलैब में, मैंने डेटा स्टोर करने की नई जगह को trace-codelab नाम दिया है. आर्टफ़ैक्ट का फ़ॉर्मैट "डॉकर" है और जगह का टाइप "क्षेत्र" है. Google Compute Engine के डिफ़ॉल्ट ज़ोन के लिए सेट किए गए इलाके के आस-पास का इलाका चुनें. उदाहरण के लिए, इस उदाहरण में "us-central1-f" को चुना गया इसलिए यहां हम "us-central1 (आयोवा)" को चुनते हैं. इसके बाद, "बनाएं" पर क्लिक करें बटन.
अब आपको "ट्रेस-कोडलैब" दिखता है रिपॉज़िटरी ब्राउज़र पर.
हम रजिस्ट्री पाथ की जांच करने के लिए बाद में यहां वापस आएंगे.
Skaffold का सेटअप
Kubernetes पर चलने वाली माइक्रोसर्विस बनाने के लिए, Skaffold एक आसान टूल है. यह कमांड के छोटे सेट का इस्तेमाल करके, ऐप्लिकेशन के कंटेनर बनाने, पुश करने, और डिप्लॉय करने का वर्कफ़्लो मैनेज करता है. Skoffold, डिफ़ॉल्ट रूप से कंटेनर रजिस्ट्री के रूप में Docker Registry का इस्तेमाल करते हैं. इसलिए, आपको कंटेनर को पुश करने पर GAR की पहचान करने के लिए, skaffold को कॉन्फ़िगर करना होगा.
Cloud Shell को फिर से खोलें और पुष्टि करें कि स्कैफ़ोल्ड को इंस्टॉल किया गया है. Cloud Shell पर, डिफ़ॉल्ट रूप से एनवायरमेंट में स्केलोल्ड इंस्टॉल होता है. निम्न कमांड चलाएं और स्केलोल्ड वर्शन देखें.
skaffold version
कमांड आउटपुट
v1.38.0
अब आपके पास स्केलोल्ड के इस्तेमाल के लिए, डिफ़ॉल्ट रिपॉज़िटरी को रजिस्टर करने का विकल्प है. रजिस्ट्री पाथ पाने के लिए, Artifact Registry के डैशबोर्ड पर जाएं. इसके बाद, उस डेटा स्टोर करने की उस जगह के नाम पर क्लिक करें जिसे आपने पिछले चरण में सेट अप किया था.
इसके बाद, आपको पेज के सबसे ऊपर ब्रेडक्रंब की जगहें दिखेंगी. रजिस्ट्री पाथ को क्लिपबोर्ड पर कॉपी करने के लिए, 
आइकॉन पर क्लिक करें.
'कॉपी करें' बटन पर क्लिक करने पर, आपको ब्राउज़र के सबसे नीचे एक डायलॉग बॉक्स दिखेगा. इस मैसेज में यह मैसेज दिखेगा:
"us-central1-docker.pkg.dev/psychic-order-307806/trace-codelab" कॉपी किया गया
क्लाउड शेल पर वापस जाएं. 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
अब आप GKE (जीकेई) पर Kubernetes कंटेनर सेट अप करने के लिए, अगले चरण पर जा सकते हैं.
खास जानकारी
इस चरण में, कोडलैब एनवायरमेंट को सेट अप किया जाता है:
- Cloud Shell सेट अप करना
- कंटेनर रजिस्ट्री के लिए, Artifact Registry का डेटा स्टोर करने की सुविधा बनाई गई है
- कंटेनर रजिस्ट्री का इस्तेमाल करने के लिए, skaffold सेट अप करना
- एक Kubernetes क्लस्टर बनाया गया है, जहां कोडलैब माइक्रोसर्विस चलता है
अगला वीडियो
अगले चरण में, आपको सर्वर सेवा में लगातार प्रोफ़ाइलर एजेंट को इंस्ट्रुमेंट करना होगा.
3. माइक्रोसर्विस बनाएं, पुश करें, और डिप्लॉय करें
कोडलैब का कॉन्टेंट डाउनलोड करना
पिछले चरण में, हमने इस कोडलैब के लिए सभी ज़रूरी शर्तें सेट अप की हैं. अब आप उनके ऊपर पूरी माइक्रोसेवाएं चलाने के लिए तैयार हैं. कोडलैब का कॉन्टेंट, GitHub पर होस्ट किया जाता है. इसलिए, यहां दिए गए git कमांड की मदद से, Cloud Shell एनवायरमेंट में उन्हें डाउनलोड करें.
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 मेनिफ़ेस्ट फ़ाइलें
- प्रोटो: क्लाइंट और सर्वर के बीच कम्यूनिकेशन के लिए प्रोटो डेफ़िनिशन
- src: हर सेवा के सोर्स कोड के लिए डायरेक्ट्री
- skaffold.yaml: skaffold के लिए कॉन्फ़िगरेशन फ़ाइल
इस कोडलैब में, step4 फ़ोल्डर में मौजूद सोर्स कोड को अपडेट किया जाएगा. शुरुआत से ही बदलावों के बारे में जानने के लिए, step[1-6] फ़ोल्डर में सोर्स कोड देखें. (पहले भाग में चरण0 से लेकर चौथे चरण तक के बारे में बताया गया है, जबकि दूसरे भाग में पांचवें और छठे चरण को शामिल किया गया है)
skaffold कमांड चलाएं
आखिरकार, आप अभी बनाए गए Kubernetes क्लस्टर पर बनाने, पुश और लागू करने के लिए तैयार हैं. ऐसा लगता है कि इसमें कई चरण हैं, लेकिन असल में स्कैफ़ोल्ड आपके लिए सब कुछ करता है. इसे नीचे दिए गए निर्देश की मदद से करके देखते हैं:
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
खास जानकारी
इस चरण में, आपने अपने एनवायरमेंट में कोडलैब मटीरियल तैयार किया है और उम्मीद के मुताबिक स्कैफ़ोल्ड के चलने की पुष्टि की है.
अगला वीडियो
अगले चरण में, आपको ट्रेस जानकारी को तैयार करने के लिए, लोडजेन सेवा के सोर्स कोड में बदलाव करना होगा.
4. Cloud Profiler एजेंट का इंस्ट्रुमेंटेशन
लगातार प्रोफ़ाइल बनाने का सिद्धांत
'लगातार प्रोफ़ाइल बनाने' के सिद्धांत को समझाने से पहले, हमें प्रोफ़ाइलिंग को समझना होगा. प्रोफ़ाइलिंग, ऐप्लिकेशन का डाइनैमिक तरीके से विश्लेषण करने का एक तरीका है. डाइनैमिक प्रोग्राम विश्लेषण. आम तौर पर, इसे ऐप्लिकेशन डेवलपमेंट के दौरान, लोड टेस्टिंग प्रोसेस के दौरान और इसी तरह के अन्य कामों के दौरान किया जाता है. यह किसी खास समयावधि के दौरान, सिस्टम की मेट्रिक, जैसे कि सीपीयू और मेमोरी के इस्तेमाल को मापने के लिए, सिंगल शॉट गतिविधि है. प्रोफ़ाइल का डेटा इकट्ठा करने के बाद, डेवलपर कोड से उसका विश्लेषण करते हैं.
लगातार प्रोफ़ाइल बनाना, सामान्य प्रोफ़ाइल बनाने का तरीका है: यह लंबे समय तक चलने वाले ऐप्लिकेशन के लिए समय-समय पर छोटी विंडो वाली प्रोफ़ाइलें चलाता है और प्रोफ़ाइल का कुछ डेटा इकट्ठा करता है. इसके बाद, यह ऐप्लिकेशन के कुछ एट्रिब्यूट के आधार पर, अपने-आप आंकड़ों का विश्लेषण जनरेट करता है. उदाहरण के लिए, वर्शन नंबर, डिप्लॉयमेंट ज़ोन, मेज़रमेंट का समय वगैरह. आपको हमारे दस्तावेज़ में इस सिद्धांत के बारे में ज़्यादा जानकारी मिल जाएगी.
टारगेट एक चल रहा ऐप्लिकेशन है, इसलिए समय-समय पर प्रोफ़ाइल डेटा इकट्ठा करने और उन्हें किसी बैकएंड पर भेजने का एक तरीका मौजूद है, जो सांख्यिकीय डेटा को प्रोसेस करने के बाद करता है. यह Cloud Profiler एजेंट है और जल्द ही इसे सर्वर सेवा में एम्बेड किया जाएगा.
Cloud Profiler एजेंट को एम्बेड करना
क्लाउड शेल के सबसे ऊपर दाईं ओर मौजूद 
बटन को दबाकर, क्लाउड शेल एडिटर खोलें. बाएं पैनल में एक्सप्लोरर से 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 के लिए कुछ सेटअप कोड दिखता है, जिसे कोडलैब के पहले हिस्से में पूरा किया जा चुका है. अब आपको 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: गोरूटीन प्रोफ़ाइलिंग बंद करें
- 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
...
}
ध्यान दें कि आप go कीवर्ड के साथ initProfiler() फ़ंक्शन को कॉल कर रहे हैं. क्योंकि profiler.Start() ब्लॉक करता है, इसलिए आपको इसे किसी दूसरे गोरूटीन में चलाना होगा. अब यह बनाए जाने के लिए तैयार है. डिप्लॉयमेंट से पहले go mod tidy को चलाना न भूलें.
go mod tidy
अब अपने क्लस्टर को अपनी नई सर्वर सेवा के साथ डिप्लॉय करें.
skaffold dev
आम तौर पर, Cloud 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 कहा जाता है. सोर्स कोड को पढ़कर, यह देखा जा सकता है कि इस फ़ंक्शन को नेस्ट किए गए फॉर-लूप के अंदर कॉल किया गया है. इसलिए, इस फ़ंक्शन का इस्तेमाल गलत हो सकता है. आइए, regexp का GoDoc देखते हैं.
इस दस्तावेज़ के मुताबिक, 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 से ली गई है. इसके बाद, लूप के लिए नेस्ट किए गए पैटर्न से बाहर ले जाया गया है.
इस कोड को डिप्लॉय करने से पहले, 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. अतिरिक्त चरण: ट्रेस वॉटरफ़ॉल में सुधार की पुष्टि करें
डिस्ट्रिब्यूटेड ट्रेस और कंटिन्यूअस प्रोफ़ाइलिंग में अंतर
कोडलैब के पहले हिस्से में, आपने यह पुष्टि की है कि आप किसी अनुरोध पाथ के लिए, माइक्रोसेवाओं में बॉटलनेक सेवा का पता लगाने की पुष्टि करते हैं. साथ ही, आपने यह भी पुष्टि की है कि किसी खास सेवा में बॉटलनेक की वजह का पता नहीं लगाया जा सका. कोडलैब के इस हिस्से में, आपने सीखा है कि लगातार प्रोफ़ाइल बनाने की सुविधा से, कॉल स्टैक से किसी एक सेवा में आने वाली रुकावट की पहचान की जा सकती है.
इस चरण में, डिस्ट्रिब्यूटेड ट्रेस (Cloud Trace) से वॉटरफ़ॉल ग्राफ़ की समीक्षा की जाती है और यह देखा जाता है कि लगातार प्रोफ़ाइल बनाने की सुविधा में क्या अंतर है.
यह वॉटरफ़ॉल ग्राफ़ "प्यार" क्वेरी के ट्रेस में से एक है. इसमें करीब 6.7 (6700 मि॰से॰) का समय लग रहा है.
ऐसा उसी क्वेरी में किए गए सुधार के बाद होता है. जैसा कि आपको बता दें, इंतज़ार का कुल समय अब 1.5 सेकंड (1500 मि॰से॰) है. यह, पिछली बार लागू करने की तुलना में एक बहुत बड़ा सुधार है.
खास बात यह है कि डिस्ट्रिब्यूट किए गए ट्रेस वॉटरफ़ॉल चार्ट में, कॉल स्टैक की जानकारी तब तक उपलब्ध नहीं होती, जब तक कि इंस्ट्रुमेंट का इस्तेमाल हर जगह न किया जा रहा हो. साथ ही, डिस्ट्रिब्यूट किए गए ट्रेस सभी सेवाओं में लगने वाले समय पर फ़ोकस करते हैं, जबकि लगातार प्रोफ़ाइल बनाने की प्रोसेस किसी एक सेवा के कंप्यूटर संसाधनों (सीपीयू, मेमोरी, ओएस थ्रेड) पर फ़ोकस करती है.
दूसरे पहलू में, डिस्ट्रिब्यूटेड ट्रेस, इवेंट आधार है और कंटिन्यूअस प्रोफ़ाइल, आंकड़े होते हैं. हर ट्रेस का इंतज़ार का समय अलग-अलग होता है और इंतज़ार के समय में होने वाले बदलावों का रुझान जानने के लिए आपको अलग फ़ॉर्मैट की ज़रूरत होती है, जैसे कि डिस्ट्रिब्यूशन.
खास जानकारी
इस चरण में, आपने डिस्ट्रिब्यूटेड ट्रेस और कंटिन्यूअस प्रोफ़ाइलिंग के बीच के अंतर की जांच की.
8. बधाई हो
आपने OpenTelemery की मदद से, डिस्ट्रिब्यूटेड ट्रेस बना लिए हैं. साथ ही, आपने Google Cloud Trace की माइक्रोसेवा में, अनुरोध के बाद के समय की पुष्टि कर दी है.
ज़्यादा समय तक कसरत करने के लिए, इन विषयों को खुद आज़माया जा सकता है.
- फ़िलहाल, लागू करने की प्रोसेस के दौरान हेल्थ जांच से जनरेट हुए सभी स्पैन भेजे जाते हैं. (
grpc.health.v1.Health/Check) Cloud Traces से इन स्पैन को कैसे फ़िल्टर किया जा सकता है? हिंट यहां दिया गया है. - इवेंट लॉग को स्पैन के साथ जोड़ें और देखें कि यह Google Cloud Trace और Google Cloud Logging पर कैसे काम करता है. हिंट यहां दिया गया है.
- किसी सेवा की जगह दूसरी भाषा की सेवा इस्तेमाल करें और उस भाषा के लिए OpenTelemetry से करूं.
साथ ही, अगर आपको इसके बाद प्रोफ़ाइलर के बारे में जानना है, तो कृपया दूसरे हिस्से पर जाएं. इस मामले में, आपके पास नीचे दिए गए क्लीनअप सेक्शन को छोड़ने का विकल्प है.
खाली करने के लिए जगह
इस कोडलैब के बाद, कृपया 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 और एडमिन" > "सेटिंग", और फिर "बंद करें" पर क्लिक करें बटन.
इसके बाद, डायलॉग बॉक्स में दिए गए फ़ॉर्म में प्रोजेक्ट का आईडी डालें, न कि प्रोजेक्ट का नाम डालें और बंद करने की पुष्टि करें.