ইউরি বুশমেলেভ "লগ সংগ্রহ এবং বিতরণের ক্ষেত্রে একটি রেকের মানচিত্র" - প্রতিবেদনের প্রতিলিপি

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

• অ্যাপ্লিকেশন থেকে লগ লিখতে কিভাবে;
• কোথায় লগ লিখতে হয়;
• কিভাবে স্টোরেজ এবং প্রক্রিয়াকরণের জন্য লগ প্রদান করতে হয়;
• কিভাবে লগ প্রক্রিয়া এবং সংরক্ষণ করতে হয়.

বর্তমানে জনপ্রিয় কন্টেইনারাইজেশন প্রযুক্তির ব্যবহার সমস্যা সমাধানের বিকল্পের ক্ষেত্রে রেকের উপরে বালি যোগ করে।

এই সম্পর্কে ইউরি বুশমেলেভের রিপোর্টের প্রতিলিপি "লগ সংগ্রহ এবং বিতরণের ক্ষেত্রে একটি রেকের মানচিত্র"

কে যত্ন করে, দয়া করে বিড়ালের নীচে।

আমার নাম ইউরি বুশমেলেভ। আমি লাজাদার জন্য কাজ করি। আজ আমি কীভাবে আমাদের লগগুলি তৈরি করেছি, কীভাবে আমরা সেগুলি সংগ্রহ করেছি এবং আমরা সেখানে কী লিখি সে সম্পর্কে কথা বলব।

আমরা কোথা থেকে এসেছি? আমরা কারা? লাজাদা দক্ষিণ-পূর্ব এশিয়ার ছয়টি দেশে #1 অনলাইন খুচরা বিক্রেতা। এই সমস্ত দেশগুলি ডেটা সেন্টারগুলির মধ্যে বিতরণ করা হয়। এখন মোট 4টি ডেটা সেন্টার রয়েছে৷ কেন এটি গুরুত্বপূর্ণ? কারণ কিছু সিদ্ধান্ত এই কারণে হয়েছিল যে কেন্দ্রগুলির মধ্যে একটি খুব দুর্বল যোগসূত্র রয়েছে। আমাদের একটি মাইক্রোসার্ভিস আর্কিটেকচার আছে। আমি অবাক হয়েছি যে আমাদের ইতিমধ্যে 80টি মাইক্রোসার্ভিস রয়েছে৷ যখন আমি লগ দিয়ে কাজটি শুরু করি, তখন তাদের মধ্যে মাত্র 20টি ছিল। এছাড়াও, পিএইচপি উত্তরাধিকারের একটি বরং বড় অংশ রয়েছে, যা আমাকেও বাঁচতে হবে এবং সহ্য করতে হবে। এই মুহূর্তে আমাদের জন্য পুরো সিস্টেমের জন্য প্রতি মিনিটে 6 মিলিয়নেরও বেশি বার্তা উৎপন্ন করে। আরও আমি দেখাব কিভাবে আমরা এটির সাথে বাঁচার চেষ্টা করছি এবং কেন এটি এমন।

আপনাকে এই 6 মিলিয়ন বার্তাগুলির সাথে কোনওভাবে বাঁচতে হবে। আমরা তাদের সঙ্গে কি করা উচিত? 6 মিলিয়ন বার্তা প্রয়োজন:

• অ্যাপ থেকে পাঠান
• ডেলিভারির জন্য গ্রহণ করুন
• বিশ্লেষণ এবং স্টোরেজ জন্য প্রদান.
• বিশ্লেষণ করতে
• কোনোভাবে সংরক্ষণ করুন।

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

এটা নিয়ে কিভাবে বাঁচবো? এখন আমি সংক্ষেপে বিকল্পগুলির ক্ষেত্রটি বর্ণনা করব - কীভাবে এই সমস্যাটি সাধারণত সমাধান করা হয়। লগ সংগ্রহ, স্থানান্তর এবং সংরক্ষণের সমস্যা কিভাবে সমাধান করা যায়।

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

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

