Kubernetes एजेंट (Helm स्थापना)

Status200 Kubernetes एजेंट एक Helm चार्ट है जो आपके क्लस्टर के मेट्रिक्स, इवेंट और पॉड लॉग, eBPF से कैप्चर किए गए एप्लिकेशन ट्रेस, और हर नोड के OS मेट्रिक्स इकट्ठा करके Status200 को भेजता है। एक helm install इसे लगा देता है, आपके ऐप के कोड में कोई बदलाव किए बिना। Kubernetes मॉनिटर इसके भेजे डेटा पर अलर्ट करते हैं।

चार्ट क्या इंस्टॉल करता है#

चार्ट अपने नेमस्पेस में कुछ वर्कलोड चलाता है। हर एक जो इकट्ठा करता है, उसे आपकी दी गई इंजेशन कुंजी के साथ OTLP पर आपके Status200 URL पर भेजता है।

हर एजेंट इमेज केवल Linux के लिए है, इसलिए हर वर्कलोड Linux नोड पर पिन किया जाता है।

शुरू करने से पहले#

• एक इंजेशन कुंजी। इसे Status200 में प्रोजेक्ट सेटिंग्स → टेलीमेट्री और APM → इंजेशन कुंजियाँ के अंतर्गत बनाएँ। एजेंट इसे x-status200-token हेडर के रूप में भेजता है, इसलिए प्रोजेक्ट API कुंजी यहाँ काम नहीं करती।
• Helm 3 और क्लस्टर तक kubectl पहुँच। अपग्रेड --reset-then-reuse-values का उपयोग करते हैं, जिसके लिए Helm 3.14 या बाद का संस्करण चाहिए।
• क्लस्टर का नाम, आपके प्रोजेक्ट में अद्वितीय। इसके बिना चार्ट इंस्टॉल होने से मना कर देता है: एक ही नाम वाले दो क्लस्टर एक के रूप में दिखेंगे।
• क्लस्टर से आपके Status200 URL तक आउटबाउंड HTTPS।

एजेंट इंस्टॉल करें#

1. Helm रिपॉज़िटरी जोड़ें#

   Bash

   helm repo add status200 https://helm-chart.status200.ru
   helm repo update

2. चार्ट इंस्टॉल करें#

   URL को अपने Status200 URL से बदलें, और दोनों प्लेसहोल्डर को अपनी इंजेशन कुंजी और क्लस्टर के नाम से:

   Bash

   helm install status200-agent status200/kubernetes-agent \
     --namespace status200-kubernetes-agent \
     --create-namespace \
     --set status200.url=https://status200.ru \
     --set status200.apiKey=<YOUR_API_KEY> \
     --set clusterName=<A_UNIQUE_NAME_FOR_THIS_CLUSTER>

   यह standard प्रीसेट का उपयोग करता है। GKE Autopilot या EKS Fargate पर, इसके बजाय उनका प्रीसेट चुनें।

3. जाँचें कि पॉड चल रहे हैं#

   Bash

   kubectl get pods -n status200-kubernetes-agent

   हर पॉड को एक-दो मिनट में Running तक पहुँच जाना चाहिए।

4. Status200 में क्लस्टर खोजें#

   उत्पाद → बुनियादी ढांचा → Kubernetes → सभी क्लस्टर खोलें। कुछ मिनटों में क्लस्टर अपने नाम से दिखता है, और उसके नोड, पॉड और वर्कलोड भर जाते हैं।

प्रीसेट चुनें#

कुछ Kubernetes प्लेटफ़ॉर्म किसी वर्कलोड को hostPath वॉल्यूम माउंट करने या DaemonSet चलाने नहीं देते, जिनका उपयोग नोड कलेक्टर करता है। preset सेटिंग चुनती है कि आपके प्लेटफ़ॉर्म पर क्या काम करता है:

अगर पक्का न हो, तो standard पाने के लिए preset को खाली छोड़ दें। अगर इंस्टॉल hostPath का नाम लेने वाली Pod Security त्रुटि के साथ विफल हो, तो gke-autopilot के साथ फिर से इंस्टॉल करें, या EKS Fargate पर eks-fargate के साथ।

