【Powershell】Powershell向Windows EventLog中写入日志

概述

Powershell 可以用于向 Windows EventLog 中写入日志，这在以下情况下非常有用：

1. 监控和故障排除：您可以使用 Powershell 脚本将自定义的事件日志写入 Windows EventLog，以便监控系统的状态和执行故障排除。通过记录特定事件和错误，您可以快速发现并解决问题。
2. 自动化任务：如果您有需要定期运行的任务或脚本，您可以使用 Powershell 将任务的执行结果写入事件日志。这样，您可以轻松地追踪任务的执行情况和结果，以便后续分析和处理。
3. 安全审计和合规性：通过将安全相关的事件写入 Windows EventLog，您可以进行安全审计和合规性检查。这包括记录用户登录、权限更改、文件访问等事件，以便后续审查和分析。
4. 日志分析和报告：将重要的操作和事件记录到事件日志中，可以帮助您进行日志分析和生成报告。通过分析事件日志，您可以获得有关系统运行状况、性能问题和异常情况的有用信息。

直接向文本文件写入日志信息不好吗？

实际上它们都有自己适用的场景，我们需要在实际使用过程中制作出选择；使用PowerShell向Windows EventLog中写入日志和向文本文件中写入日志的优缺点对比如下：

向Windows EventLog中写入日志的优点：

1. 集中管理：Windows EventLog是操作系统提供的集中管理日志的机制，可以方便地查看和分析日志信息。
2. 安全性：EventLog可以进行安全设置，只有具有适当权限的用户才能写入和读取日志。
3. 实时性：写入EventLog的日志可以实时显示在事件查看器中，方便实时监控系统状态和故障排查。
4. 可扩展性：可以自定义日志源和事件类型，方便根据需要进行扩展和分类。

向Windows EventLog中写入日志的缺点：

1. 权限要求：向EventLog写入日志需要管理员权限或具有适当权限的用户才能执行。
2. 依赖性：写入EventLog的日志依赖于操作系统的EventLog服务，如果服务停止或出现故障，可能无法写入日志。

向文本文件中写入日志的优点：

1. 简单易用：使用PowerShell或其他编程语言，可以轻松地将日志写入文本文件，不需要特殊的权限或服务支持。
2. 独立性：文本文件是独立于操作系统的，可以在不同平台和环境中使用和传递。
3. 灵活性：可以根据需要自定义日志格式和存储位置。

向文本文件中写入日志的缺点：

1. 分散管理：文本文件分散存储在不同位置，不方便集中管理和查看。
2. 安全性：文本文件的安全性较低，任何具有访问权限的用户都可以读取和修改文件。
3. 实时性：写入文本文件的日志不会实时显示在事件查看器中，需要手动打开文件查看。

综合来看，向Windows EventLog中写入日志适用于集中管理、实时监控和安全性要求较高的场景，而向文本文件中写入日志适用于简单、独立和灵活的场景。选择哪种方式取决于具体的需求和环境。

向Application Log中写入测试日志信息

写入指令：

# 写入事件日志
$eventLog = New-Object System.Diagnostics.EventLog("Application")
$eventLog.Source = "MyScript"
$eventLog.WriteEntry("Hello, World!", [System.Diagnostics.EventLogEntryType]::Information)

写入结果：

当然我们可以在写入时加上更多的参数；使得，日志本身具有实际的意义；比如：

$eventLog = New-Object System.Diagnostics.EventLog("Application")
$eventLog.Source = "MyApplication"
$eventLog.WriteEntry("not found!", "Error", 404)

获取System.Diagnostics.EventLog中的哪些日志可用？

要获取New-Object System.Diagnostics.EventLog("Application")中除了"Application"外的其他日志参数，可以使用以下代码：

$logs = [System.Diagnostics.EventLog]::GetEventLogs()
$availableLogs = $logs | Select-Object -ExpandProperty Log
$availableLogs

这将返回计算机上可用的所有日志的列表。

另一种写入WinLog的方法

PS C:\WINDOWS\system32> Remove-EventLog -Source "MyScript"
PS C:\WINDOWS\system32> # 定义要写入的日志信息
PS C:\WINDOWS\system32> $logMessage = "This is a test log message."
PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32> # 写入系统事件日志
PS C:\WINDOWS\system32> New-EventLog -LogName System -Source "MyScript"
PS C:\WINDOWS\system32> Write-EventLog -LogName System -Source "MyScript" -EntryType Information -EventID 8888 -Message $logMessage
PS C:\WINDOWS\system32>

# 如果New-EventLog -LogName System -Source "MyScript"提示日志源已存在。那么可以使用Remove-EventLog -LogName System -Source "MyScript"删除掉之前的事件源

大家可能注意到，我们创建事件源指定的日志是system；但日志却写入了Application。

对于New-EventLog命令，创建的事件源默认会被添加到注册表的"HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Application"路径下。这意味着事件源会被添加到"Application"日志中，而不是"System"日志中。【为什么会有这么奇葩的设定~~】

Write-EventLog和System.Diagnostics.EventLog区别

Write-EventLog和New-Object System.Diagnostics.EventLog是两种不同的方法来写入日志。以下是它们之间的主要区别：

1. Write-EventLog是PowerShell中的一个内置命令，用于写入事件日志。它提供了一个简单的方法来写入事件日志，不需要额外的代码。它可以直接在PowerShell脚本中使用。
2. New-Object System.Diagnostics.EventLog是使用.NET Framework中的EventLog类创建一个事件日志对象的方法。它需要编写一些额外的代码来实例化和配置EventLog对象，并使用其WriteEntry方法来写入日志。通常在C#或其他.NET语言中使用。

我个人更喜欢使用.NET Framework类的方法；各位运维的同学可能使用Write-EventLog更合适。

经常使用的.net类库都有哪些呢？

在PowerShell编程中，以下是一些常用的.NET类库：

1. System.IO：用于文件和目录操作，如读取、写入和管理文件和文件夹。
2. System.Net：用于网络通信和操作，如发送HTTP请求、处理网络流和Socket编程。
3. System.Management：用于管理和操作Windows管理对象（WMI），如查询系统信息、执行管理任务等。
4. System.Diagnostics：用于处理进程和性能计数器，如启动、停止和监视进程，以及收集性能计数器数据。
5. System.Security：用于处理安全性和加密，如访问控制、加密和数字签名。
6. System.Xml：用于处理XML数据，如读取、写入和转换XML文档。
7. System.Data：用于数据库操作，如连接、查询和更新数据库。
8. System.Collections和System.Collections.Generic：用于处理集合和数据结构，如数组、列表、字典等。
9. System.Text：用于处理字符串和文本，如编码、解码和格式化字符串。
10. System.Threading：用于多线程编程，如创建和管理线程、同步和异步操作等。

这只是一些常见的.NET类库示例，实际上还有更多的类库可以根据具体需求使用。你可以根据你的编程任务和需求来选择和使用适当的.NET类库。

类库非常丰富，基本上可以说能满足你的几乎所有需求。