বিভিন্ন লগ স্তরগুলি কখন ব্যবহার করবেন

Question

বার্তা লগ করার বিভিন্ন উপায় রয়েছে, মৃত্যুর ক্রম অনুসারে:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

কোনটি কখন ব্যবহার করব তা আমি কীভাবে সিদ্ধান্ত নেব?

ব্যবহার করার জন্য একটি উত্তম তাত্পর্যপূর্ণ কি?

Comments

বেশ বিস্তৃত প্রশ্ন। লগিংয়ের আসল পরিস্থিতির উপর নির্ভর করে একাধিক উত্তর সম্ভব। noticeএই সংগ্রহে কেউ মিস করবে কেউ আবার করবে না ...

— ওল্ফ

@ ওল্ফ এই উত্তরক্রমের অধীনে 'নোটিশ' কোথায় পড়বে? কেবল রেকর্ডের জন্য ...

— pgblu

noticeলগ 4j এর মতো কিছু জনপ্রিয় লগিং পরিষেবাগুলি এটি ব্যবহার করে না কারণ সম্ভবত অনুপস্থিত।

— pgblu

Answer 1

আমি সাধারণত নিম্নলিখিত সম্মেলনে সাবস্ক্রাইব করি:

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

Comments

কেন আপনি মার্জ তথ্য এবং সতর্ক করতে পারবেন না! ?? আসলে "তথ্য" ...

— এমপি

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

— গ্রে উইজার্ডেক্স

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

— গ্রে উইজার্ডেক্স

@ গ্রেউজার্ডেক্স, আমি মনে করি যে অন্য কারণটি হ'ল এটি ক্লায়েন্ট যা 4XX পেয়েছিল বা এটি যে সার্ভার পাঠিয়েছে is প্রথম ক্ষেত্রে, আমি ইআরআরওর (ওএমজি, এটি আমার দোষ আমি সঠিক অনুরোধ প্রস্তুত করতে পারি না) ব্যবহার করতে আরও আগ্রহী, যদিও পরবর্তী ক্ষেত্রে আমি

— সতর্কতা অবলম্বন করব

আমি সন্দেহ করি যে এটি সত্য - Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).। লগার.ডেবগ কেবলমাত্র বিকাশকারীদের পক্ষে উত্পাদনের ক্ষেত্রে খুব বাজে সমস্যাগুলি অনুসন্ধান করার জন্য যেমনIf you want to print the value of a variable at any given point inside a for loop against a condition

— আরবিটি

Answer 2

আপনি কি এই বার্তাটি মধ্যরাতে কোনও সিস্টেম প্রশাসককে বিছানা থেকে নামিয়ে আনতে চান?

• হ্যাঁ -> ত্রুটি
• না -> সতর্ক করুন

Comments

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

— প্যাক্সডিয়াবল্লো

FATALযখন সিসাদমিন ঘুম থেকে ওঠে, তখন সিদ্ধান্ত নেয় যে সে এর জন্য যথেষ্ট পরিমাণ অর্থ প্রদান করে না, এবং ঘুমাতে ফিরে যায়।

— মতিন উলহাক

Answer 3

আমি লগ ফাইল দেখার দৃষ্টিকোণ থেকে তীব্রতা সম্পর্কে চিন্তা করা আরও সহায়ক বলে মনে করি।

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

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

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

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

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

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

Comments

আমি পছন্দ করি যে এটি শ্রোতা সম্পর্কে চিন্তাভাবনা করে। যে কোনও যোগাযোগের কী (এবং লগ বার্তাগুলি যোগাযোগের একটি রূপ) আপনার শ্রোতা এবং এটির কী প্রয়োজন তা চিন্তা করা।

— sleske

ডিবাগ সম্পর্কে <-> ট্রেস: নোট করুন যে অন্তত জাভা-স্থলে, অগ্রাধিকারের ক্রমটি "ডিবাগ> ট্রেস" is এটি কনভেনশনটি সমস্ত লগিং ফ্রেমওয়ার্ক যা আমি জানি (এসএলএফ 4 জে, লগব্যাক, লগ 4 জ, অ্যাপাচি কমন্স লগিং, লগ 4 নেট, এনলগ) জানি। সুতরাং ডিবাগ <ট্রেস আমার কাছে অস্বাভাবিক বলে মনে হচ্ছে।