কিন্তু বিতরণ এবং পরবর্তী বিশ্লেষণের সাথে, বৈচিত্র্যের সংখ্যা বিস্ফোরিত হতে শুরু করে। আমি এখন প্রতিটি বিকল্প বর্ণনা করব না। আমি মনে করি মূল বিকল্পগুলি প্রত্যেকের কাছেই পরিচিত যারা বিষয়টিতে আগ্রহী।

আমি আপনাকে দেখাব যে আমরা লাজাদাতে এটি কীভাবে করেছি এবং কীভাবে এটি শুরু হয়েছিল।

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

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

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

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

এখানে (1,2,3) আমরা ফাইল লিখি এবং সেই অনুযায়ী, এখানে একবারে তিনটি রেক আছে।

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

দ্বিতীয় পয়েন্ট (2,3) হল যে আমাদের কাছে API এ প্রচুর অনুরোধ আসছে। API একটি ফাইলে প্রচুর ডেটা লেখে। ফাইল বাড়ছে। আমরা তাদের ঘোরানো প্রয়োজন. কারণ অন্যথায় আপনি সেখানে কোনো ডিস্ক সংরক্ষণ করতে পারবেন না। সেগুলিকে ঘোরানো খারাপ কারণ সেগুলিকে শেলের মাধ্যমে একটি ডিরেক্টরিতে পুনঃনির্দেশিত করা হয়। এটাকে ঘোরানোর কোনো উপায় নেই। আপনি অ্যাপ্লিকেশনটিকে হ্যান্ডলগুলি পুনরায় খুলতে বলতে পারবেন না। কারণ বিকাশকারীরা আপনাকে বোকার মতো দেখবে: “কী বর্ণনাকারী? আমরা সাধারণত stdout লিখি। ফ্রেমওয়ার্ক কপিট্রুনকেটকে লগরোটেটে পরিণত করে, যা ফাইলের একটি কপি তৈরি করে এবং আসলটিকে ট্রাঙ্ক করে। তদনুসারে, এই অনুলিপি প্রক্রিয়াগুলির মধ্যে, ডিস্কের স্থান সাধারণত ফুরিয়ে যায়।

(4) আমাদের বিভিন্ন API এ বিভিন্ন ফরম্যাট ছিল। তারা সামান্য ভিন্ন ছিল, কিন্তু regexp ভিন্নভাবে লিখতে হয়েছিল। যেহেতু এটি পুতুল দ্বারা পরিচালিত হয়েছিল, তাই তাদের নিজস্ব তেলাপোকা নিয়ে ক্লাসের একটি বড় দল ছিল। এছাড়াও, টিডি-এজেন্ট বেশিরভাগ সময় স্মৃতি খেতে পারে, বোকা হতে পারে, সে শুধু ভান করতে পারে যে সে কাজ করছে এবং কিছুই করছে না। বাহ্যিকভাবে, এটা বোঝা অসম্ভব ছিল যে তিনি কিছুই করছেন না। সর্বোপরি, সে পড়ে যাবে, এবং কেউ তাকে পরে তুলে নেবে। আরও স্পষ্টভাবে, একটি সতর্কতা উড়ে যাবে, এবং কেউ গিয়ে তাদের হাত দিয়ে এটি বাড়াবে।

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

আমরা এই প্রশ্ন জিজ্ঞাসা করা শুরু. আমরা দোষীদের খোঁজ না করার সিদ্ধান্ত নিয়েছি।

কিন্তু কিছু একটা করা দরকার! স্পষ্ট বিষয় হল যে আমাদের মান প্রতিষ্ঠা করতে হবে। আমরা ইতিমধ্যে কিছু মান ছিল. কিছু আমরা একটু পরে নিয়ে এসেছি। সৌভাগ্যবশত, সমস্ত API-এর জন্য একটি একক লগ বিন্যাস ইতিমধ্যেই সেই সময়ে অনুমোদিত হয়েছিল৷ এটি সরাসরি পরিষেবা ইন্টারঅ্যাকশন মানগুলিতে লেখা হয়। তদনুসারে, যারা লগ গ্রহণ করতে চান তাদের এই বিন্যাসে লিখতে হবে। কেউ এই বিন্যাসে লগ না লিখলে, তারপর আমরা কিছু গ্যারান্টি না.

