背景介绍

公司要发展是为了保持竞争力、实现可持续发展并满足市场需求。随着市场环境的不断变化，公司需要不断创新、拓展业务范围、提高产品质量和服务水平，以适应不断变化的市场需求和客户需求。只有不断发展的公司才能在市场中立于不败之地，实现可持续发展。而业务是公司发展的基础和核心，公司通过不断拓展和优化业务来实现发展目标。
随着业务多模式发展，二手车业务已经从相对简单的业务逐步转变为包含交易业务交易、O2O、信息业务等。随着业务的发展，用户在业务中的生命周期获得了延长，用户端和商家端在业务上结合得越发紧密。在此基础上，还有新旧业务功能持续集成，以此来产生协同效应。越来越多的业务流程也导致了管控难度的提升以及流程上下游之间衔接点的增多。在这个业务发展的背景下，技术系统在支撑业务功能迭代时发现，由于业务的广度和深度的增加，技术系统在实现业务目标时，服务与服务之间的调用链路增长，关系增多，业务目标服务与服务之间的转化难度也在逐步提升，技术系统领域的复杂度也产生了新的增长。这些技术系统的问题会直接反映在业务目标的转化上，体现在是否更快速、更高效。

意义价值

技术团队的目标是开发新功能和保障技术系统稳定运行。业务的实现严重依赖于技术系统的运行状况，而越是复杂的技术系统，就越需要技术团队来掌控其运行状态。只有当技术团队很好地掌握了技术系统的运行状况时，才能助力业务目标的实现。提高技术团队的掌控能力需要深入洞察技术系统的运行状态。随着技术系统的复杂度不断提高，技术团队面临着三个关键性洞察力问题。从业务视角来看，技术层面的监控系统缺乏对业务的深度监测和评估，链路监控无法实现对业务转化链路的串联监测，而仅有的基础资源类监控指标无法反映业务结果。

业务部门的技术团队作为为商业侧服务的技术团队，其目标都是支撑业务实现商业价值。技术团队的核心问题在于提升商业转化路径上各个业务节点的技术质量。技术团队在技术层面需要提升对技术系统的洞察力，在业务层面需要确保商业转化路径的质量。上述两个方面的诉求归根结底都与技术系统的质量相关，既横向保障业务在商业转化路径上的质量，又纵向保障技术系统在系统调用链路上的质量。综上所述，技术团队的任务是实现商业价值，而商业价值的实现路径需要有很好的质量保障。技术团队需要解决的问题是提升系统的洞察力，以夯实实现商业价值的基础。

实践操作

实现商业价值

那么业务侧的技术团队如何实现商业价值？技术团队可以通过优化业务流程、开发和实施高效的业务流程来提高公司的整体运营效率。也可以通过创新产品或服务、研发新技术或新产品来满足市场需求，从而带来商业价值，或者通过降低成本、优化技术方案来降低公司的运营成本等多种方式来在实现商业价值中做出贡献。通过拆解技术团队的日常工作，技术团队在实现商业价值中的核心是两个事项：编写代码和运行代码，然后实现新功能、改进现有功能、修复错误、提高性能或降低成本等。所有这些产生商业价值的事情只有在代码运行时才能提供，而不是在编写时就可以提供。因为即使代码设计模式适用、代码注释详尽、数据算法高效，如果没有运行，对于业务而言仍然没有实现任何商业价值。运行中的代码才是有商业价值的。因此，为了为业务提供最大价值，技术团队需要尽可能深入地了解代码运行时的状态，而技术系统的度量指标通常是实现这一要求的唯一方法。

行业解决方案

服务于业务侧的技术团队，希望能够通过对技术系统的持续改进在实现商业价值中做出更多的贡献。结合团队的诉求和现实情况，行业内有各种各样的监控系统，能够实现技术系统端到端的监控，比如Prometheus等。同时，汽车之家内部也有一些自研的监控系统，基本能够实现全覆盖的监控。然而，技术系统的持续改进与带来商业价值之间总是缺乏一个有效的链接。我们逐渐认识到单纯部署一个或是几个监控系统不能解决我们的诉求，我们需要的是一种能够建立在基于数据的决策思想之上的方法，旨在提高软件质量、性能和可维护性，在整个软件开发生命周期中持续收集、分析和利用各种度量和指标，通过与业务侧深度协作，通过有益的决策来推动持续改进。这与度量驱动开发（Metrics-Driven Development，简称MDD）的理念不谋而合。
度量驱动开发主张整个应用开发过程由指标度量驱动，通过实时度量指标来驱动快速、精确和细粒度的软件迭代。度量驱动开发的理念，不但可以让技术团队实时感知技术系统的状态，及时跟踪定位并解决问题，而且可以帮助业务和运维团队一起关注相关的业务指标。

