একটি পরিষেবা হিসাবে পর্যবেক্ষণ: মাইক্রোসার্ভিস আর্কিটেকচারের জন্য একটি মডুলার সিস্টেম

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

এই পোস্ট আমাদের সঙ্গে আমার বক্তৃতা একটি প্রতিলিপি বিভাগে RIT++ এ। অনেকেই আমাদের সেখান থেকে রিপোর্টের টেক্সট ভার্সন তৈরি করতে বলেছেন। আপনি যদি কনফারেন্সে থাকেন বা ভিডিওটি দেখে থাকেন তবে আপনি নতুন কিছু পাবেন না। এবং অন্য সবাই - বিড়াল স্বাগতম. আমি আপনাকে বলব যে আমরা কীভাবে এমন একটি সিস্টেমে এসেছি, এটি কীভাবে কাজ করে এবং কীভাবে আমরা এটি আপডেট করার পরিকল্পনা করি।

অতীত: স্কিম এবং পরিকল্পনা

আমরা কিভাবে বর্তমান মনিটরিং সিস্টেমে পৌঁছলাম? এই প্রশ্নের উত্তর দেওয়ার জন্য, আপনাকে 2015-এ যেতে হবে। এটি তখন দেখতে কেমন ছিল:

আমাদের প্রায় 24টি নোড ছিল যা পর্যবেক্ষণের জন্য দায়ী। বিভিন্ন মুকুট, স্ক্রিপ্ট, ডেমনের একটি সম্পূর্ণ প্যাক রয়েছে যা কোনওভাবে কিছু নিরীক্ষণ করে, বার্তা পাঠায় এবং কার্য সম্পাদন করে। আমরা ভেবেছিলাম যে আমরা যত এগিয়ে যাব, এই জাতীয় ব্যবস্থা তত কম কার্যকর হবে। এটি বিকাশ করার কোন মানে নেই: এটি খুব কষ্টকর।
আমরা সেই মনিটরিং উপাদানগুলি বেছে নেওয়ার সিদ্ধান্ত নিয়েছি যেগুলি আমরা রাখব এবং বিকাশ করব এবং যেগুলি আমরা পরিত্যাগ করব৷ তাদের মধ্যে 19টি ছিল। ড্যাশবোর্ড হিসাবে শুধুমাত্র গ্রাফাইট, এগ্রিগেটর এবং গ্রাফানা অবশিষ্ট ছিল। কিন্তু নতুন ব্যবস্থা কেমন হবে? এটার মত:

আমাদের একটি মেট্রিক্স স্টোরেজ রয়েছে: এগুলি হল গ্রাফাইট, যা দ্রুত SSD ড্রাইভের উপর ভিত্তি করে তৈরি করা হবে, এগুলি মেট্রিক্সের জন্য নির্দিষ্ট সংযোজনকারী। পরবর্তী - ড্যাশবোর্ড প্রদর্শনের জন্য Grafana এবং সতর্ক করার জন্য Moira. আমরা অসঙ্গতিগুলি অনুসন্ধানের জন্য একটি সিস্টেম বিকাশ করতে চেয়েছিলাম।

স্ট্যান্ডার্ড: মনিটরিং 2.0

2015 সালে পরিকল্পনাগুলি এমনই ছিল৷ কিন্তু আমাদের কেবল পরিকাঠামো এবং পরিষেবা নিজেই নয়, এর জন্য ডকুমেন্টেশনও প্রস্তুত করতে হয়েছিল৷ আমরা নিজেদের জন্য একটি কর্পোরেট মান তৈরি করেছি, যাকে আমরা বলি মনিটরিং 2.0। সিস্টেমের জন্য প্রয়োজনীয়তা কি ছিল?

• ধ্রুবক প্রাপ্যতা;
• মেট্রিক্স স্টোরেজ ব্যবধান = 10 সেকেন্ড;
• মেট্রিক্স এবং ড্যাশবোর্ডের কাঠামোগত স্টোরেজ;
• SLA > 99,99%
• UDP (!) এর মাধ্যমে ইভেন্ট মেট্রিক্সের সংগ্রহ।

