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

গ্রাফাইট+হুইস্পার থেকে গ্রাফাইট+ক্লিকহাউসে মেট্রিক্স সংরক্ষণ করা থেকে আমরা কীভাবে রূপান্তরটি সংগঠিত করেছি তা বলার আগে, আমি এই ধরনের সিদ্ধান্ত নেওয়ার কারণ এবং হুইস্পারের অসুবিধাগুলি সম্পর্কে তথ্য দিতে চাই যা আমরা দীর্ঘদিন ধরে বসবাস করছিলাম।

গ্রাফাইট + হুইস্পার সমস্যা

1. ডিস্ক সাবসিস্টেমে উচ্চ লোড

পরিবর্তনের সময়, প্রতি মিনিটে প্রায় 1.5 মিলিয়ন মেট্রিক আমাদের কাছে পৌঁছেছিল। এই ধরনের প্রবাহের সাথে, সার্ভারে ডিস্কের ব্যবহার ছিল ~30%। সাধারণভাবে, এটি বেশ গ্রহণযোগ্য ছিল - সবকিছু স্থিরভাবে কাজ করেছিল, দ্রুত লেখা হয়েছিল, দ্রুত পড়া হয়েছিল... যতক্ষণ না উন্নয়ন দলগুলির মধ্যে একটি একটি নতুন বৈশিষ্ট্য তৈরি করে এবং প্রতি মিনিটে 10 মিলিয়ন মেট্রিক পাঠাতে শুরু করে। তখনই ডিস্ক সাবসিস্টেমটি শক্ত হয়ে যায় এবং আমরা 100% ব্যবহার দেখেছি। সমস্যাটি দ্রুত সমাধান করা হয়েছিল, তবে একটি অবশিষ্টাংশ রয়ে গেছে।

2. প্রতিলিপি এবং ধারাবাহিকতার অভাব

খুব সম্ভবত, প্রত্যেকের মত যারা গ্রাফাইট+হুইস্পার ব্যবহার করে/ব্যবহার করে, আমরা একই সাথে একাধিক গ্রাফাইট সার্ভারে মেট্রিক্সের একই স্ট্রীম ঢেলে দিয়েছি যাতে ত্রুটি সহনশীলতা তৈরি হয়। এবং এর সাথে কোনও বিশেষ সমস্যা ছিল না - সেই মুহুর্ত পর্যন্ত যখন কোনও কারণে সার্ভার ক্র্যাশ হয়েছিল। কখনও কখনও আমরা একটি পতিত সার্ভারকে পর্যাপ্ত পরিমাণে তুলতে সক্ষম হয়েছি, এবং কার্বন-সি-রিলে এটির ক্যাশে থেকে মেট্রিক্স লোড করতে সক্ষম হয়েছিল, কিন্তু কখনও কখনও তা নয়। এবং তারপরে মেট্রিক্সে একটি গর্ত ছিল, যা আমরা rsync দিয়ে পূরণ করেছি। পদ্ধতিটি বেশ দীর্ঘ ছিল। একমাত্র সঞ্চয় করুণা ছিল যে এটি খুব কমই ঘটেছিল। আমরা পর্যায়ক্রমে মেট্রিক্সের একটি র্যান্ডম সেট নিয়েছি এবং ক্লাস্টারের প্রতিবেশী নোডগুলিতে একই ধরণের অন্যদের সাথে তুলনা করেছি। প্রায় 5% ক্ষেত্রে, বেশ কয়েকটি মান আলাদা ছিল, যা আমরা খুব খুশি ছিলাম না।

3. বড় পায়ের ছাপ

যেহেতু আমরা গ্রাফাইটে শুধু পরিকাঠামোই নয়, ব্যবসার মেট্রিক্সও লিখি (এবং এখন কুবারনেটসের মেট্রিক্সও), তাই আমরা প্রায়শই এমন একটি পরিস্থিতি পাই যেখানে মেট্রিকে মাত্র কয়েকটি মান থাকে এবং .wsp ফাইলটি সমস্ত ধারণ বিবেচনা করে তৈরি করা হয়। পিরিয়ড, এবং আগে থেকে বরাদ্দকৃত পরিমাণ জায়গা নেয়, যা আমাদের জন্য ছিল ~2MB। সমস্যাটি আরও বাড়ে যে সময়ের সাথে সাথে অনেকগুলি অনুরূপ ফাইল উপস্থিত হয় এবং সেগুলির উপর প্রতিবেদন তৈরি করার সময়, খালি পয়েন্টগুলি পড়তে অনেক সময় এবং সংস্থান লাগে।

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