度量驱动开发（Metrics-Driven Development）的理念理早是在2011年3月12日Etsy公司举办的一次技术交流会上，由Etsy核心平台部负责人Mike Brittain提出的。

应用可观测性

业界对于度量驱动开发有许多应用的案例和实践，来自Gartner的《2023年重要战略技术趋势》中的“应用可观测性”也介绍了类似度量驱动开发一致的理念。

“应用可观测性是指，以高度协调和整合的方式 在业务职能部门、应用和运维(I&O)团队中应用可观测的数据，尽可能缩短行动与响应之间的延迟，实现业务决策的主动规划。”
引用

Prometheus

Prometheus官网的宣传标语是From metrics to insight（从指标度量到洞察力）。

度量驱动开发

度量驱动开发的理念是需求阶段就考虑设置关键指标监控项，随着应用上线，通过指标了解系统状态，通过对现状的数字化和可视化，帮助业务对未来进行规划和预测，进而实现业务改善。而且度量驱动开发是一种文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升合作共赢的意识具有很大的帮助。

• 对业务而言，可以实时掌控业务各项指标，通过数据做出决策。
• 对研发而言，可以实时感知应用各项指标、聚焦应用优化。
• 对运维而言，可以实时感知系统各项指标、快速定位问题。

度量驱动开发可使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。我们希望通过感知技术系统的运行状态，并且不断根据运行时的数据提供改进策略，将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到系统部署后再去补充。相对于通过制定各种复杂、严格的研发规定，以及各种评审会议来确保技术系统的安全可靠、稳定运行，度量驱动开发的理念的特别之处在于，通过采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。

团队实践探索

技术团队在采用度量驱动开发的实践探索过程中，总体分为4个阶段，首先，依据业务的范围进一步圈定核心领域。其次，通过核心领取构建度量指标体系。再次，通过对于度量指标的监控协同业务侧推动部分指标的改善，我们在此采用了最小可行产品（Minimum Viable Product，MVP）的策略，通过构建具有最少功能的版本，尽早地推出产品以测试反馈并验证概念的可行性。最后在验证效果后建立可视化的技术系统来推动整体的实践探索更具易用性、扩展性的落地和发展。

度量驱动开发那么首先需要解决的问题就是度量，也就是度量指标体系的构建，回顾探索实践的过程，在实践探索的过程中遇到的困难的也是度量指标体系的构建。度量指标体系的构建我们的目标是做到覆盖尽可能全面的覆盖，我们对于全面覆盖总结为横向和纵向2个方向上的覆盖。首先，横向需要满足业务的广度尽可能的纳入更多的核心关键业务，其次，纵向需要将业务-技术纵深进行深入的挖掘覆盖尽可能多的核心关键技术系统。

团队在度量指标体系的构建中，围绕业务流程的服务树，通过业务流程中各个关键节点的指标的下钻和穿透到极致，再通过参考Google SRE中提出的系统监控的四个黄金指标，构造业务-技术的全覆盖度量指标体系。

• 延迟（Latency）：衡量服务请求所需时间。例如，从技术视角所关注的HTTP请求平均耗时，而在业务视角下为用户完成下单操作的所需时长。
• 流量（Traffic）：衡量服务的容量需求。例如，从技术视角下每秒处理的HTTP请求数或者数据库系统的事务数量，业务视角下用户完成下单的数量。
• 错误（Errors）：衡量服务错误发生的速率。例如，技术视角下HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，业务视角下用户下单失败数量等。
• 饱和度（Saturation）：衡量当前服务的饱和度。例如，技术视角下内存、CPU、I/O、磁盘使用量，业务视角下的任务的完成率、优惠卷的使用量等。