— sleske

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

— গ্রে উইজার্ডেক্স

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

— থানাটোস

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

— এডিটিসি

Answer 4

"লগার" কী আছে তার একটি তালিকা এখানে।

---

অ্যাপাচি লগ 4 জ: §1 , §2

1. FATAL:

   [ v1.2 : ..] অত্যন্ত ত্রুটিযুক্ত ত্রুটিযুক্ত ঘটনা যা সম্ভবত অ্যাপ্লিকেশনটি বাতিল করতে পরিচালিত করবে।

   [ v2.0 : ..] গুরুতর ত্রুটি যা অ্যাপ্লিকেশনটি চালিয়ে যাওয়া থেকে আটকাবে।

2. ERROR:

   [ v1.2 : ..] ত্রুটি ইভেন্টগুলি যা এখনও অ্যাপ্লিকেশনটি চালিয়ে যেতে পারে।

   [ v2.0 : ..] অ্যাপ্লিকেশনটিতে ত্রুটি, সম্ভবত পুনরুদ্ধারযোগ্য।

3. WARN:

   [ v1.2 : ..] সম্ভাব্য ক্ষতিকারক পরিস্থিতি।

   [ v2.0 : ..] এমন ইভেন্ট যা সম্ভবত [ sic ] ত্রুটির দিকে পরিচালিত করতে পারে।

4. INFO:

   [ v1.2 : ..] তথ্যমূলক বার্তা যা মোটা দানাদার স্তরে অ্যাপ্লিকেশনটির অগ্রগতি তুলে ধরে highlight

   [ v2.0 : ..] তথ্যমূলক উদ্দেশ্যে ইভেন্ট।

5. DEBUG:

   [ v1.2 : ..] সূক্ষ্ম দানাযুক্ত তথ্য ইভেন্টগুলি যা কোনও অ্যাপ্লিকেশন ডিবাগ করার জন্য সবচেয়ে কার্যকর are

   [ v2.0 : ..] সাধারণ ডিবাগিং ইভেন্ট।

6. TRACE:

   [ v1.2 : ..] এর চেয়ে সূক্ষ্ম-বর্ণযুক্ত তথ্যমূলক ইভেন্ট DEBUG।

   [ v2.0 : ..] সূক্ষ্ম-দানাযুক্ত ডিবাগ বার্তা, সাধারণত অ্যাপ্লিকেশনটির মাধ্যমে প্রবাহ ক্যাপচার করে।

---

অ্যাপাচি এইচটিপিডি (যথারীতি) ওভারকিলের জন্য যেতে পছন্দ করে: §

1. উত্স :

   জরুরী অবস্থা - সিস্টেম অব্যর্থ।

2. সতর্কতা :

   অবিলম্বে পদক্ষেপ নেওয়া উচিত [তবে সিস্টেমটি এখনও ব্যবহারযোগ্য)

3. সমালোচক :

   সমালোচনামূলক শর্ত [তবে তাত্ক্ষণিকভাবে ব্যবস্থা গ্রহণের প্রয়োজন নেই]।

   • " সকেট: একটি সকেট পেতে ব্যর্থ, শিশুকে প্রস্থান করে "

4. ত্রুটি :

   ত্রুটির শর্ত [তবে সমালোচনামূলক নয়]।

   • " স্ক্রিপ্ট শিরোনামের অকাল শেষ "

5. সতর্ক করুন :

   সতর্কতা শর্ত। [ত্রুটির কাছাকাছি, তবে ত্রুটি নয়]

6. বিজ্ঞপ্তি :

   সাধারণ তবে উল্লেখযোগ্য [ উল্লেখযোগ্য ] অবস্থা।

   • " httpd: ধরা পড়েছে SIGBUS, কোর ডাম্প করার চেষ্টা করছে ... "

7. তথ্য :

   তথ্যবহুল [এবং অলক্ষিত]।

   • [" সার্ভার x ঘন্টা ধরে চলছে " "]

8. ডিবাগ :

   ডিবাগ-স্তরের বার্তা [, অর্থাত্ ডি-বাগিংয়ের জন্য লগ করা বার্তাগুলি ]]।

   • " কনফিগারেশন ফাইল খোলা হচ্ছে ... "