উপরের সমস্তটি থাকা (আগেরটি বিবেচনায় নিয়ে প্রবন্ধ), সেইসাথে প্রাপ্ত মেট্রিক্সের সংখ্যায় ক্রমাগত বৃদ্ধি, সমস্ত মেট্রিক্সকে 30 সেকেন্ডের স্টোরেজ ব্যবধানে স্থানান্তর করার ইচ্ছা। (প্রয়োজনে 10 সেকেন্ড পর্যন্ত), আমরা Whisper-এর প্রতিশ্রুতিশীল বিকল্প হিসাবে Graphite+ClickHouse ব্যবহার করার সিদ্ধান্ত নিয়েছি।

গ্রাফাইট+ক্লিক হাউস। প্রত্যাশা

ইয়ানডেক্স থেকে ছেলেদের বেশ কয়েকটি মিটআপ পরিদর্শন করে, পড়েছি Habré উপর নিবন্ধ একটি দম্পতি, ডকুমেন্টেশনের মধ্য দিয়ে যাওয়ার পরে এবং গ্রাফাইটের অধীনে ক্লিকহাউসকে আবদ্ধ করার জন্য বুদ্ধিমান উপাদান খুঁজে পেয়ে, আমরা ব্যবস্থা নেওয়ার সিদ্ধান্ত নিয়েছি!

আমি নিম্নলিখিতগুলি পেতে চাই:

ডিস্ক সাবসিস্টেম ব্যবহার 30% থেকে কমিয়ে 5% করা;
1TB থেকে 100GB পর্যন্ত স্থান দখলের পরিমাণ হ্রাস করুন;
সার্ভারে প্রতি মিনিটে 100 মিলিয়ন মেট্রিক পেতে সক্ষম হবেন;
বাক্সের বাইরে ডেটা প্রতিলিপি এবং দোষ সহনশীলতা;
এক বছরের জন্য এই প্রকল্পে বসবেন না এবং একটি যুক্তিসঙ্গত সময় ফ্রেমের মধ্যে রূপান্তর করবেন না;
ডাউনটাইম ছাড়াই সুইচ করুন।

বেশ উচ্চাভিলাষী, তাই না?

গ্রাফাইট+ক্লিক হাউস। উপাদান

গ্রাফাইট প্রোটোকলের মাধ্যমে ডেটা গ্রহণ করতে এবং পরবর্তীতে ক্লিকহাউসে এটি রেকর্ড করতে, আমি নির্বাচন করেছি কার্বন-ক্লিকহাউস (গোলাং)।

ClickHouse-এর সর্বশেষ প্রকাশ, স্থিতিশীল সংস্করণ 1.1.54253, সময় সিরিজ সংরক্ষণের জন্য ডাটাবেস হিসেবে বেছে নেওয়া হয়েছিল। এটির সাথে কাজ করার সময় সমস্যা ছিল: লগগুলিতে ত্রুটির পাহাড় ঢেলে দেওয়া হয়েছিল এবং সেগুলির সাথে কী করতে হবে তা পুরোপুরি পরিষ্কার ছিল না। সাথে আলোচনায় রোমান লোমোনোসভ (কার্বন-ক্লিকহাউস, গ্রাফাইট-ক্লিকহাউস এবং আরও অনেকের লেখক) পুরোনোটিকে বেছে নেওয়া হয়েছিল রিলিজ 1.1.54236. ত্রুটিগুলি অদৃশ্য হয়ে গেছে - সবকিছু একটি ঠ্যাং দিয়ে কাজ শুরু করে।

ক্লিকহাউস থেকে ডেটা পড়ার জন্য নির্বাচিত গ্রাফাইট-ক্লিকহাউস (গোলাং)। গ্রাফাইটের জন্য একটি API হিসাবে - কার্বোনাপি (গোলাং)। ক্লিক হাউস টেবিলের মধ্যে প্রতিলিপি সংগঠিত করতে ব্যবহৃত হয়েছিল চিড়িয়াখানা. রাউটিং মেট্রিক্সের জন্য, আমরা আমাদের প্রিয়জনকে ছেড়েছি কার্বন-সি-রিলে (গ) (আগের নিবন্ধ দেখুন).

গ্রাফাইট+ক্লিক হাউস। টেবিল গঠন

"গ্রাফাইট" হল একটি ডাটাবেস যা আমরা পর্যবেক্ষণ টেবিলের জন্য তৈরি করি।