আমাদের UDP দরকার ছিল কারণ আমাদের কাছে প্রচুর ট্রাফিক এবং ইভেন্ট রয়েছে যা মেট্রিক্স তৈরি করে। আপনি যদি সেগুলি একবারে গ্রাফাইটে লেখেন তবে স্টোরেজটি ভেঙে যাবে। আমরা সমস্ত মেট্রিকের জন্য প্রথম-স্তরের উপসর্গগুলিও বেছে নিয়েছি।

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

বর্তমান: নিরীক্ষণ উপাদানের মিথস্ক্রিয়া ডায়াগ্রাম

প্রথমত, আমরা অ্যাপ্লিকেশনগুলি নিরীক্ষণ করি: আমাদের পিএইচপি কোড, অ্যাপ্লিকেশন এবং মাইক্রোসার্ভিসগুলি - সংক্ষেপে, আমাদের বিকাশকারীরা যা লেখেন। সমস্ত অ্যাপ্লিকেশন UDP-এর মাধ্যমে Brubeck এগ্রিগেটরকে মেট্রিক্স পাঠায় (statsd, C-তে পুনঃলিখিত)। এটি সিন্থেটিক পরীক্ষায় দ্রুততম বলে প্রমাণিত হয়েছে। এবং এটি ইতিমধ্যেই একত্রিত মেট্রিক্স গ্রাফাইটে TCP এর মাধ্যমে পাঠায়।

এতে টাইমার নামে এক ধরনের মেট্রিক্স রয়েছে। এটি একটি খুব সুবিধাজনক জিনিস. উদাহরণস্বরূপ, পরিষেবার সাথে প্রতিটি ব্যবহারকারীর সংযোগের জন্য, আপনি Brubeck-এ প্রতিক্রিয়া সময় সহ একটি মেট্রিক পাঠান। এক মিলিয়ন প্রতিক্রিয়া এসেছে, কিন্তু সমষ্টিকারী শুধুমাত্র 10 মেট্রিক ফিরিয়ে দিয়েছে। আপনার কাছে আসা লোকের সংখ্যা, সর্বাধিক, সর্বনিম্ন এবং গড় প্রতিক্রিয়া সময়, মধ্যমা এবং 4 শতাংশ। তারপর ডেটা গ্রাফাইটে স্থানান্তরিত হয় এবং আমরা এটি সমস্ত লাইভ দেখতে পাই।

হার্ডওয়্যার, সফ্টওয়্যার, সিস্টেম মেট্রিক্স এবং আমাদের পুরানো মুনিন মনিটরিং সিস্টেম (এটি 2015 পর্যন্ত আমাদের জন্য কাজ করেছিল) এর মেট্রিক্সের জন্য আমাদের কাছে একত্রিতকরণও রয়েছে। আমরা C এর CollectD ডেমনের মাধ্যমে এই সব সংগ্রহ করি (এটিতে বিভিন্ন প্লাগইন তৈরি করা আছে, এটি হোস্ট সিস্টেমের সমস্ত সংস্থান পোল করতে পারে যার উপর এটি ইনস্টল করা আছে, শুধুমাত্র কনফিগারেশনে নির্দিষ্ট করুন যেখানে ডেটা লিখতে হবে) এবং এর মাধ্যমে গ্রাফাইটে ডেটা লিখুন। এটি পাইথন প্লাগইন এবং শেল স্ক্রিপ্টগুলিকেও সমর্থন করে, যাতে আপনি নিজের কাস্টম সমাধানগুলি লিখতে পারেন: CollectD একটি স্থানীয় বা দূরবর্তী হোস্ট থেকে এই ডেটা সংগ্রহ করবে (কর্ল ধরে নিয়ে) এবং গ্রাফাইটে পাঠাবে৷

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

