স্ট্রাকচার্ড লগিং বনাম বেসিক লগিংয়ের সুবিধা

Question

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

যাইহোক, আমাদের আরও অভিজ্ঞ কোডারগুলির মধ্যে একটি ঠিক এমন কিছু করতে পছন্দ করবে: log.debug("Disk quota {0} exceeded by user {1}", quota, user);ব্যবহার করে log4netএবং তারপরে কেবল মাইএসকিউএল এর বিরুদ্ধে সিলেক্ট স্টেটমেন্টগুলি চালান যেমন:SELECT text FROM logs WHERE text LIKE "Disk quota";

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

Comments

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

— ডিটিআই-ম্যাট

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

— gbjbaanb

@ ডিটিআই-ম্যাট সেরিলোগের দিকে তাকানো থেকে এটি লগ 4 নেট-এর মতো দেখতে পাওয়া যায়। লগ 4 নেট কনফিগারেশনে কাঠামোগত লগগুলি পরিচালনা করে আপনার লগ বার্তাগুলি অনুসন্ধান করার দরকার নেই কারণ আপনার কোনও টেবিলে অতিরিক্ত তথ্য কনফিগার করা এবং লিখিত থাকতে পারে। অনর্গল tipstuff.org/2014/05/… জন্য লগ 4 নেট

— রাবারচিকেনলিডার

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

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

@gbjbaanb সেরিলোগ লগ 4 নেট হিসাবে একইভাবে কাজ করে যখন ইভেন্টগুলি পাঠ্য হিসাবে রেন্ডার করে, তবে আপনি লগগুলি সংরক্ষণের জন্য যদি কোনও কাঠামোগত বিন্যাস ব্যবহার করেন তবে এটি যুক্ত হওয়া যুক্তিগুলির সাথে নাম যুক্ত বৈশিষ্ট্যগুলিকে যুক্ত করবে (অর্থাত্ রিজেক্স ছাড়াই অনুসন্ধান / ফিল্টারিং সমর্থন করার জন্য) with ) এইচটিএইচ!

— নিকোলাস ব্লুমহার্ট

Answer 1

কাঠামোগত পদ্ধতির সাথে দুটি মৌলিক অগ্রগতি রয়েছে যা অতিরিক্ত প্রচেষ্টা ব্যতীত কখনও কখনও পাঠ্য লগগুলি ব্যবহার করে অনুকরণ করা যায় না।

ইভেন্ট প্রকার

আপনি যখন লগ 4 নেট দিয়ে দুটি ইভেন্ট লিখবেন তখন :

log.Debug("Disk quota {0} exceeded by user {1}", 100, "DTI-Matt");
log.Debug("Disk quota {0} exceeded by user {1}", 150, "nblumhardt");

এগুলি অনুরূপ পাঠ্য উত্পাদন করবে:

Disk quota 100 exceeded by user DTI-Matt
Disk quota 150 exceeded by user nblumhardt

তবে, যতক্ষণ না মেশিন প্রসেসিং সম্পর্কিত, তারা বিভিন্ন পাঠ্যের মাত্র দুটি লাইন।

আপনি সমস্ত "ডিস্কের কোটা অতিক্রম" ইভেন্টগুলি সন্ধান করতে চাইতে পারেন, তবে ইভেন্টগুলি সন্ধানের সরল like 'Disk quota%'ঘটনাটি অন্য ঘটনা যেমন ঘটবে তত তাড়াতাড়ি নেমে আসবে:

Disk quota 100 set for user DTI-Matt

পাঠ্য লগিং ইভেন্টটির উত্স সম্পর্কে প্রাথমিকভাবে আমাদের কাছে থাকা তথ্যকে ছুঁড়ে দেয় এবং সাধারণত আরও এবং আরও বিস্তৃত ম্যাচের অভিব্যক্তি সহ লগগুলি পড়ার সময় এটি পুনর্গঠন করতে হয়।

বিপরীতে, যখন আপনি নিম্নলিখিত দুটি সিরিলোগ ইভেন্ট লিখবেন :

log.Debug("Disk quota {Quota} exceeded by user {Username}", 100, "DTI-Matt");
log.Debug("Disk quota {Quota} exceeded by user {Username}", 150, "nblumhardt");

এগুলি লগ 4 নেট সংস্করণে অনুরূপ পাঠ্য আউটপুট তৈরি করে, তবে পর্দার পিছনে "Disk quota {Quota} exceeded by user {Username}" বার্তা টেমপ্লেট উভয় ইভেন্টই বহন করে।

