একটি উইন্ডোজ ইভেন্ট লগে 4 জিবি ছাড়িয়ে যাওয়ার কী কী প্রভাব রয়েছে?

Question

আমি এই মাইক্রোসফ্ট কেবিটি পেয়েছি যা উইন্ডোজ ২০০৮ / ভিস্তা পর্যন্ত অপারেটিং সিস্টেমের জন্য সর্বাধিক সেট করার প্রস্তাবিত ইভেন্ট লগকে অন্তর্ভুক্ত করে , যা সর্বোচ্চ 4 গিগাবাইটের প্রস্তাব দেয় এবং আরও কিছু অস্পষ্ট উল্লেখ দেখেছি যে 4 জিবি-র চেয়ে বড় ইভেন্ট লগ কমপক্ষে প্রস্তাবিত নয় ২০০৮ আর 2, তবে আমি ভাবছি কোন ইভেন্টের লগ এই আকার ছাড়িয়ে গেলে আসলে কী ঘটে?

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

Comments

আপনার প্রশ্নটি আমাকে উদ্দীপনা জাগিয়ে তোলে, এবং আমার মনিব আমাকে আজ হতাশ করেছে, আমি আজ রাতে আমাদের কোনও সার্ভারে ইভেন্টটি লগ হতে দেব এবং ফলাফলটি আমার বিদ্যমান উত্তরে পোস্ট করে দেব, তবে যেমনটি বলেছি, 4 জিবি ইএসএন নেই bit৪ বিট ওএসের ক্ষেত্রে কোনও হার্ড সীমা নয়, এবং আমার অভিজ্ঞতাটি হ'ল এমনকি ৩২ বিট অ্যাপস এবং এপিআইগুলি সাধারণত ফাইলগুলি> ৪ জিবি হ্যান্ডেল করে।

— আশাহীন N00b 21

আহ, দেখে মনে হচ্ছে এটি> 4 জিবি ইভেন্ট লগ ফাইল তৈরি করতে কিছুটা দীর্ঘ হতে পারে। আমাদের ব্যস্ততম ডোমেন নিয়ামক 20 মিনিট আগে লগটি সাফ করেছেন।

— আশাহীন N00b

Answer 1

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

সার্ভার ২০০৮-এর 4 জিবি সতর্কতা সেই 32-বিট সীমাটির কারণে যা প্রায়শই 4 জিবি-তে দেখা হয়। একটি bit৪ বিট সিস্টেমে, আপনার এটি 16 টিবি (বা 64৪, নির্ভর করে) পর্যন্ত বাড়তে দেওয়া উচিত, যদিও আমি জানি না যে সীমাটি পরীক্ষা করার সাথে কারও কাছে পৌঁছেছে।

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

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

#Adapted from: http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/08/how-can-i-check-the-size-of-my-event-log-and-then-backup-and-archive-it-if-it-is-more-than-half-full.aspx

Param($logName = "security",$backupFolder = "C:\backupLogs")

Function Get-EventLog([string]$logName)
{
 $log = Get-WmiObject -Class Win32_NTEventLogFile -filter "LogFileName = '$logName'"
 If($log.FileSize / $log.MaxFileSize -ge .9)
  {
   "Log is at least 90% full. Backing up now."
   Backup-EventLog($log)
  } #end if
 Else 
 { 
   "Not backed up: $logName is only " + ($log.FileSize / $log.MaxFileSize).tostring("N2") +  " percent full" 
 } #end else
} #end Get-EventLog

Function Backup-EventLog($log)
{
 $folder = Join-Path -Path $BackUpFolder -ChildPath (Get-Date).ToString("MMddyy_hhmm")
 If(-not(Test-Path $folder)) 
   { 
     New-Item -path $folder -itemtype Directory -force | out-Null
   }
  $rtn = $log.BackupEventLog("$folder\$logName.evt").ReturnValue
  If($rtn -eq 0)
    {
     $log.ClearEventLog() | out-null
    } #end if
 ELSE 
   {
    "$logName could not be cleared. Backup ended with $($rtn)" 
  }
} #end Backup-EventLog