আরও, আমি রেকর্ডিং, বিতরণ এবং লগ সংগ্রহের পদ্ধতিগুলির জন্য একটি একক মান রাখতে চাই৷ প্রকৃতপক্ষে, সেগুলি কোথায় লিখতে হবে এবং কীভাবে সেগুলি সরবরাহ করতে হবে। আদর্শ পরিস্থিতি হল যখন প্রকল্পগুলি একই লাইব্রেরি ব্যবহার করে। Go-এর জন্য আলাদা লগিং লাইব্রেরি আছে, PHP-এর জন্য আলাদা লাইব্রেরি আছে। আমাদের প্রত্যেকেরই তাদের ব্যবহার করা উচিত। এই মুহুর্তে, আমি বলব যে আমরা 80 শতাংশ সফল হচ্ছি। কিন্তু কেউ কেউ ক্যাকটি খেতে থাকেন।

এবং সেখানে (স্লাইডে) "লগ ডেলিভারির জন্য SLA" সবেমাত্র প্রদর্শিত হতে শুরু করেছে৷ এটি এখনও সেখানে নেই, তবে আমরা এটি নিয়ে কাজ করছি। কারণ এটি খুবই সুবিধাজনক যখন ইনফ্রা বলে যে আপনি যদি অমুক এবং অমুক একটি জায়গায় অমুক এবং অমুক ফর্ম্যাটে লিখুন এবং প্রতি সেকেন্ডে N বার্তার বেশি না হয়, তবে আমরা সম্ভবত এটি সেখানে পৌঁছে দেব। এটি অনেক মাথাব্যথা দূর করে। যদি একটি SLA থাকে, তাহলে এটা শুধু মহান!

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

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

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

sysadmin-এর সুস্পষ্ট সমাধান হল এই পরিমাণে সব ধরনের syslogs (syslog-ng/rsyslog/nxlog)।

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

অতএব, পছন্দটি আসলে syslog-ng এবং rsyslog-এর মধ্যে একটি পছন্দে নেমে এসেছে। আমি rsyslog-এর দিকে ঝুঁকেছিলাম কারণ আমাদের ইতিমধ্যে পাপেটে rsyslog-এর জন্য ক্লাস ছিল, এবং আমি তাদের মধ্যে একটি সুস্পষ্ট পার্থক্য খুঁজে পাইনি। syslog কি, syslog কি. হ্যাঁ, কিছু ডকুমেন্টেশন খারাপ, কিছু ভালো। তিনি এইভাবে জানেন, এবং তিনি এটি ভিন্নভাবে করেন।

এবং rsyslog সম্পর্কে একটু. প্রথমত, এটি দুর্দান্ত কারণ এতে প্রচুর মডিউল রয়েছে। এটিতে একটি মানব-পাঠযোগ্য রেনারস্ক্রিপ্ট (আধুনিক কনফিগারেশন ভাষা) রয়েছে। একটি দুর্দান্ত বোনাস হল যে আমরা টিডি-এজেন্টের আচরণকে এর আদর্শ সরঞ্জামগুলির সাথে অনুকরণ করতে পারি এবং অ্যাপ্লিকেশনগুলির জন্য কিছুই পরিবর্তন হয়নি। অর্থাৎ, আমরা টিডি-এজেন্টকে rsyslog-এ পরিবর্তন করি, এবং এখনও অন্য সবকিছু স্পর্শ করি না। এবং অবিলম্বে আমরা একটি কাজের বিতরণ পেতে. এর পরে, mmnormalize হল rsyslog সম্পর্কে দুর্দান্ত জিনিস। এটি আপনাকে লগ পার্স করতে দেয়, কিন্তু Grok এবং regexp এর সাথে নয়। এটি একটি বিমূর্ত সিনট্যাক্স গাছ তৈরি করে। এটি লগগুলিকে একইভাবে পার্স করে যেভাবে একটি কম্পাইলার সোর্স কোড পার্স করে। এটি আপনাকে খুব দ্রুত কাজ করতে, সামান্য সিপিইউ খেতে দেয় এবং সাধারণভাবে, এটি একটি খুব দুর্দান্ত জিনিস। অন্যান্য বোনাস একটি গুচ্ছ আছে. আমি তাদের উপর বাস করব না।

