1.easylogging源码学习笔记（6）
2.Kafka Logcleaner源码分析
3.如何理解深度学习源码里经常出现的码分logits？
4.如何从零写一个日志库（glog介绍）
5.常见log日志的使用方法详细解析
6.Gin源码分析 - 中间件（3）- Logger

easylogging源码学习笔记（6）

       `LOG` 是默认日志、CLOG自定义日志、码分LOG_IF条件日志

       特殊日志

       LOG_EVERY_N、码分LOG_AFTER_N、码分LOG_N_TIMES

       for (int i = 1; i <= ; ++i) {

       LOG_EVERY_N(2,码分 INFO) << "Logged every second iter";

       }// 5 logs written; 2, 4, 6, 7,

       for (int i = 1; i <= ; ++i) {

       LOG_AFTER_N(2, INFO) << "Log after 2 hits; " << i;

       }// 8 logs written; 3, 4, 5, 6, 7, 8, 9,

       for (int i = 1; i <= ; ++i) {

       LOG_N_TIMES(3, INFO) << "Log only 3 times; " << i;

       }// 3 logs writter; 1, 2, 3

       条件日志和特殊日志可以搭配使用

       * `VLOG_IF(condition, verbose-level)`

       * `CVLOG_IF(condition, verbose-level, loggerID)`

       * `VLOG_EVERY_N(n, verbose-level)`

       * `CVLOG_EVERY_N(n, verbose-level, loggerID)`

       * `VLOG_AFTER_N(n, verbose-level)`

       * `CVLOG_AFTER_N(n, verbose-level, loggerID)`

       * `VLOG_N_TIMES(n, verbose-level)`

       * `CVLOG_N_TIMES(n, verbose-level, loggerID)`

       日志详细等级判定

       if (VLOG_IS_ON(2)) {

       // Verbosity level 2 is on for this file

       }

       性能追踪

       * `TIMED_FUNC(obj-name)`

       * `TIMED_SCOPE(obj-name, block-name)`

       * `TIMED_BLOCK(obj-name, block-name)`

       这些宏实际上都是关于el::base::type::PerformanceTrackerPtr，一个指向el::base::PerformanceTracker的码分网页宠物挂件源码指针

       #if defined(ELPP_FEATURE_ALL) || defined(ELPP_FEATURE_PERFORMANCE_TRACKING)

       PerformanceTracker::PerformanceTracker(const std::string& blockName,

       base::TimestampUnit timestampUnit,

       const std::string& loggerId,

       bool scopedLog, Level level) :

       m_blockName(blockName), m_timestampUnit(timestampUnit), m_loggerId(loggerId), m_scopedLog(scopedLog),

       m_level(level), m_hasChecked(false), m_lastCheckpointId(std::string()), m_enabled(false) {

       #if !defined(ELPP_DISABLE_PERFORMANCE_TRACKING) && ELPP_LOGGING_ENABLED

       // We store it locally so that if user happen to change configuration by the end of scope

       // or before calling checkpoint, we still depend on state of configuration at time of construction

       el::Logger* loggerPtr = ELPP->registeredLoggers()->get(loggerId, false);

       m_enabled = loggerPtr != nullptr && loggerPtr->m_typedConfigurations->performanceTracking(m_level);

       if (m_enabled) {

       base::utils::DateTime::gettimeofday(&m_startTime);

       }

       #endif // !defined(ELPP_DISABLE_PERFORMANCE_TRACKING) && ELPP_LOGGING_ENABLED

       }

       在构造函数中获取一个时间，

       PerformanceTracker::~PerformanceTracker(void) {

       #if !defined(ELPP_DISABLE_PERFORMANCE_TRACKING) && ELPP_LOGGING_ENABLED

       if (m_enabled) {

       base::threading::ScopedLock scopedLock(lock());

       if (m_scopedLog) {

       base::utils::DateTime::gettimeofday(&m_endTime);

       base::type::string_t formattedTime = getFormattedTimeTaken();

       PerformanceTrackingData data(PerformanceTrackingData::DataType::Complete);

       data.init(this);

       data.m_formattedTimeTaken = formattedTime;

       PerformanceTrackingCallback* callback = nullptr;

       for (const std::pair& h

       : ELPP->m_performanceTrackingCallbacks) {

       callback = h.second.get();

       if (callback != nullptr && callback->enabled()) {

       callback->handle(&data);

       }

       }

       }

       }

       #endif // !defined(ELPP_DISABLE_PERFORMANCE_TRACKING)

       }

       在析构函数中获取一个时间，码分处理时间data，码分使用PerformanceTrackingCallback类型指针callback，码分并在callback->handle(&data)中处理输出。码分

       由于定义了ELPP_FEATURE_PERFORMANCE_TRACKING，码分因此在初始化（INITIALIZE_EASYLOGGINGPP）中实际上是码分安装了一个base::DefaultPerformanceTrackingCallback。

       在PerformanceTracker类的码分handle函数中，callback是码分一个PerformanceTrackingCallback类型指针，由于安装的码分是DefaultPerformanceTrackingCallback对象，因此是一个基类指针指向了派生类对象。处理输出的逻辑在DefaultPerformanceTrackingCallback类的handle函数中。

       DefaultPerformanceTrackingCallback类的handle函数首先会将数据成员m_data的指针赋值给函数参数，并创建一个base::type::stringstream_t类型的对象ss用于构建输出内容。根据m_data的dataType，输出不同的信息。在输出时，网页登录后台源码会使用el::base::Writer类构造并输出内容。