技术在系统建设阶段完成了一个覆盖业务上用户端到商家端，技术上客户端到服务端的全景监控系统的建设，核心功能包括数据可视化、业务链路定制和监控预警。首先，我们复用公司的数据处理能力，包括数据收集、清洗、转换和存储等基础数据处理服务，通过复用它们，我们能够迅速获取数据处理能力，确保数据的准确性和一致性。另外，我们通过接入前端性能监控、云监控以及质量罗盘等监控系统，我们实现对整个技术系统的实时监控。在系统建设的技术选型上，我们选择了低代码平台作为开发工具。低代码平台提供了可视化开发环境，减少了开发工作的复杂性，不仅加快了构建和迭代速度，还提高了系统的灵活性和可扩展性。全景监控系统的建设不仅有助于团队更好地理解和管理其业务和技术系统，还为未来的创新和扩展奠定了坚实的基础。

实践成果

完成度量指标体系构建

完成基于业务的度量指标体系构建，完成设计近400个相关数据指标，实现了业务流程和技术系统的全面覆盖，具有重要意义。这一成果为业务提供了全面的数据洞察，帮助业务和技术人员更好地理解业务进展和技术系统，从而做出更明智的战略决策、提高效率、优化资源分配、改善客户体验，最终实现竞争优势和可持续增长。这些指标不仅提供了深刻的业务洞察，还为数据驱动的决策和创新奠定了坚实的基础。

形成改善的度量指标

商业价值提升，用户买卖车信息的处理效率提升240%，用户卖车信息的从车辆信息的提交再到将车辆信息通知商家进行处理这其中要经历很多业务流程以及技术系统，通过对车辆信息数据处理流程时长的监测发现问题点，通过与业务方协作的方式，改进车辆信息数据的处理流程，提高了数据留转与处理的时效，通过技术系统的改善提升了业务的运转效率，提升了商业价值。
商业价值挽回，拦截异常车况报告解析订单2000单，在车况报告解析积压和延时的及时预警发现问题点，通过对异常情况的的及时跟进处理拦截异常订单，实现商业价值的挽回。

未来展望

度量驱动开发（Metric-Driven Development，MDD）在软件工程领域扮演着关键的角色。它强调了度量数据在软件开发过程中的重要性，这些度量数据可以是关于代码质量、性能、可维护性、进度等各个方面的信息。首先，度量驱动开发有助于质量的改进。通过定期收集和分析度量数据，技术团队可以更好地了解软件质量的状态。这包括了解代码质量、性能表现、可维护性等各个方面。当度量数据揭示出问题或潜在的缺陷时，团队可以采取措施来改进质量，确保软件达到高标准。其次，度量数据可以用于目标设定。技术团队可以根据度量数据来设定明确的开发目标。例如，他们可以使用性能度量来设定性能目标，代码质量度量来设定代码质量标准。将这些目标加入到技术团队开发过程中的指导原则，有助于确保项目朝着期望的方向前进。此外，度量数据可以提供决策支持。项目管理和决策制定者可以根据度量数据做出明智的决策。例如，他们可以根据度量数据决定是否进行技术债务的偿还、是否进行性能优化、是否进行安全漏洞修复等关键决策。持续改进是度量驱动开发的核心原则之一。通过分析度量数据，团队可以识别问题的根本原因，并采取措施来不断改进开发流程、工具和实践，以提高效率和质量。最后，度量数据还有助于提高透明度和沟通。团队成员可以共享度量数据，让每个人都了解项目的状态和质量，有助于更好地协作解决问题。

通用化建设

下一个阶段重点建设的方向是监控工具的通用化建设，通用化的工具建设将更加灵活，允许团队根据其特定需求进行定制和扩展，能够满足不同团队和业务的需求。通用化的工具建设将更易于扩展，支持集成新的数据源、第三方插件和自定义脚本，以适应不断变化的技术栈和复杂性。这将为团队提供更大的灵活性，使他们能够构建适合其独特需求的度量驱动开发的解决方案，从而更好地理解和管理他们的技术系统和业务。

智能化建设

人工智能在软件领域有广泛的应用场景，比如AIOps等，未来支持度量驱动开发的工具系统需要更加自动化和智能化。机器学习和人工智能技术将用于分析监测数据，自动检测问题、异常和趋势，并提供实时的反馈和建议。通过机器学习和人工智能技术的应用将更有助于更精准的定位问题，更快地响应和解决问题，减少人为干预的需求，提高效率、可用性和安全性，降低成本，推动团队更好地进行资源利用。

写在最后

正如现代管理学大师彼得·德鲁克所说的“如果你无法度量它，就无法改进它”，度量帮助我们更深刻认识软件工程领域中的方方面面，设定改进方向，并衡量改进效果。

