કુબરનેટીસ ક્લસ્ટરનું નિરીક્ષણ કરવું: પ્રોમિથિયસની ઝાંખી અને પરિચય

કુબરનેટ્સ મોનિટરિંગના ખ્યાલને ધ્યાનમાં લો, પ્રોમિથિયસ ટૂલથી પરિચિત થાઓ અને ચેતવણી વિશે વાત કરો.

મોનિટરિંગનો વિષય વિશાળ છે, તેને એક લેખમાં ડિસએસેમ્બલ કરી શકાતો નથી. આ ટેક્સ્ટનો હેતુ સાધનો, વિભાવનાઓ અને અભિગમોની ઝાંખી પૂરી પાડવાનો છે.

લેખની સામગ્રી એમાંથી સ્ક્વિઝ છે શાળા "સ્લર્મ" નું ઓપન લેક્ચર. જો તમે સંપૂર્ણ અભ્યાસક્રમ લેવા માંગતા હોવ તો - પરના કોર્સ માટે સાઇન અપ કરો કુબરનેટ્સમાં મોનિટરિંગ અને લોગિંગ ઈન્ફ્રાસ્ટ્રક્ચર.

કુબરનેટ્સ ક્લસ્ટરમાં શું મોનિટર કરવામાં આવે છે

ભૌતિક સર્વરો. જો Kubernetes ક્લસ્ટર તેના સર્વર પર જમાવવામાં આવે છે, તો તમારે તેમના સ્વાસ્થ્ય પર દેખરેખ રાખવાની જરૂર છે. Zabbix આ કાર્ય સંભાળે છે; જો તમે તેની સાથે કામ કરો છો, તો તમારે ના પાડવાની જરૂર નથી, કોઈ તકરાર થશે નહીં. તે Zabbix છે જે અમારા સર્વરની સ્થિતિનું નિરીક્ષણ કરે છે.

ચાલો ક્લસ્ટર સ્તરે મોનિટરિંગ તરફ આગળ વધીએ.

નિયંત્રણ પ્લેન ઘટકો: API, શેડ્યૂલર અને અન્ય. ઓછામાં ઓછું, તમારે ખાતરી કરવાની જરૂર છે કે સર્વર અથવા etcd નું API 0 કરતા વધારે છે. Etcd ઘણા બધા મેટ્રિક્સ પરત કરી શકે છે: ડિસ્ક જેના પર તે સ્પિનિંગ કરે છે તેના દ્વારા, તેના etcd ક્લસ્ટરના સ્વાસ્થ્ય દ્વારા અને અન્ય.

Docker ઘણા સમય પહેલા દેખાયા હતા અને દરેક વ્યક્તિ તેની સમસ્યાઓથી સારી રીતે વાકેફ છે: ઘણા બધા કન્ટેનર ફ્રીઝ અને અન્ય સમસ્યાઓ પેદા કરે છે. તેથી, ડોકર પોતે, સિસ્ટમ તરીકે, ઓછામાં ઓછું ઉપલબ્ધતા માટે પણ નિયંત્રિત હોવું જોઈએ.

ડી.એન.એસ. જો DNS ક્લસ્ટરમાં બંધ થઈ જશે, તો તેના પછી સમગ્ર ડિસ્કવરી સેવા બંધ થઈ જશે, પોડ્સથી પોડ્સ પરના કૉલ્સ કામ કરવાનું બંધ કરશે. મારી પ્રેક્ટિસમાં, આવી કોઈ સમસ્યાઓ ન હતી, પરંતુ આનો અર્થ એ નથી કે DNS ની સ્થિતિનું નિરીક્ષણ કરવાની જરૂર નથી. વિનંતી લેટન્સી અને કેટલાક અન્ય મેટ્રિક્સ CoreDNS પર ટ્રૅક કરી શકાય છે.

પ્રવેશ. પ્રોજેક્ટના એન્ટ્રી પોઈન્ટ તરીકે પ્રવેશની ઉપલબ્ધતા (ઈન્ગ્રેસ કંટ્રોલર સહિત)ને નિયંત્રિત કરવી જરૂરી છે.

