随着技术的成熟,应用开发方式也在不断变化。开发各类功能的专用程序段已经成为主要趋势。
在微服务架构中,每个服务运行在独立的进程中,服务与服务间通过轻量级的通信机制(一般是基于HTTP协议的API)互相协作。API主要依赖于ESB、基于文件系统的资源、云解决方案及保留系统的集成。
客户端一般通过JavaScript框架搭建展示层,处理与API的交互。
根据“XX即代码”设计思路,大量底层服务能够通过git仓库和生成机制将源码转换为功能系统。
这便是应用设计机制。经过合理的设计,各个组件便能够正常运转,提供各项功能。但应用一旦发生故障,却很难定位到问题根源。
不同组件在提供应用服务的过程中都能产生日志,但日志格式和结构各不相同,因此需要建立统一日志管理机制。
下方的统一日志管理方案可处理各个组件的日志,实现了日志的统一查看与分析。
出现故障后,开发人员可根据统一格式的日志文件查找问题,不需要在不同系统之间来回切换。
运维开发人员
如果应用突然出现故障,各组件的日志按照不同格式存储在文件系统中。即便收集到所有日志,按照时间顺序一一查询所有日志也耗时耗力。有了统一日志管理系统,日志不仅能够集中存储,还能保证格式统一,极大地方便了运维开发人员排查故障,而上下文信息也有助于找到问题的根源。
安全人员
统一日志管理系统能够帮助安全团队发现未授权的访问:从统一日志管理系统导出相关报告,比对日志,可发现可疑活动。例如,通过统一日志管理系统可发现如下错误:
通过统一日志管理系统导出报告后,可设置仅展示36209错误,显示日期/时间信息等相关消息。
IT运维人员
采用统一日志管理系统后,能够减少监控等任务对IT基础设施的侵入。IT运维人员可通过统一日志管理系统理解系统之间的交互关系,从而更加合理地安排日常巡检任务。
统一日志管理系统的基本流程如下:
采集:连接源系统,采集系统原生日志,可设置日志采集级别。
解析:将源日志转换为统一日志管理系统的标准格式。这一点很重要,因为通过API生产的日志一般都是Apache格式的扩展版本,与数据库服务器的日志格式不同。
在解析正确的前提下,上方日志可以升级为如下格式:
升级后的日志采用了标准格式,提高了日志分析效率。
优化:进一步定义日志事件。通过优化日志格式,执行逻辑,分析日志中的IP地址,从而更好地理解系统或服务。也可以针对应用或服务设置自定义常数,减少交叉检索。
上方日志可优化如下:
经过优化,将时间戳转换成标准时间格式;在IP地址中添加主机系统;锁定错误码,查看更多信息。
存储:采集、解析、优化后的日志存储在统一日志关系系统的数据库中。此时可以通过索引和检索条件进一步了解源系统的原生日志。
预警:存储日志数据后,可配置事件预警,向其他系统发送预警,及时发现潜在问题。
分析:通过统一日志管理系统界面检索、过滤、查看与故障相关的所有事件,不需要直接从源系统查询日志。
日志信息的时效性很强,因此采集过程中必须做好取舍。在文章开头的例子中,发生故障后,运维开发人员需要查看应用的全部日志,包括微服务、数据块、客户端和安全层的日志。如果日志中的部分数据与故障无关,就需要另外花时间剔除这类信息。
下图为授权服务日志:
虽然日志中的所有信息都很重要,但最好还是只保留下列信息:
这样,发生故障时,需要查看的日志量就会大大减少。
敏感信息
统一日志管理系统不能存储访问密钥、数据库连接串、加密密钥、账户信息、用户信息等敏感信息。上述案例中的tokenGoesHere消息就不应该保存在统一日志管理系统中。如确有需要,可采集下列信息:
达成约定
要基于统一日志管理系统所有用户的需求达成约定,即明确日志事件数量的上限和下限。
要根据功能需求选择统一日志管理系统。以下为参考建议:
查询数据的便捷性:用户查询定位数据是否方便?很多用户并不擅长数据分析,因此内置报告或过滤条件能够极大地改善用户体验。
分析效率:创建复杂的检索过滤条件是,系统响应速度怎么样?返回结果的可读性和可用性怎么样?如前文所说,从统一日志管理系统检索信息时,响应时间和速度很重要。而过滤条件和报告则能有效改善用户体验。
可扩展性:公司所有的系统都能接入统一日志管理系统吗?需要多个用例吗?五年以后呢?未来会有更多系统需要接入,因此需要考虑统一日志管理系统的可扩展性。可根据响应时间对比不同解决方案的性能。
存储:对存储有什么要求?存储在哪里?采用统一日志管理系统的存储成本有多高?要了解与系统性能相关的存储边界。可部署二级存储,用于存储历史数据。
日志完整性:日志信息是否全面?是否需要从其他系统获取数据?如果还需要从其他系统另行获取数据,则说明该统一日志管理方案不符合需求。
数据优化功能:是否具备数据优化功能?功能是否简单易用?应用发生故障时,查看当前日志来源能够了解更多信息。而数据优化则能提升
是否开源:解决方案是否开源?如何接入公司现有系统?
日志采集工具:日志采集器具备哪些功能?是自研产品还是第三方开发产品?日志采集器由解决方案统一管理还是由日志源单独管理?一般来说,自研产品往往滞后于第三方开发的产品。如果日志采集器由解决方案统一管理,则能大大减少维护不同日志源的成本。
配置即代码。解决方案是否采用了“XX即代码”的设计思路?统一日志管理方案的配置能否保存在代码库?如果公司产品也采用这种设计思路,则采用“配置即代码”设计思路的统一日志管理方案便能够以编程的方式创建配置用例。
分类功能:分类用户(运维开发、安全、合规、IT运维)能否通过解决方案获得所需数据?能否通过解决方案定位不合规行为?如果具备这类功能,用户便能迅速了解异常情况,同时也能认识到统一日志管理解决方案的价值。
API功能:解决方案是否具备开放API?熟悉统一日志管理解决方案底层API有助于进一步发挥解决方案的价值。
预期成本:可以根据成本比较不同产品的长期效益和可扩展性。
选择统一日志管理解决方案还是安全信息事件管理产品?
开发运维人员、IT运维人员以及安全/合规人员都会用到统一日志管理解决方案。合理使用统一日志解决方案不仅有助于定位故障根源,还能在故障发生之前及时发送预警。部署统一日志解决方案时,需合理配置记录权限,按照监管规定避开敏感信息。优秀的统一日志管理解决方案应该能够快速提供分析所需信息,通过内置报告和相关功能帮助各类用户迅速响应常规请求。
联系客服