参考文档

Metrics-Driven Development https://legacy.devopsdays.org/events/2012-italy/proposals/MetricsDrivenDevelopment/
An Intro to Metrics Driven Development: What Are Metrics and Why Should You Use Them? https://www.freecodecamp.org/news/metrics-driven-development/
Metrics-Driven Development https://sookocheff.com/post/mdd/mdd/
Metrics-Driven Development https://www.infoq.com/articles/metrics-driven-development/

做我们的日常工作中系统重构都应该是最让人头疼的工作了，无论是错综复杂还是经意简单的系统在发展的过程中都会经历重构，而系统重构也是任何一个技术团队都无法回避的问题，在我服务的多家公司几乎每家公司都经历了一次甚至多次系统的重构，本文就我在多年的重构工作中总结出来的几点建议分享给各位朋友，希望能够给朋友们带来帮助。

1、重构确定并且聚焦目标

首先我相信我们大家都确信系统重构是会有巨大的成本投入的，业务可能需要暂缓、新系统引入的问题（BUG）带来业务的不稳定、研发人员以及配合人员的投入还有各种隐性成本等等，我们服务的是一家商业公司获取利润是最终目的，在投入具体成本做一个项目就肯定要获得收益的。重构的目标一定要能够获得更大的提升无论是业务流程还是系统性能或是其他方面，如果仅仅一个很小的改善完全没有如此的大费周章，权衡好成本是否能够获得良好的收益。

无论如何进行系统重构都是一次伤筋动骨的过程，是涅槃重生还是飞蛾扑火，完全取决我们项目执行的过程中是否明确了目标且一直聚焦于目标的实现，保持目标的聚集是能否取得良好结果的必要促销，如果我们仅仅确立了目标没有聚集于目标在多个非重要的节点投入较大资源必然会导致我们对目标的投入降低，工作中的原始资本投入都是8个小时，当然如果每个人都愿意乐于加班的话另外讨论，而我们的实际情况往往是8个小时都是不够用的，这就更加需要我们明确目标聚焦目标，把有限的资源投入到最重要的事情中，才能获得既定目标的良好结果。

2、重构要有可量化的指标

团队确认了重构的目标之后，下一步一定要将目标量化，确定好目标之后也就能够确认边界，围绕在边界内要将需要实现的事项一一罗列出来，并且尽可能对每个实现制定可以用数据清晰表现出来的指标，比如用户操作的响应时间缩短到100毫秒、单元测试的覆盖率达到80%、发现问题时长降低到30分钟以内等等，有了明确的数据指标我们才能评估最终是否获得了良好收益，这些目标必须要在重构团队，包括产品、研发、测试等等，甚至包括业务方在内达成一致，是团队的目标清晰明了，防止出现过度或是不达标是最终不能获得良好收益。

3、重构要有更好的质量

既然决定了要对系统进行一次重构，那么我们肯定要做到的就是要比之前做的更好，如果之前接口响应时间在100毫秒，而经过重构之后反而减低到了200毫秒以上那么岂不是很难看，大家辛苦付出的努力是不是也更加不值得。而进行重构往往是一件十分引人注目的事情，一个微小的问题反而容易在众人注目下变得非常严重的问题。为了减少引起不必要的麻烦，重构团队就更加要注重各个方面的问题，无论是系统性能、用户体验还是BUG数量等

4、重构之前要和业务方沟通

技术团队进行系统重构的工作的时候往往忽略掉了业务方，认为这是技术团队内部的事情，不需要知会业务方，这个想法是非常错误的，进行重构的目标就是为了改善改进业务流程，而不去和业务方提前沟通进行闭门造车，最后的结果很可能和进行重构的初衷背道而驰。进行系统重构首先我们必须了解现有系统的业务需求，是否有待改进的业务需求点，是否有新的业务诉求等这些需求往往会影响到我们重构的进度和目标，甚至出现南辕北撤的事情。
技术团队和业务方往往对待问题的出发角度不同，思考问题的方式也不同，在进行重构之前和业务方沟通获得业务方的支持，往往能够事半功倍。
例如，我的团队在进行一块业务系统重构的时候进入到了系统切换的试运行的阶段，由于拿出的方案给到业务方无法被业务方接受，业务方提出的解决方案我们还需要进行再次开放对整个项目进度影响了足足一个月时间之多。吸取教训的我们在进行下一个项目的时候提前和业务方进行了沟通，业务方从他们的角度给予了很多的意见和建议以及业务未来的发展方向的指引，我们发现这些建议和意见帮助我们更好理解业务的同时也大大的降低了我们工作量，减少了我们很多冗余的设计。