একটি যথাযথ বেসিনে সঙ্গে, আপনি পরে প্রশ্নের লিখতে পারেন where MessageTemplate = 'Disk quota {Quota} exceeded by user {Username}'এবং পেতে ঠিক ঘটনা যেখানে ডিস্ক কোটা অতিক্রম করেছিল।

এটি প্রতি লগ ইভেন্টের সাথে সমগ্র বার্তাটি টেমপ্লেট সংরক্ষণ করতে সুবিধাজনক সব সময় নয়, তাই কিছু কুন্ড একটি সাংখ্যিক মধ্যে বার্তা টেমপ্লেট হ্যাশ EventTypeমান (যেমন 0x1234abcd), অথবা, আপনি লগিং পাইপলাইন একটি enricher যোগ করতে পারেন নিজেকে এই কাজ ।

এটি নীচের পরবর্তী পার্থক্যের চেয়ে আরও সূক্ষ্ম, তবে বড় লগ ভলিউমের সাথে লেনদেন করার সময় একটি বিশাল শক্তিশালী।

কাঠামোগত ডেটা

আবার ডিস্ক স্পেস ব্যবহার সম্পর্কে দুটি ইভেন্ট বিবেচনা করে, কোনও নির্দিষ্ট ব্যবহারকারীর সাথে জিজ্ঞাসা করার জন্য পাঠ্য লগগুলি ব্যবহার করা যথেষ্ট সহজ হতে পারে like 'Disk quota' and like 'DTI-Matt'।

তবে, উত্পাদন ডায়াগনস্টিকস সবসময় এত সোজা থাকে না। কল্পনা করুন যে ডিস্কের কোটা ছাড়িয়ে গেছে এমন ইভেন্টগুলি 125 এমবি এর নীচে রয়েছে?

সেরিলোগের সাহায্যে, এটি বেশিরভাগ সিঙ্কে এর বৈকল্পিক ব্যবহার করে এটি সম্ভব:

Quota < 125

একটি নিয়মিত প্রকাশ থেকে এই ধরণের কোয়েরি তৈরি করা সম্ভব তবে এটি ক্লান্তিকর হয়ে ওঠে এবং সাধারণত শেষ অবলম্বনের পরিমাপ হয়ে শেষ হয়।

এখন এটি একটি ইভেন্ট টাইপ যোগ করুন:

Quota < 125 and EventType = 0x1234abcd

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

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

Comments

আমি এই উত্তর ভালবাসি। খুব ভাল লেখা এবং কোন কারণে আমি ব্যাখ্যা করতে পারি না, আমাকে আমার আসনের কিনারায় রাখে।

— জোকব

Answer 2

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

অনুসন্ধান / অনুসন্ধানের ক্ষেত্রেও বিবেচনা করুন, যেমন :

SELECT text FROM logs WHERE text LIKE "Disk quota";

LIKEশর্তগুলির প্রতিটি textসারি মানের সাথে তুলনা করা প্রয়োজন ; আবার, এটি তুলনামূলকভাবে গণ্য ব্যয়বহুল, বিশেষত যখন ওয়াইল্ডকার্ড ব্যবহার করা হয়:

SELECT text FROM logs WHERE text LIKE "Disk %";

কাঠামোগত লগিংয়ের সাথে, আপনার ডিস্ক-ত্রুটি সম্পর্কিত লগ বার্তাটি JSON এ দেখতে দেখতে লাগবে:

{ "level": "DEBUG", "user": "username", "error_type": "disk", "text": "Disk quota ... exceeded by user ..." }

গঠন এই ধরনের ক্ষেত্রে প্রশংসনীয় সহজে ম্যাপ করতে পারেন যেমন এসকিউএল সারণি কলামে নাম, যেটা ঘুরে মানে লুকআপ আরো নির্দিষ্ট / ঝুরা হতে পারে:

SELECT user, text FROM logs WHERE error_type = "disk";

