精华内容
下载资源
问答
  • 也就是要求我们对个 Logging 的生态有完整的认识,从而来考虑分布式日志如何处理。我们先来理解一些概念:划分清楚 Logging 、Metrics、 Tracing身边有很多同事会把这三件可能认识不太彻底,其实这是三件分别侧重点...

     原创张振华 精品课

    首先,当我们如果作为架构师的角度去处理一件事情的时候,必须要有一些大局观。

    也就是要求我们对个 Logging 的生态有完整的认识,从而来考虑分布式日志如何处理。

    我们先来理解一些概念:

    划分清楚 Logging 、Metrics、 Tracing

    身边有很多同事会把这三件可能认识不太彻底,其实这是三件分别侧重点不同的事情,每件事都有各自的深度、边界和重叠部分。

    1. Logging:
      Logging 更加偏重的是一条一条的记录,而记录本身是离散事件,没有任何直接关系。Logging 可以在 Console、ElasticSearch、Kafka、File 等各种媒介中显示。而 Logging 的格式又可以通过各种 Logging 的实现去定义 Logging 的格式。

    2. Tracing:
      Tracing 的重心是整个处理链条的间接关系,而是需要把各种离散的 Logging 产生联系,让各种处理事件产生一定范围。

    3. Metrics:
      Metrics 度量的定义特征是它们是可聚合的。它们是在一段时间内构成单个逻辑度量,计数或直方图的原子数据,偏重于度量。

    而三者的边界和重叠部分需要我们在整个分布式系统中要非常清楚,而本 chat 就围绕 Logging 和 Tracing 这两件事情展开一下。

    技术 Tracing 链路跟踪、生态圈现状

    1. Google Dapper:Dapper——Google 生产环境下的分布式跟踪系统,而紧接着就发表了论文 Google Dapper paper 。

      然后就变成了所有分布式日志 Tracing 的鼻祖了,后来发展起来的 Zipkin、OpenTracing、sleuth 都是在 Google 的这篇论文作为理论基础上,不断优化发展出来的。

    2. Zipkin:Zipkin 是分布式日志链路跟踪系统,最早由 Twitter 创造和开源,现在交由 OpenZipkin 社区管理。它可以帮助收集时间数据在 Microservice 架构需要解决延迟问题。

      它管理这些数据的收集和查找。Zipkin 的设计是基于 Dapper。它也是一个完整的生态解决方案包括:collector(收集)、 storage(储存)、 search(搜索)、 Zipkin Web UI(页面控制台)。

      而其也对个各种语言做了支持,我们重点关注了一下 java 的 client,看后面的表格。github : https://github.com/openzipkin;官方地址:http://zipkin.io/

    3. OpenTracing:OpenTracinghttp://opentracing.io/通过提供平台无关、厂商无关的 API,使得开发人员能够方便的添加(或更换)追踪系统的实现。

      OpenTracing 正在为全球的分布式追踪,提供统一的概念和数据标准。而 OpenTracing 来自大名鼎鼎的 CNCF(Cloud Native Computing Foundation, https://www.cncf.io/)。

      虽然 OpenTracing 晚于 Zipkin 但是更大大佬、更大抽象,这使其很快成为业内首选。而开源团队:Zipkin、TRACER、JAEGER(Uber 出品)等等逐渐实现了 OpenTracing 的标准。

    4. Sleuth:这个热闹的事情,怎么能少了 Spring 开源社区呢?Spring-Cloud-Sleuth 是 Spring Cloud 的组成部分之一,为 SpringCloud 应用实现了一种分布式追踪解决方案,其兼容了Zipkin、HTrace、OpenTracing。

      而底层是基于 Zipkin 的 brave 做了实现。设计思路也是参考 Dapper(他们之间的关系,作者认为应该是这样的 sleuth 通过 brave 默认输出到 Zipkin,由 Zipkin 决定是否是 OpenTracing 格式的输出,PS:这个欢迎大家一起讨论)。

      官方地址:http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.0.0.RC1/single/spring-cloud-sleuth.html

    5. Jaeger 分布式监控系统由 Uber 设计并实现,现已捐赠给 CNCF 基金会,作为分布式环境下推荐的监控系统。其实主要是作为 Tracing 的 server 端,前期先支持了 Zipkin 后来又实现了 OpenTracing 的标准。有 UI 和储存(ElasticSearch、cassandra)。和 Zipkin 的 ui 服务器端有点像。官方地址:https://www.jaegertracing.io/

    重点关注一下 Zipkin 的开源库

    Tracing 整体负责干的事情有:

    1. 生成 trackId, spanId。

    2. 负责 MDC 给 log。

    3. 发送给 tracingserver 端,server 负责储存和搜索。

    4. Tracing UI 负责展示。

    技术 Logging 本身,生态圈现状

    上面我们了解整个 Tracing 的技术栈,我们再来看下关于 Logging 的技术栈。

    1. Spring Logging:Java Util Logging、SLF4J、Log4J、Log4J2和Logback 这些都是老生常谈的问题了,默认 Spring Logging 内部采用的是 Commons Logging。

      但是当我们引用相应的其它 Logging 的实现和相应的 Logging 文件的时候就会自动切换 Logging 的实现,并做到兼容。我们唯一需要注意的是:SpringProfile 的支持,如下:

    <springProfile name="staging">
        <!-- configuration to be enabled when the "staging" profile is active -->
    </springProfile>
    <springProfile name="dev, staging">
        <!-- configuration to be enabled when the "dev" or "staging" profiles are active -->
    </springProfile>
    <springProfile name="!production">
        <!-- configuration to be enabled when the "production" profile is not active -->
    </springProfile>

    自定义日志实现:

    1. ELK:Spring Logging 紧紧是负责单机日志输出,而分布式不得不请出 ELK。

      ElasticSearch 负责作为我们的 logs 的储存和查询,其数据可以提供给 Jaeger 使用可以给 Kibana 使用。

      而 Kibana 负责做各种基于 logs 的 chat 图和查看详细的 Logging 的日志记录的详情。Logstash 不用多说了,负责给我们收集日志,包括网关层,业务层等。


    1. Sentry:也是一个重量级选手。负责解决我们系统中的 error 日志和 error 日志警告。

      Sentry 就是来帮我们解决这个问题的,它是一款精致的 Django 应用,目的在于帮助开发人员从散落在多个不同服务器上毫无头绪的日志文件里发掘活跃的异常,继而找到潜在的臭虫。

      Sentry 是一个日志平台, 它分为客户端和服务端,客户端(目前客户端有 Python、PHP、C#、Ruby 等多种语言)就嵌入在你的应用程序中间,程序出现异常就向服务端发送消息,服务端将消息记录到数据库中并提供一个 Web 界面方便查看。

      Sentry 还有有很多亮点,比如敏感信息过滤, release 版本跟踪,关键字查找,受影响用户统计,权限管理等(部分可能需要我们通过代码提供内容)可以通过 Sentry 进行问题分配与跟踪。

      Sentry 的 plugin 模块还可以集成大量的第三方工具如: slack , jira 。

      对我们来说最大的便利就是利用日志进行错误发现和排查的效率变高了。

      重要的有一下三点:

      1. 及时提醒
        报警的及时性:不需要自己再去额外集成报警系统,一旦产生了 issue 便以邮件通知到项目组的每个成员。

      2. 问题关联信息的聚合
        每个问题不仅有一个整体直观的描绘,聚合的日志信息省略了人工从海量日志中寻找线索,免除大量无关信息的干扰。

      3. 丰富的上下文
        Sentry 不仅丰富还规范了上下文的内容,也让我们意识到更多的有效内容,提高日志的质量。

    技术选型 VS

    当我们了解了我们需要知道的技术点之后,接下去就是针对我们公司具体业务现状进行选型,以我们公司为例,可能不止一个 Java 团队,还有 Ruby,node.js 等其它语言的开发团队。

    好多其它技术选型都是基于 cncf 的,如:k8s、docker、permissions 等,所以我们就一如既往的还选择了 CNCF 的技术体系及 OpenTracing。

    其实如果要去真实比较的话,差别也不是特别大,并且都做到了相互的兼容。而 Jaeger VS Zipkin server 选择了 Jaeger,因其启动简单与 Java 解耦。

    Java 语言体系采用 Spring 的 Sleuth,这样我们可以省很多事情,并且也是很成熟的解决方案,而 Spring Cloud 生态也非常成熟。

    实战

    生产的日志要求

    1. 每个请求的参数是什么,输出结果是什么,debug 可以选择自由开启。

    2. 每个请求的链路要串起来。

    3. error 独立收集上下文是什么,及时警告,各个环境分开。

    生产的日志实现

    第一个问题:所有请求的日志明细

    1. 我们利用

    import org.springframework.web.filter.CommonsRequestLoggingFilter;

    来打印我们的所有的请求的日志配置如下:

    //我们只需要将此类在配置文件中加载即可。里面可以设置Logging里面是否打印header 、request payload、query String 、client信息等。唯一的缺点就是没有办法打印responseBody。
        @Bean
        @ConditionalOnMissingBean
        public CommonsRequestLoggingFilter requestLoggingFilter() {
            CommonsRequestLoggingFilter loggingFilter = new CommonsRequestLoggingFilter();
            loggingFilter.setIncludeClientInfo(true);
            loggingFilter.setIncludeQueryString(true);
            loggingFilter.setIncludePayload(true);
            loggingFilter.setIncludeHeaders(true);        return loggingFilter;
        }
    //源码和原理其实非常简单,做个filter做logging debug即可。public class CommonsRequestLoggingFilter extends AbstractRequestLoggingFilter {    @Override
        protected boolean shouldLog(HttpServletRequest request) {        return logger.isDebugEnabled();
        }    /**
         * Writes a log message before the request is processed.
         */
        @Override
        protected void beforeRequest(HttpServletRequest request, String message) {
            logger.debug(message);
        }    /**
         * Writes a log message after the request is processed.
         */
        @Override
        protected void afterRequest(HttpServletRequest request, String message) {
            logger.debug(message);
        }
    }

    日志输出的格式如下:

    [36667] 2018-05-19 20:22:06.185 - [notification-api,93bb291ab411e41a,93bb291ab411e41a,false] - DEBUG [http-nio-8080-exec-1] org.springframework.web.filter.CommonsRequestLoggingFilter.log - Before request [uri=/hello;client=127.0.0.1;headers={host=[127.0.0.1:8080], connection=[keep-alive], accept=[*/*], user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36], referer=[http://127.0.0.1:8080/swagger-ui.html], accept-encoding=[gzip, deflate, br], accept-language=[en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7], cookie=[OUTFOX_SEARCH_USER_ID_NCOO=1602949848.9012377; gsScrollPos-73=]}]
    [36667] 2018-05-19 20:22:06.434 - [notification-api,93bb291ab411e41a,93bb291ab411e41a,false] - DEBUG [http-nio-8080-exec-1] org.springframework.web.filter.CommonsRequestLoggingFilter.log - After request [uri=/hello;client=127.0.0.1;headers={host=[127.0.0.1:8080], connection=[keep-alive], accept=[*/*], user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36], referer=[http://127.0.0.1:8080/swagger-ui.html], accept-encoding=[gzip, deflate, br], accept-language=[en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7], cookie=[OUTFOX_SEARCH_USER_ID_NCOO=1602949848.9012377; gsScrollPos-73=]}]

    2. 针对没有 responseBody 的问题,我们可以自定义一个拦截器,和 CommonsRequestLoggingFilter 做差不多的事情即可。这里需要注意的是需要用到:

    import org.springframework.web.util.ContentCachingRequestWrapper;
    import org.springframework.web.util.ContentCachingResponseWrapper;

    来做参数的输出和 response 的 io 的输出。但是切记很多东西不需要重复写给大家看一个关键代码:

    第二个问题: 将 Logging 收集到 ELK

    此处我们采用的是 Docker 容器,直接将日志输出到控制台,用 logstash 直接收集 Docker 的日志给 ElasticSearch 在 kibana 显示。如下图所示:



    我们只需要 search trackID 即可。

    或者以 logback 为例,添加 logstash appender。关键代码如下:

    <!-- Appender to log to file in a JSON format -->
    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}.json</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
            <maxHistory>7</maxHistory>
        </rollingPolicy>
        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <pattern>
                    <pattern>
                        {
                        "severity": "%level",
                        "service": "${springAppName:-}",
                        "trace": "%X{X-B3-TraceId:-}",
                        "span": "%X{X-B3-SpanId:-}",
                        "parent": "%X{X-B3-ParentSpanId:-}",
                        "exportable": "%X{X-Span-Export:-}",
                        "pid": "${PID:-}",
                        "thread": "%thread",
                        "class": "%logger{40}",
                        "rest": "%message"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>
    第三个问题:我们在我们的每个请求 Header 上加上 traceId
    //从上下文中取到traceId,然后丢到返回的header里面
        @Override
        public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
            String traceId = ThreadContext.get("traceId");
                chain.doFilter(request, response);
            ((HttpServletResponse)response).setHeader("TraceId", traceId);
        }
    第四个问题:Tracing 处理

    1. 有了上面的理论基础,就是就看看 spring cloud sleuth 怎么支持 OpenTracing 和生成 tracId 和 span,及其将 log 吐给 jaeger。

    展开全文
  • 目录 基础概念 划分清楚 Logging 、Metrics...第一个问题:所有请求的日志明细 第二个问题: 将 Logging 收集到 ELK 第三个问题:我们在我们的每个请求 Header 上加上 traceId 第四个问题:Tracing 处理   ...

    目录

    基础概念

    划分清楚 Logging 、Metrics、 Tracing

    技术 Tracing 链路跟踪、生态圈现状

    技术 Logging 本身,生态圈现状

    技术选型 比较

    实战

    第一个问题:所有请求的日志明细

    第二个问题: 将 Logging 收集到 ELK

    第三个问题:我们在我们的每个请求 Header 上加上 traceId

    第四个问题:Tracing 处理


     

    本文转载自张振华老师分享的的「从架构角度来看 Java 分布式日志如何收集」,仅供大家参考学习。

    基础概念

    首先,当我们如果作为架构师的角度去处理一件事情的时候,必须要有一些大局观。

    也就是要求我们对个 Logging 的生态有完整的认识,从而来考虑分布式日志如何处理。

    我们先来理解一些概念:

    划分清楚 Logging 、Metrics、 Tracing

    身边有很多同事会把这三件可能认识不太彻底,其实这是三件分别侧重点不同的事情,每件事都有各自的深度、边界和重叠部分。

    1. Logging: Logging 更加偏重的是一条一条的记录,而记录本身是离散事件,没有任何直接关系。Logging 可以在 Console、ElasticSearch、Kafka、File 等各种媒介中显示。而 Logging 的格式又可以通过各种 Logging 的实现去定义 Logging 的格式。
    2. Tracing: Tracing 的重心是整个处理链条的间接关系,而是需要把各种离散的 Logging 产生联系,让各种处理事件产生一定范围。
    3. Metrics: Metrics 度量的定义特征是它们是可聚合的。它们是在一段时间内构成单个逻辑度量,计数或直方图的原子数据,偏重于度量。

    而三者的边界和重叠部分需要我们在整个分布式系统中要非常清楚,而本文 就围绕 Logging 和 Tracing 这两件事情展开一下。

    技术 Tracing 链路跟踪、生态圈现状

    1. Google Dapper:Dapper——Google 生产环境下的分布式跟踪系统,而紧接着就发表了论文 Google Dapper paper 。 然后就变成了所有分布式日志 Tracing 的鼻祖了,后来发展起来的 Zipkin、OpenTracing、sleuth 都是在 Google 的这篇论文作为理论基础上,不断优化发展出来的。
    2. Zipkin:Zipkin 是分布式日志链路跟踪系统,最早由 Twitter 创造和开源,现在交由 OpenZipkin 社区管理。它可以帮助收集时间数据在 Microservice 架构需要解决延迟问题。 它管理这些数据的收集和查找。Zipkin 的设计是基于 Dapper。它也是一个完整的生态解决方案包括:collector(收集)、 storage(储存)、 search(搜索)、 Zipkin Web UI(页面控制台)。 而其也对个各种语言做了支持,我们重点关注了一下 java 的 client,看后面的表格。github : https://github.com/openzipkin;官方地址:http://zipkin.io/
    3. OpenTracing:OpenTracinghttp://opentracing.io/通过提供平台无关、厂商无关的 API,使得开发人员能够方便的添加(或更换)追踪系统的实现。 OpenTracing 正在为全球的分布式追踪,提供统一的概念和数据标准。而 OpenTracing 来自大名鼎鼎的 CNCF(Cloud Native Computing Foundation, https://www.cncf.io/)。 虽然 OpenTracing 晚于 Zipkin 但是更大大佬、更大抽象,这使其很快成为业内首选。而开源团队:Zipkin、TRACER、JAEGER(Uber 出品)等等逐渐实现了 OpenTracing 的标准。
    4. Sleuth:这个热闹的事情,怎么能少了 Spring 开源社区呢?Spring-Cloud-Sleuth 是 Spring Cloud 的组成部分之一,为 SpringCloud 应用实现了一种分布式追踪解决方案,其兼容了Zipkin、HTrace、OpenTracing。 而底层是基于 Zipkin 的 brave 做了实现。设计思路也是参考 Dapper(他们之间的关系,作者认为应该是这样的 sleuth 通过 brave 默认输出到 Zipkin,由 Zipkin 决定是否是 OpenTracing 格式的输出,PS:这个欢迎大家一起讨论)。 官方地址:http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.0.0.RC1/single/spring-cloud-sleuth.html
    5. Jaeger 分布式监控系统由 Uber 设计并实现,现已捐赠给 CNCF 基金会,作为分布式环境下推荐的监控系统。其实主要是作为 Tracing 的 server 端,前期先支持了 Zipkin 后来又实现了 OpenTracing 的标准。有 UI 和储存(ElasticSearch、cassandra)。和 Zipkin 的 ui 服务器端有点像。官方地址:https://www.jaegertracing.io/

    Zipkin 的开源库

    Tracing 整体负责干的事情有:

    1. 生成 trackId, spanId。
    2. 负责 MDC 给 log。
    3. 发送给 tracingserver 端,server 负责储存和搜索。
    4. Tracing UI 负责展示。

    技术 Logging 本身,生态圈现状

    上面我们了解整个 Tracing 的技术栈,我们再来看下关于 Logging 的技术栈。

    1>. Spring Logging:Java Util Logging、SLF4J、Log4J、Log4J2和Logback 这些都是老生常谈的问题了,默认 Spring Logging 内部采用的是 Commons Logging。 但是当我们引用相应的其它 Logging 的实现和相应的 Logging 文件的时候就会自动切换 Logging 的实现,并做到兼容。我们唯一需要注意的是:SpringProfile 的支持,如下:

    <springProfile name="staging">
        <!-- configuration to be enabled when the "staging" profile is active -->
    </springProfile>
    <springProfile name="dev, staging">
        <!-- configuration to be enabled when the "dev" or "staging" profiles are active -->
    </springProfile>
    <springProfile name="!production">
        <!-- configuration to be enabled when the "production" profile is not active -->
    </springProfile>

    自定义日志实现:

    2>. ELK:Spring Logging 紧紧是负责单机日志输出,而分布式不得不请出 ELK。 ElasticSearch 负责作为我们的 logs 的储存和查询,其数据可以提供给 Jaeger 使用可以给 Kibana 使用。 而 Kibana 负责做各种基于 logs 的 chat 图和查看详细的 Logging 的日志记录的详情。Logstash 不用多说了,负责给我们收集日志,包括网关层,业务层等。

    3>. Sentry:也是一个重量级选手。负责解决我们系统中的 error 日志和 error 日志警告。 Sentry 就是来帮我们解决这个问题的,它是一款精致的 Django 应用,目的在于帮助开发人员从散落在多个不同服务器上毫无头绪的日志文件里发掘活跃的异常,继而找到潜在的臭虫。 Sentry 是一个日志平台, 它分为客户端和服务端,客户端(目前客户端有 Python、PHP、C#、Ruby 等多种语言)就嵌入在你的应用程序中间,程序出现异常就向服务端发送消息,服务端将消息记录到数据库中并提供一个 Web 界面方便查看。 Sentry 还有有很多亮点,比如敏感信息过滤, release 版本跟踪,关键字查找,受影响用户统计,权限管理等(部分可能需要我们通过代码提供内容)可以通过 Sentry 进行问题分配与跟踪。 Sentry 的 plugin 模块还可以集成大量的第三方工具如: slack , jira 。 对我们来说最大的便利就是利用日志进行错误发现和排查的效率变高了。

    重要的有以下三点:

    1. 及时提醒 报警的及时性:不需要自己再去额外集成报警系统,一旦产生了 issue 便以邮件通知到项目组的每个成员。
    2. 问题关联信息的聚合 每个问题不仅有一个整体直观的描绘,聚合的日志信息省略了人工从海量日志中寻找线索,免除大量无关信息的干扰。
    3. 丰富的上下文 Sentry 不仅丰富还规范了上下文的内容,也让我们意识到更多的有效内容,提高日志的质量。

    技术选型 比较

    当我们了解了我们需要知道的技术点之后,接下去就是针对我们公司具体业务现状进行选型,以我们公司为例,可能不止一个 Java 团队,还有 Ruby,node.js 等其它语言的开发团队。

    好多其它技术选型都是基于 cncf 的,如:k8s、docker、permissions 等,所以我们就一如既往的还选择了 CNCF 的技术体系及 OpenTracing。

    其实如果要去真实比较的话,差别也不是特别大,并且都做到了相互的兼容。而 Jaeger VS Zipkin server 选择了 Jaeger,因其启动简单与 Java 解耦。

    Java 语言体系采用 Spring 的 Sleuth,这样我们可以省很多事情,并且也是很成熟的解决方案,而 Spring Cloud 生态也非常成熟。

    实战

    生产的日志要求

    1. 每个请求的参数是什么,输出结果是什么,debug 可以选择自由开启。
    2. 每个请求的链路要串起来。
    3. error 独立收集上下文是什么,及时警告,各个环境分开。

    生产的日志实现

    第一个问题:所有请求的日志明细

    1. 我们利用

    import org.springframework.web.filter.CommonsRequestLoggingFilter;

    来打印我们的所有的请求的日志配置如下:

    //我们只需要将此类在配置文件中加载即可。里面可以设置Logging里面是否打印header 、request payload、query String 、client信息等。唯一的缺点就是没有办法打印responseBody。
        @Bean
        @ConditionalOnMissingBean
        public CommonsRequestLoggingFilter requestLoggingFilter() {
            CommonsRequestLoggingFilter loggingFilter = new CommonsRequestLoggingFilter();
            loggingFilter.setIncludeClientInfo(true);
            loggingFilter.setIncludeQueryString(true);
            loggingFilter.setIncludePayload(true);
            loggingFilter.setIncludeHeaders(true);        return loggingFilter;
        }
    //源码和原理其实非常简单,做个filter做logging debug即可。public class CommonsRequestLoggingFilter extends AbstractRequestLoggingFilter {    @Override
        protected boolean shouldLog(HttpServletRequest request) {        return logger.isDebugEnabled();
        }    /**
         * Writes a log message before the request is processed.
         */
        @Override
        protected void beforeRequest(HttpServletRequest request, String message) {
            logger.debug(message);
        }    /**
         * Writes a log message after the request is processed.
         */
        @Override
        protected void afterRequest(HttpServletRequest request, String message) {
            logger.debug(message);
        }
    }

    日志输出的格式如下:

    [36667] 2018-05-19 20:22:06.185 - [notification-api,93bb291ab411e41a,93bb291ab411e41a,false] - DEBUG [http-nio-8080-exec-1] org.springframework.web.filter.CommonsRequestLoggingFilter.log - Before request [uri=/hello;client=127.0.0.1;headers={host=[127.0.0.1:8080], connection=[keep-alive], accept=[*/*], user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36], referer=[http://127.0.0.1:8080/swagger-ui.html], accept-encoding=[gzip, deflate, br], accept-language=[en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7], cookie=[OUTFOX_SEARCH_USER_ID_NCOO=1602949848.9012377; gsScrollPos-73=]}]
    [36667] 2018-05-19 20:22:06.434 - [notification-api,93bb291ab411e41a,93bb291ab411e41a,fals

    2. 针对没有 responseBody 的问题,我们可以自定义一个拦截器,和 CommonsRequestLoggingFilter 做差不多的事情即可。这里需要注意的是需要用到:

    import org.springframework.web.util.ContentCachingRequestWrapper;
    import org.springframework.web.util.ContentCachingResponseWrapper;

    来做参数的输出和 response 的 io 的输出。但是切记很多东西不需要重复写给大家看一个关键代码:

    第二个问题: 将 Logging 收集到 ELK

    此处我们采用的是 Docker 容器,直接将日志输出到控制台,用 logstash 直接收集 Docker 的日志给 ElasticSearch 在 kibana 显示。如下图所示:

    我们只需要 search trackID 即可。

    或者以 logback 为例,添加 logstash appender。关键代码如下:

    <!-- Appender to log to file in a JSON format -->
    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}.json</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
            <maxHistory>7</maxHistory>
        </rollingPolicy>
        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <pattern>
                    <pattern>
                        {
                        "severity": "%level",
                        "service": "${springAppName:-}",
                        "trace": "%X{X-B3-TraceId:-}",
                        "span": "%X{X-B3-SpanId:-}",
                        "parent": "%X{X-B3-ParentSpanId:-}",
                        "exportable": "%X{X-Span-Export:-}",
                        "pid": "${PID:-}",
                        "thread": "%thread",
                        "class": "%logger{40}",
                        "rest": "%message"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    第三个问题:我们在我们的每个请求 Header 上加上 traceId

    //从上下文中取到traceId,然后丢到返回的header里面
        @Override
        public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
            String traceId = ThreadContext.get("traceId");
                chain.doFilter(request, response);
            ((HttpServletResponse)response).setHeader("TraceId", traceId);
        }

    第四个问题:Tracing 处理

    1. 有了上面的理论基础,就是就看看 spring cloud sleuth 怎么支持 OpenTracing 和生成 tracId 和 span,及其将 log 吐给 jaeger。

    注:

    原文发布于GitChat精品课(CSDN_Tech)

    原文发表时间:2018-06-01

     

     

     

     

     

    展开全文
  • 在实际工作中会发现身边的同事或者一些公司,搭建和构建日志系统的时候走了很多的弯路,有用 Logback 的有用 Log4j 的,有自定义 Aappender 改变日志格式的,有异步推送到日志系统的,有用 ELK 的,有用国内开源 Cat...

    在实际工作中会发现身边的同事或者一些公司,搭建和构建日志系统的时候走了很多的弯路,有用 Logback 的有用 Log4j 的,有自定义 Aappender 改变日志格式的,有异步推送到日志系统的,有用 ELK 的,有用国内开源 Cat 的。开源的 Cloud 框架有用 Sleuth 的,有用 Zipkin 的,而也有直接用 OpenTracking 的。可能五花八门什么样的都有,作者通过这篇文章,来看一下我们生产环境的日志是如何收集的。

    通过此篇 Chat 我们可以了解到如下内容:

    1. OpenTracing 是什么?
    2. Spring Cloud Sleuth 我们如何使用?
    3. Zipkin 扮演什么角色?
    4. Spring Logging 为我们做了哪些工作?
    5. ELK 应该怎么样来收集我们的日志?
    6. 如何利用 Sentry 独立收集异常和警告日志?
    7. 一个日志系统的正确架构思想是什么?
    8. 我们的生产 Framework-Logging 做了哪些工作?

    我们这篇 Chat 的中心是谈谈怎么从全局来看这件事,把实战经验给大家分享一下。由于篇幅有限可能不能谈里面的实现原理,主要是实际操作,完成整体认识。

    实录内容提要:

    1. 目前微服务盛行,这个业务可能夸多个系统,怎样设计日志系统,在出现问题时怎样,才能快速定位不同系统间的请求是同一笔请求,例如系统间日志能否有一个统一的 ID?
    2. OpenTracing 与 Zipkin 如何做选择?
    3. Server ZipkinUI 和 Jaeger 如何做选择?
    4. Sleuth 依赖 Filter 并配置一定的 Percentage 这样性能会成线性下降,你如何看这样的问题?在生产环境下查问题的时候才打开吗?
    5. JMS 日志跟踪是如何实现的?
    6. DBtracing 如何实现的?
    7. 有没有代码地址可以参考?
    8. 集成的时候坑有哪些?
    9. 日志系统架构的本质是什么?
    10. 日志级别该如何划分?
    11. 架构师最重要的素质是什么?
    12. 阿里有对 Java 日志部分做约束吗?

    阅读全文: http://gitbook.cn/gitchat/activity/5aeb13c1bba5bc30cda8303f

    您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。

    FtooAtPSkEJwnW-9xkCLqSTRpBKX

    展开全文
  • ELK,也就是Elasticsearch、Logstash、Kibana三者的结合,是一套开源的分布式日志管理方案. Elasticsearch:负责日志存储、检索和分析 LogStash:负责日志的收集、处理 Kibana:负责日志的可视化 方案: 2. 环境搭建...
  • 1.flume是分布式日志收集系统,把收集来的数据传送到目的地去。 2.flume里面有个核心概念,叫做agent。agent是一个java进程,运行在日志收集节点。通过agent接收日志,然后暂存起来,再发送到目的地。 3.agent里面...

    1.flume是分布式的日志收集系统,把收集来的数据传送到目的地去。
    2.flume里面有个核心概念,叫做agent。agent是一个java进程,运行在日志收集节点。通过agent接收日志,然后暂存起来,再发送到目的地。
    3.agent里面包含3个核心组件:source、channel、sink。
      3.1 source组件是专用于收集日志的,可以处理各种类型各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。
        source组件把数据收集来以后,临时存放在channel中。
      3.2 channel组件是在agent中专用于临时存储数据的,可以存放在memory、jdbc、file、自定义。
        channel中的数据只有在sink发送成功之后才会被删除。
      3.3 sink组件是用于把数据发送到目的地的组件,目的地包括hdfs、logger、avro、thrift、ipc、file、null、hbase、solr、自定义。
    4.在整个数据传输过程中,流动的是event。事务保证是在event级别。
    5.flume可以支持多级flume的agent,支持扇入(fan-in)、扇出(fan-out)。
    在这里插入图片描述

    6、安装Flume:

    1、先将flume的bin.jar和src.jar复制到/usr/local下,然后解压,将src目录下的文件复制到bin目录下:cp -ri apache-flume-1.4.0-src/* apache-flume-1.4.0-bin/
    2、删除/usr/lcoal下的解压好的src文件,再将bin重命名:mv apache-flume-1.4.0-bin flume
    3、flume/bin/ #flume-ng 可以看到命令的相关用法
    4、核心是写配置文件

    7.书写配置文件example

    在flume/conf/下创建配置文件example:
    vi example 或者直接在winSCP中创建

    复制代码
    #agent1表示代理名称
    agent1.sources=source1
    agent1.sinks=sink1
    agent1.channels=channel1

    #Spooling Directory是监控指定文件夹中新文件的变化,一旦新文件出现,就解析该文件内容,然后写入到channle。写入完成后,标记该文件已完成或者删除该文件。
    #配置source1 interceptor可以在数据传递过程中改变其属性信息
    agent1.sources.source1.type=spooldir
    agent1.sources.source1.spoolDir=/root/hmbbs
    agent1.sources.source1.channels=channel1
    agent1.sources.source1.fileHeader = false
    agent1.sources.source1.interceptors = i1
    agent1.sources.source1.interceptors.i1.type = timestamp

    #配置sink1
    agent1.sinks.sink1.type=hdfs
    agent1.sinks.sink1.hdfs.path=hdfs://hadoop0:9000/hmbbs
    agent1.sinks.sink1.hdfs.fileType=DataStream
    agent1.sinks.sink1.hdfs.writeFormat=TEXT
    agent1.sinks.sink1.hdfs.rollInterval=1
    agent1.sinks.sink1.channel=channel1
    agent1.sinks.sink1.hdfs.filePrefix=%Y-%m-%d

    #配置channel1
    agent1.channels.channel1.type=file
    agent1.channels.channel1.checkpointDir=/root/hmbbs_tmp/123
    agent1.channels.channel1.dataDirs=/root/hmbbs_tmp/

    复制代码

    在/root下创建文件夹hmbbs:mkdir hmbbs
    在HDFS中创建文件夹:hadoop fs -mkdir /hmbbs

    8.执行命令bin/flume-ng agent -n agent1 -c conf -f conf/example -Dflume.root.logger=DEBUG,console
    执行完了,flume就会监控/root/hmbbs中数据的变化

    在/root/hmbbs下:
      vi hello
        hello you
        hello me
      cp hello hmbbs
    现在数据就发生了变化!flume就会监控到变化,并把数据文件上传到hdfs中

    可在hadoop0:50070中观察到日志文件
    在这里插入图片描述

    也可在hadoop0/root/hmbbs下,观察到有个hello.COMPLETED,之前的hello变成了hello.COMPLETED(因为这里使用的是Spooling Directory导致的。对hello从不删除,上传完成只会重命名)
    在这里插入图片描述

    在/root/hmbbs_tmp目录下,这个目录是channel使用的目录。在/root/hmbbs_tmp123目录下,表示的是备份数据。

    展开全文
  • 前言 系统一大,就会拆分成多个独立的进程,比如web+wcf/web api等,也就成了...分布式日志收集系统就登场了。 今天介绍一款 全开源日志收集、展示系统 - logstash(基于java)+kibana(基于JRuby, logstash已自带)...
  • Flume是由Cloudera提供的一个分布式、高可靠、高可用的服务,用于分布式的海量日志的高收集、聚合、移动系统。 Agent:source,channel,sink 设计目标: 可靠性 扩展性 管理性 业界同类产品对比: (推荐) Flume:...
  • [系统架构]分布式日志收集系统

    千次阅读 2014-11-04 10:25:06
    前言系统一大,就会拆分成多个独立的进程,比如web+wcf/web api等,也就成...分布式日志收集系统就登场了。今天介绍一款全开源日志收集、展示系统 - logstash(基于java)+kibana(基于JRuby, logstash已自带)+Elastic
  • 1.flume是分布式日志收集系统,把收集来的数据传送到目的地去。 2.flume里面有个核心概念,叫做agent。agent是一个java进程,运行在日志收集节点。 3.agent里面包含3个核心组件:source、channel、sink。 3.1 ...
  • logstash是一种分布式日志收集框架,开发语言是JRuby,当然是为了与Java平台对接,不过与Ruby语法兼容良好,非常简洁强大,经常与ElasticSearch,Kibana配置,组成著名的ELK技术栈,非常适合用来做日志数据的分析。...
  • 分布式日志收集套件-ELK

    千次阅读 2017-12-13 15:02:54
    ELK 是elastic公司提供的一套完整的日志收集、展示解决方案,是三个产品的首字母缩写,分别是ElasticSearch、Logstash 和 Kibana。 ElasticSearch简称ES,它是一个实时的分布式搜索和分析引擎,它可以用于全文搜索...
  • ELK分布式日志收集系统介绍 1.ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。它提供了...
  • Flume是一个分布式、高可靠、高可用、负载均衡的进行大量日志数据采集、聚合和并转移到存储中的框架, 基于流式架构,容错性强,也很灵活简单,主要用于在线实时的引用分析,只能在Unix环境下运行,底层源码由Java...
  • 一、 ELK介绍 ElK,即ElasticSearch+Logstash+Kibana ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本...Elasticsearch是用Java开发的,并...
  • Flume安装前置条件 Java Runtime Environment - Java 1.7 or later Memory - Sufficient memory for configurations used by sources, channels or sinks Disk Space - Sufficient disk space for configurations...
  • 前提准备: 1.ES+kibana+logstash 一台虚拟机配置运行内存3G,由于本人电脑资源有限开了2台 2.kafka+zookeeper 一台虚拟机,运行内存1G 共7个G 原理图: ...更加详细的原理elk原理可以看我...rpm -qa |grep java r...
  • 1. ELK介绍 ElK,即ElasticSearch+Logstash+Kibana ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,...Elasticsearch是用Java开发的,...
  • 分布式系统日志收集

    千次阅读 2019-04-04 23:30:11
    分布式的环境中,日志收集通常采用 ELK 或其他的消息中间件,但是部署和使用都比较复杂。 本 Chat 将讲述另外一种非常简便的方式,而且不需要任何的学习成本就可以使用,那就是在 Logback 日志框架的基础上做一些...
  • 1、下载安装 java 8 SDK (不要安装最新的10.0) 并配置好环境变量(环境变量的配置就不做介绍了) 2、下载安装Elasticsearch 5.X 这里注意 只能下载 5.X版本 请勿使用其他版本(但我们用Exceptionless的时候,会出现...
  • 架构、分布式、日志队列,标题自己都看着唬人,其实就是一个日志收集的功能,只不过中间加了一个Kafka做消息队列罢了。 kafka介绍 Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。...
  • 分布式系统日志收集ELK

    万次阅读 2019-01-07 21:50:36
    1. ELK介绍 ElK,即ElasticSearch+Logstash+Kibana ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,...Elasticsearch是用Java开发的...
  • dlog分布式日志系统 ##支持以下特性1.动态修改日志等级[网络或远程登录] 2.日志远程实时输出3.日志集中搜集4.支持全文检索,以及基于日志的用户行为分析5.对java应用不侵入,只需6.支持收集常用服务的日志

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 380
精华内容 152
关键字:

java分布式日志收集

java 订阅