5、重构应该才用迭代的方式

参与过重构项目的朋友都知道，重构项目往往是个时间跨度很长的工作，少则一两个月多则一年半载都有，如果不将整个重构进行合理拆分，而是采用全部开发完成，再进行系统切换的方式会对整个重构引入很大的风险，首先长时间的时间跨度内业务会进行持续变更，其次团队面临长时间没有结果输出面临来自各个方面的压力还有系统问题持续累积，这种蒙头狂奔的方式往往造成了项目失败或是目标便宜，而采用迭代方式进行重构，可以以更小的颗粒度持续交付工作成果，交付-试用-反馈-调整，持续有交付，持续有反馈，持续调整能够保证团队的目标不会偏移，形成一个正向循环，保证最后的重构目标。

6、重构要清晰了解旧系统

知己知彼，百战不殆，系统重构是一个与旧系统对抗的过程，不对旧系统的弄的清清楚楚怎么能够比旧系统做的更好呢？其实了解现有系统是一个学习的过程，如果有旧系统的开发人员还在公司那么就事半功倍了，旧系统的开发同学帮忙给做次分享省去了我们重构团队很多的工作，比直接去读代码更能清晰明了的了解到旧系统的相关知识以及有哪些需求点和应该注意的问题等等，通过学习和了解旧系统设定目标基准值避免引入老旧问题也是避免重蹈覆辙的一个好办法。

7、重构要提前规划系统切换方案

不知道朋友有没有遇到过重构完系统发现如果进行新旧系统的切换是个难题，反正我是遇到过，由于没有提前做好规划和切换步骤导致最后临时抱佛脚，开始使用各种奇葩办法做系统切换，有的还需要增加额外工作量甚至各种办法的刷脸求人，总之这不是一个很好的体验。系统切换往往是在重构中被我们忽略的一个步骤，但是这是非常重要的一个环节，在做最初的计划就应该考虑到如何进行系统切换，一个设计好的切换方案也应该贯穿重构始终，避免因为切换方案引起服务不可用或是引入系统BUG。尤其是前期整个团队付出巨大努力取得了一定成果的时候在最后一步切换的时候出现问题对团队是个非常大的打击，也使得业务方对团队失去信心，带来很不必要的麻烦。

8、重构高度重视系统数据

一次系统重构大多数情况下会涉及到数据结构的修改，对数据结构进行修改必然引入很大的风险，尤其在一些老旧的业务系统重构精简业务去掉冗余数据的时候，往往需要将老数据的业务数据重新写入到新系统的数据库。重构的目标是为了比旧系统更好无论是性能还是业务方面，如果我们对数据的操作导致外部依赖旧系统的业务无法正常运行那将是影响SLA指标的问题还有，说到系统数据有些同学可能仅仅关注的是业务数据其实数据也包含了系统运行所产生的日志数据，无论新旧系统的日志数据都是很重要的，如果因为重构影响到数据的读取、处理、分析那么岂不是得不偿失的事情。

9、重构要才用成熟的技术选型

技术选型是重构工作的基石，选择一套成熟稳定的技术方案是重构项目完成的必要条件。有些时候我们引入最新版的数据库虽说会有性能提升但是也会引入一定的不稳定因素，之前我们团队在使用MongoDB的一个新版本的时候发现主从库的数据并不能很好的同步出现过丢失数据的情况，进入社区发现这个版本使用的用户很多都反馈了这个问题，这时候我们不得不选择了大多数人共同的一个选择降低了一个版本来解决问题，相信此类情况比比皆是。在不是很成熟的方案带来并不显著的性能提升反而还会引入不确定的风险的时候我们需要权衡利弊得失，重构更是要保证系统的稳定性。
技术方案能否有足够强大的支撑也是我们需要考虑的一个方面，现在我们团队面对的重构是从单体式架构往微服务转变，旧系统的版本构建在是PHP语言上，新的系统我们由两个选择继续选择用PHP进行重构或是才用公司统一的微服务框架，我们毫不犹豫的选择了使用公司统一的微服务，这样做有几个显而易见的好处。
1、和公司内部进行交互更加方便快捷；
2、可以直接获取成熟的经验；
3、基础服务有公司级的支持；
以上的好处显然对我们能否成功重构系统并且获得足够的帮助起到了显著的帮助，反而才用PHP进行微服务，公司内部并无成功经验可以借鉴，业内也并无太多可靠的方案可以进行选择。一个成熟可靠的的技术方案是我们能否更进一步的保障和基石。

