কুবারনেটে লগ ইন করুন (এবং শুধুমাত্র নয়) আজ: প্রত্যাশা এবং বাস্তবতা

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

যাইহোক, প্রথমে, আমি একটি রিজার্ভেশন করব যে বিভিন্ন গ্রাহকরা লগ সংগ্রহ করে খুব আলাদা জিনিস বোঝেন:

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

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

তত্ত্ব: লগিং টুলস সম্পর্কে

লগিং সিস্টেমের উপাদানগুলির পটভূমি

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

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

লগের ভলিউম বৃদ্ধি এবং ওয়েব প্রযুক্তির ব্যাপক প্রবর্তনের সাথে সাথে ব্যবহারকারীদের সুবিধাজনকভাবে কোন লগগুলি দেখানো দরকার তা নিয়ে প্রশ্ন উঠেছে। সাধারণ কনসোল টুল (awk/sed/grep) আরও উন্নত দ্বারা প্রতিস্থাপিত হয়েছে লগ দর্শক - তৃতীয় উপাদান।

লগের ভলিউম বৃদ্ধির কারণে, অন্য কিছু স্পষ্ট হয়ে উঠেছে: লগগুলি প্রয়োজন, তবে সেগুলি সব নয়। এবং বিভিন্ন লগ সংরক্ষণের বিভিন্ন স্তরের প্রয়োজন: কিছু একদিনে হারিয়ে যেতে পারে, অন্যদের 5 বছরের জন্য সংরক্ষণ করা প্রয়োজন। সুতরাং, লগিং সিস্টেমে ফিল্টারিং এবং রাউটিং ডেটা প্রবাহের জন্য একটি উপাদান যুক্ত করা হয়েছিল - আসুন এটিকে কল করি ছাঁকনি.

সঞ্চয়স্থানও একটি বড় লাফ দিয়েছে: নিয়মিত ফাইল থেকে রিলেশনাল ডাটাবেস এবং তারপরে নথি-ভিত্তিক স্টোরেজ (উদাহরণস্বরূপ, ইলাস্টিকসার্চ)। তাই সংগ্রহকারীর কাছ থেকে স্টোরেজ আলাদা করা হয়েছিল।

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

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

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

Kubernetes এবং লগ

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

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

• কেউ স্ট্যাক আনরোল ইএফকে (Elasticsearch, Fluentd, Kibana);
• কেউ সম্প্রতি মুক্তির চেষ্টা করছে লোকি বা ব্যবহার করে লগিং অপারেটর;
• нас (এবং সম্ভবত শুধুমাত্র আমরা না? ..) আমি আমার নিজের বিকাশে অনেকাংশে সন্তুষ্ট - লগ ঘর...

একটি নিয়ম হিসাবে, আমরা K8s ক্লাস্টারগুলিতে নিম্নলিখিত বান্ডিলগুলি ব্যবহার করি (স্ব-হোস্টেড সমাধানগুলির জন্য):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + লগহাউস.

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

K8 এ লগের সাথে অনুশীলন করুন

"প্রতিদিনের লগ", আপনারা কয়জন আছেন?...

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

চলুন ক্লিক হাউস চেষ্টা করা যাক

আসুন একটি অ্যাপ্লিকেশন সহ একটি প্রকল্পে একটি কেন্দ্রীভূত স্টোরেজ দেখি যা বেশ সক্রিয়ভাবে লগ তৈরি করে: প্রতি সেকেন্ডে 5000 এর বেশি লাইন। আসুন তার লগগুলিকে ক্লিক হাউসে যুক্ত করে কাজ শুরু করি।

যত তাড়াতাড়ি সর্বাধিক রিয়েলটাইম প্রয়োজন, ক্লিকহাউস সহ 4-কোর সার্ভার ইতিমধ্যেই ডিস্ক সাবসিস্টেমে ওভারলোড হবে:

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

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

এই আচরণ এড়াতে, ক্লিকহাউসে লিখতে হবে যতটা সম্ভব বড় টুকরা এবং প্রতি 1 সেকেন্ডে 2 বারের বেশি নয়। যাইহোক, বড় বিস্ফোরণে লেখা পরামর্শ দেয় যে আমাদের ক্লিকহাউসে কম ঘন ঘন লেখা উচিত। এর ফলে, একটি বাফার ওভারফ্লো এবং লগের ক্ষতি হতে পারে। সমাধান হল Fluentd বাফার বাড়ানো, কিন্তু তারপর মেমরি খরচও বাড়বে।

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

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

Elasticsearch সম্পর্কে কি?

ইলাস্টিকসার্চ ভারী কাজের চাপ সামলাতে পরিচিত। এর একই প্রকল্পে এটি চেষ্টা করা যাক. এখন লোড এই মত দেখায়:

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

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

তারপর একটি স্বাভাবিক প্রশ্ন জাগে:

কি লগ সত্যিই প্রয়োজন হয়?

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

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

