কোনও ফিফোর মাধ্যমে লগ ইন করুন, তারপরে কোনও ফাইলে পুনর্নির্দেশ করবেন?


8

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

আমরা যা নিয়ে এসেছি তা হ'ল:

  • অ্যাপ্লিকেশনটিতে লিখতে পারে এমন একটি ফিফো তৈরি করুন এবং
  • এর মাধ্যমে নিয়মিত ফাইলে সেই ফিফোর বিষয়বস্তু পুনর্নির্দেশ করুন cat

তা হ'ল সাধারনত যা ছিল:

app --logfile logfile.txt

এখন:

mkfifo logfifo
cat logfifo &> logfile.txt &
app --logfile logfifo

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

(আমাদের কাছে অ্যাপ্লিকেশনটির সোর্স কোড নেই, সুতরাং প্রোগ্রামিং সমাধানগুলি প্রশ্নের বাইরে রয়েছে Also এছাড়াও, অ্যাপ্লিকেশনটি লিখবে না stdout, সুতরাং সরাসরি আলাদা কমান্ডে পাইপিং করা প্রশ্নের বাইরে syslogনয় । তাই কোনও সম্ভাবনা নেই ।)


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


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

Stdout এ লগিং সম্পর্কে আমার উত্তর যদি আপনার আগ্রহী কোনও দিক না হয় তবে আপনি সম্ভবত "অ্যাপ্লিকেশনটি stdout এ লিখবেন না, তাই সরাসরি আলাদা কমান্ডে পাইপিং করা প্রশ্ন থেকে দূরে" প্রশ্ন থেকে বাদ দিতে পারে?
নিকগ্রিম

উত্তর:


6

নোট করুন যে প্রোগ্রামিংয়ে সাধারণত একটি ফিফো প্রয়োজনীয় যেখানে লিখিত পরিমাণটি পড়ার পরিমাণকে ছাড়িয়ে যেতে পারে।

যেমনটি অনুমান করা যায় তেমন কোনও ফিফো পুরোপুরি স্বচ্ছন্দভাবে কাজ করে না তবে অন্যটি পরিচয় করিয়ে দেওয়ার সময় আপনার মূল সমস্যাটি সমাধান করবে।

সম্ভাব্য তিনটি ক্যাভেট রয়েছে।

  1. ফিফোতে লেখা অনির্দিষ্টকালের জন্য অবরুদ্ধ থাকে যদি আরম্ভের সময় অন্য প্রান্তটি কিছু না পড়ছে।
  2. ফিফোর একটি নির্দিষ্ট প্রস্থ K৪ কে রয়েছে যার দ্বারা বাফার সেই বিন্দু দ্বারা পূরণ করা হলে আরও লেখক ব্লক হয়ে যাবে যতক্ষণ না পাঠক ধরা না পড়ে।
  3. পাইপ লেখক যদি মারা যায় বা প্রস্থান করে তবে SIGPIPE দিয়ে হত্যা করা হবে।

এর অর্থ হ'ল আপনার সমস্যাটি (নন-বাফার লেখায় বাফার I / O অনুকরণ করা) সমাধান হয়ে যাবে। এটি কারণ আপনার ফিফোর নতুন 'সীমা' কার্যকরভাবে পাইপ থেকে ডিস্কে যা লেখা থাকে তা লেখার গতি হয়ে যাবে (সম্ভবতঃ I / O বাফার হবে)।

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

আরেকটি বিষয় উল্লেখ করার দরকার হ'ল যদি সার্ভার প্যানিক্স এবং কার্নেল প্রতিক্রিয়া বন্ধ করে দেয় তবে আপনি সেই বাফারের মধ্যে থাকা 64৪ কেটের ডেটা হারাতে পারেন।

এটির সমাধানের আরেকটি উপায় হ'ল tmpfs (/ dev / shm লিনাক্স) এ লগ লিখতে এবং একটি নির্দিষ্ট ডিস্কের স্থানে আউটপুটটি লেজ করা। মেমরি বরাদ্দকরণের ক্ষেত্রে এটির কম সীমাবদ্ধতা রয়েছে (64 কে নয়, সাধারণত 2 জি!) তবে লেখকের কাছে লগ ফাইल्सগুলি পুনরায় খোলার কোনও গতিশীল উপায় না থাকলে (আপনাকে পর্যায়ক্রমে tmpfs থেকে লগগুলি পরিষ্কার করতে হবে)। এই পদ্ধতিতে সার্ভার আতঙ্কিত হলে আপনি আরও অনেক বেশি ডেটা হারাতে পারেন।


এটি সম্পর্কে কিছু ভাল তথ্য /dev/shm। আমরা এটিও বিবেচনা করেছি, যদিও এটি ব্যবহার করতে আমার মন কেড়েছিল tail -f
খ্রিস্টিয়াকক

4
mkfifo logfifo
cat logfifo &> logfile.txt &
app --logfile logfifo

যখন আপনার cat logfifoপ্রক্রিয়াটি মারা যায়, কেউ দুর্ঘটনাক্রমে এটিকে হত্যা করে, বা কেউ দুর্ঘটনাক্রমে এটি ভুল জায়গায় চিহ্নিত করে?

আমার অভিজ্ঞতা হ'ল appইচ্ছাশক্তিটি দ্রুত ব্লক হয়ে যায়। আমি টমক্যাট, অ্যাপাচি এবং কয়েকটি ছোট্ট বিল্ডিং অ্যাপ্লিকেশন দিয়ে চেষ্টা করেছি এবং একই সমস্যায় পড়েছি। আমি কখনই খুব বেশি তদন্ত করে দেখিনি, কারণ loggerবা সাধারণ I / O পুনঃনির্দেশ আমি যা চাই তা করে। আমার সাধারণত লগিং সম্পূর্ণতা প্রয়োজন হয় না, যা আপনি অনুসরণ করার চেষ্টা করছেন। এবং আপনি যেমন বলেছিলেন, আপনি লগার চান না।

