কেন বেশিরভাগ লগ ফাইলগুলি বাইনারি বিন্যাসের পরিবর্তে সরল পাঠ্য ব্যবহার করে?


81

লগিং এমন কিছু যা প্রয়োজনীয় তবে এটি (তুলনামূলকভাবে) খুব কম ব্যবহৃত হয়। স্টোরেজ হিসাবে এটি অনেক বেশি কমপ্যাক্ট করা যেতে পারে।

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

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

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


20
আমি আপনার এই দৃ challenge় প্রতিবাদকে চ্যালেঞ্জ জানাব যে লোকেরা এটি না করে । অনেকেই করেন। কিছু না, নিশ্চিত, কিন্তু প্রচুর আছে।
পরিবেশন করুন


44
> লগিং যদি বাইনারি ডেটা হিসাবে সংরক্ষণ করা হত তবে প্রচুর জায়গা সংরক্ষণ করা যেত, পুরাতন লগগুলি সাধারণত সংকুচিত হয়।
Leonbloy

89
অর্ধেক ভাঙা এমন কোনও মেশিনে একটি পাঠ্য লগ পড়ার পক্ষে এটি বিশ্লেষণের জন্য বাইনারি প্রয়োজনের চেয়ে একটি বিশাল সুবিধা হতে পারে।
tofro

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

উত্তর:


163

systemdবিখ্যাতভাবে লগ ফাইলগুলি বাইনারি ফর্ম্যাটে সংরক্ষণ করে। এটির সাথে আমি যে প্রধান সমস্যাগুলি শুনেছি তা হ'ল:

  1. লগটি যদি দুর্নীতিগ্রস্থ হয় তবে এটি বিশেষজ্ঞ টুলিংয়ের প্রয়োজন হিসাবে পুনরুদ্ধার করা শক্ত hard
  2. তারা মানুষের পাঠযোগ্য নয়, তাই আপনি এই ধরনের মান সরঞ্জাম ব্যবহার করতে পারবেন না vi, grep, tailইত্যাদি তাদের বিশ্লেষণ করতে

বাইনারি ফর্ম্যাটটি (আমার জ্ঞানের) ব্যবহারের মূল কারণ হ'ল সূচকগুলি তৈরি করা ইত্যাদির অর্থ এটি একটি ডেটাবেস ফাইলের মতো আরও চিকিত্সা করা সহজ বলে মনে করা হয়েছিল।

আমি যুক্তি দিয়ে বলব যে ডিস্কের জায়গার সুবিধাটি অনুশীলনে তুলনামূলকভাবে কম (এবং হ্রাস)। আপনি যদি প্রচুর পরিমাণে লগিং সঞ্চয় করতে চান তবে ঘূর্ণিত লগগুলি জিপ করা সত্যিই বেশ দক্ষ।

ভারসাম্য বজায় রেখে, সরঞ্জামকরণ এবং পরিচিতিগুলির সুবিধাগুলি সম্ভবত বেশিরভাগ ক্ষেত্রে পাঠ্য লগিংয়ের পক্ষে ভ্রান্ত হবে।


3
ভাল যুক্তি. আমি তত্ক্ষণাত্ সিস্টেমডের কথা ভাবছিলাম। আরও গুরুত্বপূর্ণ অংশটি এখানে আপনার অ্যাপ্লিকেশনটিতে লগ ডেটা কীভাবে সংরক্ষণ করা হয় তা জানতে হবে না । এটি সিস্টেম পরিষেবা হিসাবে সরবরাহ করা যেতে পারে।
5gon12eder

97
"বিখ্যাত", আরও "কুখ্যাত" এর মত
হোসাইম

4
পিএফ (ফায়ারওয়াল) বাইনারিতেও লগ ইন করে, বিশেষত tcpdump ফর্ম্যাটে
নিল ম্যাকগুইগান