# *** ENTRY POINT ***
Get-EventLog -logname $logname

Comments

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

— আমি বলছি মনিকা পুনরায়

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

— ইসমাইল মিগুয়েল

Answer 2

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

যে কোনও উপায়ে তৈরি হওয়া বড় লগ ফাইলগুলি পার্সিংয়ের জন্য, দুটি ভাল বিকল্প দেখা যায়:

1) বর্তমান জিইউআই পরিচালনা করতে পারে তার চেয়ে লগটিকে দ্রুত পার্স করুন বা 2) লগটিকে আলাদা আলাদা ফাইলে বিভক্ত করুন।

আমি নিশ্চিত যে 2) এর জন্য কয়েকটি সহজেই উপলভ্য ইউটিলিটি রয়েছে so সুতরাং আমি 1 এ ফোকাস করব)।

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

$timeframe = (get-date) - (new-timespan -day 1)
$userevt = Get-WinEvent -ComputerName <specify> -FilterHashTable @{LogName='Security'; Data='<enter username here>'; StartTime=$timeframe}

re userevt এখন ইভেন্টগুলির একটি সংগ্রহ। ম্যাচের সংখ্যার উপর নির্ভর করে খুব সহজেই অল্প সংখ্যক ইভেন্ট পড়তে আপনি এটি ফর্ম্যাট-তালিকার মাধ্যমে পাইপ করতে পারেন। মাঝারি সংখ্যার জন্য, একই কাজ করুন তবে আউটপুটটিকে কোনও ফাইলে পুনর্নির্দেশ করুন:

$userevt | format-list > <outputfile>.txt

প্রচুর সংখ্যার জন্য, ফিল্টারিং শুরু করুন (বলুন যে আপনি উপরে যে ব্যবহারকারীকে আমরা পেয়েছি তার মধ্যে একটি লকআউট ইভেন্টের জন্য কলার কম্পিউটারটি চান):

$userevt | %{if ($_.message -match "Caller Computer .*") {$matches[0]}}

এটি প্রতিটি লকআউট ইভেন্টের জন্য একক-লাইন ফলাফল প্রদর্শন করবে। উপরের প্রক্রিয়াগুলি ২০০৮ R2 এ 4 জিবি লগের জন্য সাধারণত 1-4 মিনিট সময় নেয়।

দ্বিতীয়ত, বিশেষত যে কোনও 2003 মেশিনের আপনি পরিচালনা করতে পারেন, আপনি ইভেন্ট ভিউয়ারের বাম অংশে একটি নির্দিষ্ট লগ ফাইলটিতে ডান ক্লিক করতে পারেন এবং 'হিসাবে লগ ফাইলটি সেভ করুন' নির্বাচন করতে পারেন।

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

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

Answer 3

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

3 মাসের মধ্যে আমরা 2008r2 এবং 2012r2 সার্ভার সার্ভারগুলিতে লগইন করতে পারিনি। লগন "স্বাগতম" স্ক্রিনে আটকে যাবে। খোলা হচ্ছে এমন বড় ফাইলগুলিকে সামঞ্জস্য করার জন্য আমরা সার্ভারের মেমরি 20gb এ বাড়িয়ে দেওয়ার চেষ্টা করেছি এবং সার্ভারটি এখনও রেগে রয়েছে। আমরা ইঞ্জিনের 1 গিগাবাইটের সুপারিশ অনুসরণ করে এবং পুরানো ফাইল সংরক্ষণাগার এ পুরোপুরি ওভাররাইট করার সময় সামঞ্জস্য করার সিদ্ধান্ত নিয়ে শেষ করেছি।

আমাদের যদি প্রয়োজন হয় তবে 180 দিনের পুরানো ফাইলগুলি পরিষ্কার করার জন্য আমাদের এই স্ক্রিপ্ট রয়েছে তবে আমরা সম্ভবত ফাইলগুলি ঠিক জায়গায় রাখতে পারি।

get-childitem -Path "C:\Windows\System32\winevt\Logs" |
  where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
  remove-item –whatif

https://www.manageengine.com/products/active-directory-audit/help/getting-started/event-log-size-retention-settings.html