系统监视和故障排除是IT团队职责的基本组成部分. While compliance frameworks 比如NIST和ITIL可以提供监控指南, 这些标准通常会留下很大的解释空间, 实施一项监测策略可能令人望而生畏. 以下各节提供了who的概述, what, where, when, 以及如何监控你的IT环境.
考虑监控环境的一种方法是将数据分为三类.
First is log data, 哪个可以定义为写入日志文件的任何数据, 不管它是普通的结构还是简单的文本. 日志数据提供了在IT环境中发生的事务的详细记录. 第二种是资产数据，它指的是直接从资产中获取的任何数据.
这可以从基本的资源指标(如CPU和内存)到关于在给定IT资产上运行的进程和应用程序的信息. 在监视通常不会在标准日志文件中捕获的事件时，资产数据可能特别有用. Lastly is network data, 哪个指的是特定于网络性能的数据, including bandwidth, 网络连接详细信息, and routing behavior.
而监控所有这三种数据类型是成熟的基础 security operations，系统监控通常侧重于对日志数据和资产数据的分析.
有很多系统可以监控, 你所选择的最终取决于你所处的环境. Options may include:
Servers: 服务器监视涵盖了广泛的系统, 包括托管应用程序的服务器, Active Directory域控制器, file shares, and email servers. 无论是Windows、Linux还是Mac机器，大多数服务器都会提供一定程度的事件日志记录.
Databases: 许多数据库提供不同的日志级别，以帮助管理员调试错误和识别即将出现的问题. 从数据库记录的典型事件包括缓慢的查询和SQL超时, row limits, memory limitations, and cache issues.
Applications: 应用程序既包括您购买的第三方应用程序，也包括内部开发的应用程序. 一些第三方应用程序将向其主机写入日志，然后可以收集日志.
您的内部团队开发的应用程序也应该被构建为记录可以捕获的重要事件. 考虑这些应用程序是面向客户的还是面向员工的. While 应用程序性能监控 不管应用程序的受众如何，都很重要吗, 面向客户的应用程序和服务可能需要更详细的日志记录.
Cloud Services: 云服务，特别是基础设施即服务解决方案，如 AWS and Azure，是系统监控计划的工具. 这些服务可以在服务本身内提供日志查看功能, 但是您也可以在这些服务之外收集和存储日志. 将所有日志收集并存储在一个位置可以使以后查找信息变得更容易.
Containers: 由于像Docker这样的服务，容器化正在成为构建和托管应用程序和基础设施的流行方法. 随着基础设施变得更加分区化, more ephemeral, 并且比物理机器更依赖于代码, container security 能在系统健康中发挥作用吗.
Employee Workstations: 当员工机器上的软件或进程发生冲突或可能使您的网络充斥数据包时, 能够看到员工的工作站上正在运行什么是必要的. 能够远程操作是很重要的, 因为追踪实物资产既耗时又不可行.
Errors: 记录应用程序和系统错误是一个简单的选择, 关键字“错误”通常是IT调查的一个很好的起点. 有些系统按类型对错误进行分类, 哪些可以提供哪些事件需要注意的指示.
CRUD Events: In general, 在创建信息时捕获, read, updated, 或删除可能对以后调试问题有用, 特别是在应用程序中. 虽然这些事件通常不会提供问题的直接迹象, 在追踪问题的根本原因时，它们可以成为极好的信息来源.
Transactions: “交易”通常指像购买这样的重要事件, subscriptions, cancellations, and submissions. 应该密切监视单个交易，以防止失败的交易和不完整的交易. Depending on the system, 错误代码可能会被记录下来，其中包含导致事务问题的重要信息. Some systems, like Microsoft SQL Server, 提供专用的事务日志，以便在一个日志中捕获此信息. 在其他系统中，您可能需要自己集中这些信息.
访问请求和权限变更: 来自活动目录等服务的日志记录可以为您的环境中的用户行为提供重要的视图. 监视和收集诸如权限更改之类的数据可以帮助您防止用户获得意外的管理权限. 这种类型的监视通常是满足某些遵从性标准所必需的
System Metrics: Systems metrics like CPU, memory, 并且应该始终密切监视磁盘利用率，以防止系统故障. 这些值的剧烈变化可能表明停机或即将停机. 在较长时间内收集这些指标还可以帮助将来进行容量规划.
考虑到系统的广度, events, 以及需要监控的指标, 将您的数据收集集中到一个单一的真实来源中可能是一个不错的决定, 尤其是当一个系统崩溃的时候. There are log management 可用于收集的解决方案, centralize, 并以易于搜索的方式组织日志, visualize, and generate alerts from.
监视还可以扩展到日志管理之外，包括对单个IT资产的监视. 这种类型的监视包括对资源利用度量的持续度量，以及对运行在资产上的软件和过程的跟踪. 软件使用情况通常不会被记录在传统的日志中，但是可以为系统问题的根本原因提供重要的线索. 不仅能够度量IT资产数据，还能够记录结果，从而在整个IT环境中提供重要的可见性.
In short, 如果您的系统需要保持持续的可用性，系统监控应该是24/7的. 通常，监视可以在后台进行，而不需要您持续关注. With that said, 在某些情况下，您应该期望保持对系统数据的积极关注, including:
System Updates: 当系统更新时, 存在更新失败或更新导致意外并发症的风险.
应用程序部署和回滚: 将代码(或回滚代码)部署到应用程序时, 可能会有意想不到的问题, 即使所有的单元测试和验收测试都通过了.
Migrations: 数据迁移通常具有挑战性，并且会出现数据类型不匹配的问题, validation issues, and more.
Peak Transaction Times当前位置一些企业已知有交易增加的时期, 如电子商务公司在节假日或促销期间. 在这些高峰时段发生的可用性问题如果不能迅速解决，可能会造成严重后果.
IT系统监控和故障排除涉及很多因素. 通过将IT环境分解为需要监视的系统和事件, 您将离为您的组织确定最佳监视策略和解决方案又近了一步.