elk 部署架构

elk 部署架构

一、概述

ELK 已经成为目前最流行的集中式日志解决方案,它主要是由Beats、Logstash、Elasticsearch、Kibana等组件组成,来共同完成实时日志的收集,存储,展示等一站式的解决方案。本文将会介绍ELK常见的架构以及相关问题解决。

Filebeat:Filebeat是一款轻量级,占用服务资源非常少的数据收集引擎,它是ELK家族的新成员,可以代替Logstash作为在应用服务器端的日志收集引擎,支持将收集到的数据输出到Kafka,Redis等队列。
Logstash:数据收集引擎,相较于Filebeat比较重量级,但它集成了大量的插件,支持丰富的数据源收集,对收集的数据可以过滤,分析,格式化日志格式。
Elasticsearch:分布式数据搜索引擎,基于Apache Lucene实现,可集群,提供数据的集中式存储,分析,以及强大的数据搜索和聚合功能。
Kibana:数据的可视化平台,通过该web平台可以实时的查看 Elasticsearch 中的相关数据,并提供了丰富的图表统计功能。

二、ELK常见部署架构

2.1、Logstash作为日志收集器

这种架构是比较原始的部署架构,在各应用服务器端分别部署一个Logstash组件,作为日志收集器,然后将Logstash收集到的数据过滤、分析、格式化处理后发送至Elasticsearch存储,最后使用Kibana进行可视化展示,这种架构不足的是:Logstash比较耗服务器资源,所以会增加应用服务器端的负载压力。

2.2、Filebeat作为日志收集器

该架构与第一种架构唯一不同的是:应用端日志收集器换成了Filebeat,Filebeat轻量,占用服务器资源少,所以使用Filebeat作为应用服务器端的日志收集器,一般Filebeat会配合Logstash一起使用,这种部署方式也是目前最常用的架构。

2.3、引入缓存队列的部署架构

该架构在第二种架构的基础上引入了Redis缓存队列(还可以是其他消息队列),将Filebeat收集到的数据发送至Redis,然后在通过Logstasth读取Redis中的数据,这种架构主要是解决大数据量下的日志收集方案,使用缓存队列主要是解决数据安全与均衡Logstash与Elasticsearch负载压力。

2.4、以上三种架构的总结

第一种部署架构由于资源占用问题,现已很少使用,目前使用最多的是第二种部署架构,至于第三种部署架构个人觉得没有必要引入消息队列,除非有其他需求,因为在数据量较大的情况下,Filebeat 使用压力敏感协议向 Logstash 或 Elasticsearch 发送数据。如果 Logstash 正在繁忙地处理数据,它会告知 Filebeat 减慢读取速度。拥塞解决后,Filebeat 将恢复初始速度并继续发送数据。

三、问题及解决方案

问题:如何实现日志的多行合并功能?

系统应用中的日志一般都是以特定格式进行打印的,属于同一条日志的数据可能分多行进行打印,那么在使用ELK收集日志的时候就需要将属于同一条日志的多行数据进行合并。

解决方案:使用Filebeat或Logstash中的multiline多行合并插件来实现

在使用multiline多行合并插件的时候需要注意,不同的ELK部署架构可能multiline的使用方式也不同,如果是本文的第一种部署架构,那么multiline需要在Logstash中配置使用,如果是第二种部署架构,那么multiline需要在Filebeat中配置使用,无需再在Logstash中配置multiline。

1、multiline在Filebeat中的配置方式:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/test.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
output:
   logstash:
      hosts: ["localhost:5044"]
  • pattern:正则表达式
  • negate:默认为false,表示匹配pattern的行合并到上一行;true表示不匹配pattern的行合并到上一行
  • match:after表示合并到上一行的末尾,before表示合并到上一行的行首

如:

pattern: '\['
negate: true
match: after

该配置表示将不匹配pattern模式的行合并到上一行的末尾

2、multiline在Logstash中的配置方式

input {
  beats {
    port => 5044
  }
}

filter {
  multiline {
    pattern => "%{LOGLEVEL}\s*\]"
    negate => true
    what => "previous"
  }
}