কার্বন-সি-রিলে তারপর গ্রাফাইট ক্লাস্টারে মেট্রিক্স পাঠায়। আমরা কার্বন-ক্যাশে ব্যবহার করি, যা গো-তে পুনরায় লেখা, মেট্রিক্সের প্রধান সঞ্চয়স্থান হিসাবে। গো-কার্বন, এর মাল্টিথ্রেডিংয়ের কারণে, কার্বন-ক্যাশে অনেক বেশি পারফর্ম করে। এটি ডাটা গ্রহণ করে এবং হুইস্পার প্যাকেজ ব্যবহার করে এটিকে ডিস্কে লেখে (মানক, পাইথনে লেখা)। আমাদের স্টোরেজ থেকে ডেটা পড়ার জন্য, আমরা গ্রাফাইট API ব্যবহার করি। এটি স্ট্যান্ডার্ড গ্রাফাইট ওয়েবের চেয়ে অনেক দ্রুত। পরবর্তী ডেটার কী হবে?

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

আসুন আরও এগিয়ে যাই: সতর্কতা। এটি একটি শক্তিশালী সিস্টেম ব্যবহার করে সংগঠিত হয় - ময়রা। এটি স্বাধীন কারণ এর হুডের নিচে নিজস্ব গ্রাফাইট রয়েছে। SKB "Kontur" থেকে ছেলেরা তৈরি করেছে, পাইথন এবং গোতে লেখা, সম্পূর্ণ ওপেন সোর্স। ময়রা একই প্রবাহ পায় যা গ্রাফাইটে যায়। যদি কোনো কারণে আপনার স্টোরেজ মারা যায়, আপনার সতর্কতা এখনও কাজ করবে।

আমরা কুবারনেটসে ময়রা স্থাপন করেছি; এটি মূল ডাটাবেস হিসাবে রেডিস সার্ভারের একটি ক্লাস্টার ব্যবহার করে। ফলাফল একটি ত্রুটি-সহনশীল সিস্টেম ছিল. এটি ট্রিগারগুলির তালিকার সাথে মেট্রিক্সের স্ট্রিমের তুলনা করে: যদি এতে কোন উল্লেখ না থাকে, তাহলে এটি মেট্রিককে ড্রপ করে। তাই এটি প্রতি মিনিটে গিগাবাইট মেট্রিক্স হজম করতে সক্ষম।

আমরা এটিতে একটি কর্পোরেট LDAP সংযুক্ত করেছি, যার সাহায্যে কর্পোরেট সিস্টেমের প্রতিটি ব্যবহারকারী বিদ্যমান (বা নতুন তৈরি) ট্রিগারগুলির উপর ভিত্তি করে নিজেদের জন্য বিজ্ঞপ্তি তৈরি করতে পারে৷ যেহেতু Moira গ্রাফাইট ধারণ করে, এটি এর সমস্ত বৈশিষ্ট্য সমর্থন করে। তাই আপনি প্রথমে লাইনটি নিন এবং এটি Grafana এ কপি করুন। গ্রাফগুলিতে ডেটা কীভাবে প্রদর্শিত হয় তা দেখুন। এবং তারপর আপনি একই লাইন গ্রহণ এবং Moira মধ্যে এটি অনুলিপি. আপনি সীমার সাথে এটি ঝুলিয়ে রাখুন এবং আউটপুটে একটি সতর্কতা পান। এই সব করার জন্য, আপনার কোন নির্দিষ্ট জ্ঞানের প্রয়োজন নেই। ময়রা এসএমএস, ইমেল, জিরা, স্ল্যাকের মাধ্যমে সতর্ক করতে পারে... এটি কাস্টম স্ক্রিপ্টগুলি সম্পাদনকেও সমর্থন করে। যখন তার সাথে একটি ট্রিগার ঘটে, এবং সে একটি কাস্টম স্ক্রিপ্ট বা বাইনারিতে সদস্যতা নেয়, তখন সে এটি চালায় এবং এই বাইনারিটির জন্য JSON-কে stdin-এ পাঠায়। তদনুসারে, আপনার প্রোগ্রাম এটি পার্স করা আবশ্যক. আপনি এই JSON দিয়ে কি করবেন তা আপনার উপর নির্ভর করে। আপনি যদি চান, টেলিগ্রামে পাঠান, আপনি চাইলে জিরাতে কাজগুলি খুলুন, যা কিছু করুন।