3
@ হাটসেপসুট রোলড লগগুলি: লগ আউটপুট একটি ফাইলে লিখে, myapp.logমধ্যরাত পর্যন্ত বলে , এবং তারপরে সেই ফাইলটিতে স্থানান্তরিত করে myapp.log.1এবং একটি নতুন myapp.logফাইলে লেখা শুরু করে । এবং পুরানো myapp.log.1সরানো হয় myapp.log.2, এবং আরও, তারা সমস্ত বরাবর রোল। সুতরাং, myapp.logসর্বদা বর্তমান হয়। অথবা কোনও নির্দিষ্ট আকার পৌঁছে গেলে তারা পরিবর্তন করতে পারে। তারা ফাইলের নামটিতে তারিখ / সময় রাখবে। অনেক লগিং ফ্রেমওয়ার্ক বাক্সের বাইরে এই ধরণের জিনিসকে সমর্থন করে।
সুসানডাব্লু

13
@ হাটসেপসুট এই শব্দটি rotatingআমার সচেতন থেকেও ব্যবহৃত হয়েছে।
জর্জ ডি

89

কেন বেশিরভাগ লগ ফাইলগুলি বাইনারি বিন্যাসের পরিবর্তে সরল পাঠ্য ব্যবহার করে?

ইউনিক্স দর্শনের উইকিপিডিয়া নিবন্ধে "পাঠ্য" শব্দটির সন্ধান করুন , উদাহরণস্বরূপ আপনি বিবৃতি পাবেন:

বেল ল্যাবস সিএসআরসি (কম্পিউটিং সায়েন্সেস রিসার্চ সেন্টার) এর তত্ত্বাবধায়ক এবং ইউনিক্স পাইপের উদ্ভাবক ম্যাকিলারয় [9] ইউনিক্স দর্শনের সংক্ষিপ্ত বিবরণ দিয়েছেন: [10]

এটি ইউনিক্স দর্শন: এমন একটি প্রোগ্রাম লিখুন যা একটি কাজ করে এবং এটি ভাল করে। এক সাথে কাজ করার জন্য প্রোগ্রাম লিখুন। পাঠ্য স্ট্রিমগুলি পরিচালনা করতে প্রোগ্রামগুলি লিখুন, কারণ এটি সর্বজনীন ইন্টারফেস।

বা উদাহরণস্বরূপ, ইউনিক্স দর্শনের মূল বিষয়গুলি থেকে ,

রচনার নিয়ম: অন্যান্য প্রোগ্রামের সাথে সংযুক্ত হওয়ার জন্য ডিজাইন প্রোগ্রামগুলি।

আপনার প্রোগ্রামগুলির মধ্যে কেউ একে অপরের সাথে কথা বলতে না পারলে ওভার কমপ্লিক্যটেটেড মনোলিথগুলি এড়ানো শক্ত hard

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

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

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

যে কেউ নিজের অতিরিক্ত সময়ে দুই দিনের মতো এটি তৈরি করতে পারে, লোকেরা কেন এটি করে না?

বাইনারিতে লগ ফাইল সংরক্ষণ করা কেবল শুরু (এবং তুচ্ছ) is এরপরে আপনার কাছে সরঞ্জামগুলি লিখতে হবে:

  • সম্পূর্ণ লগ ফাইল প্রদর্শন করুন ( edit)
  • এর শুরুটি না পড়ে লগের শেষ প্রদর্শন করুন ( tail -f)
  • ফাইলটিতে স্টাফ অনুসন্ধান করুন ( grep)
  • কেবলমাত্র নির্বাচিত / আকর্ষণীয় জিনিস প্রদর্শন করতে ফিল্টার (একরকম জটিল ফিল্টার এক্সপ্রেশন ব্যবহার করে)
  • লগটি অন্য কারও কাছে ইমেল করুন যার কাছে আপনার লগ-ফাইল-ডিকোডার-সফ্টওয়্যার নেই
  • লগ ফাইলের একটি টুকরো অনুলিপি করুন এবং আটকান
  • প্রোগ্রামটি (যা লগ ফাইল তৈরি করে) এখনও বিকাশ এবং ডিবাগ হওয়ার সময় লগ ফাইলটি পড়ুন
  • সফ্টওয়্যারটির পুরানো সংস্করণগুলি থেকে লগ ফাইলগুলি পড়ুন (যা গ্রাহক সাইটগুলিতে স্থাপন এবং চলমান)।