output {
  elasticsearch {
    hosts => "localhost:9200"
  }
}

(1)Logstash中配置的what属性值为previous,相当于Filebeat中的after,Logstash中配置的what属性值为next,相当于Filebeat中的before。
(2)pattern => “%{LOGLEVEL}\s*]” 中的LOGLEVEL是Logstash预制的正则匹配模式,预制的还有好多常用的正则匹配模式,详细请看:https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns

问题:如何将Kibana中显示日志的时间字段替换为日志信息中的时间?

默认情况下,我们在Kibana中查看的时间字段与日志信息中的时间不一致,因为默认的时间字段值是日志收集时的当前时间,所以需要将该字段的时间替换为日志信息中的时间。

解决方案:使用grok分词插件与date时间格式化插件来实现

在Logstash的配置文件的过滤器中配置grok分词插件与date时间格式化插件,如:

input {
  beats {
    port => 5044
  }
}

filter {
  multiline {
    pattern => "%{LOGLEVEL}\s*\]\[%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME}\]"
    negate => true
    what => "previous"
  }

  grok {
    match => [ "message" , "(?<customer_time>%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME})" ]
  }

  date {
        match => ["customer_time", "yyyyMMdd HH:mm:ss,SSS"] //格式化时间
        target => "@timestamp" //替换默认的时间字段
  }
}

output {
  elasticsearch {
    hosts => "localhost:9200"
  }
}

如要匹配的日志格式为:“[DEBUG][20170811 10:07:31,359][DefaultBeanDefinitionDocumentReader:106] Loading bean definitions”,解析出该日志的时间字段的方式有:

① 通过引入写好的表达式文件,如表达式文件为customer_patterns,内容为:
CUSTOMER_TIME %{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME}
注:内容格式为:[自定义表达式名称] [正则表达式]
然后logstash中就可以这样引用:

filter {
  grok {
      patterns_dir => ["./customer-patterms/mypatterns"] //引用表达式文件路径
      match => [ "message" , "%{CUSTOMER_TIME:customer_time}" ] //使用自定义的grok表达式
  }
}

② 以配置项的方式,规则为:(?<自定义表达式名称>正则匹配规则),如:

filter {
  grok {
    match => [ "message" , "(?<customer_time>%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME})" ]
  }
}

问题:如何在Kibana中通过选择不同的系统日志模块来查看数据

一般在Kibana中显示的日志数据混合了来自不同系统模块的数据,那么如何来选择或者过滤只查看指定的系统模块的日志数据?

解决方案:新增标识不同系统模块的字段或根据不同系统模块建ES索引

1、新增标识不同系统模块的字段,然后在Kibana中可以根据该字段来过滤查询不同模块的数据
这里以第二种部署架构讲解,在Filebeat中的配置内容为:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/account.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       fields: //新增log_from字段
         log_from: account

    -
       paths:
          - /home/project/elk/logs/customer.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       fields:
         log_from: customer
output:
   logstash:
      hosts: ["localhost:5044"]

通过新增:log_from字段来标识不同的系统模块日志

2、根据不同的系统模块配置对应的ES索引,然后在Kibana中创建对应的索引模式匹配,即可在页面通过索引模式下拉框选择不同的系统模块数据。
这里以第二种部署架构讲解,分为两步:

① 在Filebeat中的配置内容为:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/account.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       document_type: account

    -
       paths:
          - /home/project/elk/logs/customer.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       document_type: customer
output:
   logstash:
      hosts: ["localhost:5044"]

通过document_type来标识不同系统模块

② 修改Logstash中output的配置内容为:

output {
  elasticsearch {
    hosts => "localhost:9200"
    index => "%{type}"
  }
}

在output中增加index属性,%{type}表示按不同的document_type值建ES索引

四、总结

本文主要介绍了ELK实时日志分析的三种部署架构,以及不同架构所能解决的问题,这三种架构中第二种部署方式是时下最流行也是最常用的部署方式,最后介绍了ELK作在日志分析中的一些问题与解决方案,说在最后,ELK不仅仅可以用来作为分布式日志数据集中式查询和管理,还可以用来作为项目应用以及服务器资源监控等场景,更多内容请看官网。