ક્લસ્ટરના મુખ્ય ઘટકોને તોડી પાડવામાં આવ્યા છે - હવે ચાલો એબ્સ્ટ્રેક્શનના સ્તર પર જઈએ.

એવું લાગે છે કે એપ્લિકેશનો પોડ્સમાં ચાલે છે, જેનો અર્થ છે કે તેમને નિયંત્રિત કરવાની જરૂર છે, પરંતુ વાસ્તવમાં તે નથી. શીંગો ક્ષણિક છે: આજે તેઓ એક સર્વર પર ચાલે છે, કાલે બીજા પર; આજે તેમાંના 10 છે, આવતીકાલે 2. તેથી, કોઈ પણ શીંગો પર નજર રાખતું નથી. માઇક્રોસર્વિસ આર્કિટેક્ચરની અંદર, સંપૂર્ણ રીતે એપ્લિકેશનની ઉપલબ્ધતાને નિયંત્રિત કરવી વધુ મહત્વપૂર્ણ છે. ખાસ કરીને, સેવાના અંતિમ બિંદુઓની ઉપલબ્ધતા તપાસો: શું કંઈ કામ કરે છે? જો એપ્લિકેશન ઉપલબ્ધ છે, તો તેની પાછળ શું થાય છે, હવે કેટલી પ્રતિકૃતિઓ છે - આ બીજા ક્રમના પ્રશ્નો છે. વ્યક્તિગત ઉદાહરણો પર દેખરેખ રાખવાની જરૂર નથી.

છેલ્લા સ્તરે, તમારે એપ્લિકેશનના સંચાલનને નિયંત્રિત કરવાની જરૂર છે, વ્યવસાય મેટ્રિક્સ લેવાની જરૂર છે: ઓર્ડરની સંખ્યા, વપરાશકર્તા વર્તન, વગેરે.

પ્રોમિથિયસ

ક્લસ્ટરની દેખરેખ માટે શ્રેષ્ઠ સિસ્ટમ છે પ્રોમિથિયસ. ગુણવત્તા અને ઉપયોગમાં સરળતાના સંદર્ભમાં પ્રોમિથિયસ સાથે મેળ ખાતી હોય તેવું કોઈ સાધન મને ખબર નથી. તે લવચીક ઈન્ફ્રાસ્ટ્રક્ચર માટે ઉત્તમ છે, તેથી જ્યારે તેઓ કહે છે કે "કુબરનેટ્સ મોનિટરિંગ", ત્યારે તેનો અર્થ સામાન્ય રીતે પ્રોમિથિયસ થાય છે.

પ્રોમિથિયસ સાથે પ્રારંભ કરવા માટે કેટલાક વિકલ્પો છે: હેલ્મનો ઉપયોગ કરીને, તમે નિયમિત પ્રોમિથિયસ અથવા પ્રોમિથિયસ ઓપરેટર ઇન્સ્ટોલ કરી શકો છો.

1. નિયમિત પ્રોમિથિયસ. તેની સાથે બધું બરાબર છે, પરંતુ તમારે ConfigMap ને રૂપરેખાંકિત કરવાની જરૂર છે - વાસ્તવમાં, ટેક્સ્ટ-આધારિત રૂપરેખાંકન ફાઇલો લખો, જેમ કે અમે માઇક્રોસર્વિસ આર્કિટેક્ચર પહેલાં કર્યું હતું.
2. પ્રોમિથિયસ ઓપરેટર થોડો વધુ ફેલાયેલો છે, આંતરિક તર્કની દ્રષ્ટિએ થોડો વધુ જટિલ છે, પરંતુ તેની સાથે કામ કરવું વધુ સરળ છે: ત્યાં અલગ પદાર્થો છે, ક્લસ્ટરમાં અમૂર્તતા ઉમેરવામાં આવે છે, તેથી તે નિયંત્રિત કરવા અને ગોઠવવા માટે વધુ અનુકૂળ છે.