স্পষ্টতই সফ্টওয়্যার বাইনারি ফাইল ফর্ম্যাটগুলিও ব্যবহার করতে পারে এবং ব্যবহার করে (উদাহরণস্বরূপ রিলেশনাল ডাটাবেসগুলির জন্য) তবে লগ ফাইলগুলির জন্য এটি সাধারণত (কোনও YAGNI অর্থে) মূল্যবান নয়।


24
ডকুমেন্টেশন ভুলবেন না! আমি কয়েক বছর আগে একটি সিস্টেমের জন্য একটি বাইনারি বার্তা রেকর্ডার লিখেছিলাম, যা রিগ্রেশন / রিপ্লেয়ের জন্য আগত অনুরোধগুলি লগ করেছিল। এখন, এই জঘন্য ফাইলগুলি বোঝার একমাত্র উপায় হ'ল যে কোডগুলি সেগুলি পড়তে / লিখতে পারে সেই কোডটি দেখুন এবং অন্য দলগুলি সেগুলি ব্যবহার করে এবং সেগুলি সম্পর্কে প্রশ্ন জিজ্ঞাসা করে। ভয়াবহ জিনিস।
SusanW

2
ন্যায়সঙ্গত হওয়ার জন্য, পাঠের জন্য বেসিক ক্যোয়ারী সরঞ্জামগুলির সাথে মিলিয়ে কোনও এসকিউএল ডিবিতে আপনার লগ সংরক্ষণ করা আপনার বাক্সের বাইরে উল্লেখ করা সমস্ত বৈশিষ্ট্য সরবরাহ করবে। ;)
jpmc26

3
@ jpmc26 হ্যাঁ আপনি যতক্ষণ পারেন লগ ফাইলটি পড়তে পারেন, কোনওভাবে, এটি একটি পাঠ্য বিন্যাসে রূপান্তর করতে পারেন ...
ChrisW

1
যেমন অন্যান্য মন্তব্যে বলা হয়েছে: টেক্সট ফাইলগুলি সহজেই এবং কার্যকরভাবে সংকুচিত হতে পারে। তবে সংকোচনের 'ডেটা' থাকা দরকার নেই। ফাইল সিস্টেমটিতে সংকোচন করা যেতে পারে। যাতে আপনি সমস্ত সরঞ্জামের জন্য প্লেইন পাঠ্যটি ব্যবহার করতে পারেন এবং ডিস্কের কোনও অপচয় নষ্ট হবে না।
বার্ড উইলক πφ

2
@ JefréN। যদি আমি tail -fএকটি মাল্টি-গিগাবাইট লগ ফাইলটিতে চালিত করি তবে এটি ফাইলের শেষে চলে যায় ('পঠন' ছাড়াই 'সন্ধান করুন' ব্যবহার করে) এবং তারপরে ফাইলটির শেষ প্রান্তে পড়তে এবং প্রদর্শন করে। এটি পুরো ফাইলটি সংক্ষেপিত / ডিকোড করার দরকার নেই।
ক্রিসডাব্লু

49

এখানে প্রচুর বিতর্কিত অনুমান রয়েছে।

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

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

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


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

5
আমি "এসএসডি যেখানে লেখাগুলি সীমাবদ্ধ সেগুলি" বলতে ওপি বলতে কী বোঝায় তা হ'ল এসএসডি-তে একটি সীমাবদ্ধ লেখার / মুছার চক্র রয়েছে এবং কোনও সেক্টরে খুব বেশি লেখার ফলে ডিভাইসের পরিষেবা জীবন হ্রাস পেয়েছে। তার মানে এই নয় যে লেখাগুলি হারিয়ে গেছে।
তুলাইনস কর্ডোভা