আপনি সেই কলামগুলিতে সূচিপত্রগুলি রাখতে পারেন যার মানগুলি আপনি ঘন ঘন অনুসন্ধান / সন্ধানের প্রত্যাশা করেন যতক্ষণ না আপনি LIKEএই কলাম মানগুলির জন্য ধারাগুলি ব্যবহার না করেন । আপনি আপনার লগ বার্তাটিকে নির্দিষ্ট বিভাগগুলিতে যত বেশি ভাঙতে পারবেন, তত বেশি লক্ষ্যবস্তু হয়ে আপনি নিজের অনুসন্ধান করতে পারবেন। উদাহরণস্বরূপ, error_typeউপরের উদাহরণে ক্ষেত্র / কলাম ছাড়াও আপনি এমনকি কিছু "error_category": "disk", "error_type": "quota"বা সামসও করতে পারেন ।

আরো গঠন আপনার লগ বার্তা আপনি আছেন, (যেমন আরো অনেক কিছু আপনার পার্সিং / অনুসন্ধানের সিস্টেম fluentd, elasticsearch, kibana) যে কাঠামো সুবিধা নিন এবং বৃহত্তর গতি এবং কম CPU- র / মেমরি সঙ্গে তাদের কর্ম সম্পাদন করতে পারবেন।

আশাকরি এটা সাহায্য করবে!

Comments

+1 যোগ করতে চান এটি কেবল গতি এবং দক্ষতা সম্পর্কে নয়। কাঠামোগত লগিং এবং এভাবে "কাঠামোগত প্রশ্নগুলি" ব্যবহার করার সময় অনুসন্ধানের ফলাফলগুলির প্রাসঙ্গিকতা অনেক বেশি হবে। বিভিন্ন প্রসঙ্গে যে কোনও শব্দই অনুসন্ধান করা ছাড়া এটি আপনাকে অনেকগুলি অপ্রাসঙ্গিক হিট দেয়।

— মার্জন ভেনেমা

আমার কাছ থেকেও +1, আমি মনে করি এটি এটি নখ করে। ইভেন্টের ধরণের ক্ষেত্রেও প্রসারিত করতে নীচে কিছুটা আলাদা সূত্র যুক্ত করা হয়েছে।

— নিকোলাস ব্লুমহার্ট

Answer 3

আপনার অ্যাপ্লিকেশন প্রতিদিন কয়েকশ লগ বার্তা তৈরি করলে আপনি কাঠামোগত লগিং থেকে খুব বেশি সুবিধা পাবেন না। আপনি অবশ্যই যখন প্রতি সেকেন্ডে কয়েক শতাধিক লগ বার্তা পাবেন তখন বিভিন্ন বিস্তৃত অ্যাপ থেকে আসে from

সম্পর্কিত, ELK স্ট্যাকের লগ বার্তাগুলি শেষ হয় এমন সেটআপটি স্কেলগুলির জন্যও উপযুক্ত যেখানে এসকিউএল-এ লগইন বাধা হয়ে দাঁড়ায়।

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

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

স্ট্রাকচার্ডলগিং সহ একটি উদাহরণ। আপনি এই জাতীয় এনএলজি লগারে লগইন করুন:

logger.ExtendedError("Order send failed", new { OrderId = 1234, RestaurantId = 4567 } );

এই কাঠামোগত ডেটা কিবানে যায়। মান লগ এন্ট্রি ক্ষেত্রে 1234সংরক্ষণ করা হয় OrderId। তারপরে আপনি কিবানা কোয়েরি সিনট্যাক্স ব্যবহার করে অনুসন্ধান করতে পারেন যেমন সমস্ত লগ এন্ট্রি যেখানে @LogType:nlog AND Level:Error AND OrderId:1234।

Messageএবং OrderIdএখন কেবলমাত্র ক্ষেত্র যা আপনার প্রয়োজন অনুসারে নির্ভুল বা অযৌক্তিক মিলগুলির জন্য অনুসন্ধান করা যেতে পারে বা গণনাগুলির জন্য একত্রিত। এটি শক্তিশালী এবং নমনীয়।

থেকে StructuredLogging সর্বোত্তম কার্যাভ্যাস :

লগ করা বার্তাটি প্রতিবারের মতো হওয়া উচিত। এটি একটি ধ্রুব স্ট্রিং হওয়া উচিত, আইডি বা পরিমাণের মতো ডেটা মানগুলিতে স্ট্রিং নয়। তারপরে এটি অনুসন্ধান করা সহজ।

লগ করা বার্তাটি পৃথক হওয়া উচিত অর্থাত কোনও সম্পর্কযুক্ত লগ স্টেটমেন্ট দ্বারা উত্পন্ন বার্তার মতো নয়। তারপরে এটি অনুসন্ধানের সাথেও সম্পর্কিত নয় things