আমরা কীভাবে প্রমিথিউস, ক্লিকহাউস এবং ইএলকে-তে পর্যবেক্ষণ তৈরি করেছি

আমার নাম আন্তন বাদেরিন। আমি হাই টেকনোলজি সেন্টারে কাজ করি এবং সিস্টেম অ্যাডমিনিস্ট্রেশন করি। এক মাস আগে, আমাদের কর্পোরেট সম্মেলন শেষ হয়েছে, যেখানে আমরা আমাদের শহরের আইটি সম্প্রদায়ের সাথে আমাদের সঞ্চিত অভিজ্ঞতা শেয়ার করেছি। আমি ওয়েব অ্যাপ্লিকেশন নিরীক্ষণ সম্পর্কে কথা বলেছি. উপাদানটি জুনিয়র বা মধ্যম স্তরের জন্য উদ্দেশ্যে করা হয়েছিল, যারা স্ক্র্যাচ থেকে এই প্রক্রিয়াটি তৈরি করেনি।

যেকোন মনিটরিং সিস্টেমের ভিত্তি হল ব্যবসায়িক সমস্যার সমাধান। মনিটরিংয়ের খাতিরে মনিটরিং করাটা কারোরই আগ্রহের বিষয় নয়। ব্যবসা কি চায়? যাতে সবকিছু দ্রুত এবং ত্রুটি ছাড়াই কাজ করে। ব্যবসাগুলি সক্রিয় হতে চায়, যাতে আমরা নিজেরাই পরিষেবাতে সমস্যাগুলি চিহ্নিত করি এবং যত তাড়াতাড়ি সম্ভব সেগুলি সমাধান করি৷ আসলে, এই সমস্যাগুলি যা আমি গত বছর আমাদের একজন গ্রাহকের জন্য একটি প্রকল্পে সমাধান করেছি।

প্রকল্প সম্পর্কে

প্রকল্পটি দেশের বৃহত্তম লয়্যালটি প্রোগ্রামগুলির মধ্যে একটি। আমরা বোনাস কার্ডের মতো বিভিন্ন মার্কেটিং টুলের মাধ্যমে বিক্রয়ের ফ্রিকোয়েন্সি বাড়াতে খুচরা চেইনকে সাহায্য করি। মোট, প্রকল্পটিতে 14টি অ্যাপ্লিকেশন রয়েছে যা দশটি সার্ভারে চলে।

ইন্টারভিউ প্রক্রিয়া চলাকালীন, আমি বারবার লক্ষ্য করেছি যে প্রশাসকরা সর্বদা সঠিকভাবে ওয়েব অ্যাপ্লিকেশনগুলি পর্যবেক্ষণ করেন না: অনেকে এখনও অপারেটিং সিস্টেম মেট্রিক্সের উপর ফোকাস করে এবং মাঝে মাঝে পরিষেবাগুলি নিরীক্ষণ করে।

আমার ক্ষেত্রে, গ্রাহকের মনিটরিং সিস্টেম পূর্বে Icinga উপর ভিত্তি করে ছিল। এটি কোনোভাবেই উপরের সমস্যাগুলোর সমাধান করেনি। প্রায়শই ক্লায়েন্ট নিজেই আমাদের সমস্যা সম্পর্কে অবহিত করেন এবং প্রায়শই না, কারণটির নীচে যাওয়ার জন্য আমাদের কাছে পর্যাপ্ত ডেটা ছিল না।

উপরন্তু, এর আরও বিকাশের অসারতা সম্পর্কে একটি স্পষ্ট বোঝা ছিল। আমি মনে করি যারা আইসিঙ্গার সাথে পরিচিত তারা আমাকে বুঝতে পারবেন। সুতরাং, আমরা প্রকল্পের জন্য ওয়েব অ্যাপ্লিকেশন মনিটরিং সিস্টেমটিকে সম্পূর্ণরূপে পুনরায় ডিজাইন করার সিদ্ধান্ত নিয়েছি।

প্রমিথিউস

আমরা তিনটি প্রধান সূচকের উপর ভিত্তি করে প্রমিথিউসকে বেছে নিয়েছি:

1. উপলব্ধ মেট্রিক একটি বিশাল সংখ্যা. আমাদের ক্ষেত্রে তাদের সংখ্যা 60 হাজার। অবশ্যই, এটা লক্ষণীয় যে আমরা তাদের বিশাল সংখ্যাগরিষ্ঠ (সম্ভবত প্রায় 95%) ব্যবহার করি না। অন্যদিকে, তারা সব তুলনামূলকভাবে সস্তা। আমাদের জন্য, এটি পূর্বে ব্যবহৃত আইসিঙ্গার তুলনায় অন্য চরম। এটিতে, মেট্রিক্স যোগ করা একটি বিশেষ ব্যথা ছিল: বিদ্যমানগুলি ব্যয়বহুল ছিল (যেকোন প্লাগইনের উত্স কোডটি দেখুন)। যেকোন প্লাগইন ছিল ব্যাশ বা পাইথনের একটি স্ক্রিপ্ট, যেটির লঞ্চ খরচ সম্পদের পরিপ্রেক্ষিতে ব্যয়বহুল।
2. এই সিস্টেমটি তুলনামূলকভাবে অল্প পরিমাণ সম্পদ গ্রহণ করে। 600 MB RAM, একটি কোরের 15% এবং কয়েক ডজন IOPS আমাদের সমস্ত মেট্রিক্সের জন্য যথেষ্ট। অবশ্যই, আপনাকে মেট্রিক্স রপ্তানিকারকদের চালাতে হবে, কিন্তু তারা সবই Go-তে লেখা আছে এবং খুব বেশি পাওয়ার ক্ষুধার্তও নয়। আমি মনে করি না যে আধুনিক বাস্তবতায় এটি একটি সমস্যা।
3. কুবারনেটে স্থানান্তরিত করার ক্ষমতা প্রদান করে। গ্রাহকের পরিকল্পনা বিবেচনা করে, পছন্দ সুস্পষ্ট।

ELK

পূর্বে, আমরা লগ সংগ্রহ বা প্রক্রিয়া করিনি। ত্রুটিগুলি সবার কাছে পরিষ্কার। আমরা ELK বেছে নিয়েছি কারণ আমাদের ইতিমধ্যে এই সিস্টেমের সাথে অভিজ্ঞতা ছিল। আমরা সেখানে শুধুমাত্র অ্যাপ্লিকেশন লগ সঞ্চয়. প্রধান নির্বাচনের মানদণ্ড ছিল পূর্ণ-পাঠ্য অনুসন্ধান এবং এর গতি।

স্লিকহাউস

প্রাথমিকভাবে, পছন্দটি ইনফ্লাক্সডিবি-তে পড়েছিল। আমরা Nginx লগ, pg_stat_statements থেকে পরিসংখ্যান সংগ্রহ এবং প্রমিথিউসের ঐতিহাসিক তথ্য সংরক্ষণ করার প্রয়োজনীয়তা উপলব্ধি করেছি। আমরা ইনফ্লাক্স পছন্দ করিনি কারণ এটি পর্যায়ক্রমে প্রচুর পরিমাণে মেমরি গ্রাস করতে শুরু করে এবং ক্র্যাশ করে। উপরন্তু, আমি remote_addr দ্বারা গ্রুপ প্রশ্ন করতে চেয়েছিলাম, কিন্তু এই DBMS-এ গ্রুপিং শুধুমাত্র ট্যাগ দ্বারা। ট্যাগগুলি ব্যয়বহুল (মেমরি), তাদের সংখ্যা শর্তসাপেক্ষে সীমিত।

আমরা আবার অনুসন্ধান শুরু করলাম। কি প্রয়োজন ছিল ন্যূনতম সম্পদ খরচ সহ একটি বিশ্লেষণাত্মক ডাটাবেস, বিশেষত ডিস্কে ডেটা কম্প্রেশন সহ।

Clickhouse এই সমস্ত মানদণ্ড পূরণ করে, এবং আমরা আমাদের পছন্দের জন্য কখনোই অনুশোচনা করিনি। আমরা এতে কোনও অসাধারণ পরিমাণ ডেটা লিখি না (সন্নিবেশের সংখ্যা প্রতি মিনিটে প্রায় পাঁচ হাজার)।

NewRelic

NewRelic ঐতিহাসিকভাবে আমাদের সাথে ছিল কারণ এটি গ্রাহকের পছন্দ ছিল। আমরা এটি একটি এপিএম হিসাবে ব্যবহার করি।

Zabbix

আমরা বিভিন্ন API-এর ব্ল্যাক বক্স নিরীক্ষণ করতে একচেটিয়াভাবে Zabbix ব্যবহার করি।

একটি পর্যবেক্ষণ পদ্ধতি সংজ্ঞায়িত করা

আমরা কাজটি পচন করতে চেয়েছিলাম এবং এর ফলে পর্যবেক্ষণের পদ্ধতিকে সুশৃঙ্খল করতে চেয়েছিলাম।

এটি করার জন্য, আমি আমাদের সিস্টেমকে নিম্নলিখিত স্তরগুলিতে বিভক্ত করেছি:

• হার্ডওয়্যার এবং ভিএমএস;
• অপারেটিং সিস্টেম;
• সিস্টেম পরিষেবা, সফ্টওয়্যার স্ট্যাক;
• আবেদন
• ব্যবসায়িক যুক্তি।

কেন এই পদ্ধতিটি সুবিধাজনক:

• আমরা জানি প্রতিটি স্তরের কাজের জন্য কারা দায়ী এবং এর ভিত্তিতে আমরা সতর্কতা পাঠাতে পারি;
• সতর্কতা দমন করার সময় আমরা কাঠামোটি ব্যবহার করতে পারি - যখন ভার্চুয়াল মেশিন সম্পূর্ণরূপে অনুপলব্ধ থাকে তখন ডাটাবেসের অনুপলব্ধতা সম্পর্কে একটি সতর্কতা প্রেরণ করা অদ্ভুত হবে।

যেহেতু আমাদের কাজ হল সিস্টেমের ক্রিয়াকলাপে লঙ্ঘনগুলি চিহ্নিত করা, তাই আমাদের অবশ্যই প্রতিটি স্তরে মেট্রিক্সের একটি নির্দিষ্ট সেট হাইলাইট করতে হবে যা সতর্ক করার নিয়মগুলি লেখার সময় মনোযোগ দেওয়ার মতো। এর পরে, আসুন "ভিএমএস", "অপারেটিং সিস্টেম" এবং "সিস্টেম পরিষেবা, সফ্টওয়্যার স্ট্যাক" স্তরগুলির মধ্য দিয়ে যাওয়া যাক।

ভার্চুয়াল মেশিন

হোস্টিং আমাদের একটি প্রসেসর, ডিস্ক, মেমরি এবং নেটওয়ার্ক বরাদ্দ করে। এবং প্রথম দুটি নিয়ে আমাদের সমস্যা ছিল। সুতরাং, মেট্রিক্স:

সিপিইউ চুরির সময় - আপনি যখন অ্যামাজনে একটি ভার্চুয়াল মেশিন কিনবেন (উদাহরণস্বরূপ, t2.micro), আপনার বোঝা উচিত যে আপনাকে একটি সম্পূর্ণ প্রসেসর কোর বরাদ্দ করা হয়নি, তবে এটির সময়ের একটি কোটা। এবং যখন আপনি এটি নিঃশেষ করে দেবেন, প্রসেসরটি আপনার কাছ থেকে কেড়ে নেওয়া হবে।

এই মেট্রিক আপনাকে এই ধরনের মুহূর্তগুলি ট্র্যাক করতে এবং সিদ্ধান্ত নিতে দেয়। উদাহরণস্বরূপ, একটি মোটা শুল্ক নেওয়া বা বিভিন্ন সার্ভারে ব্যাকগ্রাউন্ড টাস্ক এবং API অনুরোধগুলির প্রক্রিয়াকরণ বিতরণ করা কি প্রয়োজন?

IOPS + CPU iowait সময় - কিছু কারণে, অনেক ক্লাউড হোস্টিং পর্যাপ্ত IOPS প্রদান না করে পাপ করে। অধিকন্তু, কম IOPS সহ একটি সময়সূচী তাদের পক্ষে যুক্তি নয়। অতএব, এটি CPU iowait সংগ্রহ মূল্য. এই জোড়া গ্রাফের সাথে - কম IOPS এবং উচ্চ I/O অপেক্ষার সাথে - আপনি ইতিমধ্যেই হোস্টিংয়ের সাথে কথা বলতে পারেন এবং সমস্যার সমাধান করতে পারেন।

অপারেটিং সিস্টেম

অপারেটিং সিস্টেম মেট্রিক্স:

• %-এ উপলব্ধ মেমরির পরিমাণ;
• অদলবদল ব্যবহার কার্যকলাপ: vmstat swapin, swapout;
• %-এ ফাইল সিস্টেমে উপলব্ধ ইনোড এবং ফাঁকা স্থানের সংখ্যা
• গড় লোড;
• দুই রাজ্যে সংযোগের সংখ্যা;
• conntrack টেবিল পূর্ণতা;
• ss ইউটিলিটি, iproute2 প্যাকেজ ব্যবহার করে নেটওয়ার্কের গুণমান পর্যবেক্ষণ করা যেতে পারে - এর আউটপুট থেকে RTT সংযোগের একটি সূচক পান এবং এটিকে গন্তব্য পোর্ট দ্বারা গোষ্ঠীভুক্ত করুন।