4
@ তুলিনস কর্ডোভা: হ্যাঁ, আমি জানতাম তিনি কী বোঝাতে চেয়েছিলেন।
রবার্ট হার্ভে

2
@ ডকসালভাজার: আমি অন্যথায় দৃ didn't়তার সাথে বলিনি।
রবার্ট হার্ভে

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

36

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

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

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

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

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

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

  • আপনি প্রচুর পরিমাণে কাঠামোগত ডেটা লিখছেন
  • লগগুলি বিশেষত দ্রুত তৈরি করতে হবে
  • আপনার "সাপোর্ট শর্তাবলী" এর অধীনে এগুলি বিশ্লেষণের দরকার নেই

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

সম্পাদনা

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


1
এমনকি ইউনিক্স /var/log/utmp/ ডাব্লুটিটিএমপি বাইনারি হয় । তারা বর্তমানে কোন টিটিতে লগ ইন করেছেন তা রেকর্ড করে (যাতে তারা কেবল বৃদ্ধি পায় না) তবে তারা লগইনের একটি রূপ। (এবং তাদের সস্তাভাবে পার্স করতে সক্ষম হওয়াই দরকারী, যেহেতু বিভিন্ন সাধারণ কমান্ডগুলি whoঠিক এটি করে))
পিটার কর্ডেস

1
@ পিটারকর্ডস আবার, সংজ্ঞায়িত ডেটা কাঠামোগত রেকর্ড এবং অবশ্যই, সমস্ত স্কেলে গতি এবং আকার সেই দিনগুলিতে ফিরে গুরুত্বপূর্ণ বিষয় ছিল।
SusanW

9

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

সতর্কতা: ফুবার্সের সারিতে গত 90 সেকেন্ডের মধ্যে 517 আইটেম বৃদ্ধি পেয়েছে। যদি এটি প্রতিদিন প্রায় একবার হয়, তবে চিন্তার কিছু নেই nothing যদি এটি প্রায়শই ঘটে বা দ্রুত ধারাবাহিকতায় ঘটে থাকে তবে আপনি ফুবার অ্যাপ্লিকেশনটিতে যে পরিমাণ র্যাম উপলব্ধ তা পরীক্ষা করতে পারেন। যদি এটি ইভেন্ট 12345 এর সাথে একসাথে ঘটে থাকে তবে মনে হচ্ছে আপনি কোনও অপ্রচলিত ডাটাবেস ব্যবহার করছেন এবং ডেটা ক্ষতি রোধ করতে আপনি + 1-555-12345 এ আরও ভাল কল করতে পারেন।

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

ডান্নো, "517" এবং "90" সহ কিছু।

এবং কোনওভাবেই সহায়ক নয়।


9
এমন নয় যে উল্লেখ খোঁজার উইন্ডোজ ইভেন্ট লগ কিছু দুঃস্বপ্ন হতে পারে। এটি অবশ্যই একটি সাধারণ পাঠ্য ফাইলের জন্য আমাকে দীর্ঘায়িত করে।
মাইকেল হ্যাম্পটন

4
অপেক্ষা করুন। আপনি কি একই সাথে দুটি (বা আরও) লগ এন্ট্রি দেখতে চান ? বেশ ভাল।
এরিক টাওয়ার

2
আমার উত্তর হতে চলেছে "উইন্ডোজ ইভেন্ট লগগুলি, যথেষ্ট পরিমাণে বলা হয়েছে"।
ক্রেগ

ইভেন্ট ভিউয়ার নিখোঁজ সম্পদের আমার অভিজ্ঞতা সরঞ্জাম না যে সঙ্গে হয়েছে আছে ইনস্টল করার সম্পদ, কিন্তু যে মামলা, AFAIR মধ্যে, এখনও প্রতিবেদনের প্রোগ্রাম থেকে প্রকৃত তথ্য একটি লাইন নীচে, এর উইন্ডোজ শেষ হবার পর তার ' রিসোর্সটি অনুপস্থিত বা দূষিত হতে পারে "স্পিল"
আন্ডারস্কোর_ডে