GKE Autopilot और EKS Fargate विशेषाधिकार वाले पॉड भी अस्वीकार करते हैं, जिनकी eBPF इंस्ट्रूमेंटेशन और प्रोफ़ाइलिंग को ज़रूरत होती है, इसलिए उनके प्रीसेट दोनों को छोड़ देते हैं:

helm install status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --create-namespace \
  --set status200.url=https://status200.ru \
  --set status200.apiKey=<YOUR_API_KEY> \
  --set clusterName=prod

helm install status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --create-namespace \
  --set status200.url=https://status200.ru \
  --set status200.apiKey=<YOUR_API_KEY> \
  --set clusterName=prod-gke-autopilot \
  --set preset=gke-autopilot

helm install status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --create-namespace \
  --set status200.url=https://status200.ru \
  --set status200.apiKey=<YOUR_API_KEY> \
  --set clusterName=prod-eks-fargate \
  --set preset=eks-fargate

क्लस्टर को लेबल दें#

इंस्टॉल के समय दिए गए लेबल क्लस्टर से, और इस एजेंट द्वारा रिपोर्ट की गई सेवाओं और होस्ट से जुड़ते हैं। --set status200.labels.<key>=<value> <key>:<value> नाम का प्रोजेक्ट लेबल बन जाता है:

helm install status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent \
  --create-namespace \
  --set status200.url=https://status200.ru \
  --set status200.apiKey=<YOUR_API_KEY> \
  --set clusterName=prod \
  --set status200.labels.team=payments \
  --set status200.labels.env=production \
  --set status200.labels.region=us-east-1

या उन्हें values फ़ाइल में रखें:

oneuptime:
  url: https://status200.ru
  apiKey: <YOUR_API_KEY>
  labels:
    team: payments
    env: production
    region: us-east-1
clusterName: prod

helm install status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --create-namespace \
  -f values.yaml

तब यह एजेंट जो भी रिकॉर्ड भेजता है - लॉग, मेट्रिक्स, ट्रेस और प्रोफ़ाइल - उसमें team:payments, env:production और region:us-east-1 होते हैं। हर लेबल एक status200.label.<key>=<value> रिसोर्स एट्रिब्यूट है, और Status200 status200.label. से शुरू होने वाले हर एट्रिब्यूट को लेबल में बदल देता है। लेबल का मिलान केस की परवाह किए बिना होता है, इसलिए मौजूदा Production लेबल दोबारा उपयोग होता है, नकल नहीं बनती। एजेंट वह लेबल कभी नहीं हटाता जो आपने Status200 में जोड़ा हो।

पॉड लॉग#

preset logs.mode सेट करता है, जिसे आप खुद भी सेट कर सकते हैं:

लॉग संग्रह बंद करने के लिए, --set logs.enabled=false सेट करें और इसके बजाय एप्लिकेशन लॉग OpenTelemetry SDK से भेजें। मेट्रिक्स पर असर नहीं पड़ता: नोड कलेक्टर चलता रहता है।

मिश्रित OS क्लस्टर (Windows नोड पूल)#

Windows नोड पर कभी एजेंट पॉड नहीं चलता। उनके और उनके पॉड के बारे में क्लस्टर-स्तर का डेटा फिर भी आता है, क्योंकि वह Kubernetes API से आता है: नोड की स्थितियाँ, पॉड फ़ेज़, Kubernetes इवेंट और kube-state-metrics। Windows नोड में वह नहीं होता जो नोड पर इकट्ठा होता है: OS मेट्रिक्स, kubelet और cAdvisor मेट्रिक्स, eBPF ट्रेस, प्रोफ़ाइल और, daemonset लॉग मोड में, पॉड लॉग।

Windows नोड पर पॉड के लॉग भी इकट्ठा करने के लिए, हाइब्रिड मोड चालू करें:

helm upgrade status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --reset-then-reuse-values \
  --set logs.windowsPods.enabled=true

तब लॉग टेलर नोड कलेक्टर के साथ चलता है, केवल Windows नोड पर मौजूद पॉड के लिए। Linux पॉड सस्ती फ़ाइल टेलिंग रखते हैं, और दोनों नोड OS के आधार पर पॉड बाँट लेते हैं, इसलिए कोई लॉग पंक्ति दो बार नहीं भेजी जाती।

