【核心议题6】企业监控系统建设的总体思路？

先大致简要说说我们的总体思路和经验，大家也可以分享自己企业的经验。
一、基础监控部分
基础监控部分的建设图：

二、业务系统可用性监控
业务系统可用性监控，将在有效的利用现有的监控管理架构的基础上，扩展IT基础架构中各单一IT资源的故障对于业务系统造成的影响分析，从而提供业务系统视角的可用性监控及报告的能力，帮助企业的IT管理从面向技术和资源向面向业务系统的管理打下基础。
在实际的环境中，业务系统往往由多个子系统／交易组成，支撑其的IT环境也都包含了复杂的组件和多个实例（如集群环境下的多台服务器，多个交易中间件等），考虑到这种复杂的情况，业务系统可用性监控方案需要从CMDB或自定义的数据存储中获取业务系统的组成模型，组件依赖及冗余关系，以此作为IT故障对业务系统可用性是否造成影响的依据。
业务系统可用性监控提供以下主要功能：
1.根据业务组成模型进行单一IT组件的事件告警关联，当判断为业务不可用时，立刻生成新的业务不可用告警，及时通知到相关负责人；
2.提供业务可用性的大屏展现，为用户提供清晰直观的业务关键组件的可用性状态，当业务不可用时，可以快速查看到对应的故障组件；
3.通过对历史数据的统计分析提供业务系统及各IT组件的可用性报表，如业务系统的可用性百分比、业务可用性排名等。
4.结合大数据应用日志分析平台对历史业务量和交易指标进行统计和预测，当业务系统不可用时，判断此时刻对业务系统的业务量的影响数值有多少，对交易指标的影响度有多少等。
三、大数据应用日志分析
可分多期项目建设大数据应用日志分析平台，一期对部分关键的交易类应用系统进行日志分析，主要着重点在日志的收集和日志的解析方面，无须对数据进行深度挖掘。二期将扩大应用日志分析的应用系统覆盖面，并在此基础上对日志内容进行深度的分析、发现数据的价值。思路的主要内容包括：

• 更多业务使用场景的建议
  大数据运维分析是大数据在运维方面的一个应用场景。运维的日志主要包括交易日志、应用日志、系统日志、运维和操作日志、网络日志。针对这些日志的分析，可以获取如下的一些有用的数据：
  （1）业务层面：业务的访问量，支付笔数，交易笔数等
  （2）应用层面：应用的报错数，调用跟踪，访问的耗时等
  （3）系统层面：系统错误，系统服务状态，系统资源使用情况等
  （4）网络层面：丢包，网络通断，流量，连接数等
  大数据的运维平台第一步是收集数据，尽可能多的把日志都收集到一起，方面以后的统一分析和查询。第二步是从数据中分析，挖掘，寻找出有价值的信息，并把这些信息通过平台的实时处理，变成监控的KPI指标，用于异常的发现和告警的触发。第三步是将抓取的数据信息，通过报表手段进行展现和发送。经过处理后的日志信息能够方便的查询和比较，并且能够灵活地实现可视化展现。
  
  图片3.png
  
  下图就是一个应用日志分析的示例：
  
  图片4.png
• 权限管理的实现
  不同角色的人员只能看到与之关的业务应用的日志信息。
  当前平台中数据并没有进行权限的设置。数据混杂在一块儿，用户可以查看到所有的数据，这样给数据的泄露带来的风险。权限管理的目标就是提高数据的安全性，管理员只能看到跟自己业务相关的数据，提高安全性，降低风险。
  通过已知的来源ip地址，日志的文件名，日志的内容等信息对日志进行打标签。不同的标签可以设置不同的管理人员对其进行访问。在系统的底层对数据的泄露进行的遏制。
  标签的过滤条件是可以灵活进行设置的，标签和管理员的对应关系也可以进行定制。方便管理员以后对权限进行修改。