5

পাঠ্য এবং বাইনারি মধ্যে নির্বাচন করার আগে আপনি দুটি প্রধান প্রশ্ন জিজ্ঞাসা করতে পারেন:

  • আমার শ্রোতা কে?
  • আমার কোন বিষয়বস্তু জানাতে হবে?

একটি সাধারণ মতামত একটি লগ বার্তা শ্রোতা একটি মানুষ হয়। এটি অবশ্যই নিখুঁত অনুমান নয়, কারণ প্রচুর লগ ক্রলিং স্ক্রিপ্ট রয়েছে তবে এটি একটি সাধারণ বিষয় common এই ক্ষেত্রে, তথ্যগুলি এমন একটি মাধ্যমের মধ্যে পৌঁছে দেওয়া বোধগম্য যা মানুষ স্বাচ্ছন্দ্য বোধ করে। পাঠ্যটির এই মাধ্যমটি হওয়ার দীর্ঘকালীন traditionতিহ্য রয়েছে।

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

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


5

টিএল; ডিআর: আকারটি আসলে কিছু যায় আসে না, তবে ব্যবহারের সুবিধে হয়

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

  1. লগগুলি অত্যন্ত অপ্রয়োজনীয় তথ্য যা খুব ভালভাবে সংকোচিত হবে: আমার অভিজ্ঞতায় সংকুচিত লগ ফাইলগুলি দেখা খুব কমই নয় যেগুলির আকার মূল ফাইলের আকারের 5% বা তার চেয়ে কম। ফলস্বরূপ, কোনও পাঠ্য বা বাইনারি ফর্ম্যাট ব্যবহারের লগগুলির দীর্ঘ সময়ের স্টোরেজে কোনও পরিমাপযোগ্য প্রভাব থাকতে হবে না।

  2. আমরা যে ফর্ম্যাটটি চয়ন করি না কেন, লগগুলি একটি দীর্ঘমেয়াদী স্টোরেজ প্ল্যাটফর্মে লগ ফাইলগুলিকে সংকুচিত করে এবং প্রেরণ করে এমন একটি "লগ ফাইল সিঙ্ক" বাস্তবায়ন না করা হলে লগগুলি দ্রুত একটি সার্ভার ডিস্ক পূরণ করবে। বাইনারি ফর্ম্যাট ব্যবহার করা এটি কিছুটা ধীর করতে পারে তবে 10 একটি ফ্যাক্টর দ্বারা পরিবর্তন করাও এতো গুরুত্বপূর্ণ নয়।

বাইনারি লগ ফর্ম্যাট বনাম পাঠ্য

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

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

(কিছু সময় আগে, আমি এই সম্পর্কে একটি ব্লগ পোস্ট লিখেছিলাম ।)


4

লগ ফাইলগুলি পাঠ্য বিন্যাসে রয়েছে কারণ এগুলি যে কোনও ধরণের পাঠ্য সম্পাদক ব্যবহার করে বা কনসোল কমান্ডের মাধ্যমে সামগ্রীগুলি প্রদর্শন করে সহজেই পড়া যায়।

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

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


3

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

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


1
একইভাবে, এম্বেডড ডিভাইস থেকে 9,600 বাউড সিরিয়াল পোর্টের মাধ্যমে এমসবেড করা ডিভাইস থেকে পিসিতে রিয়েল-টাইম লগ ইন করার চেষ্টা করার সময়, ওভারফ্লোগুলি রোধ করার জন্য প্রায়শই ডেটা সংকুচিত করা বা বাইনারি ফর্ম্যাট ব্যবহার করার পরামর্শ দেওয়া হয়।
মাওগ

3

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

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


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

3

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


2