参考资料

url 与转义

url 与转义

URI

URI,全称是 Uniform Resource Identifiers,即统一资源标识符,用于在互联网上标识一个资源,比如 https://www.upyun.com/products/cdn 这个 URI,指向的是一张漂亮的,描述又拍云 CDN 产品特性的网页。

URI 的组成

完整的 URI,由四个主要的部分构成:

<scheme>://<authority><path>?<query>

scheme 表示协议,比如 http,ftp 等等,详细介绍可以参考 rfc2396#section-3.1。

authority,用 :// 来和 scheme 区分。从字面意思看就是“认证”,“鉴权”的意思,引用 rfc2396#secion-3.2 的一句话:

这个“认证”部分,由一个基于 Internet 的服务器定义或者由命名机关注册登记(和具体的协议有关)。

而常见的 authority 则是:“由基于 Internet 的服务器定义”,其格式如下:

<userinfo>@<host>:<port>

userinfo 这个域用于填写一些用户相关的信息,比如可能会填写 “user:password”,当然这是不被建议的,抛开这个不讲,后面的 : 则是被熟知的服务器地址了,host 可以是域名,也可以是对应的 IP 地址,port 表示端口,这是一个可选项,如果不填写,会使用默认端口(和协议相关,比如 http 是 80)。

path,在 scheme 和 authority 确定下来的情况下标识资源,path 由几个段组成,每个段用 / 来分隔,path 不等同于文件系统定义的路径。

query,查询串(或者说参数串),用 ? 和 path 区分开来,其具体的含义由这个资源来定义。

保留字符

从上面的描述里看,URI 的这 4 个组件,由特定的分隔符来分离,这些分隔符有着它们的特殊含义,如果在某个部分里出现这些分隔符,比如在 path 是 /a/b?c.html,那么 c.html 会被当做是 query,这样就破坏了原本的含义,因此 URI 引入保留字符集,这些字符用于特殊目的,如果它们被用于描述资源(不是作为分隔符出现),那么必须对它们转义。
那么什么情况下需要对一个字符转义呢,引用 rfc2395#section-2.2 的一句话:

In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding.

即如果转义前后这个字符会影响到整个 URI 的意义,则它必须被转义。

由于 URI 由多个部分构成,一个字符不转义,可能会对其中一个部分会造成影响,但对另一个部分没有影响,所以“保留字符集”是由具体的 URI 组成部分来规定。

  • 对 path 部分而言,保留字符集是(参考自 rfc2396):

reserved = “/” | “?” | “;” | “=”

  • 对 query 部分而言,保留字符集是(参考自 rfc2396):

reserved = “;” | “/” | “?” | “:” | “@” | “&” | “=” | “+” | “,” | “$”

字符的转义规则如下:

escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"

比如 , 转义后为 %2C。

特殊字符

有一类不被允许用在 URI 里的特殊字符,它们被称为控制字符,即 ASCII 范围在0-31 之间的字符,以及 ASCII 码为 127 的这个字符。比如 \t,\a 这些(不包括空格),因为这些字符不可打印而且可能会消失(在某些场景下)。
另外一类则是扩展 ASCII 码,即范围 128-255 的那些字符,它们不属于 “US-ASCII coded character set”,因此这些字符如果出现在 URI 中,需要被转义。
URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded.

不安全字符

Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters “<” and “>” are unsafe because they are used as the delimiters around URLs in free text; the quote mark (“””) is used to delimit URLs in some systems. The character “#” is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character “%” is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are “{“, “}”, “|”, “”, “^”, “~”, “[”, “]”, and “`”.
这段话引用自 rfc1738 2.2 节。因为种种的原因,存在一类字符,它们是 “unsafe” 的,不加处理地存在在 URI 里,会破坏 URI 的语义完整性,对于这类字符,如果要出现在 URI 里,那么也得被转义。