"graphite.metrics" - ReplicatedReplacingMergeTree ইঞ্জিন সহ টেবিল (প্রতিলিপি করা হয়েছে) মার্জট্রি প্রতিস্থাপন করা হচ্ছে) এই টেবিলটি মেট্রিক্সের নাম এবং সেগুলির পাথ সংরক্ষণ করে৷

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"graphite.data" - ReplicatedGraphiteMergeTree ইঞ্জিন সহ টেবিল (প্রতিলিপি করা হয়েছে) GraphiteMergeTree) এই টেবিলটি মেট্রিক মান সঞ্চয় করে।

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

“graphite.date_metrics” হল ReplicatedReplacingMergeTree ইঞ্জিন সহ শর্তসাপেক্ষে পূর্ণ টেবিল। এই টেবিলটি দিনের মধ্যে সম্মুখীন হওয়া সমস্ত মেট্রিকের নাম রেকর্ড করে। এর সৃষ্টির কারণগুলি বিভাগে বর্ণিত হয়েছে "সমস্যা" এই নিবন্ধের শেষে.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"graphite.data_stat" - রেপ্লিকেটেডঅ্যাগ্রিগেটিং মার্জট্রি ইঞ্জিন সহ শর্ত অনুযায়ী একটি টেবিল ভর্তি (প্রতিলিপি করা AggregatingMergeTree) এই টেবিলটি ইনকামিং মেট্রিক্সের সংখ্যা রেকর্ড করে, 4টি নেস্টিং স্তরে বিভক্ত।

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

গ্রাফাইট+ক্লিক হাউস। উপাদান মিথস্ক্রিয়া ডায়াগ্রাম

গ্রাফাইট+ক্লিক হাউস। তথ্য স্থানান্তর

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

ClickHouse টেবিলের প্রতিলিপিতে অংশগ্রহণকারী সার্ভারগুলির একটির কার্বন-ক্লিকহাউসে মেট্রিক্সের একটি অতিরিক্ত স্ট্রিম পাঠাতে কার্বন-সি-রিলেতে একটি নিয়ম যুক্ত করা হয়েছে।
আমরা পাইথনে একটি ছোট স্ক্রিপ্ট লিখেছিলাম, যা হুইস্পার-ডাম্প লাইব্রেরি ব্যবহার করে, আমাদের স্টোরেজ থেকে সমস্ত .wsp ফাইল পড়ে এবং এই ডেটা 24টি থ্রেডে উপরে বর্ণিত কার্বন-ক্লিকহাউসে প্রেরণ করে। কার্বন-ক্লিকহাউসে গৃহীত মেট্রিক মানগুলির সংখ্যা 125 মিলিয়ন/মিনিটে পৌঁছেছে এবং ক্লিকহাউস একটি ঘামও ভাঙেনি।
বিদ্যমান ড্যাশবোর্ডে ব্যবহৃত ফাংশনগুলি ডিবাগ করার জন্য আমরা Grafana-এ একটি পৃথক ডেটাসোর্স তৈরি করেছি। আমরা যে ফাংশনগুলি ব্যবহার করেছি তার একটি তালিকা চিহ্নিত করেছি, কিন্তু সেগুলি কার্বোনাপিতে প্রয়োগ করা হয়নি। আমরা এই ফাংশনগুলি যুক্ত করেছি এবং কার্বোনাপির লেখকদের কাছে পিআর পাঠিয়েছি (তাদের বিশেষ ধন্যবাদ)।
ব্যালেন্সার সেটিংসে রিডিং লোড পরিবর্তন করতে, আমরা গ্রাফাইট-এপিআই (গ্রাফাইট+হুইস্পারের জন্য এপিআই ইন্টারফেস) থেকে কার্বোনাপিতে এন্ডপয়েন্ট পরিবর্তন করেছি।

গ্রাফাইট+ক্লিক হাউস। ফলাফল

ডিস্ক সাবসিস্টেম ব্যবহার 30% থেকে কমিয়ে 1%;
1 টিবি থেকে 300 গিগাবাইট পর্যন্ত স্থান দখলের পরিমাণ হ্রাস করা হয়েছে;
আমাদের সার্ভারে প্রতি মিনিটে 125 মিলিয়ন মেট্রিক গ্রহণ করার ক্ষমতা আছে (মাইগ্রেশনের সময় সর্বোচ্চ);
একটি ত্রিশ-সেকেন্ড স্টোরেজ ব্যবধানে সমস্ত মেট্রিক্স স্থানান্তর করা হয়েছে;
প্রাপ্ত তথ্য প্রতিলিপি এবং দোষ সহনশীলতা;
ডাউনটাইম ছাড়াই সুইচ করা হয়েছে;
সবকিছু সম্পূর্ণ করতে প্রায় 7 সপ্তাহ সময় লেগেছে।