• 在数据量不断增大的情况下平台性能和可靠性的考虑
• 平台的性能和可靠性
  一期建设的应用日志平台共有X台机器，XXXG内存，XXX个CPU核，硬盘采用存储。当前的硬件性能足以支撑每日约XXXG的日志量，如何在现有的环境下提高系统的可靠性和为将来日志量的扩充进行准备，是二期考虑的重点。此外，可依赖当前的Tivoli监控平台实现组件的自监控，及时发现组件的异常情况，当组件出现故障时，及时处理，保证数据的完整性。
• 日志接入的性能和可靠性
  一期建设的应用日志量约XXXG，日志如果在传输过程中，因为组件的实效，日志是会丢失的，所以需要对日志在收集时进行冗余处理。日志本身都是日志文件或者数据库的记录，在服务器上本身就是有一份冗余的，二期将提供数据的后期导入功能，通过识别数据中的日期信息，可以把数据进行回放处理，重新导入到平台。
• 平台的扩展性
  随着数据量的增大，平台处理性能将会达到瓶颈。存储空间可以通过存储的扩容进行扩展。平台的处理能力可以通过增加物理机进行扩展。
• 日志的规范化
  目前绝大部分企业的各应用系统在设计和开发时并未采用统一的交易日志规范，这给后续监控管理的数据集成和分析增加了难度。建设思路包括未来新建系统提出明确的交易日志规范，以使各新建应用系统遵循，主要完成对日志文件的名称、格式、内容等信息进行规划化、标准化，以便于形成统一的日志展现模式。
  四、端到端的应用性能管理
  在IT服务管理中，资源监控和应用监控是两个不同的视角来管理业务服务的运行状况，IT资源监控用于保障IT基础设施的各项指标处于正常的状况，有效的支撑业务系统的。应用交易监控则直接观察业务系统上运行的业务交易，判断业务是否正常的运行，是否在正常的时间内完成。应用性能监控，应涵盖以下几个方面：
• 主动的探测服务可用性：通过虚拟用户模仿客户访问应用，主动的探测应用的可用性，以及应用的交易性能，目的是争取避免问题，先于客户发现问题。
• 获取真实用户交易数据：通过监控真实的用户交易，获知用户的使用感受，目的是获知真实终端用户的使用情况。具体的实现方式是从网络端口获取网络传输包并进行协议栈分析，从而得到用户交易的细节，包括交易访问的URL，交易的返回状态，交易的响应时间，甚至登录的用户名等。此外，还能够自动发现和生成交易的拓扑图，直观地展现交易的路径和响应时间。支持本地安装和基于端口镜像的远程监控两种部署模式。采用基于端口镜像的远程监控模式时，能够避免在业务系统的服务器上安装代理软件，实现对于应用的无侵入式监控。
• 交易跟踪：通过端到端的交易跟踪，响应时间分段，目的是隔离问题发生的位置，缩短定位问题时间。当一个应用跨越多个节点，出现不可用，或者响应缓慢的时候，第一步是需要知道慢在哪个节点上（哪台机器上），然后才能去诊断为什么那个节点会慢。通过应用的拓扑图和每个节点上的响应时间，可以很快定位到“潜在出问题”的节点上。进而通过各ITM DB/WAS/MQ/MB Agent来查看容器的性能指标找到问题根源。下图能很好的展示交易跟踪的功能：
  
  图片5.png
• 深入诊断：结合单一域内的专业诊断监控工具，目的是找到问题的根源，解决问题。
  五、性能容量分析
• 性能预测分析
  比传统的性能报表更进一步，基于已有的历史性能数据，对今后的性能进行预测分析，为IT性能容量规划提供定量的依据。这种分析能力包括：
• 预测7天、30天、90天后的性能情况
• 预测还有多少天会达到性能阈值
• 性能预测的可信度如何
• 虚拟化环境容量分析
  针对越来越广泛的虚拟化环境，增加了容量分析管理的工具和相应的报表，这些分析能力包括：
• 能根据历史数据预测并规划对资源池的使用。并能通过模拟扩容来提前获知扩容的对现有情况的改善。
• 能根据历史性能数据，预测未来的使用瓶颈，能提前告警，提醒用户，资源可能在多长的预期内遇到瓶颈障碍。
• 能对现有的历史性能数据，进行分析，并提供各种虚拟资源的分配，使用的报表，分析虚拟化环境的负载是否均衡。