rsyslog এর অনেক বেশি অসুবিধা রয়েছে। তারা বোনাস হিসাবে একই. প্রধান সমস্যা হল যে আপনাকে এটি রান্না করতে সক্ষম হতে হবে এবং আপনাকে একটি সংস্করণ নির্বাচন করতে হবে।

আমরা সিদ্ধান্ত নিয়েছি যে আমরা একটি ইউনিক্স সকেটে লগ লিখব। এবং /dev/log-এ নয়, কারণ সেখানে আমাদের সিস্টেম লগের জগাখিচুড়ি আছে, এই পাইপলাইনে জার্নাল্ড আছে। সুতরাং আসুন একটি কাস্টম সকেট লিখুন. আমরা এটি একটি পৃথক নিয়ম সেটে সংযুক্ত করব। আসুন কিছুতে হস্তক্ষেপ না করি। সবকিছু স্বচ্ছ এবং বোধগম্য হবে। তাই আমরা আসলে. এই সকেটগুলির সাথে ডিরেক্টরিটি প্রমিত এবং সমস্ত পাত্রে ফরোয়ার্ড করা হয়। কন্টেইনাররা তাদের প্রয়োজনীয় সকেট দেখতে, খুলতে এবং লিখতে পারে।

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

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

কিন্তু এই অংশে (Logstash/Graylog/ES) পরে সেগুলো কীভাবে স্টাফ করা যায় তার সূক্ষ্মতা রয়েছে। এই অংশটি (rsyslog-rsyslog) ডেটাসেন্টারগুলির মধ্যে ব্যবহৃত হয়। এখানে একটি সংকুচিত tcp লিঙ্ক রয়েছে, যা আপনাকে ব্যান্ডউইথ সংরক্ষণ করতে দেয় এবং সেই অনুযায়ী, চ্যানেলটি পূর্ণ হলে আমরা অন্য ডেটা সেন্টার থেকে কিছু লগ পাওয়ার সম্ভাবনা বাড়ায়। কারণ আমাদের ইন্দোনেশিয়া আছে, যেখানে সবকিছু খারাপ। যে যেখানে ধ্রুবক সমস্যা মিথ্যা.

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

সমস্যাগুলো কি কি? আমাদের লাইভ API গুলি প্রতি সেকেন্ডে 50k বার্তা লেখে যে আমরা (হঠাৎ!) জানতে পেরেছি তা নিয়ে সমস্যাটি দেখা দিয়েছে। এটি স্টেজিং ছাড়াই শুধুমাত্র লাইভ API। এবং Graylog আমাদের প্রতি সেকেন্ডে 12 হাজার বার্তা দেখায়। এবং একটি যুক্তিসঙ্গত প্রশ্ন উঠেছে, অবশিষ্টাংশগুলি কোথায়? যা থেকে আমরা উপসংহারে পৌঁছেছি যে Graylog সহজভাবে মানিয়ে নিতে পারে না। আমরা দেখেছি, এবং, প্রকৃতপক্ষে, ইলাস্টিকসার্চ সহ গ্রেলগ এই প্রবাহকে আয়ত্ত করতে পারেনি।

এর পরে, আমরা পথ ধরে তৈরি করেছি অন্যান্য আবিষ্কার।

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

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

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

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

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

লগস্ট্যাশ এবং গ্রেলগের সাথে এই অংশটি, এটি সত্যিই অনেক বেড়ে যায়। অতএব, আপনি এটি পরিত্রাণ পেতে প্রয়োজন. আপনাকে একটি বেছে নিতে হবে।

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

ঠিক কি নতুন Graylog অন্তর্ভুক্ত করা হয়েছে. আমরা শুধু ডকারে সবকিছু লিখেছি। আমরা একগুচ্ছ সার্ভার নিয়েছি, তিনটি কাফকা উদাহরণ তৈরি করেছি, 7টি গ্রেলগ সার্ভার সংস্করণ 2.3 (কারণ আমি ইলাস্টিকসার্চ সংস্করণ 5 চেয়েছিলাম)। এই সব HDD থেকে অভিযানে উত্থাপিত হয়েছে. আমরা প্রতি সেকেন্ডে 100 হাজার বার্তার সূচীকরণের হার দেখেছি। আমরা চিত্র দেখেছি যে প্রতি সপ্তাহে 140 টেরাবাইট ডেটা।