9. trace1 → trace6 :

   বার্তা ট্রেস করুন [, অর্থাত্ ট্রেসিংয়ের জন্য লগ করা বার্তাগুলি ]।

   • " প্রক্সি: এফটিপি: নিয়ন্ত্রণ সংযোগ সম্পূর্ণ "
   • " প্রক্সি: সংযোগ: দূরবর্তী প্রক্সিটিতে সংযোগের অনুরোধ পাঠানো "
   • " ওপেনসেল: হ্যান্ডশেক: শুরু করুন "
   • " বুফার্ড এসএসএল ব্রিগেড, মোড 0, 17 বাইট থেকে পড়া "
   • " মানচিত্রের অনুসন্ধান ব্যর্থ:map=rewritemap key=keyname "
   • " ক্যাশে অনুসন্ধান ব্যর্থ, নতুন মানচিত্রের সন্ধানে বাধ্য করা "

10. ট্রেস 7 → ট্রেস 8 :

    প্রচুর পরিমাণে ডেটা ডাম্পিং বার্তা, ট্রেস করুন

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

---

অ্যাপাচি কমন্স-লগিং: §

1. মারাত্মক :

   গুরুতর ত্রুটি যা অকাল সমাপ্তির কারণ হয়। এগুলি স্থিতি কনসোলে তত্ক্ষণাত দৃশ্যমান হবে বলে আশা করুন।

2. ত্রুটি :

   অন্যান্য রানটাইম ত্রুটি বা অপ্রত্যাশিত শর্ত। এগুলি স্থিতি কনসোলে তত্ক্ষণাত দৃশ্যমান হবে বলে আশা করুন।

3. সতর্ক করুন :

   অবহেলিত এপিআই এর ব্যবহার, এপিআই এর দুর্বল ব্যবহার, 'প্রায়' ত্রুটি, অন্যান্য রানটাইম পরিস্থিতি যা অনাকাঙ্ক্ষিত বা অপ্রত্যাশিত, তবে অগত্যা "ভুল" নয়। এগুলি স্থিতি কনসোলে তত্ক্ষণাত দৃশ্যমান হবে বলে আশা করুন।

4. তথ্য :

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

5. ডিবাগ :

   সিস্টেমের মাধ্যমে প্রবাহ সম্পর্কে বিস্তারিত তথ্য। এগুলি কেবল লগগুলিতে লেখা হবে বলে আশা করি।

6. ট্রেস :

   আরও বিস্তারিত তথ্য। এগুলি কেবল লগগুলিতে লেখা হবে বলে আশা করি।

এন্টারপ্রাইজ ব্যবহারের জন্য অ্যাপাচি কমন্স-লগিং "সেরা অনুশীলনগুলি" ডিবাগ এবং তথ্যের মধ্যে পার্থক্য তৈরি করে তারা কোন ধরণের সীমানা অতিক্রম করে তার উপর ভিত্তি করে তৈরি করে।

সীমানা অন্তর্ভুক্ত:

• বাহ্যিক সীমানা - প্রত্যাশিত ব্যতিক্রম।

• বাহ্যিক সীমানা - অপ্রত্যাশিত ব্যতিক্রম।

• অভ্যন্তরীণ সীমানা

• উল্লেখযোগ্য অভ্যন্তরীণ সীমানা।

( আরও তথ্যের জন্য কমন্স-লগিং গাইড দেখুন See )

Answer 5

আপনি যদি সমস্যা থেকে সেরে উঠতে পারেন তবে এটি একটি সতর্কতা। যদি এটি চালিয়ে যাওয়া চালিয়ে যাওয়া রোধ করে তবে এটি একটি ত্রুটি।

Comments

তবে, ত্রুটি এবং মারাত্মক ত্রুটির মধ্যে পার্থক্য কী?

— ব্যবহারকারী 192472

একটি ত্রুটি এমন কিছু যা আপনি করেন (উদাহরণস্বরূপ একটি অস্তিত্বের ফাইলটি পড়ুন), মারাত্মক ত্রুটি এমন কিছু যা আপনার দ্বারা করা হয় (উদাহরণস্বরূপ স্মৃতিশক্তি ফুরিয়ে যায়)।