• टेलर इमेज का संस्करण। केवल-Windows वाला बँटवारा kubernetes-log-tailer इमेज में बना है। पुरानी इमेज इसे अनदेखा करती है और हर पॉड को टेल करती है, जिससे हर Linux पॉड के लॉग दो बार भेजे जाते हैं। logs.api.image.tag को चार्ट रिलीज़ से पुराने संस्करण पर पिन न करें, और अगर किसी नोड ने पुरानी release इमेज कैश की हो सकती है, तो अपग्रेड में --set logs.api.image.pullPolicy=Always जोड़ें।
• गंभीरता के आधार पर फ़िल्टरिंग। filters.logs.minSeverity सेट होने पर, बिना पहचानने योग्य गंभीरता वाली पंक्ति नोड कलेक्टर के रास्ते पर हटा दी जाती है पर लॉग टेलर के रास्ते पर रखी जाती है - देखें लॉग गंभीरता द्वारा फ़िल्टरिंग। तब Windows पॉड Linux पॉड से ज़्यादा बिना स्तर वाली पंक्तियाँ भेज सकते हैं।

eBPF के साथ एप्लिकेशन ट्रेस#

चार्ट हर नोड पर OpenTelemetry eBPF Instrumentation (OBI) चलाता है। OBI Linux कर्नेल में eBPF प्रोग्राम लोड करता है और हर पॉड का नेटवर्क ट्रैफ़िक देखता है, इसलिए वह आपके ऐप में कोई बदलाव किए बिना HTTP और HTTPS, gRPC, और SQL और Redis कॉल फिर से बना सकता है: न SDK, न sidecar। वह इन्हें ट्रेस और अनुरोध मेट्रिक्स के रूप में Status200 को भेजता है।

आपकी सेवाएँ एक-दो मिनट में उत्पाद → ट्रेस के अंतर्गत और सर्विस मैप पर दिखती हैं, k8s.cluster.name को क्लस्टर के नाम पर सेट करके, ताकि आप क्लस्टर के आधार पर फ़िल्टर कर सकें।

eBPF कब बंद करें#

eBPF डिफ़ॉल्ट रूप से चालू है। इसे --set ebpf.enabled=false से तब बंद करें जब:

• क्लस्टर GKE Autopilot या EKS Fargate हो। यह उनके प्रीसेट आपके लिए कर देते हैं: वे प्लेटफ़ॉर्म विशेषाधिकार वाले पॉड अस्वीकार करते हैं, और OBI को अपने प्रोग्राम लोड करने के लिए विशेषाधिकार चाहिए।
• नोड Linux 5.8 से पुराना और बिना BTF वाला कर्नेल चलाते हों। Debian 11, Ubuntu 20.10, Fedora 34, RHEL 9 और बाद के संस्करण ठीक हैं।
• आपके ऐप पहले से OpenTelemetry SDK से ट्रेस भेजते हों, और आप उन्हें दो बार नहीं चाहते।

eBPF क्या भेजता है#

OBI कई तरह के सिग्नल भेजता है। हर एक को --set ebpf.features.<key>=false से बंद किया जा सकता है:

सेवाओं के बीच ट्रेस जोड़ना#

OBI किसी कॉल के पार ट्रेस को आगे भी ले जाता है: जब पॉड A HTTP या gRPC पर पॉड B को कॉल करता है, तो B की तरफ़ का स्पैन A के ट्रेस से जुड़ जाता है, किसी भी ऐप में SDK के बिना। यह डिफ़ॉल्ट रूप से चालू है। इसके बिना, किसी दूसरे नोड के पॉड को की गई कॉल अपना अलग ट्रेस शुरू करती है; उसी नोड पर OBI दोनों सिरों को खुद जोड़ देता है। अगर नीचे की चेतावनी में बताई गई समस्या आपके सामने आए, तो इसे --set ebpf.contextPropagation=false से बंद करें।

लॉग को ट्रेस से जोड़ना#

डिफ़ॉल्ट रूप से बंद। चालू होने पर, OBI हर उस प्रोसेस की write() सिस्टम कॉल से एक प्रोब जोड़ता है जिसे वह इंस्ट्रूमेंट करता है, और:

• JSON लॉग पंक्ति को trace_id और span_id फ़ील्ड मिलते हैं (पंक्ति में पहले से मौजूद फ़ील्ड रखे जाते हैं)। नोड कलेक्टर उन्हें लॉग रिकॉर्ड के अपने ट्रेस फ़ील्ड में ले जाता है, इसलिए Status200 में किसी स्पैन के लॉग एक क्लिक की दूरी पर होते हैं, और किसी लॉग पंक्ति का ट्रेस भी।
• कोई भी दूसरी लॉग पंक्ति बिना बदलाव के, बिना लिंक के इकट्ठा होती है।

