掌握Web服务器信息——Web服务器探针 (web服务器探针)
Web服务器是指在Internet上提供Web服务的计算机程序或运行该程序的计算机系统，常见的Web服务器软件包括Apache、Nginx、IIS等。Web服务器通常可以通过HTTP请求响应来向外界提供信息和服务。但是，我们在利用Web服务器和开发Web应用程序的过程中，有时需要获取一些服务器的具体信息，例如：服务器操作系统、应用程序版本、安全漏洞情况等等。这个时候，Web服务器探针就发挥了重要作用。
Web服务器探针是一种通过向目标服务器发送HTTP请求，获取服务器上运行的Web应用程序信息，以及操作系统信息、Web服务器类型、Web应用程序技术等信息的软件工具。通过Web服务器探针，使用者可以了解目标服务器上安装的软件、版本、服务及其运行时间，以及部署Web应用的文件结构。对于服务器管理者来说，掌握这些信息对于服务器管理、安全监控等方面非常有帮助。
常见的Web服务器探针有WhatWeb、Nmap、dirbuster等，它们大多采用模拟正常用户访问的方式向目标服务器发送HTTP请求，并利用某些漏洞和规律来获取服务器信息。在使用Web服务器探针时，用户需要特别注意，毕竟探测他人服务器可能存在法律上的风险，应该遵循诚信、合法、合理的原则，不做侵害他人隐私和安全的行为。
在掌握Web服务器信息方面，Web服务器探针也提供了广阔的探索空间。一些开发者甚至可以使用探针的信息来进行Web应用的渗透测试、黑盒测试、搭建本地测试环境等等。而在保持Web服务器安全的方面，也需要加大防范和监控手段。Web服务器探针可以检测服务器安全漏洞，及时发现被黑客攻击的迹象，并加强服务器防范措施。
Web服务器探针这个工具，对于了解和掌握服务器信息、进行安全监控和渗透测试、开发Web应用程序等方面，都具有重要的实际应用价值。但是，作为使用者需要遵循道德规范和法律法规，确保不侵犯他人的权益。同时，服务器管理者也需要在保障系统正常运营的前提下，加强对系统的安全防护，尽可能地减少其被攻击的可能性。
相关问题拓展阅读：
Wazuh简介
Wazuh是一个安全检测、可视化和安全合规开源项目。它最初是OSSEC HIDS的一个分支，后来与Elastic Stack和OpenSCAP集成在一起，发展成为一个更全面的解决方案。下面是这些工具的简要描述以及它们的作用:
1.1OSSEC HIDS
OSSEC HIDS是一种基于主机的入侵检测系统(HIDS)，用于安全检测、可见性和遵从性监控。它基于一个多平台代理，将系统数据(如：日志消息、文件散列和检测到的异常)转发给一个中央管理器，并在其中对其进行进一步分析和处理，从而产生安全警报。代理将事件数据通过安全且经过身份验证的通道传递给中央管理器，以便进行分析。
此外，OSSEC HIDS提供了一个集中的syslog服务器和一个无代理的配置监视系统，该系统提供了对防火墙、交换机、路由器、接入点、网络设备等无代理设备上的事件和更改的安全洞察。
1.2OpenSCAP
OpenSCAP是一种OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)解释器，用于检查系统配置和检测脆弱应用程序。
这是一种众所周知的工具，用于检查安全合规性和使用工业标准安全基线对企业环境的加固。
1.3Elastic Stack
Elastic Stack是一个软件套件(Filebeat、Logstash、Elasticsearch、Kibana)，用于收集、解析、索引、存储、搜索和显示日志数据。它提供了一个web前端，该前端提供事件的高级仪表板视图，支持深入到事件数据存储的高级分析和数据挖掘。
二、组件
Wazuh的主要组件是运行在每个受监控主机上的代理，以及分析从代理和syslog等无代理源接收到的数据的服务器。此外，服务器将事件数据转发到一个Elasticsearch集群，在这里对信息进行索引和存储。
2.1Wazuh agent
Wazuh代理运行在Windows、Linux、Solaris、BSD和Mac操作系统上。它用于收集不同类型的系统和应用程序数据，这些数据通过加密和经过身份验证的通道转发给Wazuh服务器。为了建立这个安全通道，使用了一个包含唯一预共享密钥的注册过程。
代理可以用来监视物理服务器、虚拟机和云实例(例如Amazon AWS、Azure或谷歌云)。预编译的代理安装包可用于Linux、HP-UX、AIX、Solaris、Windows和Darwin (Mac OS X)。
在基于Unix的操作系统上，代理运行多个进程，尺伍这些进程通过本地Unix域套接字相互通信。其中一个进程负责向Wazuh服务器发送通信和数据。在Windows系统上，只有一个代理进程使用互斥对象运行多个任务。
不同的代理任务或过程以不同的方式监视系统(例如，监视文件完整性、读取系统日志消息和扫描系统配置)。
下图表示在代理级别上发生的内部任务和流程:
所有代理进程都有不同的目的和设置。以下是他们的简要说明:
Rootcheck:这个过核困歼程执行多个与检测rootkit、恶意软件和系统异常相关的任务。它还对系统配置文件运行某些基本的安全检查。
日志收集器 Log Collector :此代理组件用于改冲读取操作系统和应用程序日志消息，包括平面日志文件、标准Windows事件日志甚至Windows事件通道。还可以将其配置为定期运行并捕获特定命令的输出。
Syscheck:这个过程执行文件完整性监视(FIM)，也可以监视Windows系统上的注册表项。它能够检测文件的内容、所有权和其他属性的变化，以及记录文件的创建和删除。虽然它在默认情况下执行定期的FIM扫描，但它也可以配置为与操作系统内核通信，以便实时检测文件更改并生成文本文件的详细更改报告(diffs)。
OpenSCAP:该模块使用已发布的OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)基线安全概要。通过定期扫描系统，它可以找到不符合众所周知的标准的脆弱的应用程序或配置，例如在CIS(互联网安全中心)基准测试中定义的那些。
代理守护进程 Agent Daemon :这个进程接收所有其他代理组件生成或收集的数据。它通过经过身份验证的通道将数据压缩、加密并交付给服务器。这个进程运行在一个独立的“chroot”(更改根)环境中，这意味着它对被监视系统的访问是有限的。这提高了代理的整体安全性，因为它是连接到网络的唯一进程。
2.2Wazuh server
服务器组件负责分析从代理接收的数据，并在事件匹配规则时触发警报(例如检测到入侵、文件更改、配置不符合策略、可能的rootkit等)。
服务器通常运行在独立的物理机器、虚拟机或云实例上，并运行代理组件，其目的是监视服务器本身。以下是主要服务器组件列表:
注册服务 Registration service :通过提供和分发每个代理特有的预共享身份验证密钥来注册新代理。此流程作为网络服务运行，支持通过TLS/SSL和/或通过固定密码进行身份验证。
远程守护进程服务 Remote daemon service :这是从代理接收数据的服务。它使用预共享密钥来验证每个代理的身份，并加密代理和管理器之间的通信。
分析守护进程 Analysis daemon :这是执行数据分析的进程。它利用解码器识别正在处理的信息类型(如Windows事件、SSHD日志、web服务器日志等)，然后从日志消息(如源ip、事件id、用户等)中提取相关数据元素。接下来，通过使用规则，它可以识别解码后的日志记录中的特定模式，这些模式可能触发警报，甚至可能调用自动对策(主动响应)，比如防火墙上的IP禁令。
RESTful API RESTful API :这提供了一个接口来管理和监视代理的配置和部署状态。它也被一个Kibana应用程序Wazuh web界面所使用。
2.3Elastic Stack
Elastic Stack是一个流行的用于日志管理的开源项目的统一套件，包括Elasticsearch、Logstash、Kibana、Filebeat等。与Wazuh解决方案特别相关的项目有:
Elasticsearch :一个高度可伸缩，全文搜索和分析引擎。弹性搜索被分配，意味着数据(索引)被分成shard，并且每个shard可以具有零个或更多个副本。
Logstash:收集和解析要保存到存储系统中的日志的工具(例如，Elasticsearch)。收集到的事件还可以使用输入、过滤和输出插件进行丰富和转换。
Kibana:一个灵活和直观的web界面，用于挖掘、分析和可视化数据。它运行在一个Elasticsearch集群上索引的内容之上。
Filebeat:一种轻量级转发器，用于在网络中传送日志，通常用于Logstash或Elasticsearch。
Wazuh与Elastic Stack集成，提供已解码的日志消息提要，这些日志消息将由Elasticsearch索引，以及用于警报和日志数据分析的实时web控制台。此外，Wazuh用户界面(运行在Kibana之上)可用于管理和监视您的Wazuh基础设施。
Elasticsearch索引是具有某些相似特征(如某些公共字段和共享数据保留需求)的文档。Wazuh每天使用多达三种不同的索引来存储不同的事件类型:
Wazuh -alerts:每当事件触发规则时，Wazuh服务器生成警报的索引。
wazuh-events:从代理接收的所有事件(归档数据)的索引，无论它们是否触发规则。
wazuh-monitoring:索引与代理状态相关的数据。web接口使用它表示单个代理处于或已经处于“活动”、“断开”或“从未连接”的情况。
索引是由文档组成的。对于上面的索引，文档是单个警报、归档事件或状态事件。
将Elasticsearch索引分成一个或多个shard，并且每个shard可以选择性地具有一个或多个副本。每一主和副本shard是单个的Lucene索引。因此，一个Elasticsearch索引是由许多Lucene索引组成的。当搜索在Elasticsearch索引上运行时，将并行地对所有shard执行搜索，并合并结果。将Elasticsearch索引分成多个shard和复制品用于多节点的弹性搜索集群，目的是缩小搜索和获得高可用性。单节点Elasticsearch集群通常每个索引只有一个shard，没有副本。
三、体系结构
Wazuh架构基于运行在受监视主机上的代理，这些主机将日志数据转发到中央服务器。此外，还支持无代理设备(如防火墙、交换机、路由器、接入点等)，并可以通过syslog和/或其配置更改的定期探针主动提交日志数据，以便稍后将数据转发到中央服务器。中央服务器对输入的信息进行解码和分析，并将结果传递给一个Elasticsearch集群进行索引和存储。
一个Elasticsearch集群是一个或多个节点(服务器)的，这些节点(服务器)相互通信，对索引执行读写操作。小型Wazuh部署(
当Wazuh服务器和Elasticsearch集群在不同的主机上时，Filebeat可使用TLS加密将Wazuh警报和/或存档事件安全地转发到Elasticsearch服务器。
下图说明了Wazuh服务器和Elasticsearch集群在不同主机上运行时组件是如何分布的。注意，对于多节点集群，将有多个Elastic堆栈服务器，Filebeat可以将数据转发到这些服务器:
在较小的Wazuh部署中，使用单节点Elasticsearch实例的Wazuh和Elastic堆栈都可以部署在单个服务器上。在这个场景中，Logstash可以直接从本地文件系统读取Wazuh警报和/或归档事件，并将它们提供给本地Elasticsearch实例。
四、通信与数据流
4.1代理-服务器通信
Wazuh代理使用OSSEC消息协议通过端口1514 (UDP或TCP)将收集到的事件发送到Wazuh服务器。然后，Wazuh服务器解码并使用分析引擎对接收到的事件进行规则检查。触发规则的事件会被添加警告数据，如规则id和规则名称。根据规则是否触发，可以将事件存储到以下一个或两个文件:
文件/var/ossec/logs/archives/archives.json包含所有事件，不管它们是否触发了规则。
文件/var/ossec/logs/alerts/alerts.json只包含触发规则的事件。
Wazuh消息协议使用的是192位Blowfish加密，完全实现了16轮，或者AES加密，每块128位，密钥256位。
4.2Wazuh-Elastic通信
在大型部署中，Wazuh服务器使用Filebeat使用TLS加密将警报和事件数据发送到弹性堆栈服务器上的loghide (5000/TCP)。对于单主机架构，Logstash可以直接从本地文件系统读取事件/警报，而无需使用Filebeat。
Logstash对输入的数据进行格式化，并可选择在将数据发送到Elasticsearch(端口9200/TCP)之前丰富GeoIP信息。一旦数据被索引到Elasticsearch，就会使用Kibana(端口5601/TCP)来挖掘和可视化信息。
Wazuh APP运行在Kibana内部，不断查询RESTful API (Wazuh管理器上的端口55000/TCP)，以便显示服务器和代理的配置和状态相关信息，并在需要时重新启动代理。此通信使用TLS加密，并使用用户名和密码进行身份验证。
五、所需端口
对于安装Wazuh和Elastic堆栈，必须有几个网络端口可用并打开，以便不同组件之间能够正确通信。
六、档案数据存储
除了发送到Elasticsearch之外，警报和非警报事件都存储在Wazuh服务器上的文件中。这些文件可以是ON格式(. ON)和/或纯文本格式(日志-没有解码字段，但更紧凑)。这些文件每天使用MD5和SHA1校验和进行压缩和签名。目录和文件名结构如下:
建议根据Wazuh Manager服务器的存储容量对归档文件进行轮换和备份。通过使用cron作业，您可以很容易地安排只在管理器上保留一个特定的存档文件时间窗口(例如，去年或过去三个月)。
另一方面，您可以选择完全不存储归档文件，而仅仅依赖于Elasticsearch来存储归档文件，特别是在运行定期的Elasticsearch快照备份和/或具有碎片副本的多节点Elasticsearch集群以获得高可用性时。您甚至可以使用cron作业将快照索引移动到最终的数据存储服务器，并使用MD5和SHA1算法对其进行签名。
如何使用Diagnostics工具监控应用服务器
文档编写目的
本文档介绍HP Diagnostics应用服务器监控工具的安装、配置、作用以及影响。
HP Diagnostics组件介绍
2.1Diagnostics Probe
Diagnostics Probe(探针)负责从应用程序中捕捉各种事件、对象，计算度量信息并将结果发送到Diagnostics Server。Java Probe还提供剖析功能，能获取到与被测程序有关的更细节的诊断信息。
2.2Diagnostics Servers
Diagnostics Servers负责协调Probe及其他HP软件，处理从各个组件搜集的性能诊断数据，并以各种视图的形式展示出来。
Mediator模式的Diagnostics Server接受来自Probe的哪竖拍诊断数据，并通过进一步处理和纤慎计算，生成可供在视图上展示的数据。
Commander模式的Diagnostics Server负责调控Diagnostics各个组件及其他外部产品（LoadRunner Controller、Performance Center等），跟踪各个组件的工作状态。Commander模式的另一个作用是为最终用户提供一个监控各种性能视图，执行各种参数配置的界面。同时Commander模式的Diagnostics Server也拥有Mediator模式的Server的数据处理功能。
2.3Diagnostics结构图
l一套Diagnostics系统中包括至少一个Command模式下的Server，可以包含0-N个Mediator模式的Server
HP Diagnostics安装及配置
3.1HP Diagnostics 系统硬件配置要求
3.1.1Diagnostics Server
Platform
Item
Up to 10 Probes
Up to 20 Probes
Up to 10 Probes
Windows
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
Windows
Memory
768MB
1GB
3GB
Solaris
CPU
1XUltra Sparc 2
2XUltra Sparc 2
2XUltra Sparc 3
Solaris
Memory
1GB
1.5GB
3GB
Linux
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
Linux
Memory
768MB
1GB
3GB
HP-UX
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
HP-UX
Memory
768MB
1GB
3GB
All
Java Heap
350MB
700MB
1400MB
All
Disk
3 GB per probe
3.1.2Diagnostics JAVA Probe
Platform
All Platforms
Memory
50 MB Additional RAM
Free Hard Disk Space
200 MB Additional Space
3.2HP Diagnostics 系统安装
3.2.1Diagnostics Server安装
在Windows系统下安装Diagnostics Server的步骤如下：
l从安装文件所在文件夹中运行DiagnosticsServerSetupWin_8_00.exe
l阅读许可文档
l选择安装路径
l选择Server运行在Commander模式或Mediator模式下
l（如果选择了安装Commander模式的Server）选择时间同步方式，用于同步一套Diagnostics系统，这里选择Synchronize with system time。
l选择Diagnostics Server是否与HP其他软件产品一起工作，没有的话直接选择Next
l确认安李羡装选项，开始安装
l结束安装
3.2.2Windows下Diagnostics JAVA Probe安装
在Windows系统下安装Diagnostics JAVA Probe的步骤如下：
l从安装文件所在文件夹中运行JavaAgentSetup_win_8_00.exe。
l阅读许可文档。
l选择安装目录。
l确认安装选项，开始安装。
l结束安装，自动弹出Agent配置界面。
选择如上图所示，点击“下一步”。
l填写探针名称和组名称，以便在服务器端识别，组名称使用Default也可，点击“下一步”。
l填写Diagnostics Server的IP地址及端口号，点击“下一步”。
l配置后选项，勾选“运行JRE Instrumenter…”
l添加JVM,选择复制参数。
l将复制的参数添加到WebLogic启动文件中，重新启动WebLogic服务器。
3.2.3UNIX下Diagnostics JAVA Probe 安装
Diagnostics Java Probe在IBM AIX、HP UNIX以及Linux操作系统中安装方法一致。唯一的区别是不同的平台有不同的安装文件。例如：AIX平台的安装文件为JavaAgentSetup_ibm_8_00.bin、HP平台的安装文件为JavaAgentSetup_hp11x_8_00.bin。
下面以AIX平台root用户安装Java Probe为例进行说明：
一、以二进制方式上传安装文件至服务器。
二、执行 #chmod 755 JavaAgentSetup_ibm_8_00.bin授予文件可执行权限。
三、执行 #./ JavaAgentSetup_ibm_8_00.bin -console，根据提示进行安装即可，注意设置Java Probe的安装目录，此处假设为 /MercuryDiagnostics。
四、修改/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc下的三个配置文件配置Java Probe：
1、 dynamic.properties修改配置如下：
mediator.host.name=IP (diagnostics8服务器IP地址)
mediator.port.number=(代理端与服务器的通信端口，默认2612)
2、 dispatcher.properties修改配置如下：
registrar.url=
(diagnostics8服务器IP地址和端口)
3、 probe.properties修改配置如下：
active.products=Enterprise
id=lcam
group=szcomtop
五、进入/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/bin，运行如下命令：
#./jreinstrumenter.sh –i /usr/java5(应用所使用的JVM的安装路径)
生成一段代码。
六、将生成的代码添加到WebLogic启动文件中，重新启动WebLogic服务器。
HP Diagnostics 基本功能
打开IE浏览器输入 Server使用界面如下：
点击Open Diagnostics，输入用户名密码（均为admin）进入监控主界面
在此界面中选择对应的应用程序，可打开该应用程序的各种监控视图
Diagnositcs系统组织结构定义：
lDiagnostics System可包含多个Application，通过Diagnostics Server（Commander）的监控界面可以查看所有被监控的Application状态
lApplication被监控程序，一个Application中可以包含多个Probe Groop
lProbe Group Probe组，可以是一组职能相近的Probe的
lProbe一个探针
4.1Server Summary View
l最上方的Status视图列出Probe Group中的所有Probe，选择任意一个Probe就会列出该Probe的一些系统级的诊断信息。
l左下方的All Aggregate Requests视图显示近5分钟内延迟最严重的Top 5请求（注意这个Top5是针对所有Probe侦测的所有请求而言的，如果需要观察某个Probe的Top5延迟请求，需要使用Filter）
l右下方的Alert Events显示最近5个发声的Alert Notification（可以针对Server、Host、Probe Group、Probe设置各种Alert Notification Rule，当系统状况打到某个条件时发送Notification）
4.2Application Metric View
l该视图显示过去5分钟内CPU使用率更高的5个Application
l鼠标移动到某一条趋势线会有详细信息列出，见下图（这里的Latency延迟我不是太理解是指哪个对象的延迟，应该是指请求在应用程序的延迟）
4.3Dependent Services View
l该视图显示延迟最严重的5个Dependent Services
lDependent Services应该是指JDBC、RMI、WebServices、ADO（.NET）等非应用层的外部服务单元
l上面是每个Dependent Services 的 Services Call View，显示针对这个Services的Top 5延迟的Services Call
4.4Host View
l显示CPU使用率更高的5台服务器
4.5Load View
l该视图显示Load值更高的前5个Layer
lLoad值计算方法：
Load = Average Latency / Point Duration
其实Average Latency是指所有线程在当前Layer中的平均执行时间，Point Duration是一个合计的粒度值。
4.6Outbound Calls View
l该视图显示延迟更高的5个Outbound Calls
lDiagnostic监控的Outbound Calls类型包括：
ØWeb Service
ØRMI. Calls between Java servers.
ØRFC (SAP R/3). Calls between SAP servers.
ØCICS. Calls within an IBM environment.
ØJMS. Calls between Java servers and message servers.
4.7Probe View
l该视图显示JVM使用率更高的5个Probe信息。
l视图对象表格
l双击某个Probe会显示该Probe的Server Request View。
4.8SQL Statements View
l该视图显示执行时间最长的5条SQL语句
l默认是从所有Probe Group中的所有Probe上执行过的所有SQL语句中筛选，如果需要查看某个Probe的SQL执行情况，请使用Filter
lSQL语句的执行时间需超过设置的限定值才会在本视图中显示，限定值在相关配置文件中设置，默认限定值为1s。
lDetails中列出所选SQL语句的执行位置、执行方法、次数、超时率等信息
4.9Aggregate Requests and Server Requests View
Aggregate Requests View
Server Requests View
l显示响应时间最长的5个Aggregate Request和Server Request
lAggregate Request和Server Request的区别，Aggregate Request的响应时间包括server requests和 dependent service calls的时间。
lServer Request的视图对象表的细节
显示请求的类型、请求发起的源码位置（Package、Method等）
l在Server Request视图中，当选择了某个Server Request，视图中将会高亮该Request的趋势线，同时会
点击途中的、、图标，将会显示当前Request的Instance Tree（CallProfile）视图，其中各图标的含义如下：
A maximum instance tree，响应时间最长时的内部调用轨迹
A median instance tree，响应时间中等时的内部调用轨迹
A minimum instance tree，响应时间最短时的内部调用轨迹
典型的Instance Tree视图如下：
4.10 Status Views
l显示系统中所有Probe Group、Probe、Host的概要信息及当前状态
4.11 Topology View
l根据发送的请求的执行路径，获取并显示当前应用的网络拓扑图。
4.12 Transactions View
l该视图显示响应时间最长的5个事务。
4.13 Trended Methods View
l显示执行时间最长的5个方法，要对特定类、方法进行监测，需修改相关配置文件。
4.14 Layers View
l该视图显示执行时间所占比重更高的5个Layer的延迟时间
l视图对象表格细节
4.15 Call Profile View
lCall Profile Graph显示一个Server Request的方法调用过程，高亮最耗时的方法调用步骤
lCall Tree Table以制表的形式列出Call Profile Graph的调用过程，包括每个层级中各个方法调用的耗时、占比、使用的CPU时间等
lDetails Pane显示某个方法调用的一些详细信息
4.16 Collections and Resources Views
Collections Views
l该视图可以按照Collection Size或者growth排列显示出排名前5的Collection信息
Resources Views
l该视图显示element数量前5位的Resource，Resource是指各种jar包
Diagnostics分析功能
访问J2EE Diagnostics Profiler的URL：
其中probeport默认为35000
工具栏的几个按钮：
lRefresh实时刷新最新数据
lGarbage Collection 强制垃圾回收
lReset 重置计数和时间信息
lLink to Product information
lHelp 打开On-line help
5.1使用Summary Tab来分析性能
lSummary Tab显示当前Probe的JVM内存使用情况、Load值和最慢的Requests
l在Memory视图点击“drill into”按钮会显示堆的细分内容（详细请见Collection Tab章节）
l在Load视图中会根据不同的层显示每个层的Load值，见下图：
l在Slowest Requests视图中点击每个Request，会弹出对应的Call Profile View
5.2使用Hotspots Tab来分析性能
lHotspots Tab显示耗时最长的方法、CPU时间使用最久的方法及执行时间最长的SQL语句
l点击“view all methods”将链接到All Methods Tab，点击“view all SQL”将链接到All SQL Tab
l在Slowest Methods和CPU Hotspots两个视图中点击某个方法，都会跳转到该方法的Call Profile 视图
l在Slowest SQL视图中点击某个SQL语句，会显示完整版的SQL语句
5.3使用Metrics Tab来分析性能
5.4使用Threads Tab来分析性能
5.5使用All Methods Tab来分析性能
l显示方法名、总耗时、平均耗时、被调次数、异常数、总CPU时间、平均CPU时间、所属层级
l双击方法会显示该方法的Call Profile View
5.6使用All SQL Tab来分析性能
l所有SQL的执行情况
5.7使用Exceptions Tab来分析性能
l所有异常情况及次数
5.8使用Server Requests Tab来分析性能
l所有Server Requests的统计信息。
5.9使用Web Services Tab来分析性能
l现在最慢的前四个Web Service Operations（Inbound Call）和Outbound Web Service Calls
Diagnostics监控工具安装后风险分析
Ø安装Diagnostics Server需要更改计算机MAC地址，要确保该机器允许修改MAC地址。
ØDiagnostics Server与应用服务器是两台机器，安装Diagnostics Server不影响应用系统。
ØDiagnostics服务器通过应用服务器上的Diagnostics Probe(探针)获取通过应用服务器的信息，进行监控。探针对服务器的影响微小，可忽略不计。
Ø探针如果出现问题，导致weblogic服务无法启动，紧急情况可将添加在startWebLogic.sh文件中的那段代码去掉即可。
转载，仅供参考，祝你愉快，满意请采纳。文档编写目的
本文档介绍HP Diagnostics应用服务器监控工具的安装、配置、作用以及影响。
HP Diagnostics组件介绍
2.1Diagnostics Probe
Diagnostics Probe(探针)负责从应用程序中捕捉各种事件、对象，计算度量信息并将结果发送到Diagnostics Server。Java Probe还提供剖析功能，能获取到与被测程序有关的更细节的诊断信息。
2.2Diagnostics Servers
Diagnostics Servers负责协调Probe及其他HP软件，处理从各个组件搜集的性能诊断数据，并以各种视图的形式展示出来。
Mediator模式的Diagnostics Server接受来自Probe的诊断数据，并通过进一步处理和计算，生成可供在视图上展示的数据。
Commander模式的Diagnostics Server负责调控Diagnostics各个组件及其他外部产品（LoadRunner Controller、Performance Center等），跟踪各个组件的工作状态。Commander模式的另一个作用是为最终用户提供一个监控各种性能视图，执行各种参数配置的界面。同时Commander模式的Diagnostics Server也拥有Mediator模式的Server的数据处理功能。
关于web服务器探针的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