আমরা আমাদের সফ্টওয়্যারটির দৃust়তা অর্জন এবং বজায় রাখার জন্য ইউনিট পরীক্ষার উপর নির্ভর করি। (আমাদের বেশিরভাগ কোড একটি সার্ভারে চালিত হয়, শিরোনামহীন; লগ ফাইলগুলির অপারেশন পরবর্তী বিশ্লেষণ একটি মূল কৌশল)) আমাদের বাস্তবায়নের প্রায় প্রতিটি শ্রেণী কিছু লগিং করে। আমাদের ইউনিট পরীক্ষার একটি গুরুত্বপূর্ণ অংশ হ'ল 'মক' লগারের ব্যবহার যা ইউনিট পরীক্ষার সময় ব্যবহৃত হয়। একটি ইউনিট পরীক্ষা একটি মক লগার তৈরি করে এবং এটি পরীক্ষিত আইটেমটিকে সরবরাহ করে। এরপরে (যখন দরকারী / যথাযথ) বিশ্লেষণ করে যা লগ হয়েছে (বিশেষত ত্রুটি এবং সতর্কতা)। পাঠ্য-ভিত্তিক লগ ফর্ম্যাটটি ব্যবহার করা 'রিয়েল' লগগুলিতে সম্পাদিত বিশ্লেষণের একই কারণগুলির জন্য এটি অনেক সহজ করে তোলে: আপনার নিষ্পত্তি করার জন্য আরও সরঞ্জাম রয়েছে যা ব্যবহার এবং অভিযোজনে দ্রুত are


2
যদিও অন্য কেউ অবনমিত, আমি এই ধরণের উত্তরটি এখনও মান প্রদান করে তা উল্লেখ করতে চাই, এটি দেখায় যে পাঠ্য-ভিত্তিক লগগুলি আপনার গড় প্রোগ্রামারকে যেভাবে যত্নশীল করে না সেগুলি অনুশীলনের সবচেয়ে খারাপ পর্যায়েও কার্যকর করা যেতে পারে, তবে উচিত। +1
শন উইলসন

সমর্থন মন্তব্যের জন্য ধন্যবাদ। আমি এমন তথ্য সরবরাহ করার চেষ্টা করি যা আমার ধারণা কমপক্ষে কিছু লোকের পক্ষে কার্যকর হবে। আমি যখন যাব তখন এটিই আমি চাই এবং প্রত্যাশা করি।
আর্ট Swri

2

.তিহাসিকভাবে, লগগুলি সরকারী, হাতের লিখিত এবং ঘটনার ক্রমযুক্ত রেকর্ড ছিল। যন্ত্রপাতি যখন ইভেন্টগুলি রেকর্ড করতে সক্ষম হয়ে ওঠে, এগুলি হার্ড-কপির আউটপুট ডিভাইসে যেমন একটি টেলি টাইপ প্রিন্টারে লেখা হয়েছিল, যা স্থায়ী ক্রমবর্ধমান রেকর্ড তৈরি করে তবে এটি কেবল পাঠ্য প্রক্রিয়া করতে পারে এবং মাঝে মাঝে একটি বেল বাজায় ...


2

আমার মেইনফ্রেমের দিনগুলিতে, আমরা কাস্টম ডিজাইনের বাইনারি লগ ফর্ম্যাটটি ব্যবহার করেছি। মূল কারণ স্থান বাঁচানো নয়, কারণ এটি ছিল যে আমরা নতুনদের সাথে পুরানো এন্ট্রিগুলিকে ওভাররাইট করে সীমাবদ্ধ স্থান দখল করতে চাই; আমরা যে সর্বশেষ জিনিসটি চেয়েছিলাম তা হ'ল ডিস্কগুলি পূর্ণ হয়ে যাওয়ার কারণে সমস্যাগুলি সনাক্ত করতে অক্ষম হয়ে পড়ে (1980 সালে ডিস্কের জায়গার জন্য $ 1000 / Mb ব্যয় হত, তাই লোকেরা তাদের প্রয়োজনের চেয়ে বেশি কিনে না)।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.