10、重构更加关注重视团队成员

参与过重构的同学都知道重构工作是一项枯燥乏味的工作，往往周期长、复杂度、 难度大、牵扯广、优先级低而且很有可能是一件费力不讨好的工作，开发一个业 务方期待的新功能、新模块往往比一场翻天覆地的重构更能引起业务方的重视也 更容易获取良好结果与反馈，反而不需要承担大多的压力。而越是面对这样的情 况越是需要加大对团队的鼓励增强团队的信心，消除团队的疑虑困惑，给予团队 持续的鼓励，给整个团队注入正能量，让团队保持积极向上的团队氛围，即使面 对各种困难、问题，也始终对团队保持信心保持乐观，让大家轻松愉快的投入到 重构工作中，尽量不担负额外的压力。

以内内容均为工作中的总结反思，分享给大家希望以上的这些总结能够对大家有所帮助，文章所讲述的内容如有不足之处还望指出。

随着系统和业务的复杂度提升我们会对日志进行各种分类处理如通过日志的级别分类或是对不同的业务的日志进行分类处理，即使面对以上的需要我们仍然需要有一个统一的日志格式，这样就需要我们有一个标准的日志模块来完成这些工作，然而我们也希望这个日志模块是性能优良且方便易用的。

Java有一个比较出名的日志组件log4j，PHP语言也有类似的日志框架，同样来自于Apache的log4php是一个多功能的为PHP使用的日志框架。和log4j类似，通过log4php我们也可以控制日志信息输送的目的地是控制台、文件、数据库甚至是套接口服务器、syslog守护进程等，同样我们也可以控制每一条日志的输出格式;通过定义日志信息的级别，我们能够更加有效细致地控制日志的生成过程。更加惊喜的是以上叙述的这些功能甚至不需要我们修改代码，而是通过一个配置文件来灵活地进行配置。

安装介绍

log4php提供了两种安装方式，一是通过直接下载源码包，Apache log4php - Download；二是通过PEAR渠道安装。

PEAR方式安装命令

pear channel-discover pear.apache.org/log4php
pear install log4php/Apache_log4php

目录结构

├───apidocs - API生成文档
└───src

├───assembly - Maven的配置
├───changes - 更新日志
├───examples - 各种用法示例
├───main
│       └───php - 主要源码
├───site - 网站源码
└───test - 单元测试

配置介绍

log4php支持XML、PHP以及Properties三种配置文件，我们今天主要通过Properties方式的配置文件来讲解，此种方式的配置较为全面。如果不在日志记录前调用Logger::configure()方法进行配置，log4php使用默认方式进行配置

日志输出方式

名称                                     介绍
LoggerAppenderConsole         控制台，标准输出或标准错误流。
LoggerAppenderEcho             控制台，通过PHP的echo方式输出
LoggerAppenderFile               文件
LoggerAppenderDailyFile        文件（通过日志生成新文件）
LoggerAppenderRollingFile     文件 (通过尺寸设置生成新的日志文件).
LoggerAppenderMail              通过电子邮件发送日志，整个日志在一个电子邮件发送。
LoggerAppenderMailEvent      通过电子邮件发送日志，每条日志通过单独的电子邮件发送。
LoggerAppenderMongoDB      MongoDB
LoggerAppenderNull              忽略所有的日志事件
LoggerAppenderPDO             数据库
LoggerAppenderPhp              通过使用PHP trigger_error（）函数PHP用户级的消息
LoggerAppenderSocket          通过套接口输出日志
LoggerAppenderSyslog          syslog

日志内容输出格式方式

名称                                   介绍
LoggerLayoutHTML              输出到HTML表格中
LoggerLayoutPattern            灵活格式，通过一个字符串配置
LoggerLayoutSimple             简单格式，不可配置
LoggerLayoutSerialized         输出序列化对象
LoggerLayoutTTCC               包括时间，主题，类别和嵌套诊断上下文的 （不建议使用）
LoggerLayoutXml                 输出到XML文件