— Ignacio Vazquez-Abram

@ IgnacioVazquez-Abram আপনার পার্থক্য করার পদ্ধতিটি আমি পছন্দ করি। তবে আপনার মন্তব্যটি কিসের ভিত্তিতে তৈরি? আফসোস আইওএস বিকাশকারীদের মধ্যে এটি একটি কনফিগারেশন লেখার কনভেনশন যা fatalErrorকোনও ফাইল উপস্থিত না থাকায় সম্পর্কিত । মূলত এটি আপনি যা বলেছেন তার বিপরীত।

— মধু

@ মধু: একটি মোবাইল পরিস্থিতিতে অনুপস্থিত ফাইলটিকে মারাত্মক ত্রুটি হিসাবে বিবেচনা করা যুক্তিসঙ্গত।

— ইগনাসিও ওয়াজকেজ-আব্রামস

Answer 6

আমি Syslog তীব্রতা মাত্রা গ্রহণ বলতে চাই: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY। Http://en.wikedia.org/wiki/Syslog#Severity_levels
দেখুন

তাদের বেশিরভাগ ব্যবহারের ক্ষেত্রে পর্যাপ্ত পরিমাণে সূক্ষ্ম তীব্রতা স্তর সরবরাহ করা উচিত এবং বিদ্যমান লগ-পার্সারদের দ্বারা স্বীকৃত। আপনার অবশ্যই অবশ্যই একটি উপসেট বাস্তবায়নের স্বাধীনতা রয়েছে, যেমন DEBUG, ERROR, EMERGENCYআপনার অ্যাপের প্রয়োজনীয়তার উপর নির্ভর করে।

আসুন আমরা তৈরি প্রতিটি আলাদা অ্যাপের জন্য আমাদের নিজস্ব স্ট্যান্ডার্ড নিয়ে আসার পরিবর্তে যুগে যুগে এমন কিছুকে প্রমিত করে তুলি। একবার আপনি লগগুলি একত্রিত করা শুরু করে এবং বিভিন্নগুলি জুড়ে নিদর্শনগুলি সনাক্ত করার চেষ্টা করলে এটি সত্যই সহায়তা করে।

Comments

আমার কোডগুলিতে কীভাবে জিনিসগুলি কার্যকর হচ্ছে তা দেখতে আমার একটি ট্রেস লগ দরকার। সিসলগ এটি ঠিক করতে কী করে?

— কার্ল মরিসন

ট্রেসগুলি সাধারণত এমন কিছু নয় যা আপনি সিসলোগের মাধ্যমে প্রেরণ করতে চান এবং আমি মনে করি আপনি নিজের ইন্টারেক্টিভ ডিবাগিং সেশনগুলির জন্য এই স্তরটি যুক্ত করতে মুক্ত?

— কেভিজ

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

— এডিটিসি