nginx 的 URI 转义机制

nginx (以现在最新的 1.13.6 版本为准)提供了一个名为 ngx_escape_uri 的函数,函数原型如下:

uintptr_t ngx_escape_uri(u_char *dst, u_char *src, size_t size,ngx_uint_t type);

第三个参数,type,可以接受这些值:

#define NGX_ESCAPE_URI 0
#define NGX_ESCAPE_ARGS 1
#define NGX_ESCAPE_URI_COMPONENT 2
#define NGX_ESCAPE_HTML 3
#define NGX_ESCAPE_REFRESH 4
#define NGX_ESCAPE_MEMCACHED 5
#define NGX_ESCAPE_MAIL_AUTH 6

我们只关心其中的 NGX_ESCAPE_URI ,NGX_ESCAPE_ARGS ,NGX_ESCAPE_URI_COMPONENT 三个,根据 nginx 官方提供的 nginx 各模块和核心 API 介绍,这三个宏的含义如下:

NGX_ESCAPE_URI: Escape a standard URI
NGX_ESCAPE_ARGS: Escape query arguments
NGX_ESCAPE_URI_COMPONENT: Escape the URI after the domain

对应地,ngx_escape_uri 这个函数,内置了几个相关的 bitmap,区别在于各自的转义字符集,具体可以查阅 nginx 的源码(ngx_string.c#1441)。
其中针对整个 URI 的转义处理,ngx_escapeuri 会把 ” “, “#”, “%”, “?” 以及 %00-%1F 和 %7F-%FF 的字符转义;针对 query 的转义,会把 ” “, “#”, “%”, “&”, “+”, “?” 以及 %00-%1F 和 %7F-%FF 的字符转义;针对 path + query(the URI after the domain)的转义,会把除英文字母,数字,以及 “-“, “.”, ““, “~” 这些以外的字符全部转义。
可以看到,NGX_ESCAPE_URI 和 NGX_ESCAPE_ARGS 没有处理不安全字符,前者站在处理整个的 URI 的角度上编码,因此 ‘/’, ‘&’ 等分割符字符没有编码(但是对 ‘?’ 却编码,这点的原因目前未知),后者站在处理 query 的角度上编码,所以对于会破坏 query 串语义的字符,都进行了编码;而 NGX_ESCAPE_URI_COMPONENT ,处理角度不是整个 URI,而是 domain 之后的 URI 组件,它兼顾 path 和 query 的保留字符集,更加严格,遵守了 rfc3986#section-2.2 的规范。
这里顺便提一下 ngx_proxy 模块对应的 URI 转义处理,在构造向上游发送的请求行时,ngx_proxy 模块针对 proxy_pass 指令做出了不同的处理:

  • URI 包含了变量,将变量解析,然后直接构造 URI 发送到上游;
  • URI 不含变量,没有指定 path 部分,使用 client 发来的原生的 path 部分拼接到 URI,然后发送到上游;
  • URI 不含变量,指定了 path,这里的处理是,把 decode 过的,client 发来的 URI 里的 path 部分,去掉和当前 location 匹配的部分后,转义(按 NGX_ESCAPE_URI 来操作)以后,和 proxy_pass 里指定的 URI 的 path 拼接,发送到上游,比如这样的配置:
location /foo {
    proxy_pass http://127.0.0.1:8082/bar;
}

如果 client 发来的 URI 里 path 是 /foo/%5B-%5D,最终上游的 URI path 会是 /bar/[-]。
因此我们在做 nginx conf 配置的时候,也需要小心考虑 URI 转义的问题。

ngx_lua 的 URI 转义机制

ngx_lua 提供的 ngx.escape_uri 函数,和 nginx 核心的转义机制也有一些差异(基于 ngx_lua v0.10.11),体现在对保留字符的处理上,ngx.escape_uri 底层使用的 ngx_http_lua_escape_uri,结构和 ngx_escape_uri 一致,而对应的 bitmap 不同。
对于整个 URI 的转义处理,在 ngx_escapeuri 的基础上,对 ‘”‘, ‘&’, ‘+’, ‘/’, ‘:’, ‘;’, ‘<‘, ‘=’, ‘>’, ‘[‘, ‘\’, ‘]’, ‘^’, ‘‘, ‘{‘ , ‘}’进行转义;对于 query 的处理,这里去掉了 & 的转义;对于 path + query 的处理,去掉了对 “‘”, “*”, “)”, “(“, “!” 的转义。目前 ngx.escape_uri 使用的是 NGX_ESCAPE_URI_COMPONENT ,从 PR 提交的信息来看,目前 ngx.escape_uri 的行为和 Chrome JS 实现的 encodeURIComponent 一致。
另外,ngx_lua 对 URI 的解码操作,除了它把 + 解码为空格以外,其他和 nginx 相同。

总结

在做相关的代理服务,网关服务时,URI 的编解码处理都是非常重要的,某些场景我们可能需要用 URI 来做 key,如果不处理好编解码问题,可能在 URI 复杂的情况下会达不到我们的预期效果,反而会浪费很多时间去排查问题的原因,特别地,在使用 nginx 和 ngx_lua 做服务时,我们更应该熟知它们处理 URI 编解码的区别,在理解它们的区别上做自身的业务处理,避免踩坑。

参考资料

参考资料

高并发系统

9种高性能可用高并发的技术架构

来源:头条科技

1、分层

分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统。

在网站的分层架构中,常见的为3层,即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。

分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分别部署在不同的服务器上,是网站拥有更多的计算资源以应对越来越多的用户访问。

所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在网站的发展过程中,分层结构对网站支持高并发向分布式方向的发展至关重要。

2、冗余

网站需要7×24小时连续运行,那么就得有相应的冗余机制,以防某台机器宕掉时无法访问,而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。

3、分隔

如果说分层是将软件在横向方面进行切分,那么分隔就是在纵向方面对软件进行切分。

网站越大,功能越复杂,服务和数据处理的种类也越多,将这些不同的功能和服务分隔开来,包装成高内聚低耦合的模块单元,不仅有助于软件的开发维护也便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。

大型网站分隔的粒度可能会很小。比如在应用层,将不同业务进行分隔,例如将购物、论坛、搜索、广告分隔成不同的应用,有对立的团队负责,部署在不同的服务器上。

4、异步

使用异步,业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方法异步执行进行协作。

具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理;在分布式系统中可用通过分布式消息队列来实现异步。

异步架构的典型就是生产者消费者方式,两者不存在直接调用。

5、分布式

对于大型网站,分层和分隔的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块部署在不同的服务器上,通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作,计算机越多,CPU、内存、存储资源就越多,能过处理的并发访问和数据量就越大,进而能够为更多的用户提供服务。

在网站应用中,常用的分布式方案有一下几种.

分布式应用和服务:将分层和分隔后的应用和服务模块分布式部署,可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。

分布式静态资源:网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署,并采用独立的域名,即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度。

分布式数据和存储:大型网站需要处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,这些数据库需要分布式存储。

分布式计算:目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算,其特点是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算。

6、安全

网站在安全架构方面有许多模式:通过密码和手机校验码进行身份认证;登录、交易需要对网络通信进行加密;为了防止机器人程序滥用资源,需要使用验证码进行识别;对常见的XSS攻击、SQL注入需要编码转换;垃圾信息需要过滤等。

7、自动化

具体有自动化发布过程,自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。

8、集群

对于用户访问集中的模块需要将独立部署的服务器集群化,即多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务。

服务器集群能够为相同的服务提供更多的并发支持,因此当有更多的用户访问时,只需要向集群中加入新的机器即可;另外可以实现当其中的某台服务器发生故障时,可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上,因此可以提高系统的可用性。

9、缓存

缓存目的就是减轻服务器的计算,使数据直接返回给用户。在现在的软件设计中,缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。

使用缓存有两个条件:访问数据热点不均衡,即某些频繁访问的数据需要放在缓存中;数据在某个时间段内有效,不过很快过期,否则会因为数据过期而脏读,影响数据的正确性。

参考资料