আমরা সতর্ক করার জন্য আমাদের নিজস্ব উন্নয়ন ব্যবহার করি - ইমাগোট্যাগ। আমরা প্যানেলটিকে অভিযোজিত করেছি, যা সাধারণত দোকানে ইলেকট্রনিক মূল্য ট্যাগের জন্য ব্যবহৃত হয়, আমাদের প্রয়োজন অনুসারে। আমরা ময়রা থেকে এটিতে ট্রিগার নিয়ে এসেছি। এটি নির্দেশ করে যে তারা কোন অবস্থায় আছে এবং কখন ঘটেছে। কিছু উন্নয়ন লোক এই প্যানেলের পক্ষে স্ল্যাক এবং ইমেলে বিজ্ঞপ্তিগুলি পরিত্যাগ করেছে৷

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

মনিটরিং উপাদান

এই কাজের জন্য আমরা যে উপাদানগুলি ব্যবহার করেছি তার লিঙ্কগুলির একটি তালিকা এখানে রয়েছে। সবগুলোই ওপেন সোর্স।

গ্রাফাইট:

• গো-কার্বন: github.com/lomik/go-carbon
• ফিসফিস github.com/graphite-project/whisper
• গ্রাফাইট-এপিআই: github.com/brutasse/graphite-api

কার্বন-সি-রিলে:

github.com/grobian/carbon-c-relay

ব্রুবেক:

github.com/github/brubeck

সংগৃহীত:

collected.org

মাইরা:

github.com/moira-alert

গ্রাফনা:

grafana.com

হিপস্টার:

github.com/kubernetes/heapster

Статистика

এবং সিস্টেমটি আমাদের জন্য কীভাবে কাজ করে সে সম্পর্কে এখানে কিছু সংখ্যা রয়েছে।

অ্যাগ্রিগেটর (ব্রুবেক)

মেট্রিকের সংখ্যা: ~300/সেকেন্ড
গ্রাফাইটে মেট্রিক্স পাঠানোর ব্যবধান: 30 সেকেন্ড
সার্ভার রিসোর্স ব্যবহার: ~ 6% CPU (আমরা পূর্ণাঙ্গ সার্ভারের কথা বলছি); ~ 1 জিবি RAM; ~3 Mbps LAN

গ্রাফাইট (গো-কার্বন)

মেট্রিক্সের সংখ্যা: ~ 1 / মিনিট
মেট্রিক্স আপডেট ব্যবধান: 30 সেকেন্ড
মেট্রিক্স স্টোরেজ স্কিম: 30sec 35d, 5min 90d, 10min 365d (দীর্ঘ সময়ের মধ্যে পরিষেবার কী ঘটবে তা আপনাকে বোঝায়)
সার্ভার সম্পদ ব্যবহার: ~10% CPU; ~ 20 জিবি RAM; ~30 Mbps LAN

নমনীয়তা

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

এখানে একটি বাস্তব সমস্যার একটি উদাহরণ। গ্রাফাইটে একটি মেট্রিক একটি ফাইল। এর একটি নাম আছে। ফাইলের নাম = মেট্রিক নাম। এবং সেখানে পেতে একটি উপায় আছে. লিনাক্সে ফাইলের নাম 255 অক্ষরের মধ্যে সীমাবদ্ধ। এবং আমাদের ("অভ্যন্তরীণ গ্রাহক" হিসাবে) ডাটাবেস বিভাগের ছেলেরা আছে। তারা আমাদের বলে: "আমরা আমাদের এসকিউএল প্রশ্নগুলি নিরীক্ষণ করতে চাই৷ এবং সেগুলি 255 অক্ষর নয়, প্রতিটি 8 এমবি। আমরা সেগুলিকে Grafana-এ প্রদর্শন করতে চাই, এই অনুরোধের পরামিতিগুলি দেখতে চাই, এবং আরও ভাল, আমরা এই ধরনের অনুরোধগুলির শীর্ষ দেখতে চাই৷ এটা রিয়েল টাইমে প্রদর্শিত হলে এটি দুর্দান্ত হবে। তাদের সতর্ক করা সত্যিই চমৎকার হবে।"