helm upgrade status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent --reset-then-reuse-values \
  --set ebpf.logToTraceCorrelation=true

इसके साथ क्रैश होने वाले APM एजेंट#

एनरिचर ऐप के आउटपुट बफ़र को प्रोसेस के अंदर दोबारा लिखता है: जब कोई मेल खाने वाला प्रोसेस write() कॉल करता है, तो OBI मूल बाइट खाली करके एक एनरिच की गई कॉपी लिखता है। जो APM एजेंट LD_PRELOAD से लोड होते हैं और खुद write() को रैप करते हैं, वे इसे नहीं झेल पाते:

.NET ऐप सबसे ज़्यादा जोखिम में हैं: Dynatrace का .NET एजेंट हमेशा LD_PRELOAD से लोड होता है, और Microsoft.Extensions.Logging का कंसोल लॉग अनबफ़र्ड होता है, इसलिए हर पंक्ति यही रास्ता लेती है। Python और Go ऐप आमतौर पर प्रभावित नहीं होते।

इनमें से किसी एजेंट के साथ इसका उपयोग करने के लिए, logEnricher.services को केवल उन पॉड की ओर इंगित करें जिनमें वह एजेंट नहीं है। एनरिचर के पास बाहर रखने का कोई तरीका नहीं है, इसलिए जिन्हें एनरिच करना है उन्हें सूचीबद्ध करें:

ebpf:
  logToTraceCorrelation: true
  logEnricher:
    services:
      # Enrich only pods with the apm-agent=none label
      - service:
          - k8s_pod_labels:
              apm-agent: "none"

या रनटाइम के आधार पर चुनें। Dynatrace की LD_PRELOAD लोडिंग .NET को लक्ष्य करती है, इसलिए केवल Python, Go, Ruby और Node.js को एनरिच करने से इससे बचा जा सकता है:

ebpf:
  logToTraceCorrelation: true
  logEnricher:
    services:
      - service:
          - languages: "python,go,ruby,nodejs"

लॉग JSON और अनबफ़र्ड होने चाहिए#

• केवल JSON पंक्तियों को trace_id मिलता है। लॉगर को JSON फ़ॉर्मैट पर बदलें: structlog, pino, winston, serilog, logback-json, klog --logging-format=json और ऐसे ही।
• बफ़र्ड आउटपुट लिंक तोड़ देता है, क्योंकि तब write() अनुरोध से अलग थ्रेड पर होता है। Python में, PYTHONUNBUFFERED=1 सेट करें। .NET में, स्टार्टअप पर Console.SetOut(new StreamWriter(Console.OpenStandardOutput()) { AutoFlush = true }) कॉल करें; Microsoft.Extensions.Logging का AddConsole() और Serilog के async सिंक काम नहीं करते, Serilog का सादा WriteTo.Console() काम करता है।
• Greenlet, gevent, Tornado और अन्य कस्टम async रनटाइम समर्थित नहीं हैं।

eBPF को ट्यून करना#

यह जाँचने के लिए कि OBI चल रहा है और ट्रैफ़िक देख रहा है:

kubectl get pods -n status200-kubernetes-agent -l component=ebpf-instrument
kubectl logs -n status200-kubernetes-agent -l component=ebpf-instrument --tail=200

निरंतर CPU प्रोफ़ाइलिंग#

OpenTelemetry eBPF Profiler भी हर नोड पर चल सकता है, otel/opentelemetry-collector-ebpf-profiler इमेज के रूप में। यह हर प्रोसेस जो चला रहा है उसका सेकंड में 19 बार सैंपल लेता है, Go, Java, .NET, Python, Ruby, Node.js, PHP, Perl, C, C++ और Rust में, और प्रोफ़ाइल Status200 को भेजता है। वे उत्पाद → प्रदर्शन प्रोफाइल के अंतर्गत, और हर ट्रेस स्पैन पर फ़्लेम ग्राफ़ के रूप में दिखती हैं।