Kafka Logcleaner源码分析

       Kafka日志保留策略包括按时间/大小和compact两种。Logcleaner遵循compact策略清理日志，只保留最新的消息，当多个消息具有相同key时，只保留最新的一个。

       每个日志由两部分组成：clean和dirty。dirty部分可以进一步划分为cleanable和uncleanable。uncleanable部分不允许清理，包括活跃段和未达到compact延迟时间的段。

       清理过程由后台线程定期执行，选择最脏的日志进行清理，脏度由dirty部分字节数与总字节数的比例决定。清理前，Logcleaner构建一个key->last_offset映射，包含dirty部分的所有消息。清理后，日志文件过滤掉过期消息，并合并较小的连续段为较大文件。

       payload为null的消息被Logcleaner删除，这类消息在topic配置的房友源码出售时间内保留，然后被清理。清理过程需与幂等性和事务性生产者兼容，保留活跃生产者最后一批消息，直到产生新消息或生产者不活跃。只清理提交或终止事物中的消息，未提交事物中的消息不清理。

       Logcleaner通过cleanOrSleep方法启动清理，选择最脏日志，调用clean清理并合并段。在清理前计算tombstone的移除时间，确保在clean部分驻留一定时间后移除。清理过程包括构建offset映射，分组段文件并清理合并。

       Logcleaner的清理逻辑确保了高效和一致的日志管理，助力Kafka系统稳定运行。

如何理解深度学习源码里经常出现的logits？

深度学习的秘钥：揭示logits的真面目

       在深度学习的源码世界中，logits一词频繁出现，它似乎隐藏着某种魔力。那么，logits究竟是什么？它与我们熟知的概率计算有何关联？让我们一探究竟，揭示这个术语背后的android源码配置app深层含义。（p - 李航《统计学习方法》）

       首先，logits是概率学中的一个重要概念，它并非简单的对数，而是事件发生与不发生比值的对数形式。想象一下，当某个事件发生的概率为p时，其logits可以这样表示：\[ \text{ logits} = \log\left(\frac{ p}{ 1-p}\right) \]（p - TensorFlow官方文档）

       当我们将logits与深度学习中的softmax层联系起来，你会发现它们之间的紧密关系。softmax层的作用是将一组未归一化的数值（即logits）转换为一个概率分布，确保所有概率值之和为1。在TensorFlow中，我们通常称这些未经过归一化的数值为logits，而不是它们的数学定义。

       实际上，logits在深度学习模型中扮演着未加工的概率值角色，它们是概率分布的起点。softmax层通过对logits进行加和运算，将其转变为一个清晰、可解释的概率矩阵。理解这一点至关重要，因为logits的趋势彩虹指标源码计算结果直接影响着模型的决策过程和最终预测。

       总结来说，logits在深度学习中是未归一化的概率表示，它们是softmax函数运算的起点，是模型输出概率分布的基础。掌握这个概念，就能更好地解析和解读源码中的logits，从而深入理解模型的工作原理。（p - TensorFlow官方教程）

如何从零写一个日志库（glog介绍）

       探索日志管理的艺术，本文将深入解析glog——谷歌开源的日志库，为你揭示从零开始构建自定义日志解决方案的关键要素。让我们一起从基本需求到高级接口，一窥其内部工作原理。