ઉત્પાદનને સમજવા માટે, હું પહેલા નિયમિત પ્રોમિથિયસ ઇન્સ્ટોલ કરવાની ભલામણ કરું છું. તમારે રૂપરેખા દ્વારા બધું રૂપરેખાંકિત કરવું પડશે, પરંતુ આ ફાયદાકારક રહેશે: તમે સમજી શકશો કે શું છે અને તે કેવી રીતે ગોઠવેલ છે. પ્રોમિથિયસ ઓપરેટરમાં, તમે તુરંત જ અમૂર્તતાની ઊંચાઈ પર જાઓ છો, જો કે તમે ઈચ્છો તો ઊંડાણમાં પણ જઈ શકો છો.

પ્રોમિથિયસ કુબરનેટ્સ સાથે સારી રીતે સંકલિત છે: તે API સર્વરને ઍક્સેસ કરી શકે છે અને તેની સાથે ક્રિયાપ્રતિક્રિયા કરી શકે છે.

પ્રોમિથિયસ લોકપ્રિય છે અને મોટી સંખ્યામાં એપ્લિકેશન્સ અને પ્રોગ્રામિંગ ભાષાઓ દ્વારા સપોર્ટેડ છે. સપોર્ટની જરૂર છે કારણ કે પ્રોમિથિયસનું પોતાનું મેટ્રિક્સ ફોર્મેટ છે, અને તેને સ્થાનાંતરિત કરવા માટે તમારે એપ્લિકેશનની અંદર લાઇબ્રેરી અથવા તૈયાર નિકાસકારની જરૂર છે. અને આવા ઘણા બધા નિકાસકારો છે. ઉદાહરણ તરીકે, PostgreSQL એક્સપોર્ટર છે: તે PostgreSQL માંથી ડેટા લે છે અને તેને પ્રોમિથિયસ ફોર્મેટમાં રૂપાંતરિત કરે છે જેથી કરીને પ્રોમિથિયસ તેની સાથે કામ કરી શકે.

પ્રોમિથિયસ આર્કિટેક્ચર

પ્રોમિથિયસ સર્વર પાછળનો છેડો, પ્રોમિથિયસનું મગજ છે. મેટ્રિક્સ અહીં સંગ્રહિત અને પ્રક્રિયા કરવામાં આવે છે.

મેટ્રિક્સ સમય શ્રેણી ડેટાબેઝ (TSDB) માં સંગ્રહિત થાય છે. TSDB એ અલગ ડેટાબેઝ નથી, પરંતુ ગો ભાષામાં એક પેકેજ છે જે પ્રોમિથિયસમાં જડિત છે. આશરે કહીએ તો, બધું એક બાઈનરીમાં છે.

TSDB માં લાંબા સમય સુધી ડેટા સ્ટોર કરશો નહીં

પ્રોમિથિયસ ઈન્ફ્રાસ્ટ્રક્ચર મેટ્રિક્સના લાંબા ગાળાના સંગ્રહ માટે યોગ્ય નથી. ડિફોલ્ટ રીટેન્શન અવધિ 15 દિવસ છે. તમે આ મર્યાદાને ઓળંગી શકો છો, પરંતુ ધ્યાનમાં રાખો: તમે TSDBમાં જેટલો વધુ ડેટા સ્ટોર કરશો અને જેટલો લાંબો સમય તમે તેને કરશો, તેટલા વધુ સંસાધનોનો તે વપરાશ કરશે. પ્રોમિથિયસમાં ઐતિહાસિક માહિતી સંગ્રહિત કરવી એ ખરાબ પ્રથા માનવામાં આવે છે.

જો તમારી પાસે વિશાળ ટ્રાફિક હોય, તો મેટ્રિક્સની સંખ્યા સેકન્ડ દીઠ હજારોની સંખ્યામાં છે, તો પછી ડિસ્ક સ્પેસ અથવા અવધિ દ્વારા તેમના સ્ટોરેજને મર્યાદિત કરવું વધુ સારું છે. સામાન્ય રીતે, TSDB “હોટ ડેટા” સ્ટોર કરે છે, મેટ્રિક્સ શાબ્દિક રીતે થોડા કલાકો માટે. લાંબા ગાળાના સ્ટોરેજ માટે, તે ડેટાબેસેસમાં બાહ્ય સ્ટોરેજનો ઉપયોગ કરવામાં આવે છે જે ખરેખર આ માટે યોગ્ય છે, ઉદાહરણ તરીકે InfluxDB, ClickHouse અને તેથી વધુ. મેં ક્લિકહાઉસ વિશે વધુ સારી સમીક્ષાઓ જોઈ.

