日志审计在API技术中通常是结合已有的日志服务一起使用，很少单独去构建日志审计服务，API服务仅作为日志输入的一个端点，为审计服务提供日志数据来源。如图所示，业务组件服务和API服务作为两个不同的端点向日志审计系统输入原始日志数据。
日志审计的目的是通过审计策略和日志分析，发现系统在某一时间段内发生的异常事件，通过事件关联和追溯，分析与事件相关联的内外部人员、系统、事件涉及的范围等。一条标准的日志，至少包含以下关键要素。
- 时间：指日志发生的时间点，一般精确到秒级，特殊业务需要精确到毫秒级，准确的时间记录有利于事件的分析与关联。
- 来源：指日志操作的来源，比如源IP、源主机。
- 结果：指日志涉及的操作是否成功，比如一次管理API的调用请求，在日志中需要记录是调用成功还是失败。
- 操作者：指当前日志是由谁操作的，是某个用户还是某个客户端应用程序。
- 操作详情：指操作的具体内容是什么，比如给某个API授权，则操作详情需要记录授予什么样的权限。
- 目标对象：指被操作的对象，比如被请求的API端点、被访问的目标主机。
除了上述基本字段外，很多审计系统根据业务场景的不同在设计时会增加其他关键字段，比如日志的类型表示是新增操作还是删除操作或其他，会话ID记录多条日志与会话的关系。
在API服务的日志采集中，可以从以下两个层面去收集。
- 接口层：接口的日志主要用于记录在什么时间，谁调用了哪个API端点，是否调用成功等信息。如果在整个技术架构中使用了API网关，则最好在网关层面收集。这类日志信息的格式易于统一和标准化，收集可以使用代理或切面的方式，对原有API服务的影响小，基本很少需要改造。
- 操作层：操作的日志主要用于记录API端点被调用时执行的业务操作，比如创建某个资源、删除某个资源、查询哪些数据等。这些与业务逻辑相关的日志信息，需要提前在代码中植入代码片段，按照日志标准格式输出。
当前互联网应用系统中，对API日志的收集主要采用拦截器技术。在不同的API服务或API端点日志被收集后，交由后端日志分析服务，根据既定的审计规则对数据进行分析，生成审计事件。这个过程中，审计规则的制定需要根据业务情况去梳理并在运营过程中不断优化。举例来说，系统中存在一条针对API调用限流的审计规则是非工作时间单位时间5min内连续调用接口大于2000次。在第三方厂商的业务初期，业务量小，这条审计规则不会触发审计事件，但当第三方厂商业务发展起来之后，2000的阈值可能会导致审计系统频繁触发审计事件。这时，这条审计规则就需要根据实际业务量来评估一个合理值作为新的阈值。
从日志采集、日志标准化到日志分析、日志展现，这些功能在已有日志审计系统的前提下，直接把API服务当作一个日志输入接入系统比较简单。但如果没有日志审计系统，业界也有一些开源产品供架构设计时选择，主要的产品有Elasticsearch、Logstash、Kibana、Filebeat等。
Beats工具内置多种模块（如Filebeat、AuditBeat、Functionbeat等），可针对常见设备或组件（如Apache、Cisco ASA、Kubernetes、Docker、NGINX、MySQL等）的日志进行收集、解析；Elasticsearch是实时全文搜索和分析引擎，提供检索、分析、存储数据的功能；Kibana用于搜索、分析和可视化数据。使用这些开源组件搭建日志审计系统在技术上已经比较成熟，架构选择时，可以通过这些组件的整合为业务提供一整套日志审计的解决方案，满足大多数场景下的应用需求。