লিনাক্স নন-ব্লকিং ফিফোতে (ডিমান্ড লগিংয়ের ক্ষেত্রে) এই সমস্যা নিয়ে কিছু আলোচনা রয়েছে ।


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

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

2

আপনার বিকল্পগুলি অ্যাপ্লিকেশন দ্বারা মোটামুটি সীমাবদ্ধ তবে আপনি যা পরীক্ষা করেছেন তা কার্যকর হবে।

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


শীতল, শুনে আমরা আনন্দিত যে আমরা কেবল এটির সাথেই আসছি না।
খ্রিস্টিয়াকক

2

পরিবেশটি সেন্টোস এবং অ্যাপ্লিকেশনটি একটি ফাইলে লিখেছে ...

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

আপনি যেমন শেল স্ক্রিপ্ট ব্যবহার করতে সক্ষম হবেন:

logger -p daemon.notice -t app < fifo

আপনি পাইপ loggerথেকে catবা ইনপুটও নিতে পারেন tail -f:

tail -f fifo | logger ...
cat fifo | logger ...

একমাত্র সমস্যাটি হ'ল লগ বার্তাটির গুরুত্বের ভিত্তিতে এটি পৃথক করে না (সবকিছুই বিজ্ঞপ্তি ) তবে কমপক্ষে এটি লগ হয়ে যায় এবং একটি কেন্দ্রীয় সার্ভারে হোস্ট-অফকে প্রেরণ করে।

সিসলগ কনফিগার করা আপনি কোন সার্ভারটি ব্যবহার করছেন তার উপর নির্ভর করে। আছে rsyslogএবং syslog-ng(উভয়ই খুব সক্ষম)।

সম্পাদনা : পোস্টার থেকে আরও তথ্য পাওয়ার পরে সংশোধিত।


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

একটি নোটিশ এবং একটি ত্রুটির মধ্যে কোন পার্থক্য নেই? ওহ সত্যি ? মধ্যে কোনো পার্থক্য Slow query detectedএবং Database halted?
মেই

(আমি পোস্টটি আপডেট করেছি))
মেই

1

তুমি লেখ:

এছাড়াও, অ্যাপ্লিকেশনটি এতে লিখবে না stdout...

আপনি কি "ফাইল" এ লগ ইন করার চেষ্টা করেছিলেন /dev/stdout? এটি আপনাকে এমন কিছু করতে সক্ষম করতে পারে:

app --logfile /dev/stdout | logger -t app

এটি কি কোনও ফিফোর চেয়ে আলাদা? গেটছস কি? আমি কোনও বিকল্প খুঁজছি না, প্রতি সে ; আমি তালিকাভুক্ত পদ্ধতিটি শক্তিশালী কিনা তা অন্তর্দৃষ্টি অনুসন্ধান করছি।
এগুলিতে

1
হ্যাঁ, এটি কোনও ফিফোর চেয়ে আলাদা; এটি মূলত একটি ফাইল যা STDOUT এর সাথে সংযুক্ত। সুতরাং আপনি এটি STDOUT এ লগ করতে এবং সেখান থেকে সিসলগ বা অনুরূপ ব্যবহার করতে পারেন। এটি আপনার মূল সমস্যার সমাধান হিসাবে উদ্দিষ্ট, তবে আশা করা যায় যে চলমান অংশ কম থাকায় ফিফোর চেয়ে বেশি শক্তিশালী।
নিকগ্রিম

1

একটি ফিফোতে লিখতে এবং তারপরে অন্য কোনও প্রক্রিয়া কোনও ফাইলে এটি লেখার কোনও অর্থ নেই। কেবলমাত্র সরাসরি ফাইলটিতে সরাসরি লিখুন এবং একবার write()ফিরে আসার পরে এটি কার্নেলের হাতে রয়েছে; অ্যাপ্লিকেশন ক্রাশ হয়ে গেলে এটি ডিস্কে এটি লিখবে।


প্রতিটি লগ বার্তা ফ্লাশ করা হয় : এগুলি ব্লক করে লেখাগুলি। অ্যাপ্লিকেশনটির সোর্স কোড না থাকায় আমাদের এতে কোনও নিয়ন্ত্রণ নেই।
খ্রিস্টিয়াকক

@ ক্রাইসাইক, ঠিক আছে ... তাই সমস্যা কোথায়?
psusi

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

@ ক্রিস্যাককক, ওহ, সুতরাং অ্যাপ্লিকেশনটি বর্তমানে ওএসওয়াইএনসি ব্যবহার করে বা fsync()প্রতিটি লেখার জন্য ডিস্কটি চাপার জন্য অপেক্ষা করে, এবং আপনি কি চান না যে এটি ঘটবে (সিস্টেম ক্র্যাশ হলে ক্ষতির আশঙ্কা হবে)?
psusi

1
@ ক্রিস্যাককক, ড্রাইভের ইন্টারফেসের সাথে এটির কোনও যোগসূত্র নেই, এর সাধারণ অর্থ কেবল কার্নেল এটি ফাইল সিস্টেম ক্যাশে অনুলিপি করেছে (এবং অ্যাপ্লিকেশনটি বাইরে)। যেমনটি আমি আমার উত্তরে বলেছিলাম যে, একবার write()ফিরে আসার পরে, অ্যাপ্লিকেশনটি তার পছন্দসই সমস্ত ক্র্যাশ করতে পারে - যতক্ষণ না কার্নেল ক্রাশ না হয় ততক্ষণ ডেটা ডিস্কে এনে দেবে।
psusi
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.