પ્રોમિથિયસ સર્વર મોડેલ મુજબ કામ કરે છે ખેંચો: તે અમે તેને આપેલા અંતિમ બિંદુઓ માટે મેટ્રિક્સ માટે જાય છે. તેઓએ કહ્યું: “API સર્વર પર જાઓ”, અને તે ત્યાં દર n-મી સેકન્ડે જાય છે અને મેટ્રિક્સ લે છે.

ટૂંકા જીવનકાળ (નોકરી અથવા ક્રોન જોબ) સાથેના ઑબ્જેક્ટ્સ માટે જે સ્ક્રેપિંગ સમયગાળા વચ્ચે દેખાઈ શકે છે, ત્યાં પુશગેટવે ઘટક છે. ટૂંકા ગાળાના ઑબ્જેક્ટ્સમાંથી મેટ્રિક્સ તેમાં ધકેલવામાં આવે છે: જોબ વધી ગઈ છે, ક્રિયા કરી છે, મેટ્રિક્સ પુશગેટવે પર મોકલવામાં આવી છે અને પૂર્ણ થઈ ગઈ છે. થોડા સમય પછી, પ્રોમિથિયસ તેની પોતાની ગતિએ નીચે આવશે અને પુશગેટવેમાંથી આ મેટ્રિક્સ પસંદ કરશે.

પ્રોમિથિયસમાં સૂચનાઓને ગોઠવવા માટે એક અલગ ઘટક છે - ચેતવણી વ્યવસ્થાપક. અને ચેતવણીના નિયમો. ઉદાહરણ તરીકે, જો સર્વર API 0 હોય તો તમારે ચેતવણી બનાવવાની જરૂર છે. જ્યારે ઇવેન્ટ ટ્રિગર થાય છે, ત્યારે ચેતવણી વધુ મોકલવા માટે ચેતવણી મેનેજરને મોકલવામાં આવે છે. એલર્ટ મેનેજર પાસે એકદમ લવચીક રૂટીંગ સેટિંગ્સ છે: ચેતવણીઓનું એક જૂથ એડમિન્સની ટેલિગ્રામ ચેટમાં, બીજું ડેવલપર્સની ચેટમાં અને ત્રીજું ઇન્ફ્રાસ્ટ્રક્ચર વર્કર્સની ચેટમાં મોકલી શકાય છે. Slack, Telegram, email અને અન્ય ચેનલો પર સૂચનાઓ મોકલી શકાય છે.

અને અંતે, હું તમને પ્રોમિથિયસ કિલર લક્ષણ વિશે કહીશ - ડિસ્કવરિંગ. પ્રોમિથિયસ સાથે કામ કરતી વખતે, તમારે દેખરેખ માટે ઑબ્જેક્ટ્સના ચોક્કસ સરનામાંનો ઉલ્લેખ કરવાની જરૂર નથી, તે તેમના પ્રકારને સેટ કરવા માટે પૂરતું છે. એટલે કે, તમારે "અહીં IP સરનામું છે, અહીં પોર્ટ છે - મોનિટર" લખવાની જરૂર નથી, તેના બદલે, તમારે આ ઑબ્જેક્ટ્સને શોધવા માટે કયા સિદ્ધાંતો દ્વારા નક્કી કરવાની જરૂર છે (લક્ષ્યો - ગોલ). પ્રોમિથિયસ પોતે, જે ઑબ્જેક્ટ્સ હાલમાં સક્રિય છે તેના આધારે, જરૂરી વસ્તુઓ ખેંચે છે અને તેમને મોનિટરિંગમાં ઉમેરે છે.

આ અભિગમ કુબરનેટ્સ સ્ટ્રક્ચર સાથે સારી રીતે બંધબેસે છે, જ્યાં બધું પણ તરતું રહે છે: આજે 10 સર્વર છે, આવતીકાલે 3. દરેક વખતે સર્વરનું IP સરનામું સ્પષ્ટ ન કરવા માટે, તેઓએ તેને કેવી રીતે શોધવું તે એકવાર લખ્યું - અને ડિસ્કવરિંગ તે કરશે .