(cont'd) অ্যাপ্লিকেশনটি পরিপক্ক হওয়ার সাথে সাথে আপনি প্রয়োজনে আরও স্তরে প্রসারিত করতে পারেন। উভয় DEBUGএবং TRACEবিকাশকারীদের গ্রানুলারিটি নিয়ন্ত্রণ করতে পছন্দ করে। আর ERRORপ্রসারিত অন্যান্য স্তরগুলোর পছন্দ করতে CRITICAL, ALERT, EMERGENCYত্রুটি তীব্রতা পার্থক্য এবং তীব্রতার উপর ভিত্তি করে কর্ম নির্ধারণ।

— এডিটিসি

Answer 7

সতর্কতাগুলি থেকে আপনি পুনরুদ্ধার করতে পারেন। ত্রুটিগুলি আপনি পারবেন না। এটি আমার ধর্মীয়, অন্যের অন্যান্য ধারণা থাকতে পারে।

উদাহরণস্বরূপ, আসুন আমরা বলি যে আপনি "Angela Müller"আপনার অ্যাপ্লিকেশনটিতে নামটি প্রবেশ করুন / আমদানি করুন (এর উপর umlaut নোট করুন u) আপনার কোড / ডাটাবেসটি কেবল ইংরেজী হতে পারে (যদিও এটি সম্ভবত এই দিন এবং বয়সের মধ্যে না হওয়া উচিত ) এবং তাই সতর্ক করতে পারে যে সমস্ত "অস্বাভাবিক" অক্ষরগুলি নিয়মিত ইংরেজি অক্ষরে রূপান্তরিত হয়েছিল।

ডাটাবেসে সেই তথ্যটি লেখার চেষ্টা করার সাথে এবং সরাসরি 60 সেকেন্ডের জন্য কোনও নেটওয়ার্ক ডাউন বার্তা ফিরে পাওয়ার সাথে এর বিপরীতে। এটি একটি সতর্কতার চেয়ে ত্রুটি বেশি।

Comments

যদি ডাটাবেসটি কোনও নির্দিষ্ট অক্ষরে থাকে যা উমলাউটকে অন্তর্ভুক্ত করে না তবে এই ইনপুটটিকে প্রত্যাখ্যান করতে হবে।

— কোচাইজ রুহুলেসিন

— কোচিজে, পৃথিবীটি

Answer 8

অন্যরা যেমন বলেছে, ত্রুটিগুলি সমস্যা; সতর্কতা হ'ল সম্ভাব্য সমস্যা।

বিকাশে, আমি প্রায়শই সতর্কতা ব্যবহার করি যেখানে আমি দৃ as় ব্যর্থতার সমতুল্য রাখতে পারি তবে অ্যাপ্লিকেশন কাজ চালিয়ে যেতে পারে; এটি আমাকে কেসটি আসলে ঘটেছে কিনা তা আবিষ্কার করতে সক্ষম করে তোলে বা এটি আমার কল্পনাও করে।

তবে হ্যাঁ, এটি পুনরুদ্ধারযোগ্য এবং বাস্তবতার দিকগুলিতে নেমে যায়। আপনি যদি পুনরুদ্ধার করতে পারেন তবে এটি সম্ভবত একটি সতর্কতা; যদি এটি আসলে কিছু ব্যর্থ হয় তবে এটি একটি ত্রুটি।

Answer 9

আমি মনে করি যে অ্যাপ্লিকেশন-স্তরের লগিংয়ের জন্য SYSLOG স্তরের বিজ্ঞপ্তি এবং ALERT / EMERGENCY মূলত অতিরিক্তভাবে অতিরিক্ত প্রয়োজন - যখন ক্রিয়টিক্যাল / অ্যালার্ট / ইমারজেনসি কোনও অপারেটরের পক্ষে দরকারী সতর্কতা স্তর হতে পারে যা কোনও অ্যাপ্লিকেশন অ্যাডমিনের কাছে এটি একই রকম হয় মারাত্মক. এবং আমি কেবল একটি নোটিশ বা কিছু তথ্য দেওয়ার মধ্যে যথেষ্ট পার্থক্য করতে পারি না। তথ্যটি লক্ষণীয় না হলে, এটি আসলে তথ্য নয় :)

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

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

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

Answer 10

আরএফসি 5424 থেকে, সিসলগ প্রোটোকল (আইইটিএফ) - পৃষ্ঠা 10:

প্রতিটি বার্তা অগ্রাধিকার দশমিক তীব্রতা স্তর সূচক আছে। এগুলি তাদের সংখ্যাসূচক মানগুলির সাথে নিম্নলিখিত টেবিলে বর্ণিত আছে। তীব্রতার মানগুলি 0 থেকে 7 সহ অন্তর্ভুক্ত থাকতে হবে।

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

Answer 11

গ দিন,

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

বিভিন্ন ধরণের লগ বার্তাগুলি দেখতে পাওয়া বেদনাদায়ক যেখানে তীব্রতা এবং নির্বাচিত লগ স্তরের অসঙ্গতি রয়েছে।

বিভিন্ন লগিং স্তরের সম্ভব হলে উদাহরণ সরবরাহ করুন। এবং একটি বার্তায় লগ ইন করা তথ্যের সাথে সামঞ্জস্য থাকুন।

আছে HTH

Answer 12

আমি অন্যদের সাথে সম্পূর্ণরূপে একমত এবং ভাবি যে গ্রে উইজার্ডেক্স এটি সর্বোত্তম বলেছিল said