示例说明

示例一

配置示例

;定义输出方式名称default
log4php.appender.default = LoggerAppenderEcho
log4php.appender.default.layout = LoggerLayoutSimple

;定义一组新的输出方式名称为test
;日志输出方式设置
log4php.appender.test = LoggerAppenderDailyFile
;日志内容格式设置
log4php.appender.test.layout = LoggerLayoutPattern
;日志内容参数设置（日期 PID 日志级别 日志名称 日志文本 换行符）
log4php.appender.test.layout.ConversionPattern = "%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n"
;日志文件名称配置
log4php.appender.test.datePattern = Ymd
;日志文件路径配置
log4php.appender.test.file = /var/log/daily_%s.log

;日志输出方式以及输入级别设置
log4php.rootLogger = DEBUG, default

如果设置为已下值，日志可同时使用default和test两个输出定义进行记录
log4php.rootLogger = DEBUG, default,test

代码示例

<?php

require_once dirname(__FILE__) . '/log4php/main/php/Logger.php';
Logger::configure(dirname(__FILE__) . '/log4php.properties');
$logger = Logger::getLogger('exception');
$message = 'hello world!';
$logger->error('error,' . $message);//会产生记录
$logger->info('info,' . $message);//会产生记录
$logger->trace('trace,' . $message);//不会产生记录，因为设置的日志级别DEBUG，只有高于等于DEBUG级别的日志才会记录

输出示例

2016-12-15 16:25:55.55 [121215] ERROR exception: error,hello world!
2016-12-15 16:25:55.55 [121215] INFO exception: info,hello world!

示例二

配置示例

;定义输出方式名称default
log4php.appender.default = LoggerAppenderEcho
log4php.appender.default.layout = LoggerLayoutSimple

;定义一组新的输出方式名称为test
;日志输出方式设置
log4php.appender.test = LoggerAppenderDailyFile
;日志内容格式设置
log4php.appender.test.layout = LoggerLayoutPattern
;日志内容参数设置（日期 PID 日志级别 日志名称 日志文本 换行符）
log4php.appender.test.layout.ConversionPattern = "%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n"
;日志文件名称配置
log4php.appender.test.datePattern = Ymd
;日志文件路径配置
log4php.appender.test.file = /var/log/test_daily_%s.log
;日志输出方式以及输入级别设置
log4php.logger.test = INFO, test

;定义一组新的输出方式名称为pro
;日志输出方式设置
log4php.appender.pro = LoggerAppenderDailyFile
;日志内容格式设置
log4php.appender.pro.layout = LoggerLayoutPattern
;日志文内容式参数配（日期 PID 日志级别 日志名称 日志文本 换行符）
log4php.appender.test.layout.ConversionPattern = "%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n"
;日志文件名称配置
log4php.appender.pro.datePattern = Ymd
;日志文件路径配置
log4php.appender.pro.file = /var/log/pro_daily_%s.log
;日志输出方式以及输入级别设置
log4php.logger.pro = INFO, pro

代码示例

<?php
require_once dirname(__FILE__) . '/log4php/main/php/Logger.php';
Logger::configure(dirname(__FILE__) . '/log4php.properties');

/*
* 使用名称为test的方式处理日志
*/
$logger = Logger::getLogger('test');
$message = 'hello world!';
$logger->error($message);//会产生记录

/*
* 使用名称为pro的方式处理日志
*/
$logger = Logger::getLogger('pro');
$message = 'Hey, beautiful!';
$logger->error($message);//会产生记录

输出示例

/var/log/test_daily_20161215.log文件

2016-12-15 16:25:55.55 [121215] ERROR test: hello world!

/var/log/pro_daily_20161215.log文件

2016-12-15 16:25:55.55 [121215] ERROR test: Hey, beautiful!

log4php的配置文件十分灵活和简单，以上的只是很简单的两个示例，还不能全面的展示出来log4php配置方面的简单易用以及灵活性，仍然希望这能够对大家有所帮助，log4php的官方提供了良好的文档以及十分丰富的API，几乎满足了我们对于日志模块需要的全部需求，大家也可以通过查阅相关文档调整配置做出自己需要的日志模块。

log4php文档地址：http://logging.apache.org/log4php/index.html

希望这篇文章对你有所帮助，如果没有任何帮助抱歉浪费了你的阅读时间但是我不负任何责任，如有不足支持还望指出