এছাড়াও অপারেটিং সিস্টেম স্তরে আমাদের প্রসেস হিসাবে একটি সত্তা আছে। সিস্টেমে প্রক্রিয়াগুলির একটি সেট সনাক্ত করা গুরুত্বপূর্ণ যা এটির ক্রিয়াকলাপে গুরুত্বপূর্ণ ভূমিকা পালন করে। যদি, উদাহরণস্বরূপ, আপনার বেশ কয়েকটি pgpool আছে, তাহলে আপনাকে তাদের প্রত্যেকের জন্য তথ্য সংগ্রহ করতে হবে।

মেট্রিক্সের সেটটি নিম্নরূপ:

• সিপিইউ;
• স্মৃতি প্রাথমিকভাবে বাসিন্দা;
• IO - বিশেষত IOPS এ;
• FileFd - খোলা এবং সীমা;
• উল্লেখযোগ্য পৃষ্ঠা ব্যর্থতা - এইভাবে আপনি বুঝতে পারবেন কোন প্রক্রিয়াটি অদলবদল করা হচ্ছে।

আমরা ডকারে সমস্ত মনিটরিং স্থাপন করি এবং মেট্রিক্স ডেটা সংগ্রহ করতে আমরা উপদেষ্টা ব্যবহার করি। অন্যান্য মেশিনে আমরা প্রক্রিয়া-রপ্তানিকারক ব্যবহার করি।

সিস্টেম পরিষেবা, সফ্টওয়্যার স্ট্যাক

প্রতিটি অ্যাপ্লিকেশনের নিজস্ব সুনির্দিষ্ট বৈশিষ্ট্য রয়েছে এবং মেট্রিক্সের একটি নির্দিষ্ট সেটকে একক করা কঠিন।

সার্বজনীন সেট হল:

• অনুরোধের হার;
• ভুল সংখ্যা;
• বিলম্ব
• স্যাচুরেশন

এই স্তরে নিরীক্ষণের আমাদের সবচেয়ে আকর্ষণীয় উদাহরণ হল Nginx এবং PostgreSQL।

আমাদের সিস্টেমে সবচেয়ে লোড করা পরিষেবা হল ডাটাবেস। অতীতে, ডাটাবেস কী করছে তা খুঁজে বের করতে আমাদের প্রায়ই সমস্যা হতো।

আমরা ডিস্কগুলিতে একটি উচ্চ লোড দেখেছি, কিন্তু ধীর লগগুলি সত্যিই কিছু দেখায়নি। আমরা pg_stat_statements ব্যবহার করে এই সমস্যার সমাধান করেছি, একটি ভিউ যা ক্যোয়ারী পরিসংখ্যান সংগ্রহ করে।

এই সব অ্যাডমিন প্রয়োজন.

আমরা পড়ার এবং লেখার অনুরোধের কার্যকলাপের গ্রাফ তৈরি করি:

সবকিছু সহজ এবং পরিষ্কার, প্রতিটি অনুরোধের নিজস্ব রঙ আছে।

একটি সমান আকর্ষণীয় উদাহরণ হল Nginx লগ। এটা আশ্চর্যের কিছু নয় যে খুব কম লোকই সেগুলিকে বিশ্লেষণ করে বা তাদের অবশ্যই থাকা-খাওয়ার তালিকায় উল্লেখ করে৷ আদর্শ বিন্যাস খুব তথ্যপূর্ণ নয় এবং প্রসারিত করা প্রয়োজন।

ব্যক্তিগতভাবে, আমি request_time, upstream_response_time, body_bytes_sent, request_length, request_id যোগ করেছি। আমরা প্রতিক্রিয়ার সময় এবং ত্রুটির সংখ্যা প্লট করি:

আমরা প্রতিক্রিয়ার সময় এবং ত্রুটির সংখ্যার গ্রাফ তৈরি করি। মনে আছে? আমি কি ব্যবসার উদ্দেশ্য নিয়ে কথা বলেছি? দ্রুত এবং ত্রুটি ছাড়া? আমরা ইতিমধ্যে দুটি চার্ট দিয়ে এই সমস্যাগুলি কভার করেছি। এবং আপনি ইতিমধ্যেই তাদের ব্যবহার করে প্রশাসকদের দায়িত্বে কল করতে পারেন।

তবে আরও একটি সমস্যা থেকে যায় - ঘটনার কারণগুলির দ্রুত নির্মূল নিশ্চিত করা।

ঘটনার সমাধান

একটি সমস্যা সনাক্তকরণ থেকে সমাধান করার পুরো প্রক্রিয়াটিকে কয়েকটি ধাপে ভাগ করা যেতে পারে:

• সমস্যা চিহ্নিত করা;
• ডিউটি ​​অ্যাডমিনিস্ট্রেটরের কাছে বিজ্ঞপ্তি;
• একটি ঘটনার প্রতিক্রিয়া;
• কারণ নির্মূল।

এটা গুরুত্বপূর্ণ যে আমরা যত তাড়াতাড়ি সম্ভব এটি করতে হবে। এবং যদি একটি সমস্যা চিহ্নিত করার এবং একটি বিজ্ঞপ্তি পাঠানোর পর্যায়ে আমরা খুব বেশি সময় লাভ করতে না পারি - যে কোনও ক্ষেত্রেই তাদের জন্য দুই মিনিট ব্যয় করা হবে, তবে পরবর্তীগুলি কেবল উন্নতির জন্য খালি খালি।

কল্পনা করা যাক যে ডিউটি ​​অফিসারের ফোন বেজে উঠল। সে কি করবে? প্রশ্নগুলির উত্তর সন্ধান করুন - কী ভেঙেছে, কোথায় ভেঙেছে, কীভাবে প্রতিক্রিয়া করবেন? এখানে আমরা এই প্রশ্নের উত্তর কিভাবে:

আমরা কেবল বিজ্ঞপ্তির পাঠ্যে এই সমস্ত তথ্য অন্তর্ভুক্ত করি, এটিকে একটি উইকি পৃষ্ঠার একটি লিঙ্ক দিন যা বর্ণনা করে যে কীভাবে এই সমস্যাটির প্রতিক্রিয়া জানাতে হয়, কীভাবে এটি সমাধান করা যায় এবং এটিকে বাড়িয়ে তোলে।

আমি এখনও অ্যাপ্লিকেশন স্তর এবং ব্যবসায়িক যুক্তি সম্পর্কে কিছু বলিনি। দুর্ভাগ্যবশত, আমাদের অ্যাপ্লিকেশনগুলি এখনও মেট্রিক্স সংগ্রহ বাস্তবায়ন করে না। এই স্তরগুলি থেকে যেকোনো তথ্যের একমাত্র উৎস হল লগ।

পয়েন্ট একটি দম্পতি.

প্রথমত, কাঠামোবদ্ধ লগ লিখুন। বার্তার পাঠ্যে প্রসঙ্গ অন্তর্ভুক্ত করার দরকার নেই। এটি তাদের গ্রুপ করা এবং বিশ্লেষণ করা কঠিন করে তোলে। এই সব স্বাভাবিক করতে Logstash অনেক সময় নেয়।

দ্বিতীয়ত, তীব্রতার মাত্রা সঠিকভাবে ব্যবহার করুন। প্রতিটি ভাষার নিজস্ব মান আছে। ব্যক্তিগতভাবে, আমি চারটি স্তর আলাদা করি:

1. কোন ত্রুটি নেই;
2. ক্লায়েন্ট সাইড ত্রুটি;
3. ভুল আমাদের পক্ষে, আমরা অর্থ হারাবো না, আমরা ঝুঁকি বহন করি না;
4. ভুল আমাদের পক্ষে, আমরা অর্থ হারাই।

আমাকে সংক্ষিপ্ত করা যাক. আপনাকে ব্যবসায়িক যুক্তির উপর ভিত্তি করে মনিটরিং তৈরি করার চেষ্টা করতে হবে। অ্যাপ্লিকেশনটি নিজেই নিরীক্ষণ করার চেষ্টা করুন এবং বিক্রয়ের সংখ্যা, নতুন ব্যবহারকারীর নিবন্ধনের সংখ্যা, বর্তমানে সক্রিয় ব্যবহারকারীর সংখ্যা ইত্যাদির মতো মেট্রিকগুলির সাথে কাজ করুন৷

আপনার পুরো ব্যবসা যদি ব্রাউজারে একটি বোতাম হয়, তাহলে আপনাকে এটি ক্লিক করে এবং সঠিকভাবে কাজ করে কিনা তা নিরীক্ষণ করতে হবে। বাকি সব কিছু যায় আসে না।

যদি আপনার কাছে এটি না থাকে, আপনি অ্যাপ্লিকেশন লগ, Nginx লগ এবং আরও অনেক কিছুতে এটি ধরার চেষ্টা করতে পারেন, যেমনটি আমরা করেছি। আপনার যতটা সম্ভব অ্যাপ্লিকেশনের কাছাকাছি থাকা উচিত।

অপারেটিং সিস্টেম মেট্রিক্স অবশ্যই গুরুত্বপূর্ণ, কিন্তু ব্যবসা তাদের আগ্রহী নয়, আমরা তাদের জন্য অর্থ প্রদান করা হয় না.

উত্স: www.habr.com