উদাহরণ SQL কোয়েরি থেকে একটি উদাহরণ হিসাবে নেওয়া হয়েছে সাইট postgrespro.ru

আমরা একটি রেডিস সার্ভার সেট আপ করি এবং আমাদের সংগৃহীত প্লাগইনগুলি ব্যবহার করি, যা পোস্টগ্রেসে যায় এবং সেখান থেকে সমস্ত ডেটা নিয়ে যায়, গ্রাফাইটে মেট্রিক্স পাঠায়। কিন্তু আমরা হ্যাশ দিয়ে মেট্রিক নাম প্রতিস্থাপন. আমরা একই সাথে একই হ্যাশ Redis-এ একটি কী হিসেবে পাঠাই, এবং সমগ্র SQL কোয়েরি একটি মান হিসেবে। আমাদের যা করতে হবে তা নিশ্চিত করতে হবে যে Grafana Redis-এ গিয়ে এই তথ্য নিতে পারে। আমরা Graphite API খুলছি কারণ... গ্রাফাইটের সাথে সমস্ত মনিটরিং উপাদানগুলির মিথস্ক্রিয়া করার জন্য এটিই প্রধান ইন্টারফেস, এবং আমরা সেখানে একটি নতুন ফাংশন প্রবেশ করি যার নাম aliasByHash() - Grafana থেকে আমরা মেট্রিকের নাম পাই, এবং এটিকে একটি কী হিসাবে Redis-এর কাছে একটি অনুরোধে ব্যবহার করি। প্রতিক্রিয়ায় আমরা কীটির মান পাই, যা আমাদের "SQL ক্যোয়ারী" " এইভাবে, আমরা Grafana-এ একটি এসকিউএল কোয়েরির একটি প্রদর্শন প্রদর্শন করেছি, যা তত্ত্বগতভাবে সেখানে পরিসংখ্যান সহ প্রদর্শন করা অসম্ভব ছিল (কল, সারি, মোট_সময়, ...)।

ফলাফল

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

নির্ভরযোগ্যতা। সমস্ত উপাদান দোষ-সহনশীল এবং আমাদের লোডগুলি ভালভাবে পরিচালনা করে।

প্রবেশে কম বাধা। এই সিস্টেমটি ব্যবহার করার জন্য, আপনাকে গ্রাফনায় প্রোগ্রামিং ভাষা এবং প্রশ্নগুলি শিখতে হবে না। শুধু আপনার অ্যাপ্লিকেশনটি খুলুন, এতে একটি সকেট লিখুন যা গ্রাফাইটে মেট্রিক্স পাঠাবে, এটি বন্ধ করবে, Grafana খুলবে, সেখানে ড্যাশবোর্ড তৈরি করবে এবং আপনার মেট্রিক্সের আচরণ দেখবে, Moira এর মাধ্যমে বিজ্ঞপ্তিগুলি পাবে।

স্বাধীনতা। DevOps ইঞ্জিনিয়ারদের সাহায্য ছাড়াই আপনি নিজেই এই সব করতে পারেন। এবং এটি একটি সুবিধা, কারণ আপনি এখনই আপনার প্রকল্প নিরীক্ষণ করতে পারেন, আপনাকে কাউকে জিজ্ঞাসা করতে হবে না - হয় কাজ শুরু করতে বা পরিবর্তন করতে।

আমরা কি জন্য প্রচেষ্টা করছি?

নীচে তালিকাভুক্ত সমস্ত কিছুই কেবল বিমূর্ত চিন্তা নয়, তবে এমন কিছু যার দিকে কমপক্ষে প্রথম পদক্ষেপ নেওয়া হয়েছে।