আবার একটা রেক! আমরা দুটি বিক্রয় আসছে. আমরা 6 মিলিয়ন পোস্ট অতিক্রম করেছি। আমরা Graylog চিবানোর সময় নেই. কোনোভাবে আবার বাঁচতে হবে।

এভাবেই আমরা বেঁচে গেলাম। আরো কয়েকটি সার্ভার এবং SSD যোগ করা হয়েছে। এই মুহুর্তে আমরা এভাবেই বেঁচে আছি। এখন আমরা ইতিমধ্যে প্রতি সেকেন্ডে 160k বার্তা চিবিয়ে দিচ্ছি। আমরা এখনও সীমা অতিক্রম করিনি, তাই আমরা কতটা বাস্তবসম্মতভাবে এটি থেকে বেরিয়ে আসতে পারি তা স্পষ্ট নয়।

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

Graylog থেকে মেট্রিক্স সংগ্রহ করুন।

একটি হারের সীমা তৈরি করুন যাতে আমাদের একটি পাগল API থাকে যা আমাদের ব্যান্ডউইথ এবং অন্য সবকিছুকে হত্যা করে না।

এবং পরিশেষে, ডেভেলপারদের সাথে কিছু ধরণের SLA স্বাক্ষর করুন যাতে আমরা ততটা পরিবেশন করতে পারি। বেশি লিখলে মাফ করবেন।

এবং ডকুমেন্টেশন লিখুন।

সংক্ষেপে, আমরা যা কিছু অভিজ্ঞতা করেছি তার ফলাফল। প্রথমত, মান. দ্বিতীয়ত, সিসলগ হল কেক। তৃতীয়ত, rsyslog ঠিক যেভাবে স্লাইডে লেখা আছে ঠিক সেভাবে কাজ করে। এবং আসুন প্রশ্ন পেতে.

প্রশ্ন.

প্রশ্ন: কেন তারা না নেওয়ার সিদ্ধান্ত নিয়েছে... (ফাইলবিট?)

উত্তর: একটি ফাইলে লিখতে হবে। আমি সত্যিই চাইনি. যখন আপনার API প্রতি সেকেন্ডে হাজার হাজার বার্তা লেখে, এমনকি যদি আপনি ঘন্টায় একবার ঘোরান, এটি এখনও একটি বিকল্প নয়। আপনি পাইপ লিখতে পারেন. যার জন্য বিকাশকারীরা আমাকে জিজ্ঞাসা করেছিলেন: "আমরা যে প্রক্রিয়ায় লিখি তা পড়ে গেলে কী হবে"? আমি তাদের কি উত্তর দেব তা খুঁজে পেলাম না, এবং বললাম: "আচ্ছা, ঠিক আছে, আসুন তা করি না।"

প্রশ্ন: কেন আপনি শুধু HDFS-এ লগ লিখছেন না?

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

প্রশ্ন: একটি কলাম বিন্যাস আরো উপযুক্ত হবে.

উত্তর: আমি বুঝেছি. আমরা উভয় হাত দিয়ে "জন্য"।

প্রশ্ন: আপনি rsyslog এ লিখুন। TCP এবং UDP উভয়ই সেখানে উপলব্ধ। কিন্তু যদি ইউডিপি, তাহলে আপনি কিভাবে ডেলিভারির গ্যারান্টি দেবেন?

