微服务日志

微服务日志

设立应用实例标识符
在使用微服务时，整套体系往往会同一时间运行同一组件的多个实例。最重要的就是在日志条目中设立实例标识符，从而区分各条目的具体来源。其ID的具体生成方式其实并不重要，只要保证惟一即可，这样我们才能借此回溯到特定服务器/容器以及生成该条目的应用处。在微服务架构中，大家可以利用服务注册表轻松为每项服务分配惟一的标识符。

坚持使用UTC时间
这项心得不仅适用于微服务架构，在其它场景下也同样值得坚持。任何使用过分布式应用程序——或者组件分散在各处——的朋友，都会意识到各组件使用不同时区进行计时有多么令人头痛。而在微服务架构中，以本地时间记录的日志条目会带来更严重的问题。如果大家确实需要使用本地时间，请在日志条目中以字段形式添加时区，从而简化信息的检索方式。但更重要的是一定要为UTC时间设立时区，并利用它在聚合工具内进行信息排序。

生成请求标识符
在将业务逻辑拆分为多个不同组件时，我们的逻辑最终需要由一个或者多个组件构成。而在追踪这些事务时，我们往往很难对其加以识别。因此，大家应当为每个事务生成一个惟一标识符，并利用其关联事件以及追踪各项事务。

利用聚合工具进行日志分组
如果大家没有对来自全部微服务的日志条目进行聚合，那么以上提到的心得将毫无意义。要实现这一目标，我们需要使用一款能够轻松实现条目分组与查询的工具。我个人使用ELK堆栈，其效果相当出色。如果大家之前没听过ELK，这里可以稍微解释几句。ELK是三款应用的集合体，由此构成的完整解决方案能够调度日志条目、实现条目存储与索引，而后对信息进行聚合与可视化处理。

日志数据结构

{"level":"error",“time”:"2021-02-27 10:08:08","server":"服务器1","service name":"dal","service code":"123456","func":"函数1","log":"非法访问"}

可以快速定位哪个服务器.微服务.函数，产生了哪种类型的日志。