আমি যা যা যোগ করতে পারি তা হ'ল এই স্তরগুলি সাধারণত তাদের অভিধান সংজ্ঞাগুলির সাথে মিলে যায় তাই এটি এত কঠিন হতে পারে না। সন্দেহ হলে এটিকে ধাঁধার মতো আচরণ করুন। আপনার নির্দিষ্ট প্রকল্পের জন্য, আপনি লগ করতে চাইতে পারেন এমন সমস্ত কিছু মনে করুন।

এখন, আপনি কী মারাত্মক হতে পারে তা বুঝতে পারেন? আপনি জানেন মারাত্মক মানে, তাই না? সুতরাং, আপনার তালিকার কোন আইটেমগুলি মারাত্মক।

ঠিক আছে, এটি মারাত্মকভাবে মোকাবেলা করা হয়েছে, এখন ত্রুটিগুলি দেখুন ... ধুয়ে ফেলুন এবং পুনরাবৃত্তি করুন।

মারাত্মক, বা ত্রুটির নীচে, আমি পরামর্শ দেব যে আরও তথ্য সর্বদা কমের চেয়ে ভাল, সুতরাং "উপরের দিকে" ভুল হয়। নিশ্চিত না এটি তথ্য বা সতর্কতা কিনা? তারপর এটি একটি সতর্কতা করুন।

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

এখানে কিছু উদাহরন:

মারাত্মক - মেমরি, ডাটাবেস, ইত্যাদি বরাদ্দ করতে পারে না - চালিয়ে যেতে পারে না।

ত্রুটি - বার্তার কোনও উত্তর নেই, লেনদেন বাতিল করা হয়েছে, ফাইল সংরক্ষণ করতে পারে না ইত্যাদি

সতর্কতা - সম্পদের বরাদ্দ X% (80% বলুন) এ পৌঁছেছে - এটি এমন একটি চিহ্ন যা আপনি নিজের দিকটি পুনরায় মাত্রায় দেখতে চান।

তথ্য - ব্যবহারকারী লগ ইন / আউট, নতুন লেনদেন, ফাইল ক্র্যাটেড, নতুন ডি / বি ক্ষেত্র, বা ক্ষেত্র মোছা হয়েছে।

ডিবাগ - অভ্যন্তরীণ ডেটা স্ট্রাকচারের ডাম্প, ফাইলের নাম এবং লাইন নম্বর সহ যে কোনও কিছুই ট্রেস স্তর।
ট্রেস - ক্রিয়াটি সফল / ব্যর্থ হয়েছে, d / b আপডেট হয়েছে।

Answer 13

একটি ত্রুটি এমন কিছু যা ভুল, সাধারণ ভুল, এর চারপাশে কোনও উপায় নয়, এটি সংশোধন করা দরকার।

সতর্কতা হ'ল এমন একটি প্যাটার্নের চিহ্ন যা ভুল হতে পারে, কিন্তু তারপরেও তা নাও হতে পারে।

এটি বলার পরে, আমি একটি সতর্কতার একটি ভাল উদাহরণ নিয়ে আসতে পারি না যা ত্রুটিও নয়। আমি এর দ্বারা যা বোঝাতে চাইছি তা হ'ল যদি আপনি কোনও সতর্কতা লগ করার সমস্যায় যান তবে আপনি অন্তর্নিহিত সমস্যাটিও ঠিক করতে পারেন।

তবে, "এসকিএল এক্সিকিউশনটি খুব বেশি সময় নেয়" এর মতো জিনিসগুলি একটি সতর্কতা হতে পারে, যখন "এসকিএল এক্সিকিউশন ডেডলকস" একটি ত্রুটি, তাই সম্ভবত এর পরেও কিছু ঘটনা রয়েছে।

Comments

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

— ক্রাস্ট