উত্তরউত্তর: দুটি পয়েন্ট আছে। প্রথমত, আমি অবিলম্বে সবাইকে বলি যে আমরা লগ সরবরাহের নিশ্চয়তা দিই না। কারণ যখন ডেভেলপাররা এসে বলে: "আসুন সেখানে আর্থিক ডেটা লেখা শুরু করি, এবং কিছু ঘটলে আপনি এটি আমাদের জন্য কোথাও রাখবেন," আমরা তাদের উত্তর দিই, "দারুণ! আসুন সকেটে লেখার উপর ব্লক করা শুরু করি, এবং এটি লেনদেনে করি, যাতে আপনি এটিকে আমাদের জন্য সকেটে রাখার নিশ্চয়তা পান এবং নিশ্চিত হন যে আমরা অন্য দিক থেকে এটি পেয়েছি। এবং এই মুহূর্তে, সবাই অবিলম্বে অপ্রয়োজনীয় হয়ে ওঠে। এবং যদি না হয়, তাহলে আমাদের কি প্রশ্ন আছে? আপনি যদি সকেটে লেখার নিশ্চয়তা দিতে না চান, তাহলে আমরা কেন ডেলিভারির গ্যারান্টি দেব? আমরা সর্বোচ্চ চেষ্টা করছি। আমরা সত্যিই যতটা সম্ভব এবং যতটা সম্ভব সেরা ডেলিভারি করার চেষ্টা করি, কিন্তু আমরা 100% গ্যারান্টি দিই না। অতএব, আপনাকে সেখানে আর্থিক তথ্য লিখতে হবে না। এই জন্য লেনদেন ডেটাবেস আছে.

প্রশ্ন: যখন API লগে কিছু বার্তা তৈরি করে এবং মাইক্রোসার্ভিসে নিয়ন্ত্রণ স্থানান্তর করে, আপনি কি সমস্যার সম্মুখীন হয়েছেন যে বিভিন্ন মাইক্রোসার্ভিস থেকে বার্তাগুলি ভুল ক্রমে আসে? এ কারণে বিভ্রান্তির সৃষ্টি হয়।

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

প্রশ্ন: টাইমস্ট্যাম্প মিলিসেকেন্ড দ্বারা পরিবর্তিত হতে পারে।

উত্তর: টাইমস্ট্যাম্প API নিজেই তৈরি করে। এই, আসলে, পুরো বিন্দু. আমাদের এনটিপি আছে। API ইতিমধ্যেই বার্তায় একটি টাইমস্ট্যাম্প তৈরি করে। এটি rsyslog দ্বারা যোগ করা হয় না।

প্রশ্ন: ডেটা সেন্টারের মধ্যে মিথস্ক্রিয়া খুব স্পষ্ট নয়। ডেটা সেন্টারের কাঠামোর মধ্যে, এটি স্পষ্ট যে কীভাবে লগগুলি সংগ্রহ এবং প্রক্রিয়া করা হয়েছিল। কিভাবে তথ্য কেন্দ্রের মধ্যে মিথস্ক্রিয়া হয়? নাকি প্রতিটি ডেটা সেন্টার তার নিজস্ব জীবনযাপন করে?

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

প্রশ্ন: আপনি কি অস্বাভাবিক পরিস্থিতিতে সেখান থেকে লগ পান?

উত্তর: আপনি সেখানে যেতে পারেন (ফাইল স্টোরেজ) এবং দেখতে পারেন.

প্রশ্ন: আপনি কিভাবে নিরীক্ষণ করবেন যে আপনি লগ হারান না?

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

প্রশ্ন: ইলাস্টিক সার্চে, আপনি অপ্রয়োজনীয়তার সাথে লগ সংরক্ষণ করেন। আপনার কত প্রতিলিপি আছে?

উত্তর: এক প্রতিরূপ।

প্রশ্ন: এটা কি শুধু একটা লাইন?

উত্তর: এই মাস্টার এবং প্রতিরূপ. তথ্য সদৃশ সংরক্ষণ করা হয়.

প্রশ্ন: আপনি কি কোনোভাবে rsyslog বাফারের আকার পরিবর্তন করেছেন?

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

প্রশ্ন: আপনি কি ভাঙা JSON লেখেন?

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

প্রশ্ন: কেন কাফকা? আপনি কি RabbitMQ চেষ্টা করেছেন? Graylog যেমন লোড অধীনে আপ যোগ না?

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