তাই আমরা এই সিদ্ধান্তে উপনীত হয়েছি কেন্দ্রীভূত লগিং সবসময় ন্যায়সঙ্গত নয়. প্রায়শই ক্লায়েন্ট সমস্ত লগ এক জায়গায় সংগ্রহ করতে চায়, যদিও প্রকৃতপক্ষে, সম্পূর্ণ লগ থেকে, শুধুমাত্র একটি শর্তসাপেক্ষ 5% বার্তা যা ব্যবসার জন্য গুরুত্বপূর্ণ:

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

জীবন থেকে দৃষ্টান্ত

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

কর্পোরেট সমস্যা সনাক্তকরণ সেন্সর - QRadar-এর সাথে কেন্দ্রীভূত লগ সংগ্রহের সিস্টেমের "বন্ধু তৈরি" করা প্রয়োজন ছিল। এই সিস্টেমটি syslog প্রোটোকলের মাধ্যমে লগ গ্রহণ করতে পারে এবং সেগুলি FTP থেকে পুনরুদ্ধার করতে পারে। যাইহোক, fluentd এর জন্য remote_syslog প্লাগইনের সাথে এটিকে সংহত করা অবিলম্বে সম্ভব ছিল না (হিসাবে পরিণত, আমরা একা নই). QRadar সেট আপ করার ক্ষেত্রে সমস্যাগুলি ক্লায়েন্টের নিরাপত্তা দলের পক্ষে ছিল।

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

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

লগ জন্য মানদণ্ড

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

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

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

ত্রুটির অর্থ হল আপনি এমন একটি ক্ষেত্র পাঠাচ্ছেন যার ধরন একটি তৈরি ম্যাপিং সহ সূচকে অস্থির। সবচেয়ে সহজ উদাহরণ হল একটি ভেরিয়েবল সহ nginx লগের একটি ক্ষেত্র $upstream_status. এটি একটি সংখ্যা বা একটি স্ট্রিং থাকতে পারে। উদাহরণ স্বরূপ:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

লগগুলি দেখায় যে সার্ভার 10.100.0.10 একটি 404 ত্রুটির সাথে প্রতিক্রিয়া জানিয়েছে এবং অনুরোধটি অন্য সামগ্রী স্টোরেজে পাঠানো হয়েছিল৷ ফলস্বরূপ, লগগুলিতে মানটি এইরকম হয়ে উঠেছে:

"upstream_response_time": "0.001, 0.007"

এই পরিস্থিতি এত সাধারণ যে এটি এমনকি একটি পৃথক প্রাপ্য ডকুমেন্টেশনে রেফারেন্স.

নির্ভরযোগ্যতা সম্পর্কে কি?

এমন সময় আছে যখন ব্যতিক্রম ছাড়া সমস্ত লগ অত্যাবশ্যক। এবং এর সাথে, উপরে প্রস্তাবিত/আলোচিত K8-এর জন্য সাধারণ লগ সংগ্রহের স্কিমগুলিতে সমস্যা রয়েছে।

উদাহরণস্বরূপ, fluentd স্বল্পস্থায়ী পাত্র থেকে লগ সংগ্রহ করতে পারে না। আমাদের একটি প্রকল্পে, ডাটাবেস মাইগ্রেশন কন্টেইনারটি 4 সেকেন্ডেরও কম সময়ের জন্য বেঁচে ছিল এবং তারপরে মুছে ফেলা হয়েছিল - সংশ্লিষ্ট টীকা অনুসারে:

"helm.sh/hook-delete-policy": hook-succeeded

এই কারণে, মাইগ্রেশন এক্সিকিউশন লগ স্টোরেজের মধ্যে অন্তর্ভুক্ত করা হয়নি। এক্ষেত্রে রাজনীতি সাহায্য করতে পারে। before-hook-creation.

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

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

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

তথ্যও

এই নিবন্ধে, আমরা Datadog এর মত SaaS সমাধানগুলি দেখছি না। এখানে বর্ণিত সমস্যাগুলির অনেকগুলি ইতিমধ্যেই লগ সংগ্রহে বিশেষজ্ঞ বাণিজ্যিক সংস্থাগুলির দ্বারা কোনও না কোনও উপায়ে সমাধান করা হয়েছে, তবে সবাই বিভিন্ন কারণে SaaS ব্যবহার করতে পারে না (প্রধানগুলি হল খরচ এবং 152-FZ এর সাথে সম্মতি).

কেন্দ্রীভূত লগ সংগ্রহ প্রথমে একটি সহজ কাজের মত দেখায়, কিন্তু এটি মোটেই নয়। এটা মনে রাখা গুরুত্বপূর্ণ যে:

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

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

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «লগহাউস প্রবর্তন করা হচ্ছে - কুবারনেটে লগের সাথে কাজ করার জন্য একটি ওপেন সোর্স সিস্টেম";
• «KubeCon'19 থেকে Kubernetes ইকোসিস্টেমের জন্য রিলিজ: JFrog কন্টেইনার রেজিস্ট্রি, IBM থেকে Kui, Loki 1.0.0…";
• «মনিটরিং এবং কুবারনেটস (পর্যালোচনা এবং ভিডিও প্রতিবেদন)».

উত্স: www.habr.com