SNMP监控一些常用OID的总结
|
系统参数（1.3.6.1.2.1.1） |
|||
|
OID |
描述 |
备注 |
请求方式 |
|
.1.3.6.1.2.1.1.1.0 |
获取系统基本信息 |
SysDesc |
GET |
|
.1.3.6.1.2.1.1.3.0 |
监控时间 |
sysUptime |
GET |
|
.1.3.6.1.2.1.1.4.0 |
系统联系人 |
sysContact |
GET |
|
.1.3.6.1.2.1.1.5.0 |
获取机器名 |
SysName |
GET |
|
.1.3.6.1.2.1.1.6.0 |
机器坐在位置 |
SysLocation |
GET |
|
.1.3.6.1.2.1.1.7.0 |
机器提供的服务 |
SysService |
GET |
|
.1.3.6.1.2.1.25.4.2.1.2 |
系统运行的进程列表 |
hrSWRunName |
WALK |
|
.1.3.6.1.2.1.25.6.3.1.2 |
系统安装的软件列表 |
hrSWInstalledName |
WALK |
|
网络接口（1.3.6.1.2.1.2） |
|||
|
OID |
描述 |
备注 |
请求方式 |
|
.1.3.6.1.2.1.2.1.0 |
网络接口的数目 |
IfNumber |
GET |
|
.1.3.6.1.2.1.2.2.1.2 |
网络接口信息描述 |
IfDescr |
WALK |
|
.1.3.6.1.2.1.2.2.1.3 |
网络接口类型 |
IfType |
WALK |
|
.1.3.6.1.2.1.2.2.1.4 |
接口发送和接收的最大IP数据报[BYTE] |
IfMTU |
WALK |
|
.1.3.6.1.2.1.2.2.1.5 |
接口当前带宽[bps] |
IfSpeed |
WALK |
|
.1.3.6.1.2.1.2.2.1.6 |
接口的物理地址 |
IfPhysAddress |
WALK |
|
.1.3.6.1.2.1.2.2.1.8 |
接口当前操作状态[up|down] |
IfOperStatus |
WALK |
|
.1.3.6.1.2.1.2.2.1.10 |
接口收到的字节数 |
IfInOctet |
WALK |
|
.1.3.6.1.2.1.2.2.1.16 |
接口发送的字节数 |
IfOutOctet |
WALK |
|
.1.3.6.1.2.1.2.2.1.11 |
接口收到的数据包个数 |
IfInUcastPkts |
WALK |
|
.1.3.6.1.2.1.2.2.1.17 |
接口发送的数据包个数 |
IfOutUcastPkts |
WALK |
|
CPU及负载 |
|||
|
OID |
描述 |
备注 |
请求方式 |
|
. 1.3.6.1.4.1.2021.11.9.0 |
用户CPU百分比 |
ssCpuUser |
GET |
|
. 1.3.6.1.4.1.2021.11.10.0 |
系统CPU百分比 |
ssCpuSystem |
GET |
|
. 1.3.6.1.4.1.2021.11.11.0 |
空闲CPU百分比 |
ssCpuIdle |
GET |
|
. 1.3.6.1.4.1.2021.11.50.0 |
原始用户CPU使用时间 |
ssCpuRawUser |
GET |
|
.1.3.6.1.4.1.2021.11.51.0 |
原始nice占用时间 |
ssCpuRawNice |
GET |
|
. 1.3.6.1.4.1.2021.11.52.0 |
原始系统CPU使用时间 |
ssCpuRawSystem. |
GET |
|
. 1.3.6.1.4.1.2021.11.53.0 |
原始CPU空闲时间 |
ssCpuRawIdle |
GET |
|
. 1.3.6.1.2.1.25.3.3.1.2 |
CPU的当前负载，N个核就有N个负载 |
hrProcessorLoad |
WALK |
|
. 1.3.6.1.4.1.2021.11.3.0 |
ssSwapIn |
GET |
|
|
. 1.3.6.1.4.1.2021.11.4.0 |
SsSwapOut |
GET |
|
|
. 1.3.6.1.4.1.2021.11.5.0 |
ssIOSent |
GET |
|
|
. 1.3.6.1.4.1.2021.11.6.0 |
ssIOReceive |
GET |
|
|
. 1.3.6.1.4.1.2021.11.7.0 |
ssSysInterrupts |
GET |
|
|
. 1.3.6.1.4.1.2021.11.8.0 |
ssSysContext |
GET |
|
|
. 1.3.6.1.4.1.2021.11.54.0 |
ssCpuRawWait |
GET |
|
|
. 1.3.6.1.4.1.2021.11.56.0 |
ssCpuRawInterrupt |
GET |
|
|
. 1.3.6.1.4.1.2021.11.57.0 |
ssIORawSent |
GET |
|
|
. 1.3.6.1.4.1.2021.11.58.0 |
ssIORawReceived |
GET |
|
|
. 1.3.6.1.4.1.2021.11.59.0 |
ssRawInterrupts |
GET |
|
|
. 1.3.6.1.4.1.2021.11.60.0 |
ssRawContexts |
GET |
|
|
. 1.3.6.1.4.1.2021.11.61.0 |
ssCpuRawSoftIRQ |
GET |
|
|
. 1.3.6.1.4.1.2021.11.62.0 |
ssRawSwapIn. |
GET |
|
|
. 1.3.6.1.4.1.2021.11.63.0 |
ssRawSwapOut |
GET |
|
|
.1.3.6.1.4.1.2021.10.1.3.1 |
Load5 |
GET |
|
|
.1.3.6.1.4.1.2021.10.1.3.2 |
Load10 |
GET |
|
|
.1.3.6.1.4.1.2021.10.1.3.3 |
Load15 |
GET |
|
|
内存及磁盘（1.3.6.1.2.1.25） |
|||
|
OID |
描述 |
备注 |
请求方式 |
|
.1.3.6.1.2.1.25.2.2.0 |
获取内存大小 |
hrMemorySize |
GET |
|
.1.3.6.1.2.1.25.2.3.1.1 |
存储设备编号 |
hrStorageIndex |
WALK |
|
.1.3.6.1.2.1.25.2.3.1.2 |
存储设备类型 |
hrStorageType[OID] |
WALK |
|
.1.3.6.1.2.1.25.2.3.1.3 |
存储设备描述 |
hrStorageDescr |
WALK |
|
.1.3.6.1.2.1.25.2.3.1.4 |
簇的大小 |
hrStorageAllocationUnits |
WALK |
|
.1.3.6.1.2.1.25.2.3.1.5 |
簇的的数目 |
hrStorageSize |
WALK |
|
.1.3.6.1.2.1.25.2.3.1.6 |
使用多少，跟总容量相除就是占用率 |
hrStorageUsed |
WALK |
|
.1.3.6.1.4.1.2021.4.3.0 |
Total Swap Size(虚拟内存) |
memTotalSwap |
GET |
|
.1.3.6.1.4.1.2021.4.4.0 |
Available Swap Space |
memAvailSwap |
GET |
|
.1.3.6.1.4.1.2021.4.5.0 |
Total RAM in machine |
memTotalReal |
GET |
|
.1.3.6.1.4.1.2021.4.6.0 |
Total RAM used |
memAvailReal |
GET |
|
.1.3.6.1.4.1.2021.4.11.0 |
Total RAM Free |
memTotalFree |
GET |
|
.1.3.6.1.4.1.2021.4.13.0 |
Total RAM Shared |
memShared |
GET |
|
.1.3.6.1.4.1.2021.4.14.0 |
Total RAM Buffered |
memBuffer |
GET |
|
.1.3.6.1.4.1.2021.4.15.0 |
Total Cached Memory |
GET |
|
|
.1.3.6.1.4.1.2021.9.1.2 |
Path where the disk is mounted |
dskPath |
WALK |
|
.1.3.6.1.4.1.2021.9.1.3 |
Path of the device for the partition |
dskDevice |
WALK |
|
.1.3.6.1.4.1.2021.9.1.6 |
Total size of the disk/partion (kBytes) |
dskTotal |
WALK |
|
.1.3.6.1.4.1.2021.9.1.7 |
Available space on the disk |
dskAvail |
WALK |
|
.1.3.6.1.4.1.2021.9.1.8 |
Used space on the disk |
dskUsed |
WALK |
|
.1.3.6.1.4.1.2021.9.1.9 |
Percentage of space used on disk |
dskPercent |
WALK |
|
.1.3.6.1.4.1.2021.9.1.10 |
Percentage of inodes used on disk |
dskPercentNode |
WALK |
SNMP v1/v2c/v3
最近在学习SNMP，MIB测试，碰到了SNMP v3，算是比较新的技术，在网上找了很多资料就没找到好的，现在自己研究，总结知识。
本内容的主要点在后面的SNMP v3的配置，纠结了很久，终于搞懂了。
另外SNMP测试可以使用iReasoning MIB,在http://www.ireasoning.com/ 可以下载到。
知识总结：
SNMP是Simple Network Manger Protocol（简单网络管理协议）的缩写，利用SNMP协议，网络管理员可以对网络上的节点进行信息查询、网络配置、故障定位、容量规划，网络监控和管理是SNMP的基本功能。
SNMP是一个应用层协议，为客户机/服务器模式，包括三个部分：
n SNMP网络管理器 //一般即为主机上的网管软件，HP OPENVIEW ，SOLDWIND 等，现今的大规模网络管理都使用此协议， UDP 162 由于trap消息为代理主动发送，此处需要端口号
n SNMP代理 //路由器交换机等网络设备上运行的SNMP程序，负责处理请 求及回应的 UDP 161
n MIB管理信息库 // 预先定义好的树形结构库，单个节点代表一个信息
MIB的相关概念：
下图为MIB的一个示例，很形象，学习过数据结果的一定不陌生，其它不多说。
上图中每个叶子节点代表一个属性，可以囊括网络产品的所有树形，如设备型号，电源状态，接口速率，流量类型等等。
如1.3.6.1.2.1.5 为节点ICMP，在网管软件中获取此节点与子节点的信息，可以得到所有与ICMP有关的信息与操作。
管理信息结构SMI（structure of management information) ：
指定了在 SNMP 的 MIB 中用于定义管理目标的规则。
SMI 是一种语言，是为了确保网络管理数据的语法和语义明确和无二义性而定义的语言。 如整数型，浮点型，二进制型，IP地址类型，数据结构等。
它是定义被管理网络实体中特定数据的语言。
它定义了数据类型、对象模型，以及写入和修改管理信息的规则。读写权限。
目前的SNMP版本：
n SNMPv1 ：简单网络管理协议的第一个正式版本，在RFC1157中定义。
n SNMPv2C：基于共同体（Community-Based）的SNMPv2管理架构, 在RFC1901中定义的一个实验性协议。
n SNMPv3 ：通过对数据进行鉴别和加密，提供了以下的安全特性：
1） 确保数据在传输过程中不被篡改；
2） 确保数据从合法的数据源发出；
3） 加密报文，确保数据的机密性；
SNMPv2C是对SNMPV2的改进，增加了Get-bulk操作机制并且能够对管理工作站返回更加详细的错误信息类型。Get-bulk操作能够一次性地获取表格(注意与walk的区别，walk是获取所有表的信息)中的所有信息或者获取大批量的数据，从而减少请求-响应的次数。避免多次getnext.
SNMP管理操作:
SNMP协议中的NMS和Agent之间的交互信息，定义了6种操作类型：
1） Get-request操作：NMS从Agent提取一个或多个参数值。
2） Get-next-request操作：NMS从Agent提取一个或多个参数的下一个参数值。
3） Get-bulk操作：NMS从Agent提取批量的参数值；一个表格，SNMPV1不支持
4） Set-request操作：NMS设置Agent的一个或多个参数值。节点要有可写属性
5） Get-response操作：Agent返回的一个或多个参数值，是Agent对NMS前面3个操作的响应操作。
6） Trap操作：Agent主动发出的报文，通知NMS有某些事情发生。
将某些用户和一个组关联，再将某个组与某个视图关联。
snmp-server view view-name oid-tree {include | exclude} //定义可以被访问或者排除的MIB
snmp-server group groupname {v1 | v2c |v3 {auth | noauth | priv}} [read readview] [write writeview] [access {[ipv6 ipv6_aclname] [aclnum | aclname] }] //创建组并和视图关联
Ruijie(config)# snmp-server user username roupname {v1 | v2 | v3 [encrypted] [auth {md5|sha } auth-password ] [priv des56 priv-password] } [access {[ipv6 ipv6_aclname] [aclnum | aclname] }] //配置用户和组关联
配置实例：
1、snmpv1/v2模式均只要一条命令：
snmp-server comm. gaodong rw //gaodong相当于共享的密码，为明文传输
snmp-ser enable traps //开启trap通告
snmp host 192.168.225.147 traps gaodong //trap发往的主机地址
2、SNMP V3的配置
①认证不加密型：
snmp-server user gduser gdgroup v3 encrypted auth md5 gdong //用户名，组，认证方式，认证密码
snmp-server group gdgroup v3 auth read default write default //认证组赋予权限，auth为只认证不加密，其中default为默认的view视图，此view可自行定义，但有的设备不支持
snmp-server host 192.168.45.96 traps version 3 auth gduser //TRAP通告地址。指定用户名
snmp-server enable traps
snmp-server community gd rw
②、认证加密型：
snmp-server user gduser gdgroup v3 encrypted auth md5 gdong priv des56 gaod //指定认证加密的类型，密码，用户与组关联
snmp-server group gdgroup v3 priv read default write default //定义组的权限，priv为既认证又加密
snmp-server host 192.168.45.96 traps version 3 priv gduser
snmp-server enable traps
snmp-server community gd rw
③、不认证，不加密型：
snmp-server user gduser gdgroup v3 //用户名与组关联，指定版本号
snmp-server group gdgroup v3 noauth read default write default //定义组的权限，noauth为既不认证也不加密
snmp-server host 192.168.45.96 traps version 3 noauth gduser
snmp-server enable traps
snmp-server community gd rw
3 包含视图的配置实例：
以下的配置允许SNMPv3的管理者采用认证＋加密模式通过用户名v3user对MIB-2(1.3.6.1.2.1)节点下的管理变量进行设置和查看。采用的认证模式为MD5，使用的认证密码为MD5-Auth，采用DES加密，加密密钥为DES-Priv。同时允许向192.168.65.199以SNMPv3格式发送Trap。发送Trap使用的用户名为v3user,采用认证＋加密模式发送，采用的认证模式为MD5，使用的认证密码为MD5-Auth，采用DES加密，加密密钥为DES-Priv。
(config)# snmp-server view v3userview 1.3.6.1.2.1 include
(config)# snmp-server group v3usergroup v3 priv read v3userview write v3userview
(config)# snmp-server user v3user v3usergroup v3 auth md5 md5-auth priv des56 des-priv
(config)# snmp-server host 192.168.65.199 traps version 3 priv v3user
Article From
http://www.clnchina.com.cn/professional_certs/2011/0627/11299.shtml
设置Active Directory域控制器
正如我们在网络与系统配置专题文章中所提到的那样，我们已将两部服务器设置为对应于内部域“intdomain.com”的Active Directory域控制器。我们借助专用计算机设置了第一个域控制器，并为实现系统冗余而在管理服务器上设置了第二个域控制器。
由于域控制器必须具备既可从Web服务器和命令处理服务器（针对消息队列）、又可从两个已实现群集化的数据库服务器接受访问调用的能力，因此，就必须与后端网络、管理网络或以上两者同时建立连接。
在接下来的章节中，我们将针对设置Active Directory域控制器的分步操作程序以及设置对应于特定域的Active Directory客户端的操作程序加以详细说明。
安装第一个域控制器
请依次执行下列步骤，以便创建一个新的域，并在某一服务器上安装Active Directory服务，然后，将该服务器设定为对应于新建域的第一个域控制器：
在开始菜单上单击运行，并在随后出现的对话框内输入dcpromo，然后，单击确定。上述操作将启动Active Directory安装向导。
在通过欢迎屏幕后，向导程序将要求您为即将安装Active Directory的服务器指定域控制器类型。请保持相关选项的缺省状态，以便将该服务器设置为对应于新建域的域控制器。
接下来，向导程序将要求您生成一个新的域树，或在现有域树中生成新建一个子域。在这个例子中，应针对内部域新建一个域树。
然后，向导程序将要求您新建一个森林，或加入一个现有森林。因为您正在创建第一个域，而且目前尚不存在现成的森林，所以，请保持有关系选项的缺省设置状态，以便创建一个同域树相对应的新森林。
如前所述，Windows 2000所配备的Active Directory服务目前主要将完全合格域名（FQDN）作为首选命名规范加以应用。当向导程序要求您为新建域设定名称时，就请键入同内部域相对应的FQDN（在本例中，应输入“intdomain.com”）。
Active Directory具备针对Windows NT早期版本的向后兼容性，这主要取决于同这些版本命名规范相对应的NetBIOS名称。出于连贯性方面的考虑，我们应选用与NetBIOS名称完全相同的域名。在这个例子中，应接受系统为NetBIOS设定的缺省域名“INTDOMAIN”。
向导程序将在接下来的两个对话框中要求您针对Active Directory数据库与活动日志的存储位置以及共享系统卷加以指定。为实现更加理想的性能表现及可恢复能力，我们建议您将数据库和日志存储在独立硬盘上。为简化操作过程，我们选择接受所有缺省位置。
安装向导将在这个环节尝试同对应于新建域的DNS服务器取得联系。如果对应于新建域的DNS服务器已经存在，并可在网络上被查找到，向导程序便会继续转移到下一个安装步骤；如果网络上并不存在上述DNS服务器，向导程序则将就是否在Active Directory安装过程中基于同一计算机安装并配置DNS服务器、亦或稍后安装DNS服务器向您进行询问。在此，我们建议您保持第一个选项的缺省设置状态，除非您确实需要亲自执行所有DNS资源记录的设置工作。
由安装向导显示的其余对话框将主要用来处理安全保障事宜。根据Duwamish Online案例，如果域内所有计算机都在运行Windows 2000操作系统，就请将仅与Windows 2000服务器相兼容的许可权限选项设定为选中状态。接下来，向导程序将要求您为管理员设定一个专用口令。
最后，向导程序将显示一个总结屏幕，以便就已经设定的选项与您进行确认。如果屏幕上所显示的信息正确无误，就请单击下一步确认。
当配置处理过程执行完毕后，重新启动服务器。
安装第二个域控制器
第二个Active Directory域控制器的安装过程要比第一个域控制器的安装过程简单得多。在启动安装程序之前，应首先确认第二台服务器已具备针对同一网络部分实施访问调用的权限。只有这样，该服务器才能与第一台服务器进行通信联络。此外，您还应为DNS服务器设定IP地址（根据前文所提供的建议，这个地址必须同第一个域控制器相对应），而这个IP地址则可供用来针对充当域控制器的计算机进行定位。
如需设定DNS服务器，则请依次执行下列操作步骤：
右键单击网络邻居，并在随后弹出的快捷菜单上选择属性命令。
从网络与拨号连接对话框内，右键单击本地连接图标，并在随后弹出的快捷菜单上选择属性命令。
说明：如果您的计算机配备有多块与不同网络部分相连的网络适配卡（类似于Duwamish Online网络配置方案），而您又无法对已同内部建立连接的网卡加以确认，那么，您便可通过以物理方式切断与内部网络相连之电缆的做法识别出所需查找的相关连接。这样一来，对应于目标连接的图标便会呈现出已被禁用的状态。请在恢复网络电缆连接之前，为刚刚查找到的连接重新指定相应名称。
选择Internet协议（TCP/IP），并单击属性。
在Internet协议（TCP/IP）属性对话框内，将使用下列DNS服务器地址选项设定为选中状态。
在首选DNS服务器栏内，输入相关IP地址。（如果DNS服务器已作为第一个Active Directory服务器安装过程的组成部分实现了安装，就请为该服务器输入IP地址。有关操作方法请参阅上一章节--“安装第一个域控制器”--中的第8步。）
单击确定，以便使修改生效。
DNS一经设定，您便可着手安装第二个域控制器。
如需安装第二个域控制器，则请依次执行下列操作步骤：
在开始菜单上单击运行，并在随后出现的对话框内输入dcpromo，然后，单击确定。上述操作将启动Active Directory安装向导。
在通过欢迎屏幕后，向导程序将要求您为相关器服务器指定域控制器类型。在此，应选择设置对应于现有域的第二个域控制器。
接下来，向导程序将要求您输入用户名、口令和域名（在这个例子中，请输入“intdomain”）。
根据向导程序提示，为特定域输入完全合格域名，而同这个域相对应的计算机则将成为第二个域控制器。（在这个例子中，请输入“intdomain.com”。）
与您安装第一个Active Directory服务器时的情形相似，向导程序将要求您针对数据库和日志存储位置以及共享系统卷加以指定。为简化操作过程，我们选择接受所有缺省位置。
在完成管理员口令设置工作后，向导程序将要求您在总结屏幕上重新核对并最终确认刚刚设定的信息。请单击下一步开始安装。
请在安装程序执行完毕后重新启动服务器。
设置Active Directory客户端
在Windows 2000安装过程中，向导程序将就是否加入现有域或工作组向您进行询问。如果域控制器在安装时尚不可用，您便只能在晚些时候加入相关域。
在开始执行设置过程前，请先确保计算机已具备针对同一网络部分的访问调用权限，以便使其能够同相关域进行通信联络。在设置第二个域控制器的过程中，您还应为DNS服务器指定相关IP地址。
下列步骤描述了在Windows 2000操作系统中将某一计算机添加至新建域的具体方法。
右键单击我的电脑，并在随后弹出的快捷菜单上选择属性命令。
在系统属性对话框内，先单击网络标识选项卡，再单击属性按钮。
在标识修改对话框内，将域单选框设定为选中状态，并输入完整域名（在这个例子中，请输入“intdomain.com”）。
单击确定，以便确认上述修改。向导程序还将提示您输入域用户名和口令。
重新启动服务器，以便使修改生效。
小结
Active Directory可为改进型消息队列（MSMQ）特性提供所需支持，并在此基础上允许针对公共消息队列加以利用，因而，成为DuwamishOnline.com Web区的首选解决方案。如需获取有关MSMQ和Duwamish Online网络体系结构的更多信息资料，敬请查阅题为消息队列配置的技术文章。而Active Directory在这个配置方案中所产生的次要收益则体现为DNS配置任务的简化，这恰恰是创建数据库群集所不可或缺的关键要素（请参阅创建具备高度可用性的数据库群集）。
如何验证 Active Directory 安装
更多信息
验证 Active Directory 的成功安装是非常重要的。当执行升级后，可以通过验证以下各项来验证是否将服务器提升为域控制器： 1. 默认容器：它们在创建第一个域时自动创建。打开 Active Directory 用户和计算机，然后验证存在以下容器：计算机、用户和 ForeignSecurityPrincipals。
2. 默认的域控制器组织单位：它包含第一个域控制器，另外还用作新 Windows 2000 域控制器的默认容器。打开 Active Directory 用户和计算机，然后验证该组织单位。
3. 默认的第一个站点的名称：在将服务器提升为域控制器的过程中，Dcpromo.exe 程序会确定该域控制器可以成为哪个站点的成员。如果所创建的域控制器是新域控制器林中的第一个域控制器，则会创建一个名为“Default-First-Site-Name”的默认站点，而域控制器将成为该站点的成员，直至配置相应的子网和站点。您可以使用“Active Directory 站点和服务”来验证此项。
4. Active Directory 数据库：Active Directory 数据库就是您的 Ntds.dit 文件。验证它是否存在于 %Systemroot%\Ntds 文件夹中。
5. 全局编录服务器：默认情况下，第一个域控制器会成为全局编录服务器。若要验证此项，请执行以下操作：a. 单击开始，指向程序，单击管理工具，然后单击 Active Directory 站点和服务。
b. 双击站点以将其展开，展开服务器，然后选择您的域控制器。
c. 双击域控制器以展开服务器内容。
d. 该服务器下会显示 NTDS 设置对象。右键单击该对象，然后单击属性。
e. 默认情况下，常规选项卡上会显示已选中的全局编录复选框。
6. 根域：安装第一个域控制器时会创建目录林的根。在我的电脑中验证计算机的网络标识。计算机的域名系统 (DNS) 前缀应该与域控制器所属的域名相匹配。另外，确保计算机已注册正确的计算机角色。若要验证此角色，请使用 net accounts 命令。根据计算机是否为域中的第一个域控制器，计算机角色应显示“主”(primary)或“备份”(backup)。
7. 共享系统卷：Windows 2000 域控制器应该含有位于 %Systemroot%\Sysvol\Sysvol 文件夹中的共享系统卷。若要验证此项，请使用 net share 命令。在安装过程中，Active Directory 还会创建两个标准的策略：“默认域”策略和“默认域控制器”策略（位于 %Systemroot%\Sysvol\Domain\Policies 文件夹中）。这些策略显示为以下全局唯一标识符 (GUID)：
表示“默认域”策略的 {31B2F340-016D-11D2-945F-00C04FB984F9}
表示“默认域控制器”策略的 {6AC1786C-016F-11D2-945F-00C04fB984F9}
8. SRV 资源记录：您必须装有为 Active Directory 安装并配置的 DNS 服务器和相关客户端软件，才能正常地工作。Microsoft 建议使用 Microsoft DNS 服务器，它随 Windows 2000 Server 作为 DNS 服务器提供。但是，Microsoft DNS 服务器并不是必需的。您使用的 DNS 服务器必须支持服务资源记录 (SRV RR) 注释请求文件 (RFC) 2052 以及动态更新协议 (RFC 2136)。使用 DNS Manager Microsoft Management Console (MMC) 管理单元来验证为每个 DNS 区域创建了适当的区域和资源记录。Active Directory 在以下文件夹中创建其 SRV RR：• _Msdcs/Dc/_Sites/Default-first-site-name/_Tcp
• _Msdcs/Dc/_Tcp
在这些位置，将显示以下服务的 SRV RR： • _kerberos
CLARiiON MetaLUN详解（二） - LUN的基本概念
Nagios & Cacti & Zabbix.
One of my professional duties in my past ten years was monitoring systems. Even my diploma thesis was dedicated to distributed monitoring (altough my professor sucked badly ). Apart from a few custom-programmed scripts to analyze special situations (e.g. proxy clusters) I used tools that fellow administrators will find familiar: Nagios and Cacti. And another less famous text-configuration-based monitoring tool called Cricket. That worked well somehow but Cricket was hard to learn for my coworkers and Cacti seems unreliable and fundamentally broken in terms of SNMP checking. Besides why do I have to set up availability checking in Nagios and set up checking of the same parameters in another software to draw graphs? Then in 2009 I came across an open-source software I hadn't heard of before: Zabbix. And although it has a few rough edges it seems way more professional than other common tools (the commercial tools I saw were even worse than the open-source variants). I tried it and after a lot of reading and trying it looks like it has a good potential to replace Nagios and Cacti. So I thought I'd sum up my personal experiences with all of these tools.
Nagios. Their makers claim that it's the "industry-standard in IT infrastructure monitoring". Honestly it's a great tool but considering how many years it has been existing it barely evolved. During my diploma thesis in the year 2000 I wrote an alternative software that I called "MrNetwork" that dealt with flaws that Nagios hasn't even fixed today. Still Nagios is a tool I have used for many years and it is very reliable.
Advantages:
- open source
- large community
- many powerful plugins (and own plugins are easy to create: just write a program that prints a one-line string and set a certain return code)
- easy-to-use web frontend
- debugging plugins is moderately simple.
- many thought-out features like host groups or notification options that make your life easier
- dependencies (so that you don't get 100 alerts if a router between the Nagios server and other servers went down)
- nagvis plugin with a great interactive editor that draws nice management-suitable graphs (although I found the ndo2db interface hard to set up at first and a little flaky)
Annoyances:
- The focus is on availability checking - you don't get fancy graphs on the values that are monitored (e.g how the CPU load was over time). So you'll need a second tool and set up the same checks there just to get graphs. But availability percentages are computed automatically.
- Textual configuration that has so many different settings that you need to look up the parameters often. A web-based configuration would probably be better (and is available as an add-on but I haven't tested it).
- Third-party plugins are often very badly programmed and barely documented that it appeared easier to reinvent the wheel. ("Look, ma, I can has plugins.")
- Some views on the web interface are not very obvious (e.g. clicking on the title of a host group gives a nice view of all hosts with all services).
- Many plugins don't have corresponding configuration entries so you have to find out how they work and write configuration entries yourself (and those which are preconfigured take some archeology to find out which parameters they expect). This is a huge time-waster for beginners. And in your services configuration you have to verify your checks configuration to understand the meaning of each parameter. Or do you remember what "check_http 80!john!doe!10!30!body" is supposed to check?
- Every set of parameters of a certain plugin requires a distinct configuration entry. The plugins have dozens of configuration switches that you may need one day. Want to set a timeout on HTTP checks? Write another check configuration. Want to check for a certain string in the HTTP response? Write another check configuration. And so on.
- Most checks are run from the Nagios server itself (the NRPE plugin to do the checks on the respective remote systems somehow refused to work properly here) which is suboptimal and puts a lot of load on the server.
- By default every alert triggers a notification. So if you can't define proper dependencies (e.g. if you want to check your web server in all 30 supported languages and there is some logical error) then you will get spammed with alerts.
Cricket. As Nagios does not support plotting graphs of the monitored values I was in need of another piece of software. Basically Cricket is a frontend to RRD (which stores data in a rotating/round-robin file that keeps data of the last X minutes/hours/days). It has a textual configuration that takes a lot of getting used to. It's main principle is inheritance of settings - they call it "configuration tree". Which means you have a master DEFAULTS file that contains general settings like how to query SNMP. In a subdirectory you define a certain class of devices that you want to monitor - e.g. routers (the DEFAULTS are inherited to this level). Within the routers directory you can just define a list of routers you want to monitor. All settings are inherited from "above" (parent directories). It's more a geek tool for shell lovers. 
Advantages:
- very quick to monitor a large set of similar devices once the general device class is defined
- simple web interface
- very reliable
- can monitor SNMP values (it does this very well) or execute external scripts - thus can be easily extended
- flexible graphing - you can sum up values of two graphs into a new graph (aka "mtargets" - multiple targets)
- different check frequencies can be configured for different subtrees through cron (by default values are collected every 5 minutes - this can be set as low as one minute if needed)
Annoyances:
- the textual configuration is error-prone (leading to funny Perl errors that can be hard to debug)
- users may expect to see all parameters of a certain device instead of all devices having a certain parameters ("Give me the statistics of router42" instead of "Let's see the temperature of all routers we have.")
- customizing the graphs (drawn by RRD tool) isn't trivial
- Frequency of checks is by default 5 minutes. Before RRD can draw the first value of a graph it needs three values. So you'll be waiting 15 minutes before you see any results.
- RRD rounds data by default. So the yearly graph doesn't show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of graphed data is not possible without throwing away the RRD files and manually customizing them. Changing the monitoring frequency (aka "heartbeat") is not possible either without throwing away the data and starting from scratch either.
- No proper built-in alerting in case certain thresholds are exceeded.
Cacti. Another frontend to RRD - and a pretty sophisticated one. Nearly everything is configured through its web interface. And the result is beautiful. It's not entirely reliable though and SNMP support (at least in version 0.8.7b) is a big fail. I like Cacti because its user interface is much better than Cactis but it's less reliable and flexible. 
Advantages:
- Beautiful and (for most features) simple web interface. Nice features like graphs that can be zoomed using Javascript.
- Fine-grained permissions system. So a certain user may get read-only access to a certain subtree.
- The tree where graphs are placed can be configured freely so you get exactly the view you want.
Disadvantages:
- Doesn't hide the RRD magic very well. The user is easily confused by templates, data sources and the like.
- Graphing sometimes just stops working for no reason or values are missing although the server isn't overloaded and other software doesn't show such outages. According to a quick search on the lazyweb I'm not the only one with such effects.
- Setting up many systems means a lot of clicking in the web interface. Setting up new kinds of checks (aka "templates") means even more clicking and is very error-prone.
- The quality of some third-party templates I tested was pretty bad. Creating new templates is tedious, error-prone, frustrating and close to black magic. Nothing for the casual user at least.
- Doesn't handle SNMP correctly (this is the biggest fail in my opinion and makes it unusable here). Although it knows how to query indexes (e.g. ifDescr to get the names of your network interfaces) it just seems to stored fixed OIDs. So once the SNMP tables change the order or number of items (which isn't unusual) then suddenly other parameters get graphed.
- Frequency of checks is by default 5 minutes. Increasing the frequency leads to missing data and wrong results.
- As it uses RRD and needs 3 valid values you won't see that your monitoring fails until you wait 3x5=15 minutes. Not suitable for impatient non-smokers like me. :)
- Debugging failed checks is close to impossible. If a check fails then I find myself clicking around randomly trying to find typos because the alternative is digging around in database entries.
- The web interface is sometimes confusing. A refresh of SNMP tables is done by clicking a unmeaning green circle icon. Adding new items to a list is done by clicking an inconspicious "Add" link that doesn't even look like a link.
- Another UI confusion: graphs are created from the "devices" view. But they are deleted from the "graph management" view.
- No alerting in case certain thresholds are exceeded. Another tool like Nagios would still be needed to notify you.
- Can't sum up multiple targets so monitoring failover clusters doesn't work well.
- RRD averages data when putting daily values into weekly values, weekly into monthly and monthly into yearly. So the yearly graph doesn't show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of detailed graphed data is not possible (RRD). Changing the monitoring frequency (aka "heartbeat") is not possible either without throwing away the data and startin from scratch.
Zenoss. People pointed me to Zenoss which is supposed to offer the same functionality as other monitoring systems but is much more integrated. So this short list is more a quick one-day-experimental expression than a thorough analysis. But in the end much of the fuss is just marketing. Advantages:
- Beautiful web interface
- Nice gimmicks like google maps integration to show you where your servers are down worldwide. Only makes sense when monitoring networks with several/many remote locations.
- Can partly discover parameters of systems automatically. That works for static routes (although I wonder why the heck I want to monitor static routes), file systems and network interfaces. On the other hand processes can't be discovered automatically and have to be set up manually.
- Does not come with a specific agent but plays rather well with plain old SNMP.
- Can monitor Windows through native WMI.
- Large fanbase.
Annoyances:
- Web interface feels slow (Zope is bloated)
- Opaque operation. It does not tell what's actually going on. You can add monitoring and check back later if anything worked they way you want.
- Questionable reliability. In a test here I was monitoring a running process. The process was said to be down and suddenly went to "up" after a while although nothing had changed on the system.
- Just one dashboard. Several dashboards similar to Zabbix "screens" would be nice.
- Configuration and data is spread across MySQL, the internal Zope database storage and RRD files on disk.
- The dependency graph is a nice Flash-based applet displaying how the systems are connected. But it does not show any details about the systems aside from whether they are up or down. And clicking on a host does not take you anywhere but center on the system. Beautiful but it could do so much more than just look beautiful.
- I dislike the way that things are configured. The context menu with the "down arrow" needs to be used. I'd prefer simple "add" or "delete" actions instead of navigating the menu all the time. Looks like Javascript is used wrongly here.
- Limited open-source version. Full version needs to be paid for.
Zabbix (1.8.2). I'm using the backported Zabbix 1.8.2 on Debian Lenny here. Debian Lenny's native 1.4 version lacked some interesting features like proper SNMP handling. Zabbix seems close to the perfect monitoring system I had always dreamt of. I would have designed it differently in some aspects though.
Advantages:
- Availability Monitoring (like Nagios) and graphing (like Cacti) is combined into one tool.
- Highly configurable. User John may just get an SMS for problems of high severity during the weekend and on weekdays get a Jabber message. Even automatic actions like restarting services can be set up.
- The notifications actually help the person who gets the message. "Low disk space on /var on web5" with an additional comment is pretty helpful even when sent via SMS. Notifications are completely customizable with macro variables.
- Very performant. A Zabbix agent can be installed on the systems (available for several operating systems - even for Windows) which gathers the information on each system efficiently. The agent can even call scripts or shell one-liners to gather information. This kind of data collection is very efficient. You will need a server with a good I/O performance and a lot of RAM though so that the database can work efficiently. At first I virtualized Zabbix on a Debian server on a VmWare server with 1 GB of RAM. The database access became so slow that showing graphs or recent events made me store at a busy mouse cursor for up to a minute. On a server with 4 GB of RAM, a large MySQL key buffer and SAS disks the system runs well again.
- Collecting items (gather information about system parameters) happens at set intervals. You don't have to wait for several minutes until you see results (it usually takes half a minute). Each item can have a custom check interval. So you can check for the CPU load every 30 seconds but check the number of free inodes on /home just once an hour.
- Fast web interface.
- Sophisticated monitoring of web sites. Zabbix can follow a path of simulated mouse clicks on a web site and check for functionality and response time.
- Real-time graphs. Values are by default collected every 30 seconds. You quickly see where you are going.
- Permissions system. Certain users can be limited to certain views.
- Gathered data is stored in a database (MySQL, PostgreSQL, SQLite) instead of an unflexible RRD file. Storage periods (aka "history") can be configured freely. Backing up the database is all there is to be done.
- Templates (that can even link to further templates) save time in setting up many checks.
- Graphs (plots of values over time) can be customized like which items are plotted and in what way. Even pie charts are possible.
- Even the parameters that don't get an explicit graph can be graphed at any time. E.g. the agent has tracked the CPU load on a system that you never cared about then you can graph that with one mouse-click.
- Screens and slide shows can be used for high-level views (aka "dashboards") or to be displayed on a big geeky display. They can combine textual display of the status as well as clocks, ad-hoc graphs or predefined graphs.
- Very flexible trigger expressions. For example you can tell a trigger to fire if the average system load over the last 15 minutes is above a certain value. As all measured parameters are stored in a backend database you can use all kinds of mathemical expressions. Like firing a trigger if the average number of running processes during the last half hour is above 50. All other software I tested just has access to the last value gathered.
- Alerting/notifications can be scripted easily by using shell scripts.
- Remote monitoring made easy by using a Zabbix proxy.
- Paid support and paid custom programming available. But the software is completely open-sourced.
- 320 page PDF manual with screenshots and nice references. (Although I'd personally prefer an online help. Currently the "?" link within the web interface just points to the PDF that you can download.)
Annoyances:
- A lot of mouse moving and clicking is required to set up things. For example setting up an alert if the free space on a disk on a certain server is getting too low then you need to set up hosts, items, triggers and actions. Some of the clicking seems redundant. E.g. I didn't find a way to create triggers automtically for a set of checks. If I monitor how full the "/home" partition is then I'd like to set a threshold in the same configuration step.
- Takes a little patience understanding the concepts (because there is no hidden magic) although they make sense after half a day.
- The web interface is crammed full of features. For casual users it's confusing to navigate. In a real-life network you find yourself setting host variables, juggling templates and unless you remember everything you did you will not get a good overview of your configuration. Zabbix is very complex but in my opinion it would need an even better web interface to deal with its featurs properly.
- The map editor was close to unusable at first but has improved in version 1.8. It still takes a lot of time to set up the maps. The map editor could really use fewer mouse clicks to set up the map. I was also missing a feature to add current item values to the map (like the server room temperature or bandwidth on our load balancer). You can just add triggers which occupy a lot of space on the map, too.
- You can just return one value per item. Sometimes you need to return a good/bad value plus some additional information. Nagios for example delivers a return code for OK/WARNING/ALERT and also a text string. In Zabbix this are different items.
- Zabbix gets painful when you want to monitoring different assets of the same kind. Different network interfaces, disk partitions, MySQL instances or web server ports. Templates are pretty useless here. You will have to copy every item and trigger.
- Does not detect the available assets in a monitored server automatically. Imagine that you want to monitor the space on all disk partitions on a system. You will have to copy over or create the check items manually or define all possible checks in a template and disable those you don't need. Cacti handles that better by offering you a list of partitions to monitor. Zenoss can do that partly. The zabbix agent should be able to handle such a service discover automatically. (The built-in "Discovery" feature rather seems to detect new servers in a given network range automatically. But that's something different.)
- Hard to debug. Why was an action not run? Who would get alerted for a certain trigger? Why has a value become 'unknown' without a reason? Of course there are reasons for what Zabbix does. But it often takes clicking and guessing instead of telling the user.
See my Zabbix screencasts if you like to learn more.
See also: Ben Rockwood's blog Further similar software I didn' test thoroughly: Hyperic and Opsview. All of the above tools are great. I'm not meaning to say that "Zenoss is total crap" for example. The differences are subtle. And whether a piece of software suits your needs really depends on your expectations. I love that all this software is available as open-source. And a totally unscientific but fun analysis of the community is counting the number of active people in the respective channels on the Freenode IRC network:
Either Nagios has the largest fanbase or perhaps that means that the majority of people needs help with it. :)
FreeRADIUS + MySQL
-
From:http://www.2cto.com/net/201110/106597.html
一、FreeRADIUS 服务端安装
1.1、下载、编译、安装
wget -c ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.1.11.tar.gz
tar zxf freeradius-server-2.1.11.tar.gz
cd freeradius-server-2.1.11
./configure
make && make install1.2、基本文件的本地测试（选做）
测试是否安装成功，如果不需要与mysql集成，那么就已安装完成。
vim /usr/local/etc/raddb/users
查找 steve Cleartext-Password := "testing" （76-84行）, 取消该段内容的注释。# 大写X，意思是以debug模式运行。
/usr/local/sbin/radiusd -X
#新开一个窗口执行，看到 "Access-Accept packet" 表示成功了，"Access-Reject" 表示失败了。
/usr/local/bin/radtest steve testing localhost 0 testing123二、FreeRadius MySQL 模块配置
2.1、启用MySQL模块支持# 查找"sql.conf”(683行)，去掉#号
vim /usr/local/etc/raddb/radiusd.conf2.2、创建 radius 数据库及表
# 123456是你mysql的root密码
mysqladmin -uroot -p123456 create radius;#修改radius帐号的密码
cd /usr/local/etc/raddb/sql/mysql
sed -i 's/radpass/123456/g' admin.sql
sed -i 's/radpass/123456/g' /usr/local/etc/raddb/sql.confmysql -uroot -p123456 < admin.sql
mysql -uroot -p123456 radius < ippool.sql
mysql -uroot -p123456 radius < schema.sql
mysql -uroot -p123456 radius < wimax.sql
mysql -uroot -p123456 radius < cui.sql
mysql -uroot -p123456 radius < nas.sql2.3、打开从数据库查询nas支持
默认从 "/usr/local/etc/raddb/clients.conf" 文件读取，开启后可从数据库nas表读取。
sed -i 's/\#readclients/readclients/g' /usr/local/etc/raddb/sql.conf2.4、打开在线人数查询支持
# 查找simul_count_query将279-282行注释去掉
vim /usr/local/etc/raddb/sql/mysql/dialup.conf2.5、修改sites-enabled目录配置文件
vim /usr/local/etc/raddb/sites-enabled/default
找到authorize {}模块，注释掉files（159行），去掉sql前的#号（166行）
找到accounting {}模块，注释掉radutmp(385行),注释掉去掉sql前面的#号(395行)。
找到session {}模块，注释掉radutmp（439行），去掉sql前面的#号（443行）。
找到post-auth {}模块，去掉sql前的#号（464行），去掉sql前的#号（552行）。vim /usr/local/etc/raddb/sites-enabled/inner-tunnel
找到authorize {}模块，注释掉files（124行），去掉sql前的#号（131行）。
找到session {}模块，注释掉radutmp（251行），去掉sql前面的#号（255行）。
找到post-auth {}模块，去掉sql前的#号（277行）,去掉sql前的#号（301行）。三、FreeRADIUS 客户端安装与配置
3.1、编译与安装
wget -c ftp://ftp.freeradius.org/pub/freeradius/freeradius-client-1.1.6.tar.gz
tar -zxf freeradius-client-1.1.6.tar.gz
cd freeradius-client-1.1.6
./configure
make && make install3.2、设置通信密码
cat >>/usr/local/etc/radiusclient/servers<<EOF
localhost testing123
EOF其中localhost可以写成服务器IP地址，testing123是认证服务器的连接密码。
注：如果使用的是IP地址，记得同时修改下面设置。1
sed -i 's/localhost/192.168.8.129/g' /usr/local/etc/radiusclient/radiusclient.conf3.3、增加字典
这一步很重要！否则windows客户端无法连接服务器。1
2
wget -c http://small-script.googlecode.com/files/dictionary.microsoft
mv ./dictionary.microsoft /usr/local/etc/radiusclient/
cat >>/usr/local/etc/radiusclient/dictionary<<EOF
INCLUDE /usr/local/etc/radiusclient/dictionary.sip
INCLUDE /usr/local/etc/radiusclient/dictionary.ascend
INCLUDE /usr/local/etc/radiusclient/dictionary.merit
INCLUDE /usr/local/etc/radiusclient/dictionary.compat
INCLUDE /usr/local/etc/radiusclient/dictionary.microsoft
EOF3.4、PPTP启用freeradius插件
这一步网上一些教程没提，但很重要，否则会报错！sed -i 's/logwtmp/\#logwtmp/g' /etc/pptpd.conf
sed -i 's/radius_deadtime/\#radius_deadtime/g' /usr/local/etc/radiusclient/radiusclient.conf
sed -i 's/bindaddr/\#bindaddr/g' /usr/local/etc/radiusclient/radiusclient.conf注：64位系统插件路径是 "/usr/lib64/pppd/2.4.5/radius.so"
cat >>/etc/ppp/pptpd-options<<EOF
plugin /usr/lib/pppd/2.4.5/radius.so
radius-config-file /usr/local/etc/radiusclient/radiusclient.conf
EOF3.5、L2TP启用freeradius插件
L2TP 的道理也一样，你首先安装配置好L2TP/IPSec，并保证能正常使用。注：64位系统插件路径是 "/usr/lib64/pppd/2.4.5/radius.so"
cat >>/etc/ppp/options.xl2tpd<<EOF
plugin /usr/lib/pppd/2.4.5/radius.so
radius-config-file /usr/local/etc/radiusclient/radiusclient.conf
EOF四、用户权限管理
# 连接 MySQL 数据库
mysql -uroot -p123456;
# 使用 radius 数据库
USE radius;
# 添加用户demo，密码demo，注意是在radchec表
INSERT INTO radcheck (username,attribute,op,VALUE) VALUES ('demo','Cleartext-Password',':=','demo');
# 将用户demo加入VIP1用户组
INSERT INTO radusergroup (username,groupname) VALUES ('demo','VIP1');
# 限制同时登陆人数，注意是在radgroupcheck表
INSERT INTO radgroupcheck (groupname,attribute,op,VALUE) VALUES ('normal','Simultaneous-Use',':=','1');
# 其他
INSERT INTO radgroupreply (groupname,attribute,op,VALUE) VALUES ('VIP1','Auth-Type',':=','Local');
INSERT INTO radgroupreply (groupname,attribute,op,VALUE) VALUES ('VIP1','Service-Type',':=','Framed-User');
INSERT INTO radgroupreply (groupname,attribute,op,VALUE) VALUES ('VIP1','Framed-Protocol',':=','PPP');
INSERT INTO radgroupreply (groupname,attribute,op,VALUE) VALUES ('VIP1','Framed-MTU',':=','1500');
INSERT INTO radgroupreply (groupname,attribute,op,VALUE) VALUES ('VIP1','Framed-Compression',':=','Van-Jacobson-TCP-IP');五、启动
cp /usr/local/sbin/rc.radiusd /etc/init.d/radiusd
/etc/init.d/radiusd start原文地址：https://wangyan.org/blog/freeradius-pptp-l2tp-html.html
参考文章：wiki.freeradius.org/SQL%20HOWTO