কাফকার কথা। ঐতিহাসিকভাবে তাই ঘটেছে। আমি যখন পৌঁছেছিলাম, তখন এটি ইতিমধ্যেই সেখানে ছিল এবং লগগুলি ইতিমধ্যেই এটিতে লেখা হচ্ছে৷ আমরা শুধু আমাদের ক্লাস্টার উত্থাপন করেছি এবং এতে লগগুলি সরিয়েছি। আমরা তাকে পরিচালনা করি, আমরা জানি সে কেমন অনুভব করে। RabbitMQ এর জন্য... আমাদের RabbitMQ নিয়ে সমস্যা হচ্ছে। এবং RabbitMQ আমাদের জন্য বিকাশ করছে। আমাদের এটি উত্পাদনে রয়েছে এবং এটিতে সমস্যা ছিল। এখন, বিক্রির আগে, তাকে শামানাইজ করা হবে এবং সে স্বাভাবিকভাবে কাজ শুরু করবে। তবে এর আগে আমি এটি প্রযোজনায় মুক্তি দিতে প্রস্তুত ছিলাম না। আরও একটা কথা আছে। Graylog AMQP 0.9 সংস্করণ পড়তে পারে এবং rsyslog AMQP 1.0 সংস্করণ লিখতে পারে। এবং মাঝখানে উভয় করতে পারে এমন একটি সমাধান নেই। একটি বা অন্য হয়. তাই আপাতত শুধু কাফকা। কিন্তু সূক্ষ্মতা আছে. কারণ rsyslog-এর যে সংস্করণটি আমরা ব্যবহার করি তার omkafka পুরো বার্তা বাফারটি হারাতে পারে যা এটি rsyslog থেকে স্কূপ করেছে। যতদিন আমরা এটা সঙ্গে রাখা.

প্রশ্ন: আপনি কি কাফকা ব্যবহার করছেন কারণ আপনার কাছে এটি ছিল? অন্য কোন কাজে ব্যবহার করা হয় না?

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

প্রশ্ন: কেন আমরা সকেট সঙ্গে এই shamanism প্রয়োজন? আপনি কন্টেইনারগুলির জন্য syslog লগ ড্রাইভার ব্যবহার করার চেষ্টা করেছেন?

উত্তর: যখন আমরা এই প্রশ্নটি জিজ্ঞাসা করেছি, তখন ডকারের সাথে আমাদের উত্তেজনাপূর্ণ সম্পর্ক ছিল। এটি ডকার 1.0 বা 0.9 ছিল। ডকার নিজেই অদ্ভুত ছিল। দ্বিতীয়ত, আপনি যদি এটিতে লগগুলিও ঢেলে দেন... আমার একটি অযাচাইকৃত সন্দেহ আছে যে এটি ডকার ডেমনের মাধ্যমে নিজেই সমস্ত লগ পাস করে। যদি আমাদের একটি এপিআই পাগল হয়ে যায়, তাহলে বাকি এপিআইগুলি এই সত্যে চলে যাবে যে তারা stdout এবং stderr পাঠাতে পারে না। আমি জানি না এটা কোথায় নিয়ে যাবে। আমার অনুভূতির স্তরে একটি সন্দেহ আছে যে এই জায়গায় ডকার সিসলগ ড্রাইভার ব্যবহার করার প্রয়োজন নেই। আমাদের কার্যকরী পরীক্ষা বিভাগের লগ সহ নিজস্ব গ্রেলগ ক্লাস্টার রয়েছে। তারা ডকার লগ ড্রাইভার ব্যবহার করে এবং সেখানে সবকিছু ঠিক আছে বলে মনে হয়। কিন্তু তারা অবিলম্বে Graylog এ GELF লিখে। এই মুহুর্তে যখন আমরা এই সব শুরু করেছি, আমাদের এটি কেবল কাজ করার প্রয়োজন ছিল। সম্ভবত পরে, যখন কেউ এসে বলে যে এটি একশ বছর ধরে স্বাভাবিকভাবে কাজ করছে, আমরা চেষ্টা করব।

প্রশ্ন: আপনি rsyslog ব্যবহার করে ডেটা সেন্টারের মধ্যে বিতরণ করেন। কাফকার উপর কেন নয়?

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

উত্স: www.habr.com