基本需求与核心组件

       glog的核心在于LogMessage类，它负责记录日志的时间、位置信息以及根据过滤条件进行输出。0.3.5版本作为起点，提供了诸如LOG、LOG_IF和LOG_TO_SINK等接口，让你能灵活定制输出到默认目标或自定义sink。

       获取glog的源代码：/google/glog.git，源码中的src/glog/http://logging.h.in是你探索之旅的起点。

关键接口详解

       LOG(severity)：这是基础接口，将日志发送到默认输出，如LOG_ERROR = LogMessage(FILE, LINE, GLOG_ERROR)。

       LOG_IF(severity, condition)：条件式过滤，如LOG_IF(severity, !condition) & LOG(severity)，只在满足条件时记录。

       LOG_TO_SINK(sink, severity)：直接将日志导向自定义sink，同时不遗漏默认输出。

宏定义的艺术

       通过VLOG、LOG_TO_STRING和SYSLOG_IF等宏，你可以根据需求进行灵活的抽样和条件输出。例如，VLOG_IF(INFO, condition)在满足条件时增加日志的可见性，VLOG_EVERY_N则进行抽样记录。

深入日志流程

       glog的过滤机制依赖于LOG_IF，它根据FLAGS_minloglevel调整记录行为，避免不必要的CPU开销。LogMessage的构造和析构处理日志记录，而Stream函数确保与输出操作的兼容性。

       在使用时，如LOG(INFO) << "log test"，实际上会先检查条件，然后输出，返回值为void以保持与"<<"操作符的配合。

高级定制与性能优化

       LogMessageData结构体提供了字节的流式输出能力，通过LogDestination和Logger接口，实现灵活的日志目标管理，如支持异步写入的MyAppLogSink。

       尽管glog提供了强大的基础，但其在多线程写入和日志文件类型上的限制需要通过sink接口进行扩展，以适应复杂环境下的日志需求。

后续章节预告

       接下来的文章将深入讨论FATAL日志和coredump的生成过程，带你了解glog在故障诊断中的关键作用。

       总之，glog不仅是一个强大的日志库，更是日志管理策略的灵活载体。掌握它，为你的项目增添强大的故障排查能力。敬请期待《深入解析glog的FATAL与coredump》。

常见log日志的使用方法详细解析

       日志在程序开发中起着至关重要的作用，它能帮助我们调试错误并记录关键信息。常见的日志框架包括Java自带的原生日志、log4j以及Slf4j等。

       日志级别是控制输出信息的关键，通常分为：OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE和ALL，级别越高，信息越详细。Java.util.Logger，如在源代码中使用`Logger`，可以通过设置级别来调整输出，例如，`logger.setLevel(Level.ALL)`会显示所有级别的信息，而`logger.setLevel(Level.WARNING)`则只会显示严重和警告级别的信息。

       log4j则通常在XML配置文件中配置，比如导入依赖和配置``元素。通过这种方式，可以精细地控制每个日志条目的格式和输出位置。log4j2的配置文件如`log4j2.xml`，提供了丰富的自定义选项。

       Slf4j作为当前主流的日志框架，支持参数化输出，只需在类头引入`import org.slf4j.Logger`和`LoggerFactory.getLogger`，并在代码中调用相关方法。在引入依赖时，可能出现`SLF4J: Failed to load class`的问题，解决方法通常是检查类路径和slf4j的绑定。Slf4j的输出信息中包含类路径信息，便于追踪问题来源。

       总结来说，log日志的使用方法因框架而异，但核心在于控制输出级别和配置细节，以满足不同开发阶段的需求。通过灵活运用这些工具，可以提高程序的可维护性和可读性。

Gin源码分析 - 中间件（3）- Logger

       本文深入剖析Gin框架内置中间件Logger，详细阐述其四种创建形式。基本形式以默认配置输出日志至标准输出。自定义格式器形式允许用户调整日志输出格式。指定输出流形式则灵活地将日志输出至特定写入器，同时可忽略指定路径的日志。复杂配置形式提供高度定制化，是创建中间件的高级手段。深入探讨LoggerConfig结构体，解析其三个关键属性：日志格式、输出器和忽略路径。LogFormatter方法实现日志的格式化，包含辅助函数进行颜色调整，如根据HTTP响应码和请求类型设置显示颜色。defaultLogFormatter方法提供默认的日志格式化操作。详细解析LoggerWithConfig方法，该方法获取配置参数并判断输出环境，随后将忽略路径保存为映射，记录过滤的路径。计算处理时间和构建日志字符串，输出至指定写入器。