আমিও যে একটি ত্রুটি বিবেচনা করবে। কিছু ক্ষেত্রে, বিষয়বস্তুগুলি "পাঠ্য" (ডেটাটাইপের অর্থ নয়), যার অর্থ সম্ভবত এটি কেটে ফেলা ঠিক is অন্য ক্ষেত্রে এটি একটি কোড, যেখানে বিটগুলি কেটে ফেলা এটি দুর্নীতিগ্রস্ত করবে বা এর অর্থ পরিবর্তন করবে, যা ঠিক নয়। আমার মতে, আমি কী বলতে চাইছিলাম তা অনুমান করার চেষ্টা করা সফ্টওয়্যারটির পক্ষে নয়। আমি যদি 200 ক্যারেক্টার স্ট্রিংটিকে একটি কলামে জোর করার চেষ্টা করি যা কেবল 150 টি অক্ষর নেয় তবে এটি আমি জানতে চাই। আমি অন্যদের দ্বারা তৈরি করা পার্থক্যের মতো এখানেও করি, আপনি যদি পুনরুদ্ধার করতে পারেন তবে এটি একটি সতর্কতা, তবে তারপরে ... আপনার লগ ইন করা দরকার?

— লাসে ভি কার্লসেন

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

— লারাড্ডা

Answer 14

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

Answer 15

নিম্নলিখিতগুলি ব্যবহারের আগে আমি সিস্টেমগুলি তৈরি করেছি:

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

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

Answer 16

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

আপনি যদি সতর্কতা স্তরে ক্যাপচার করছিলেন এবং সতর্কতার সাথে সম্পর্কিত কিছু ডিবাগ তথ্য চান, তবে সতর্কতাটি পুনরায় তৈরি করতে অক্ষম হলে কী হবে?

সবকিছু ক্যাপচার এবং পরে ফিল্টার করুন!

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

সবকিছু ক্যাপচার করুন এবং পরে ফিল্টার করুন !!

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

Answer 17

আমার দুটি সেন্ট FATALএবং TRACEত্রুটি লগ স্তরের সম্পর্কে ।

ERROR যখন কিছু ব্যর্থ (ব্যতিক্রম) ঘটে।

FATAL আসলে ডাবল ব্যর্থ: ব্যতিক্রম পরিচালনা করার সময় যখন ব্যতিক্রম ঘটে occur

ওয়েব পরিষেবার জন্য এটি বোঝা সহজ।

1. অনুরোধ আসলো। ইভেন্ট হিসাবে লগ ইনINFO
2. সিস্টেমটি কম ডিস্কের স্থান সনাক্ত করে। ইভেন্ট হিসাবে লগ ইনWARN
3. অনুরোধটি পরিচালনা করতে কিছু ফাংশন ডাকা হয়। শূন্য দ্বারা বিভাগ প্রক্রিয়া করার সময় ঘটে। ইভেন্ট হিসাবে লগ ইনERROR
4. ওয়েব সার্ভিসের ব্যতিক্রম হ্যান্ডলারকে শূন্য দ্বারা বিভাগ পরিচালনা করতে বলা হয়। ওয়েব পরিষেবা / ফ্রেমওয়ার্কটি ইমেল প্রেরণ করতে চলেছে, তবে মেলিং পরিষেবাটি অফলাইনে থাকায় এটি করা যায় না। এই দ্বিতীয় ব্যতিক্রমটি সাধারণত পরিচালনা করা যায় না, কারণ ওয়েব পরিষেবাদির ব্যতিক্রম হ্যান্ডলার ব্যতিক্রম প্রক্রিয়া করতে পারে না।
5. বিভিন্ন ব্যতিক্রম হ্যান্ডলারকে ডেকে আনা হয়েছে। ইভেন্ট হিসাবে লগ ইনFATAL

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

সুতরাং আপনার প্রোগ্রামে সাধারণত আপনি কি DEBUG, INFOএবং WARNলগিং। এবং আপনি যদি কিছু ওয়েব পরিষেবা / ফ্রেমওয়ার্ক লেখেন তবেই আপনি ব্যবহার করবেন FATAL। এবং আপনি যখন অ্যাপ্লিকেশন ডিবাগিং করছেন আপনি TRACEএই ধরণের সফ্টওয়্যার থেকে লগিং পাবেন ।

Answer 18

আমি কেবল তিনটি স্তর ব্যবহার করার পরামর্শ দিচ্ছি

1. মারাত্মক - যা অ্যাপ্লিকেশনটি ভেঙে দেবে।
2. তথ্য - তথ্য
3. ডিবাগ - কম গুরুত্বপূর্ণ তথ্য