1. অসঙ্গতি সনাক্তকারী। আমরা একটি পরিষেবা তৈরি করতে চাই যা আমাদের গ্রাফাইট স্টোরেজে যাবে এবং বিভিন্ন অ্যালগরিদম ব্যবহার করে প্রতিটি মেট্রিক পরীক্ষা করবে। ইতিমধ্যেই এমন অ্যালগরিদম আছে যা আমরা দেখতে চাই, সেখানে ডেটা আছে, আমরা জানি কিভাবে এটি দিয়ে কাজ করতে হয়।
2. মেটাডেটা। আমাদের অনেক পরিষেবা রয়েছে, তারা সময়ের সাথে সাথে পরিবর্তিত হয়, ঠিক তাদের সাথে যারা কাজ করে তাদের মতো। ক্রমাগত ম্যানুয়ালি ডকুমেন্টেশন বজায় রাখা একটি বিকল্প নয়। এজন্য আমরা এখন আমাদের মাইক্রোসার্ভিসে মেটাডেটা এম্বেড করছি। এটি কে এটি তৈরি করেছে, এটি যে ভাষাগুলির সাথে ইন্টারঅ্যাক্ট করে, SLA প্রয়োজনীয়তা, কোথায় এবং কাকে বিজ্ঞপ্তি পাঠানো উচিত তা বলে৷ একটি পরিষেবা স্থাপন করার সময়, সমস্ত সত্তা ডেটা স্বাধীনভাবে তৈরি করা হয়। ফলস্বরূপ, আপনি দুটি লিঙ্ক পাবেন - একটি ট্রিগার করতে, অন্যটি গ্রাফনায় ড্যাশবোর্ডে।
3. প্রতিটি বাড়িতে মনিটরিং। আমরা বিশ্বাস করি যে সমস্ত ডেভেলপারদের এই ধরনের একটি সিস্টেম ব্যবহার করা উচিত। এই ক্ষেত্রে, আপনি সর্বদা বুঝতে পারেন আপনার ট্র্যাফিক কোথায়, এটির কী ঘটে, এটি কোথায় পড়ে, এর দুর্বলতাগুলি কোথায়। উদাহরণস্বরূপ, যদি কিছু আসে এবং আপনার পরিষেবা ক্র্যাশ করে, তবে আপনি এটি সম্পর্কে ম্যানেজারের কাছ থেকে কল করার সময় নয়, একটি সতর্কতা থেকে শিখবেন এবং আপনি অবিলম্বে সর্বশেষ লগগুলি খুলতে পারেন এবং সেখানে কী ঘটেছে তা দেখতে পারেন।
4. উচ্চ কার্যকারিতা. আমাদের প্রকল্প ক্রমাগত বৃদ্ধি পাচ্ছে, এবং আজ এটি প্রতি মিনিটে প্রায় 2 মেট্রিক মান প্রক্রিয়া করে। এক বছর আগে, এই সংখ্যা ছিল 000। এবং বৃদ্ধি অব্যাহত, এবং এর মানে হল যে কিছু সময় পরে গ্রাফাইট (ফিসফিস) ডিস্ক সাবসিস্টেমকে ভারীভাবে লোড করতে শুরু করবে। আমি ইতিমধ্যেই বলেছি, উপাদানগুলির বিনিময়যোগ্যতার কারণে এই পর্যবেক্ষণ ব্যবস্থাটি বেশ সর্বজনীন। কেউ গ্রাফাইটের জন্য বিশেষভাবে তাদের অবকাঠামো বজায় রাখে এবং ক্রমাগত প্রসারিত করে, কিন্তু আমরা একটি ভিন্ন রুটে যাওয়ার সিদ্ধান্ত নিয়েছি: ব্যবহার করুন ক্লিকহাউস আমাদের মেট্রিক্সের জন্য একটি সংগ্রহস্থল হিসাবে। এই রূপান্তরটি প্রায় সম্পূর্ণ, এবং খুব শীঘ্রই আমি আপনাকে আরও বিস্তারিতভাবে বলব যে এটি কীভাবে করা হয়েছিল: কী অসুবিধা ছিল এবং কীভাবে সেগুলি কাটিয়ে উঠল, কীভাবে স্থানান্তর প্রক্রিয়াটি হয়েছিল, আমি বাঁধাই হিসাবে নির্বাচিত উপাদানগুলি এবং তাদের কনফিগারেশনগুলি বর্ণনা করব।

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

উত্স: www.habr.com