प्रोफ़ाइलिंग डिफ़ॉल्ट रूप से बंद है: इसमें प्रति नोड eBPF इंस्ट्रूमेंटेशन से ज़्यादा CPU और मेमोरी लगती है। इसे --set profiling.enabled=true से चालू करें।

eBPF इंस्ट्रूमेंटेशन भी चालू होने पर (डिफ़ॉल्ट), हर सैंपल में वह ट्रेस होता है जिससे वह जुड़ा है, इसलिए किसी स्पैन का अपना फ़्लेम ग्राफ़ होता है। इसके लिए, चार्ट OBI से चल रहे ट्रेस कॉन्टेक्स्ट को उपलब्ध रखने को कहता है (OTEL_EBPF_BPF_POPULATE_TRACE_CONTEXT=true), जिससे इंस्ट्रूमेंट किए गए ऐप को हर async कॉन्टेक्स्ट स्विच पर थोड़ी लागत आती है। स्पैन से लिंक के बिना फ़्लेम ग्राफ़ के लिए profiling.obiProcessContext=false सेट करें।

प्रोफ़ाइलिंग के लिए Linux 5.10 या बाद का संस्करण, और नोड की प्रोसेस ID वाला विशेषाधिकार वाला पॉड चाहिए: यह GKE Autopilot या EKS Fargate पर नहीं चल सकती, और उनके प्रीसेट इसे बंद रखते हैं। जो नोड खुद कंटेनर हैं, जैसे kind या k3d, उन पर यह प्रोसेस को अलग नहीं कर पाती, और लगभग कोई सैंपल किसी स्पैन से नहीं जुड़ता।

अन्य डेटा संग्रह#

सामान्य विकल्प#

चार्ट का values.yaml हर विकल्प को सूचीबद्ध करता है और समझाता है, और Kubernetes एजेंट फ़िल्टरिंग, सैंपलिंग और डेटा की मात्रा कम रखने को कवर करता है।

अपग्रेड करना#

helm repo update
helm upgrade status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent \
  --reset-then-reuse-values

--reset-then-reuse-values (Helm 3.14 और बाद के संस्करण) आपके सेट किए मान रखता है - प्रीसेट, क्लस्टर का नाम, फ़िल्टर - और बाकी हर मान नए चार्ट से लेता है। इसके बाद कोई भी नया --set जोड़ें। Helm 3.13 या पहले के संस्करण पर, इसके बजाय अपने सेट किए मानों के साथ अपग्रेड करें:

helm repo update
helm get values status200-agent --namespace status200-kubernetes-agent -o yaml > values.yaml && \
  helm upgrade status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent -f values.yaml

--reuse-values से अपग्रेड न करें: यह उस चार्ट के डिफ़ॉल्ट भी रखता है जिससे आप अपग्रेड कर रहे हैं, इसलिए नए चार्ट के डिफ़ॉल्ट, जिनमें उसकी eBPF इमेज भी है, कभी लागू नहीं होते। जब कोई रिलीज़ पुराने चार्ट के डिफ़ॉल्ट पर चलती है, तो इंस्टॉल या अपग्रेड के बाद Helm जो नोट्स प्रिंट करता है, वे एक चेतावनी और उसे ठीक करने वाले कमांड के साथ खत्म होते हैं।

अनइंस्टॉल करना#

helm uninstall status200-agent --namespace status200-kubernetes-agent
kubectl delete namespace status200-kubernetes-agent

समस्या निवारण#

curl -fsSL https://raw.githubusercontent.com/OneUptime/status200/master/HelmChart/Public/kubernetes-agent/troubleshoot.sh \
  | bash -s -- -n status200-kubernetes-agent

helm repo update
helm upgrade status200-agent status200/kubernetes-agent \
  --namespace status200-kubernetes-agent \
  --reset-then-reuse-values \
  --set preset=gke-autopilot

kubectl get pods -n status200-kubernetes-agent
kubectl logs -n status200-kubernetes-agent -l app.kubernetes.io/part-of=oneuptime --tail=200

kubectl logs -n status200-kubernetes-agent -l component=ebpf-instrument --tail=200

helm install status200-agent-ns-a status200/kubernetes-agent \
  --set preset=gke-autopilot \
  --set-json 'namespaceFilters.rules=[{"action":"include","namespaces":["app-a","app-b"],"scopes":["podLogs"]}]' \
  ...

अगले कदम#