গ্রাফাইট+ক্লিক হাউস। সমস্যা

আমাদের ক্ষেত্রে, কিছু ত্রুটি ছিল। উত্তরণের পরে আমরা এটির মুখোমুখি হয়েছি।

ClickHouse সর্বদা ফ্লাইতে কনফিগারগুলি পুনরায় পড়ে না; কখনও কখনও এটি পুনরায় বুট করা প্রয়োজন। উদাহরণস্বরূপ, ক্লিকহাউস কনফিগারেশনে চিড়িয়াখানার ক্লাস্টারের বর্ণনার ক্ষেত্রে, ক্লিকহাউস-সার্ভার রিবুট না হওয়া পর্যন্ত এটি ব্যবহার করা হয়নি।
বৃহৎ ক্লিকহাউসের অনুরোধগুলি যায় নি, তাই গ্রাফাইট-ক্লিকহাউসে আমাদের ক্লিকহাউস সংযোগ স্ট্রিংটি এইরকম দেখায়:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ক্লিকহাউস প্রায়শই স্থিতিশীল রিলিজের নতুন সংস্করণ প্রকাশ করে; সেগুলিতে বিস্ময় থাকতে পারে: সতর্ক থাকুন।
কুবারনেটে গতিশীলভাবে তৈরি কন্টেইনারগুলি একটি ছোট এবং এলোমেলো জীবনকাল সহ প্রচুর সংখ্যক মেট্রিক্স পাঠায়। এই ধরনের মেট্রিক্সের জন্য অনেক পয়েন্ট নেই, এবং স্থানের সাথে কোন সমস্যা নেই। কিন্তু প্রশ্ন তৈরি করার সময়, ClickHouse 'মেট্রিক্স' টেবিল থেকে এই একই মেট্রিকগুলির একটি বিশাল সংখ্যা বাছাই করে। 90% ক্ষেত্রে, জানালার বাইরে (24 ঘন্টা) তাদের উপর কোন তথ্য নেই। কিন্তু 'ডেটা' সারণীতে এই ডেটা অনুসন্ধান করতে সময় ব্যয় করা হয় এবং শেষ পর্যন্ত সময় শেষ হয়ে যায়। এই সমস্যাটি সমাধান করার জন্য, আমরা দিনের সম্মুখীন হওয়া মেট্রিক্সের তথ্য সহ একটি পৃথক দৃষ্টিভঙ্গি বজায় রাখতে শুরু করেছি। এইভাবে, গতিশীলভাবে তৈরি কন্টেইনারগুলির জন্য রিপোর্ট (গ্রাফ) তৈরি করার সময়, আমরা শুধুমাত্র সেই মেট্রিক্সগুলিকে জিজ্ঞাসা করি যেগুলি একটি প্রদত্ত উইন্ডোর মধ্যে সম্মুখীন হয়েছিল, এবং পুরো সময়ের জন্য নয়, যা উল্লেখযোগ্যভাবে তাদের উপর প্রতিবেদন তৈরির গতি বাড়িয়েছে৷ উপরে বর্ণিত সমাধানের জন্য, আমি সংগ্রহ করেছি গ্রাফাইট-ক্লিকহাউস (কাঁটা), যা date_metrics টেবিলের সাথে কাজ করার বাস্তবায়ন অন্তর্ভুক্ত করে।

গ্রাফাইট+ক্লিক হাউস। ট্যাগ

সংস্করণ 1.1.0 গ্রাফাইট অফিসিয়াল হয়ে ওঠে সমর্থন ট্যাগ. এবং আমরা গ্রাফাইট+ক্লিকহাউস স্ট্যাকে এই উদ্যোগটিকে সমর্থন করার জন্য কী এবং কীভাবে করতে হবে তা নিয়ে সক্রিয়ভাবে চিন্তা করছি।

গ্রাফাইট+ক্লিক হাউস। অসঙ্গতি সনাক্তকারী

উপরে বর্ণিত অবকাঠামোর উপর ভিত্তি করে, আমরা একটি অসঙ্গতি সনাক্তকারীর একটি প্রোটোটাইপ প্রয়োগ করেছি এবং এটি কাজ করে! কিন্তু পরবর্তী নিবন্ধে তার সম্পর্কে আরো.

সাবস্ক্রাইব করুন, উপরের তীর টিপুন এবং খুশি হন!

উত্স: www.habr.com

মেট্রিক্স স্টোরেজ: আমরা কীভাবে গ্রাফাইট+হুইস্পার থেকে গ্রাফাইট+ক্লিকহাউসে স্যুইচ করেছি