પ્રોમિથિયસ ભાષા કહેવાય છે પ્રોમક્યુએલ. આ ભાષાનો ઉપયોગ કરીને, તમે ચોક્કસ મેટ્રિક્સના મૂલ્યો મેળવી શકો છો અને પછી તેમને કન્વર્ટ કરી શકો છો, તેના આધારે વિશ્લેષણાત્મક ગણતરીઓ બનાવી શકો છો.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

પ્રોમિથિયસ વેબ ઈન્ટરફેસ

પ્રોમિથિયસનું પોતાનું, એકદમ ન્યૂનતમ વેબ ઈન્ટરફેસ છે. માત્ર ડીબગ અથવા પ્રદર્શન માટે યોગ્ય.

એક્સપ્રેશન લાઇનમાં, તમે PromQL ભાષામાં ક્વેરી લખી શકો છો.

ચેતવણીઓ ટેબમાં ચેતવણીના નિયમો હોય છે, અને તેમની ત્રણ સ્થિતિઓ હોય છે:

1. નિષ્ક્રિય - જો આ ક્ષણે ચેતવણી સક્રિય નથી, એટલે કે, તેની સાથે બધું બરાબર છે, અને તે કામ કરતું નથી;
2. બાકી - આ છે જો ચેતવણી કામ કરે છે, પરંતુ મોકલવાનું હજી પસાર થયું નથી. વિલંબ નેટવર્ક ઝબકવા માટે વળતર આપવા માટે સેટ છે: જો ઉલ્લેખિત સેવા એક મિનિટની અંદર વધી ગઈ હોય, તો એલાર્મ હજુ સુધી વગાડવો જોઈએ નહીં;
3. ફાયરિંગ એ ત્રીજી સ્થિતિ છે જ્યારે એલર્ટ લાઇટ થાય છે અને સંદેશા મોકલે છે.

સ્ટેટસ મેનૂમાં તમને પ્રોમિથિયસ શું છે તે વિશેની માહિતીની ઍક્સેસ મળશે. લક્ષ્યો (લક્ષ્યો) માં સંક્રમણ પણ છે, જેના વિશે આપણે ઉપર વાત કરી છે.

પ્રોમિથિયસ ઇન્ટરફેસની વધુ વિગતવાર ઝાંખી માટે, જુઓ કુબરનેટીસ ક્લસ્ટરની દેખરેખ પર સ્લર્મના વ્યાખ્યાનમાં.

Grafana સાથે એકીકરણ

પ્રોમિથિયસ વેબ ઈન્ટરફેસમાં, તમને સુંદર અને સમજી શકાય તેવા આલેખ મળશે નહીં કે જેનાથી તમે ક્લસ્ટરની સ્થિતિ વિશે કોઈ નિષ્કર્ષ દોરી શકો. તેમને બનાવવા માટે, પ્રોમિથિયસ ગ્રાફના સાથે સંકલિત છે. અમને આવા ડેશબોર્ડ મળે છે.

પ્રોમિથિયસ અને ગ્રાફનાના એકીકરણને સેટ કરવું બિલકુલ મુશ્કેલ નથી; સૂચનાઓ દસ્તાવેજોમાં મળી શકે છે: પ્રોમિથિયસ માટે ગ્રાફના સપોર્ટસારું, હું આ સાથે સમાપ્ત કરીશ.

નીચેના લેખોમાં અમે મોનિટરિંગનો વિષય ચાલુ રાખીશું: અમે ગ્રાફના લોકી અને વૈકલ્પિક સાધનોનો ઉપયોગ કરીને લોગ એકત્રિત કરવા અને તેનું વિશ્લેષણ કરવા વિશે વાત કરીશું.

લેખક: માર્સેલ ઇબ્રાએવ, પ્રમાણિત કુબરનેટ્સ એડમિનિસ્ટ્રેટર, કંપનીમાં પ્રેક્ટિસ એન્જિનિયર સાઉથબ્રીજ, સ્પીકર અને સ્લર્મ કોર્સ ડેવલપર.

સોર્સ: www.habr.com