ELK的踩坑之旅

前言

起源
許多年前,一個剛結婚的名叫 Shay Banon 的失業開發者,跟着他的妻子去了倫敦,他的妻子在那裡學習廚師。 在尋找一個賺錢的工作的時候,為了給他的妻子做一個食譜搜索引擎,他開始使用 Lucene 的一個早期版本。
直接使用 Lucene 是很難的,因此 Shay 開始做一個抽象層,Java 開發者使用它可以很簡單的給他們的程序添加搜索功能。 他發布了他的第一個開源項目 Compass。
後來 Shay 獲得了一份工作,主要是高性能,分佈式環境下的內存數據網格。這個對於高性能,實時,分佈式搜索引擎的需求尤為突出, 他決定重寫 Compass,把它變為一個獨立的服務並取名 Elasticsearch。
第一個公開版本在2010年2月發布,從此以後,Elasticsearch 已經成為了 Github 上最活躍的項目之一,他擁有超過300名 contributors(目前736名 contributors )。 一家公司已經開始圍繞 Elasticsearch 提供商業服務,並開發新的特性,但是,Elasticsearch 將永遠開源並對所有人可用。
據說,Shay 的妻子還在等着她的食譜搜索引擎…​

設計思路如下

有3台機器

2台做elasticsearch的主副節點

1台做kibana和elasticsearch_head 由於機器匱乏我還在這台機器上部署了logstash和nginx服務(雖然下面的架構中都提到了redis等緩存,但是暫時沒有加該服務,後期會研究添加上的)

先說目的:將nginx的日誌通過logstash收集后發送到ela,然後kibana進行展示

環境如下
elasticsearch master 10.5.2.175:9200
elasticsearch salve 10.5.2.176:9200
logstash 172.17.211.153 啟動命令: nohup /usr/local/logstash/bin/logstash -f /usr/local/logstash/config/agent.conf -w 10 -l /usr/local/logstash/logs/logstash-plain.log &
nginx 
es-head: 172.16.211.143:9100
kibana: 172.16.211.143:5601

架構如下:

加redis/kafa的原因:

在生產環境中,我們的日誌可能會有瞬時高峰,而這個時候如果直接存入es,可能會導致es承受不住,從而影響日誌的收集和查詢。 一般情況下,我們會將日誌存直接放到kafka或者redis這種讀寫性能非常高的應用中,作為一個緩存,然後通過下游組件(例如logstash)進行消費、過濾后存入ES,然後通過可視化界面查看。

ELK的工作流程

  • logstash客戶端收集到日誌后將日誌存入到redis之類的緩存中
  • Logstash_server將數據從redis中提取出來並根據/usr/local/logstash/patterns下的文件(文件名隨意取)這裏叫grok-patterns裏面根據不同的日誌,比如apache、nginx服務規定的不同格式來進行切割,切割完畢后將日誌存入到elastaicsearch中,格式裏面的key vlaue值就是els中的字段和值
  • elastaicsearch對logstash_server發送過來的值進行集群保存,提供被調用接口以及快速的搜索服務(這裏還可以安裝分詞插件,當做搜索引擎)
  • kibana對es根據條件進行搜索並對搜索到的數據進行展示,使我們看起來更加直觀。

一、elasticsearch

Elasticsearch 是一個開源的搜索引擎,建立在一個全文搜索引擎庫 Apache Lucene™ 基礎之上。 Lucene 可以說是當下最先進、高性能、全功能的搜索引擎庫—無論是開源還是私有。
中文文檔https://www.elastic.co/guide/cn/elasticsearch/guide/current/intro.html#intro

elasticsearch的安裝

具體安裝可以參考https://www.cnblogs.com/yanjieli/p/11187430.html這個教程,這裏直說下配置和思路,首先懂思路,安裝看教程就行。

需要有jdk環境
vim /etc/elasticsearch/jvm.options
2g
2g

1.vim /etc/elasticsearch/elasticsearch.yml
http.port: 9200
discovery.zen.ping.unicast.hosts: ["10.5.2.175","10.5.2.176"]
network.host: 10.5.2.175

2.vim /etc/systemd/system.conf
DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity

3.vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 32000
* hard nproc 32000
* hard memlock unlimited
* soft memlock unlimited

4.vim /etc/sysconfig/elasticsearch
JAVA_HOME=/usr/java/jdk1.8.0_151

5.vim /usr/lib/systemd/system/elasticsearch.service
[Service]
LimitMEMLOCK=infinity

elasticsearch的問題

啟動elasticsearch失敗,報找不到JAVA環境,可明明系統是有的 解決方法如下:

vim /etc/sysconfig/elasticsearch
JAVA_HOME=/usr/java/jdk1.8.0_151

elasticsearch的概念

index 索引 相當於數據庫里的“數據庫” 他是我們存儲和索引關聯數據的地方

type 類數據 將一類的數據放到一起 相當於數據庫中的“表”

id 相當於數據庫表中的一行

  • Elastic 本質上是一個分佈式數據庫,允許多台服務器協同工作,每台服務器可以運行多個 Elastic 實例。單個 Elastic 實例稱為一個節點(node)。一組節點構成一個集群(cluster)。

  • Elastic 會索引所有字段,經過處理后寫入一個反向索引(Inverted Index)。查找數據的時候,直接查找該索引。

    倒排索引(反向索引)

    原始文檔

    創建倒排索引列表

    倒排索引創建索引的流程:

    1) 首先把所有的原始數據進行編號,形成文檔列表

    2) 把文檔數據進行分詞,得到很多的詞條,以詞條為索引。保存包含這些詞條的文檔的編號信息。

    搜索的過程:

    當用戶輸入任意的詞條時,首先對用戶輸入的數據進行分詞,得到用戶要搜索的所有詞條,然後拿着這些詞條去倒排索引列表中進行匹配。找到這些詞條就能找到包含這些詞條的所有文檔的編號。

    然後根據這些編號去文檔列表中找到文檔

  • 所以,Elastic 數據管理的頂層單位就叫做 Index(索引)。它是單個數據庫的同義詞。每個 Index (即數據庫)的名字必須是小寫。

下面的命令可以查看當前節點的所有 Index。

$ curl -X GET 'http://localhost:9200/_cat/indices?v

index 索引 相當於數據庫里的“數據庫” 他是我們存儲和索引關聯數據的地方

type 類數據 將一類的數據放到一起 相當於數據庫中的“表”

id 相當於數據庫表中的一行

pertty 在網頁中格式化輸出響應內容

elasticsearch的操作方法

官方教程在這裏,我覺得這個更加實用官方教程 https://www.cnblogs.com/chuyuan/p/11380744.html

# 增加
http://10.5.103.176:9200/database1/table1 

{
  "name": "doudou",
  "age": 4.5,
  "weight": 20,
}

# 查詢

# 以上方法是正確的
但是再增加一個table2的是否發生如下報錯
http://10.5.103.176:9200/database1/table2
{
  "name": "dianche1",
   "weight": 1000
}

原因是elastic search在6.x版本調整了, 一個index只能存儲一種type。

GET /atguigu/_mapping
1. 檢索文檔
Mysql : select * from user where id = 1
ES : GET /atguigu/doc/1
響應結果
{
  "_index" :   "megacorp",
  "_type" :    "employee",
  "_id" :      "1",
  "_version" : 1,
  "found" :    true,
  "_source" :  {
      "first_name" :  "John",
      "last_name" :   "Smith",
      "age" :         25,
      "about" :       "I love to go rock climbing",
      "interests":  [ "sports", "music" ]
  }
}

2.簡單檢索
Mysql : select * from user
ES : GET /megacorp/employee/_search

3.全文檢索
ES : GET /megacorp/employee/_search?q=haha
查詢出所有文檔字段值為haha的文檔

4.搜索(模糊查詢)
ES : GET /megacorp/employee/_search?q=hello
查詢出所有文檔字段值分詞后包含hello的文檔

5.聚合
PUT atguigu/_mapping/doc
{ 
  "properties": { 
    "interests": { 
      "type": "text", 
      "fielddata": true 
      } 
  }
}

elasticsearch-head的安裝

ealsticsearch只是後端提供各種api,那麼怎麼直觀的使用它呢?elasticsearch-head將是一款專門針對於elasticsearch的客戶端工具,是es的集群管理工具、數據可視化、增刪改查工具。相關詳細的教程在這裏
1 https://www.sojson.com/blog/85.html
2 https://www.cnblogs.com/xuwenjin/p/8792919.html
3 https://blog.csdn.net/huwei2003/article/details/40581143

一、下載head插件
https://github.com/mobz/elasticsearch-head

二、解壓到任意目錄
注意:為避免找不到,一定要和elasticsearch的安裝目錄區分開

三、安裝Node.js
因為head是一個Node.js項目。所以,如果沒有安裝nodejs需要先安裝Node.js
32位安裝包下載地址: https://nodejs.org/dist/v4.4.3/node-v4.4.3-x86.tar.gz
64位安裝包下載地址: https://nodejs.org/dist/v4.4.3/node-v4.4.3-x64.tar.gz
檢測PATH環境變量是否配置了Node.js,打開命令行輸入命令"which npm",輸出如下結果:
/usr/bin/npm
wget https://nodejs.org/dist/latest-v8.x/node-v8.16.0.tar.gz
tar xf node-v8.16.0.tar.gz
cd node-v8.16.0
./configure --prefix=/usr/local/node-v8.16
make -j 8 && make install
添加環境變量
vim /etc/profile
################nodejs###############
export NODE_HOME=/usr/local/node-v8.16
export PATH=$PATH:$NODE_HOME/bin
source /etc/profile
node -v
v8.16.0
npm -v
6.4.1

四、安裝npm 
yum install npm -y

五、es-head安裝:
解壓源碼包:elasticsearch-head.tar.gz
啟動:cd /usr/local/src/elasticsearch-head
npm run start &
訪問地址是http://{你的ip地址}:9200/_plugin/head/
在瀏覽器中輸入:這台機器的ip+端口
http://10.5.2.220:9100/

問題解決:

在elasticsearch中沒有當天的索引

頭一天使用過的bj日誌第二天無法收集到,原因是昨天logstash已經收集過一遍,就被打過了標籤,今天再使用的話,如果這個日誌是不再增加的就不會被收集,因為日誌中沒有新的內容進來,解決方法如下:

在logstash的config文件下的agent.conf加入以下配置
start_position =>"beginning"#檢查時間戳

二、kibana

語言設置

vim config/kibana.yml
i18n.locale: "en" 或者zh-CN中文
systemctl restart kibana重啟即可

安裝配置

重新加載systemctl配置,這個是針對centos7以上使用systemctl kibana restart命令的

systemctl daemon-reload

這裏由於是二進制的安裝方法,所以要設置一個systemctl start kibana.service的啟動方法

1. vim /usr/lib/systemd/system/kibana.service
添加以下內容
[Unit]
Description=Kibana
After=network.target

[Service]
ExecStart=/usr/local/kibana/bin/kibana
Type=simple
PIDFile=/usr/local/kibana/kibana.pid
Restart=always
#User=es 這裏我直接使用root用戶進行啟動
#Group=es
[Install]
WantedBy=default.target

2. 重新加載一下配置文件
systemctl daemon-reload

3. 啟動
systemctl start kibana.service

4. 訪問測試
http://10.5.2.220:5601

查詢語法

參考地址1 參考地址2 參考地址3https://blog.csdn.net/u013958257/article/details/88567581

kibana查詢語法基於Lucene

Lucene是apache軟件基金會4 jakarta項目組的一個子項目,是一個開放源代碼的全文檢索引擎工具包,但它不是一個完整的全文檢索引擎,而是一個全文檢索引擎的架構,提供了完整的查詢引擎和索引引擎,部分文本分析引擎(英文與德文兩種西方語言)。Lucene的目的是為軟件開發人員提供一個簡單易用的工具包,以方便的在目標系統中實現全文檢索的功能,或者是以此為基礎建立起完整的全文檢索引擎。Lucene是一套用於全文檢索和搜尋的開源程式庫,由Apache軟件基金會支持和提供。Lucene提供了一個簡單卻強大的應用程式接口,能夠做全文索引和搜尋。在Java開發環境里Lucene是一個成熟的免費開源工具。就其本身而言,Lucene是當前以及最近幾年最受歡迎的免費Java信息檢索程序庫。人們經常提到信息檢索程序庫,雖然與搜索引擎有關,但不應該將信息檢索程序庫與搜索引擎相混淆。
Lucene最初是由Doug Cutting開發的,在SourceForge的網站上提供下載。在2001年9月作為高質量的開源Java產品加入到Apache軟件基金會的 Jakarta家族中

kibana在ELK陣營中用來查詢展示數據
elasticsearch構建在Lucene之上,過濾器語法和Lucene相同

1. 根據某個字段查詢
精確匹配: agent:"Mozilla/5.0"
如果不帶雙引號,只要包含指定值就可以搜索到 agent:Mozilla/5.0
如果是數值類型沒有以上區別

2. 數組範圍查詢
[7758794 TO 7758794] 表示等於,原意思是一個區間範圍
指定區間: response:[100 TO 200]
大於等於指定數值的: response:[201 TO *]
小於等於指定數值的: response:[* TO 200]

3. 從指定時間到現在/或者查詢指定時間前數據
2015-05-20T09:20:41.943Z之後的數據: @timestamp:{2015-05-20T09:20:41.943Z TO *}
2015-05-20T09:20:41.943Z之前的數據: @timestamp:{* TO 2015-05-20T09:20:41.943Z }
指定時間範圍: @timestamp:{2015-05-20T09:20:41.943Z TO 015-05-22T09:20:41.943Z}
備註:09:20:41事實上是17:20:41,存在8個小時差

4. 正則匹配
包含指定值: request:/uploads*/
不包含指定值: !request:/uploads*/

5. 邏輯查詢
AND(與關係數據庫一樣) request:/uploads*/ AND response:404
OR(與關係數據庫一樣) request:/uploads*/ OR response:200
組合查詢: (uid OR token) AND version

6. 存在/不存在
存在host字段但不存在url字段: _exists_:host AND _missing_:url
特殊轉義字符
+ – && || ! () {} [] ^” ~ * ? : \

kibana創建索引模式(手動)

https://blog.csdn.net/weixin_34727238/article/details/81540692

當在els中有了當天的索引,就可以到kibana中取創建索引模式了,只是這裏提供了一手動創建的方式,無法自動進行,需要本地定義腳本的方式進行自動索引的創建。

等所有索引都創建完畢后,在下面就能看到了

然後在下面這個裡面就能看到我們的索引裏面的數據情況了,前提是你的logstash成功將切割后的日誌發送到了els中

否則就是以下這種的

kibana創建索引模式(自動)

由於logstash客戶端運行的問題,只要有當天日誌產生,就會將該日誌發送給elasticsearch,然後會在elasticsearch裏面產生一個新的索引

方法如下:

在kibana節點上寫一個腳本,然後設置定時任務執行kibana中索引與elasticsearch的關聯
vim /usr/local/scripts/kibana_create_index.sh
#!/bin/bash
today=`date +%Y-%m-%d`
index_name="nginx-log-${today}.log"
curl -X POST -H "kbn-xsrf:reporting" -H "Content-Type: application/json"  -d  '{"attributes":{"title":"'$log_name'"}}'  'http://172.16.211.143:5601/api/saved_objects/index-pattern'

這裏遇到一個問題,json中調用變量的問題,一直調用不到,後來各種查詢原來是格式不對

json數據里變量要用''括起來
<font color=gray size=72>color=gray</font>

json數據里變量要用”括起來https://www.cnblogs.com/landhu/p/7048255.html

ELK 索引生命周期管理

問題解決

Kibana server is not ready yet出現的原因

第一點:KB、ES版本不一致(網上大部分都是這麼說的)

解決方法:把KB和ES版本調整為統一版本

第二點:kibana.yml中配置有問題(通過查看日誌,發現了Error: No Living connections的問題)

解決方法:將配置文件kibana.yml中的elasticsearch.url改為正確的鏈接,默認為: http://elasticsearch:9200

改為http://自己的IP地址:9200

第三點:瀏覽器沒有緩過來

解決方法:刷新幾次瀏覽器。

終極解決方法:在elasticsearch中刪除kibana的相關索引,只是再打開kibana看不到其他了之前創建的圖形什麼的了

kibana可以做哪些分析

分析的必要性:頂級

  • 用戶分佈
  • PV、UV
  • 狀態碼
  • 訪問時間

更多圖形看這裏https://www.cnblogs.com/hanyifeng/p/5860731.html

比較牛逼一點的教程看這裏https://www.bilibili.com/video/BV1TE411A77i?p=6

三、logstash

logstash和filebeat的對比

Filebeat是收集日誌的另外一種方式,二者區別在於以下

Filebeat用於日誌收集和傳輸,相比Logstash更加輕量級和易部署,對系統資源開銷更小,日誌流架構的話,Filebeat適合部署在收集的最前端,Logstash相比Filebeat功能更強,可以在Filebeat收集之後,由Logstash進一步做日誌的解析,至於kafka也可以考慮添加,然後收集的數據都存放在elasticsearch中。

  1. logstash和filebeat都是可以作為日誌採集的工具,目前日誌採集的工具有很多種,如fluentd, flume, logstash,betas等等。甚至最後我決定用filebeat作為日誌採集端工具的時候,還有人問我為什麼不用flume,logstash等採集工具。
  2. logstash出現時間要比filebeat早許多,隨着時間發展,logstash不僅僅是一個日誌採集工具,它也是可以作為一個日誌搜集工具,有豐富的input|filter|output插件可以使用。常用的ELK日誌採集方案中,大部分的做法就是將所有節點的日誌內容上送到kafka消息隊列,然後使用logstash集群讀取消息隊列內容,根據配置文件進行過濾。上送到elasticsearch。logstash詳細信息可前往https://www.elastic.co/
  3. logstash是使用Java編寫,插件是使用jruby編寫,對機器的資源要求會比較高,網上有一篇關於其性能測試的報告。之前自己也做過和filebeat的測試對比。在採集日誌方面,對CPU,內存上都要比前者高很多。LogStash::Inputs::Syslog 性能測試與優化
  4. filebeat也是elastic.公司開發的,其官方的說法是為了替代logstash-forward。採用go語言開發。代碼開源。elastic/beats filebeat是beats的一個文件採集工具,目前其官方基於libbeats平台開發的還有Packetbeat, Metricbeat, Winlogbeat。filebeat性能非常好,部署簡單。是一個非常理想的文件採集工具。我自己採集工具也是基於beats源碼進行的二次開發。

https://blog.csdn.net/m0_38120325/article/details/79072921

自動創建elasticsearch的索引

在logstash客戶端的配置文件中會有這麼一個配置文件

就是會將日誌發送到當天日期的索引匯總,沒有的話自動創建索引,我們只需要做的就是每日刪除舊的索引。

电子書教程推薦:http://doc.yonyoucloud.com/doc/logstash-best-practice-cn/get_start/introduction.html

啟動方法 基於最基礎的 nohup 方式
nohup /usr/local/logstash/bin/logstash -f /usr/local/logstash/conf/agent.conf &> /dev/null

也可以用daemontools來進行管理
安裝
yum -y install supervisord --enablerepo=epel
在 /etc/supervisord.conf 配置文件里添加內容,定義你要啟動的程序:
[program:elkpro_1]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro1.conf --pluginpath /opt/logstash/plugins/ -w 10 -l /var/log/logstash/pro1.log
[program:elkpro_2]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro2.conf --pluginpath /opt/logstash/plugins/ -w 10 -l /var/log/logstash/pro2.log

然後啟動 service supervisord start 即可。
logstash 會以 supervisord 子進程的身份運行,你還可以使用 supervisorctl 命令,單獨控制一系列 logstash 子進程中某一個進程的啟停操作:

supervisorctl stop elkpro_2

關於grok語法

官方給定的語法

https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns

https://github.com/elastic/logstash/tree/v1.4.2/patterns

如果你使用的正則語言可以將nginx日誌進行匹配,就可以成功對日誌進行切割,效果看下圖:

調試的過程中可以使用這個網站來進行正則語法的測試:http://grokdebug.herokuapp.com/

1. 線上配置的信息格式192.168.70.94 跟權威指南中的一樣
SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:

以下這個是Logstash默認自帶了Apache標準日誌的grok正則表達式:
COMMONAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest
})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)

COMBINEDAPACHELOG %{COMMONAPACHELOG} %{QS:referrer} %{QS:agent}

2. 我的nginx日誌切割格式
NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{HTTPDATE:tiem_local}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_referer}\" \"%{DATA:http_user_agent}\"

MAINNGINXLOG %{COMBINEDAPACHELOG} %{QS:x_forwarded_for}
COMBINEDAPACHELOG 合併的apache日誌  logstash客戶端用的是這種方式
COMMONAPACHELOG 普通的apache日誌
當grok匹配失敗的時候,插件會為這個事件打個tag,默認是_grokparsefailure。LogStash允許你把這些處理失敗的事件路由到其他地方做後續的處理
input { # ... }
filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{IPV4:ip};%{WORD:environment}\] %{LOGLEVEL:log_level} %{GREEDYDATA:message}" }
  }
}
output {
  if "_grokparsefailure" in [tags] {
    # write events that didn't match to a file
    file { "path" => "/tmp/grok_failures.txt" }
  } else {
     elasticsearch { }
  }
}

看下面紅色的地方,表示grok匹配失敗,才會將tags的標籤定義成_grokparsefailure這個默認的

解決說是要設置錨點 目前不懂什麼意思 先放到這裏

https://www.jianshu.com/p/86133dd66ca4

另外一種說法,暫時不會用,先放着
1.
if "_grokparsefailure" in [tags] { drop { } }
2.match語句跟第一個一樣的  沒啥要點,看着官網例子搞就行了

3.盡量用grok吧 ,grep功能以後要去掉的。

當時想的另外一種解決方法就是改nginx的日誌格式成json形式的,但是我不想用這種方法。

log_format json '{"@timestamp":"$time_iso8601",'
                 '"host":"$server_addr",'
                 '"clientip":"$remote_addr",'
                 '"request":"$request",'
                 '"status":"$status",'
                 '"request_method": "$request_method",'
                 '"size":"$body_bytes_sent",'
                 '"request_time":"$request_time",'
                 '"upstreamtime":"$upstream_response_time",'
                 '"upstreamhost":"$upstream_addr",'
                 '"http_host":"$host",'
                 '"url":"$uri",'
                 '"http_forward":"$http_x_forwarded_for",'
                 '"referer":"$http_referer",'
                 '"agent":"$http_user_agent"}';

access_log  /var/log/nginx/access.log json ;

問題解決

Nginx日誌沒有被成功切割的終極原因

    以下是兩種日誌方式:
    log_format  main  '$remote_addr - $remote_user [$time_iso8601] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$host" "$request_time"';

    log_format format2  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$host" "$request_time"';
 
 在logstash中進行切割的時候調用的時間變量是不同的,靈感來自如下:
 grok {
        match => { "message" => "%{TIMESTAMP_ISO8601:time}" }
    }
date{
        match => ["time", "yyyy-MM-dd HH:mm:ss", "ISO8601"]
        target => "@timestamp"
    }
mutate{
        remove_field => ["time"]
    }
定義:
HTTPDATE %{MONTHDAY}/%{MONTH}/%{YEAR}:%{TIME} %{INT}
TIMESTAMP_ISO8601 %{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})?%{ISO8601_TIMEZONE}?
#NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{HTTPDATE:time_iso8601}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_referer}\" \"%
{DATA:http_user_agent}\"

{DATA:http_user_agent}\"
NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{TIMESTAMP_ISO8601:time_iso8601}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_refere
r}\" \"%{DATA:http_user_agent}\"

SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:
COMMONAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest
})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)
COMBINEDAPACHELOG %{COMMONAPACHELOG} %{QS:referrer} %{QS:agent}

Nginx中時間格式1:$time_local   對應logstash中\[%{HTTPDATE:timestamp}\]
Nginx中時間格式2:$time_iso8601 對應logstash中\[%{TIMESTAMP_ISO8601:timestamp}\]

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

區分http請求狀態碼來理解緩存(協商緩存和強制緩存)

什麼是http緩存呢,當我們使用chrome瀏覽器,按F12打開控制台,在網絡請求中有時候看到狀態碼是200,有時候狀態碼是304,當我們去看這種請求的時候,我們會發現狀態碼為304的狀態結果是:Status Code: 304 Not Modified,而狀態碼為200的時候一般會有四種情況,一種是直接返回200,沒有任何其他的標誌,另一種是Status Code: 200 OK (from memory cache),還有一種是Status Code: 200 (from disk cache)。最後一種不是太常見,Status Code: 200 (from Service Worker).後面這三種狀態碼看到的效果是灰色的,其實從給出的信息也能看出來是從緩存中獲取上數據。下面我們來詳細介紹一下他們都分別是什麼時候出現的。

其實我們可以按狀態碼來區分其為兩大類,分別是協商緩存–304和強制緩存–200

協商緩存(304)

這種方式使用到了headers請求頭裡的兩個字段,Last-Modified & If-Modified-Since 。服務器通過響應頭Last-Modified告知瀏覽器,資源最後被修改的時間:

Last-Modified: Thu, 20 Jun 2019 15:58:05 GMT 

當再次請求該資源時,瀏覽器需要再次向服務器確認,資源是否過期,其中的憑證就是請求頭If-Modified-Since字段,值為上次請求中響應頭Last-Modified字段的值:

If-Modified-Since: Thu, 20 Jun 2019 15:58:05 GMT 

瀏覽器在發送請求的時候服務器會檢查請求頭request header裏面的If-modified-Since,如果最後修改時間相同則返回304,否則給返回頭(response header)添加last-Modified並且返回數據(response body)。

另外,瀏覽器在發送請求的時候服務器會檢查請求頭(request header)裏面的if-none-match的值與當前文件的內容通過hash算法(例如 nodejs: cryto.createHash(‘sha1’))生成的內容摘要字符對比,相同則直接返回304,否則給返回頭(response header)添加etag屬性為當前的內容摘要字符,並且返回內容。

綜上總結為:

  • 請求頭last-modified的日期與響應頭的last-modified一致
  • 請求頭if-none-match的hash與響應頭的etag一致
    這兩種情況會返回Status Code: 304

強制緩存(200(from …))

這裏我們使用到了Cache-Control和Expires這兩個字段來進行控制,Cache-Control裏面可以有多個屬性,可以組合設置,其屬性有如下幾種:

  • max-age=xxx,最大的有效時間 單位秒,是一個相對時間
  • must-revalidate,如果超過了max-age的時間,必須向服務器發送請求,驗證資源的有效性
  • no-cache,基本等價於max-age=0,由協商緩存來決定是否緩存資源
  • no-store,真正意義上的不緩存
  • public,代表 http 請求返回的內容所經過的任何路徑當中(包括中間一些http代理服務器以及發出請求的客戶端瀏覽器),都可以對返回內容進行緩存操作
  • private,代表只有發起請求的瀏覽器才可以進行緩存。默認值

比如我們設置

Catch-Control:public,max-age=360000 

我們在之前說了強制緩存有三種情況,上面說返回200有四種,第一種其實是不緩存,正常服務器返迴響應。

Service Worker

這個東西其實本質上時服務器和客戶端之間的代理服務器,一般我們在使用react開發的時候,會發現在根目錄出現了一個server-worker.js文件,這個東西就是和service Worker緩存相關的,他會根據網絡的狀態做出不同的緩存策略,有時候斷網了,之前訪問過的接口有可能依然會返回數據,其數據來源就是從其緩存中讀取。

memory cache

這個是將資源緩存在了內存中。事實上,所有的網絡請求都會被瀏覽器緩存到內存中,當然,內存容量有限,緩存不能無限存放在內存中,因此,註定是個短期緩存。而其控制權在於瀏覽器。

disk cache

與內存緩存相對的,這個是將資源緩存在硬盤中。雖然相比於內存,硬盤的讀取速度要慢很多,但總比沒有強。硬盤緩存的控制權在後端,通過什麼控制呢?通過HTTP響應頭控制,也就是我們在上面說到的catche-control和expires

Expires設置的過期時間是一個絕對的GMT時間,例如:Expires:Thu,20 Jun 2019 20:00:00 GMT; 他告訴瀏覽器緩存有效性持續到2019年6月20日為止,一直都使用緩存來處理。

Expires有一個非常大的缺陷,它使用一個固定的時間,要求服務器與客戶端的時鐘保持嚴格的同步,並且這一天到來后,服務器還得重新設定新的時間。

HTTP1.1引入了Cathe-Control,它使用max-age指定組件被緩存多久,從請求開始在max-age時間內瀏覽器使用緩存,之外的使用請求,這樣就可以消除Expires的限制,

如果對瀏覽器兼容性要求很高的話,可以兩個都使用。

其實在上面說到的Last-Modified對比最後修改時間與Expires一樣是有缺陷的,如果,資源的變化的時間間隔小於秒級,比如說是毫秒級的,或者說資源直接是動態生成的,那根據Last-Modified判斷,資源就是每時每刻都最新的,即被修改過!

所以,Etag & If-Node-Match 就是來解決這個問題的。
Etag字段的值為文件的特殊標識,一般都是hash生成的,服務器存儲着資源的Etag值。接下來的流程都與Lst-Modified & If-Modified-Since一致,只不過,比較的值從最後修改時間變成了Etag值。

Etag的優點在於,對於動態資源或者現在流行的Restful API返回的JSON數據,這些是沒有修改時間這一說法的,但是Http標準並沒有規定Etag值如何生成,因此我們通過代碼自己生成Etag值。當然,計算Etag值會消耗服務器性能。

Cache-Control+Last-Modified+ETag 的優先級會如何?

因為http1.1>http1.0,所以Cache-Control>Expires,ETag>Last-Modified。依照就近原則,先找本地緩存,沒有再向服務器發請求,所以Expires>Last-Modified,Cache-Control>ETag,

如果瀏覽器只支持http1.0,那麼瀏覽器只會攜帶Last-Modified發送給後台,
如果服務器只支持http1.0,那麼服務器會以Last-Modified為標準。
如果瀏覽器支持http1.1,那麼瀏覽器會攜帶Cache-Control+Last-Modified+ETag發送給後台,
如果服務器支持http1.1,那麼服務器會以Cache-Control+ETag為標準。

200狀態碼和304狀態碼何時出現

在沒有設置Cache-Contral的情況下,設置Last-Modified和ETag緩存,會出現200(from cache)和304 交替出現的情況。

設置Cache-Contral的情況下,過期刷新會出現304(如果有更新內容,則是200),之後再過期之前刷新都是200(from cache)。如果要確保要向服務端確認,可以將Cache-Contral的max-age設置為0。

通過下圖我們可以清晰的明白200和304

https://www.oecom.cn/http-header-control/

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

機油怎麼分好壞?教授親自帶你到歐洲看機油研發過程

實測:在發動機測試實里我們看到各種不同的發動機,所有機油在路試之前都要在這裏分別進行100小時高溫測試、冷機潤滑性能測試、模擬實際使用情況長測,以及整車測試等。在探訪過程中我們還發現了送測的日產雷諾新1。6T機器,整車合作廠家會把最新的發動機送來研發中心,因應發動機的特性開發專用機油並加以改進,所以所謂品牌專用機油和市場上買到的還真是有區別。

說起汽車機油,相信大家都知道每次保養時需要更換,但不同機油之間的差別,好像一般用家不會太在意。比較資深的老司機會知道機油有合成、礦物油之分,也知道機油有不同標號、等級之分,但怎麼選擇一款最適合自己愛車的機油,一款好機油的技術含量有多高,你又知道多少?

在出發前,我們先掃一下盲。

發動機裏面有無數金屬部件在運動,運動過程中會產生摩擦,就好像人的關節一樣,使用了不良或是不合適的機油,發動機就好像得了關節炎一樣,運動不順暢,久而久之,甚至會得大病。

機油具有潤滑、清潔、冷卻、密封、減磨、防鏽 的功能。因此選擇機油是不能馬虎的。

Jacky 此次特意飛往來自法國的品牌—道達爾的集團總部参觀學習,給大家窺探一款優異的機油的研發過程。

什麼?只聽過殼牌、美孚、嘉實多?那你就Out 了!

道達爾是世界第四大石油天然氣公司,業務遍及130多個國家。

在汽車賽事方面,道達爾一直活躍於國內外頂級賽車運動的賽場上,在頂級的賽車運動場上始終能看到道達爾的身影,如一級方程式錦標賽(F1)、世界拉力錦標賽(WRC)、世界耐力錦標賽(WEC)、以及勒芒24小時耐力賽、達喀爾拉力賽(Dakar)。

亞洲勒芒系列賽事(ALMS)、世界房車錦標賽(WTCC)、中國越野拉力賽(CGR)、絲綢之路拉力賽(Silk Way Rally)等其它著名賽事。通過這些頂級賽事,道達爾的產品性能(潤滑油和燃油)在非常嚴苛的環境下都得到了驗證。

到底一款優良的機油是怎樣研發的呢?第一站我們來到了位於里昂近郊的道達爾Soliaze研發中心。

在這裏每年有超過1200種不同特性的潤滑油誕生。

機油研發分為調配、試驗、分析、實測幾個重要步驟:

調配:因應不同的訴求,加入不同的添加劑來達到相應的效果,你所使用的機油和F1車隊使用的機油都是在同一個實驗室由同一幫工程師調配出來的。

試驗:調和好的機油會送到實驗室進行高溫、低溫、各種耐久測試,這裏的溫度控制精度必須達到小數點后2位,因為實驗室屬於整個生產流程的最頂端,不能允許有任何誤差。在這裏我們也看到了標緻和雷諾的廠家機油測試標準,比一般的歐標和美標都要更嚴格一些。

實測:在發動機測試實里我們看到各種不同的發動機,所有機油在路試之前都要在這裏分別進行100小時高溫測試、冷機潤滑性能測試、模擬實際使用情況長測,以及整車測試等。在探訪過程中我們還發現了送測的日產雷諾新1.6T機器,整車合作廠家會把最新的發動機送來研發中心,因應發動機的特性開發專用機油並加以改進,所以所謂品牌專用機油和市場上買到的還真是有區別。

在巴黎車展上,我們看到了道達爾贊助的雷諾F1賽車、標緻3008 DKR 賽車和208WRX 賽車,在208 WRX 的宣傳片上我甚至看到添加道達爾快馳潤滑油的片段,所以我很好奇到底賽用機油跟我們民用機油的相似度有多少。

為此我特意來到了道達爾集團位於巴黎的總公司,和他們的拉力和耐力賽經理聊了一下。

道達爾多年來积極支持各大國際知名賽事,如世界房車錦標賽WTCC、世界耐力錦標賽WEC、世界拉力錦標賽WRC,一級方程式比賽F1等等,併為贊助車隊提供高品質的潤滑油產品和技術支持。

這些參賽車輛在運行過程中擁有非常高的轉速,這樣的環境對賽車發動機及潤滑油都有着嚴苛的考驗,所以賽車用油或多或少都與民用油有所不同,尤其是像F1這樣對速度要求十分高的賽事,所需的機油和民用油差別則更大,但在賽事嚴苛的使用環境中,機油可以得到深度的測試,賽後進行樣本分析,再把數據應用到民用產品當中。

和賽事中純性能取向不同,一款良好的民用機油應該具備以下特性,我們可以拿道達爾快馳9000 5W-40汽車潤滑油舉個例子:

它有哪些特性呢?:

1、全合成產品,性能穩定可本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨,RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

厲害了!知道這樣重命名文件都是大佬級別!

大家好,我是良許。

在 Linux 下,重命名一個文件,我們通常是使用 mv 命令,一般是這樣操作的:

$ mv file1.txt file2.txt

這樣重命令的方式當然是可以,但有個弊端就是你需要輸入兩次文件名。文件名比較短還好,一旦比較長的話,輸兩次會很讓人崩潰的。

本文就介紹幾種更高效的文件重命令方法,一般人不知道哦,知道的都是大神級別。

高效重命名文件的方法

首先,我們需要使用 vim 編輯 ~/.bashrc 文件。

$ vim ~/.bashrc

將下面這段代碼添加到 ~/.bashrc 文件末尾:

# Bash Function To Rename Files Without Typing Full Name Twice
function mv() {
  if [ "$#" -ne 1 ] || [ ! -e "$1" ]; then
    command mv "$@"
    return
  fi

  read -ei "$1" newfilename
  command mv -v -- "$1" "$newfilename"
}

然後,再按 wq 保存並退出。再接下來,使用 source 命令讓這個修改生效。

$ source ~/.bashrc

接下來,就是見證奇迹的時刻!

現在,我們要重命名 file1.txt 文件,我們只需這樣操作即可:

$ mv file1.txt

然後,重命名的過程可以看下面這個動圖:

由上面這個動圖可以看出來,終端里會显示出來原來文件名稱,然後你可以對這個名稱直接進行更改,而無需再次輸入一遍原來的名稱,效率提高不止一點!

重命名成功后,終端也會這樣提示:

‘file1.txt’ -> ‘file2.txt’

其它高效重命名方法

當然,除了修改 .bashrc 文件之外,還有很多高效重命名方法,這裏再介紹兩個。

方法一:使用 mv 命令

又回到了 mv 命令?打臉啦?

然鵝,命令是 mv ,但用法不一樣!

很多情況下,我們只是修改文件名的某一個部分,比如說,將 file1.txt 修改為 file2.txt ,也就是把 1 改為 2 。在這種情況下,其實有個更高效的改法:

# mv file{1,2}.txt

運行的結果如下:

如果我們想保留原來的文件,再複製一個副本,那就只要將 mv 命令換成 cp 命令即可。

# cp file{1,2}.txt

這個結果應該是顯而易見的,就不截圖結果了。

方法二:使用快捷鍵(ctrl+w,ctrl+y)

既然大部分人是知道重命名文件需要輸入兩次文件名,那麼我就滿足你,依然輸入兩次文件名。但是,這裏介紹一種更高效的重複輸入文件名的方法。

在 Shell 里,我們可以使用 ctrl+w 來剪切最後的單詞,使用 ctrl+y 來粘貼被剪切出來的內容。所以利用這個快捷鍵我們可以更高效重複輸入文件名。

直接上動圖:

公眾號:良許Linux

有收穫?希望老鐵們來個三連擊,給更多的人看到這篇文章

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準

氦元素 – CUBA 應用程序新樣式主題

    CUBA 框架一直以來定位的目標是業務系統的開發。業務系統的界面通常是給後台員工使用的,看重的是功能實現。多年來,界面外觀和樣式並不是後台管理系統的主要關注點,界面中的控件也更緊湊,唯一的原因就是:在單一屏幕中擺放盡可能多的控件,以提供足夠多的功能。

    但是在最近十年裡,人們使用了越來越多的小尺寸觸控屏設備,遊戲規則因此而改變。要有易於觸控點擊的控件,它們之間需要有足夠的間距,防止被誤點擊。應用程序的配色也變得偏於使用雜色和對比色。所以,近些年的現代應用程序在設計上更注重樣式,其中非功能性需求都佔了很大的一部分。

    順應趨勢,我們很高興推出新可視化主題 – 氦元素(Helium)!與以前的樣式主題相比,氦元素主題更簡潔、明亮,視覺噪音也更少。另外很重要的一點:能夠以最少的工作量為最終用戶和 CUBA 開發人員提供樣式定製。

功能

    首先要提到的是,新主題是動態的,意味着您可以隨時在線更改應用程序樣式!以前,CUBA 使用 SCSS 變量定義顏色,這樣每次修改過後都需要重新編譯。而新主題依賴 CSS 定製屬性 ,即使沒有頁面刷新或重新登錄,這些屬性也可以在運行時立即起效。

預設配色

    開箱即用支持兩種預設的配色方案:淺色(light)和深色(dark)。

    終端用戶可選擇的主題需要通過下列屬性配置(主題安裝流程請參考後續章節):

cuba.theme.modes = light|dark
cuba.theme.defaultMode = light

    另外,也可以通過在線主題編輯器創建自定義的配色方案(點擊下方的在線示例和編輯器章節名稱了解更多細節)。

預設大小

    主題自帶三種內置的控件大小配置:小(small),中(medium)和大(large)。

    跟配色方案類似,也可以通過主題屬性修改:

cuba.theme.sizes = small|medium|large
cuba.theme.defaultSize = medium

設置界面

    設置界面可以通過主菜單的 Help -> Theme Settings 打開。這裏可以讓最終用戶自定義他們喜歡的配色和控件大小。該界面帶有幾乎所有的主要控件,所以用戶可以預覽他調整之後的界面大概什麼樣。

在線示例和編輯器

    關於新主題的另一個重要部分就是其在線交互式編輯器。這裏可以試試調整樣式變量,馬上就能看到調整結果 – 一旦樣式滿足您的需求,只需要點擊下載按鈕並按照提供的說明將其安裝到您的 CUBA 應用程序中即可。

    其實,在線編輯器最好的一點是:不只是開發人員可以使用。將這個鏈接發送給您的追求極致的客戶,這樣他們可以根據自己的偏好自定義配色,然後下載併發送結果給開發人員,只需要幾分鐘便可以應用新的樣式。同時,編輯器本身也允許導入顏色變量,這樣可以基於已有的配色做修改。

    如需使用自定義配色,需要基於氦元素創建主題擴展。

安裝

    該主題是通過 擴展插件 的形式發布。該擴展兼容 7.1.5 以上的 CUBA 應用程序(注意,我們推薦您跟蹤 CUBA 框架的 bugfix 版本並更新您的應用程序至最新版)。可以參考 Studio 的 相關章節 了解如何安裝擴展插件。

    擴展安裝完成后,可以通過下面的方式啟用新的主題:
    啟動應用程序,打開主菜單下的設置界面:Help -> Settings。在可視化主題選項中選擇 Helium 即可。

    如需將氦元素主題設為默認主題,可以在 web-app.properties 中添加:

cuba.web.theme = helium

    如果之前自定義設置過 cuba.themeConfig 屬性,別忘了也需要添加氦元素屬性:

cuba.themeConfig = +/com/haulmont/addon/helium/web/helium-theme.properties

    如需自定義主題屬性,可以在 web 模塊的主包路徑創建 helium-theme.properties,內容如下:

@include=com/haulmont/addon/helium/web/helium-theme.properties

cuba.theme.modes = light|dark
cuba.theme.defaultMode = light

cuba.theme.sizes = small|medium|large
cuba.theme.defaultSize = medium\

    然後在 cuba.themeConfig 屬性中註冊一下該文件:

cuba.themeConfig = +/com/example/project/helium-theme.properties

    如需深度定製該主題,包括應用自定義配色,則需要創建主題擴展。按照該說明操作。

路線圖

    我們計劃繼續開發氦元素主題並添加新功能,包括:

  • 深色模式改進
  • 在主題編輯器中提供更有用的模板
  • 在淺色和深色模式之間自動切換
  • 提供可自定義的 border radius 變量,同樣也基於 CSS 變量。
  • 提供 Figma 的 CUBA 套件。Figma 是 UI/UХ 設計師最流行的工具之一,他們可以用來創建界面模型。

結論

    我們很樂意看到新主題和在線編輯器能用在您的項目中,希望新主題能讓您的應用煥然一新。如果您有任何問題,可以在我們的論壇創建主題討論。項目源碼可以在 Github 找到: 主題 / 編輯器。期待您的反饋!

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※推薦台中搬家公司優質服務,可到府估價

Istio的運維-診斷工具(istio 系列五)

Istio的運維-診斷工具

在參考官方文檔的時候發現環境偶爾會出現問題,因此插入一章與調試有關的內容,便於簡單問題的定位。涵蓋官方文檔的診斷工具章節

目錄

  • Istio的運維-診斷工具
    • 使用istioctl命令行工具
      • istioctl自動補全
      • 查看網格的狀態
      • 獲取代理配置
    • 調試Envoy和istiod
      • 獲取網格概況
      • 檢索Envoy和istiod的差異
      • 深入探究Envoy配置
      • 檢查bootstrap配置
      • 校驗到istiod的連通性
    • 通過istioctl的輸出理解網格
      • 校驗pod是否在網格中
      • 校驗destination rule配置
      • 校驗virtual service配置
      • 校驗流量路由
      • 檢查strict mutual TLS(官方文檔待更新)
      • 卸載
    • 使用istioctl analyse診斷配置
      • 分析現有的集群/本地文件或二者
    • 組件內省
    • 組件日誌
      • 日誌作用域
      • 控制輸出
      • 日誌滾動
      • 組件調試

使用istioctl命令行工具

首先可以通過日誌或Introspection檢查各個組件,如果不足以支持問題定位,可以參考如下操作:

istioctl是一個可以用於調試和診斷istio服務網格的工具。Istio項目為Bash和ZSH運行下的istioctl提供了自動補全功能。

建議安裝對應istio版本的istioctl

istioctl自動補全

  • 將如下內容添加到 ~/.bash_profile 文件中

    [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
    
  • 使用bash時,將在tools命令中的istioctl.bash文件拷貝到$HOME目錄下,然後執行如下操作即可

    $ source ~/istioctl.bash
    

查看網格的狀態

可以使用istioctl proxy-statusistioctl ps命令查看網格的狀態。如果輸出結果中缺少某個代理,說明該代理當前沒有連接到Pilot實例,因而無法接收到任何配置。如果狀態為stale,表示當前存在網絡故障,或Pilot需要擴容。

獲取代理配置

可以使用istioctl proxy-configistioctl pc檢索代理配置信息。

例如,使用如下方式可以檢索特定pod中的Envoy實例的集群配置信息。

$ istioctl proxy-config cluster <pod-name> [flags]

使用如下方式可以檢索特定pod中的Envoy實例的bootstrap配置信息。

$ istioctl proxy-config bootstrap <pod-name> [flags]

使用如下方式可以檢索特定pod中的Envoy實例的listener(監聽器)配置信息。

$ istioctl proxy-config listener <pod-name> [flags]

使用如下方式可以檢索特定pod中的Envoy實例的route(路由)配置信息。

$ istioctl proxy-config route <pod-name> [flags]

使用如下方式可以檢索特定pod中的Envoy實例的endpoint (後端)配置信息。

$ istioctl proxy-config endpoints <pod-name> [flags]

更多參見下一節調試Envoy和istiod

調試Envoy和istiod

istio提供了兩個非常有用的命令來診斷流量管理配置問題:proxy-status 和proxy-config。proxy-status可以獲取網格的概述並確定導致問題的代理。proxy-config可以檢查Envoy配置並診斷該問題。

如果要嘗試如下命令,可以:

  • 安裝Bookinfo
  • 使用kubernetes集群中部署類似應用

獲取網格概況

通過proxy-status命令可以查看網格的概況,了解是否有sidecar無法接收配置或無法保持同步。

如果某個代理沒有出現在輸出列表中,則說明該代理沒有連接到istiod實例,因此也無法接收任何配置信息。狀態信息如下:

  • SYNCED:表示Envoy確認了istiod發過來的配置
  • NOT SENT:表示istiod還沒有發送配置到Envoy。通常時因為istiod當前沒有需要發送的配置信息
  • STALE:表示istiod發送了一個更新到Envoy,但沒有接收到確認。通常表示Envoy和istiod之間的網絡出現了問題,或istio本身出現了bug。
$ istioctl ps                                                                               
NAME                                                  CDS      LDS       EDS       RDS        PILOT                     VERSION
details-v1-78d78fbddf-psnmk.default                   SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
istio-ingressgateway-569669bb67-dsd5h.istio-system    SYNCED   SYNCED    SYNCED    NOT SENT   istiod-788cf6c878-4pq5g   1.6.0
productpage-v1-85b9bf9cd7-d8hm8.default               SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
prometheus-79878ff5fd-tjdxx.istio-system              SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
ratings-v1-6c9dbf6b45-xlf2q.default                   SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
reviews-v1-564b97f875-q5l9r.default                   SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
reviews-v2-568c7c9d8f-vcd94.default                   SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
reviews-v3-67b4988599-psllq.default                   SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0
sleep-78484c89dd-fmxbc.default                        SYNCED   SYNCED    SYNCED    SYNCED     istiod-788cf6c878-4pq5g   1.6.0

檢索Envoy和istiod的差異

proxy-status加上proxy ID可以檢索Envoy加載的配置和istiod發送的配置之間的差異,通過這種方式可以確定哪部分內容沒有被同步,並確定可能存在的問題。

下面的例子可以看到ingressgateway的listeners和routers配置都與istiod發過來的配置匹配,但clusters不匹配。

$ istioctl proxy-status details-v1-6dcc6fbb9d-wsjz4.default
--- Istiod Clusters
+++ Envoy Clusters
@@ -374,36 +374,14 @@
             "edsClusterConfig": {
                "edsConfig": {
                   "ads": {

                   }
                },
                "serviceName": "outbound|443||public-cr0bdc785ce3f14722918080a97e1f26be-alb1.kube-system.svc.cluster.local"
-            },
-            "connectTimeout": "1.000s",
-            "circuitBreakers": {
-               "thresholds": [
-                  {
-
-                  }
-               ]
-            }
-         }
-      },
-      {
-         "cluster": {
-            "name": "outbound|53||kube-dns.kube-system.svc.cluster.local",
-            "type": "EDS",
-            "edsClusterConfig": {
-               "edsConfig": {
-                  "ads": {
-
-                  }
-               },
-               "serviceName": "outbound|53||kube-dns.kube-system.svc.cluster.local"
             },
             "connectTimeout": "1.000s",
             "circuitBreakers": {
                "thresholds": [
                   {

                   }

Listeners Match
Routes Match

深入探究Envoy配置

proxy-config命令可以查看一個Envoy實例的配置,用於定位無法通過查看istio配置和用戶資源發現的問題。例如,使用如下命令可以獲取特定pod的clusters,listeners或routes概要。注:首先通過istioctl ps查看出不匹配的代理,然後使用istioctl pc查看具體的不匹配的信息。

$ istioctl proxy-config cluster -n istio-system istio-ingressgateway-7d6874b48f-qxhn5
SERVICE FQDN                                           PORT    SUBSET  DIRECTION  TYPE
BlackHoleCluster                                       -       -       -          STATIC
agent                                                  -       -       -          STATIC
details.default.svc.cluster.local                      9080    -       outbound   EDS
istio-ingressgateway.istio-system.svc.cluster.local    80      -       outbound   EDS
istio-ingressgateway.istio-system.svc.cluster.local    443     -       outbound   EDS
istio-ingressgateway.istio-system.svc.cluster.local    15021   -       outbound   EDS
istio-ingressgateway.istio-system.svc.cluster.local    15443   -       outbound   EDS
istiod.istio-system.svc.cluster.local                  443     -       outbound   EDS
istiod.istio-system.svc.cluster.local                  853     -       outbound   EDS
istiod.istio-system.svc.cluster.local                  15010   -       outbound   EDS
istiod.istio-system.svc.cluster.local                  15012   -       outbound   EDS
istiod.istio-system.svc.cluster.local                  15014   -       outbound   EDS
kube-dns.kube-system.svc.cluster.local                 53      -       outbound   EDS
kube-dns.kube-system.svc.cluster.local                 9153    -       outbound   EDS
kubernetes.default.svc.cluster.local                   443     -       outbound   EDS
...                                                                               
productpage.default.svc.cluster.local                  9080    -       outbound   EDS
prometheus.istio-system.svc.cluster.local              9090    -       outbound   EDS
prometheus_stats                                       -       -       -          STATIC
ratings.default.svc.cluster.local                      9080    -       outbound   EDS
reviews.default.svc.cluster.local                      9080    -       outbound   EDS
sds-grpc                                               -       -       -          STATIC
xds-grpc                                               -       -       -          STRICT_DNS
zipkin                                                 -       -       -          STRICT_DNS

為了調試Envoy,首先需要理解Envoy的clusters/listeners/routes/endpoints,以及它們之間是如何交互的。下面將使用帶有-o json和篩選標誌的proxy config命令來跟蹤Envoy,因為它決定在哪裡將請求從productpage pod發送到reviews pod的 reviews:9080

  1. 如果請求了一個pod的listener概要,可以看到istio生成了如下listeners:

    • 一個0.0.0.0:15006的listener,用於接收到pod的入站流量;以及一個 0.0.0.0:15001的listener,用於接收所有到pod的出站流量,然後將請求交給一個 virtual listener。
    • 每個kubernetes service IP都對應一個virtual listener,非HTTP的listener用於出站的TCP/HTTPS流量
    • pod IP中的virtual listener暴露了接收入站流量的端口
    • 0.0.0.0的HTTP類型的virtual listener,用於出站的HTTP流量

    Istio使用的端口信息如下:

    Port Protocol Used by Description
    15000 TCP Envoy Envoy admin port (commands/diagnostics)
    15001 TCP Envoy √ Envoy Outbound
    15006 TCP Envoy √ Envoy Inbound
    15020 HTTP Envoy Istio agent Prometheus telemetry
    15021 HTTP Envoy Health checks
    15090 HTTP Envoy Envoy Prometheus telemetry
    15010 GRPC Istiod XDS and CA services (plaintext)
    15012 GRPC Istiod XDS and CA services (TLS)
    8080 HTTP Istiod Debug interface
    443 HTTPS Istiod Webhooks
    15014 HTTP Mixer, Istiod Control plane monitoring
    15443 TLS Ingress and Egress Gateways SNI
    9090 HTTP Prometheus Prometheus
    42422 TCP Mixer Telemetry – Prometheus
    15004 HTTP Mixer, Pilot Policy/Telemetry – mTLS
    9091 HTTP Mixer Policy/Telemetry

    可以看到TYPE字段是沒有HTTPS的,HTTPS作為TCP類型。下面是productpage的listeners,刪減了部分信息。10.84開頭的是各個kubernetes service的CLUSTER-IP,以172.20開頭的是kubernetes的node IP,以nodePort方式暴露服務。

    $ istioctl proxy-config listeners productpage-v1-85b9bf9cd7-d8hm8.default
    ADDRESS          PORT     TYPE    
    0.0.0.0          443      TCP     <--+
    10.84.71.37      443      TCP        |
    10.84.223.189    443      TCP        |
    10.84.100.226    15443    TCP        |
    10.84.121.154    443      TCP        |
    10.84.142.44     443      TCP        | #從0.0.0.0_15001相關IP:PORT上接收出站的non-HTTP流量
    10.84.155.219    443      TCP        |
    172.20.127.212   9100     TCP        |
    10.84.205.103    443      TCP        | 
    10.84.167.116    443      TCP        |
    172.20.127.211   9100     TCP     <--+
    10.84.113.197    9979     HTTP+TCP<--+
    0.0.0.0          9091     HTTP+TCP   |
    10.84.30.227     9092     HTTP+TCP   |
    10.84.108.37     8080     HTTP+TCP   |
    10.84.158.64     8443     HTTP+TCP   |
    10.84.202.185    8080     HTTP+TCP   |
    10.84.21.252     8443     HTTP+TCP   |
    10.84.215.56     8443     HTTP+TCP   |
    0.0.0.0          60000    HTTP+TCP   | # 從0.0.0.0_15001的相關端口上接收出站的HTTP+TCP流量
    10.84.126.74     8778     HTTP+TCP   |
    10.84.126.74     8080     HTTP+TCP   |
    10.84.123.207    8080     HTTP+TCP   |
    10.84.30.227     9091     HTTP+TCP   |
    10.84.229.5      8080     HTTP+TCP<--+
    0.0.0.0          9080     HTTP+TCP     # 從 0.0.0.0_15006 上接收所有到9080的入站流量
    0.0.0.0          15001    TCP          # 從IP tables接收pod的所有出站流量,並移交給虛擬偵聽器
    0.0.0.0          15006    HTTP+TCP     # Envoy 入站
    0.0.0.0          15090    HTTP         # Envoy Prometheus 遙測
    0.0.0.0          15021    HTTP         # 健康檢查
    

    下面是productpage Pod中實際監聽的端口信息,與上述對應。

    $ ss -ntpl                                 
    State          Recv-Q        Send-Q        Local Address:Port          Peer Address:Port
    LISTEN         0             128                 0.0.0.0:15090              0.0.0.0:*
    LISTEN         0             128               127.0.0.1:15000              0.0.0.0:*
    LISTEN         0             128                 0.0.0.0:9080               0.0.0.0:*
    LISTEN         0             128                 0.0.0.0:15001              0.0.0.0:*
    LISTEN         0             128                 0.0.0.0:15006              0.0.0.0:*
    LISTEN         0             128                 0.0.0.0:15021              0.0.0.0:*
    LISTEN         0             128                       *:15020                    *:* 
    
  2. 從上述輸出概要中可以看到每個sidecar都有一個綁定到 0.0.0.0:15006的listener,IP tables會將所有入站的Pod流量導入該listener;以及一個綁定到 0.0.0.0:15001的listener,IP tables會將所有出站流量導入該listener,該listener有一個字段useOriginalDst設置為true,表示會使用最佳匹配原始目的地的方式將請求分發到virtual listener,如果沒有找到任何virtual listener,將會直接發送到連接目的地的PassthroughCluster

    $ istioctl pc listener productpage-v1-85b9bf9cd7-d8hm8.default --port 15001 -o json
    [
        {
            "name": "virtualOutbound",
            "address": {
                "socketAddress": {
                    "address": "0.0.0.0",
                    "portValue": 15001
                }
            },
            "filterChains": [
                {
                    "filters": [
                        {
                            "name": "istio.stats",
                            "typedConfig": {
                                "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
                                "typeUrl": "type.googleapis.com/envoy.extensions.filters.network.wasm.v3.Wasm",
                                "value": {
                                    "config": {
                                        "configuration": "{\n  \"debug\": \"false\",\n  \"stat_prefix\": \"istio\"\n}\n",
                                        "root_id": "stats_outbound",
                                        "vm_config": {
                                            "code": {
                                                "local": {
                                                    "inline_string": "envoy.wasm.stats"
                                                }
                                            },
                                            "runtime": "envoy.wasm.runtime.null",
                                            "vm_id": "tcp_stats_outbound"
                                        }
                                    }
                                }
                            }
                        },
                        {
                            "name": "envoy.tcp_proxy",
                            "typedConfig": {
                                "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                                "statPrefix": "PassthroughCluster",
                                "cluster": "PassthroughCluster",
                                "accessLog": [
                                    {
                                        "name": "envoy.file_access_log",
                                        "typedConfig": {
                                            "@type": "type.googleapis.com/envoy.config.accesslog.v2.FileAccessLog",
                                            "path": "/dev/stdout",
                                            "format": "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% \"%DYNAMIC_METADATA(istio.mixer:status)%\" \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
                                        }
                                    }
                                ]
                            }
                        }
                    ],
                    "name": "virtualOutbound-catchall-tcp"
                }
            ],
            "useOriginalDst": true,
            "trafficDirection": "OUTBOUND"
        }
    ]
    
  3. 應用的請求為一個出站HTTP請求,會到達9080端口,這意味着請求將傳遞給0.0.0.0:9080 virtual listener。該listener會查看其RDS中配置的路由。這種情況下會查找istiod配置的RDS的9080路由

    $ istioctl pc listener productpage-v1-85b9bf9cd7-d8hm8.default  -o json --address 0.0.0.0 --port 9080
    [
        {
            "name": "0.0.0.0_9080",
            "address": {
                "socketAddress": {
                    "address": "0.0.0.0",
                    "portValue": 9080
                }
            },
            "filterChains": [
                {
                    "filterChainMatch": {
                        "applicationProtocols": [
                            "http/1.0",
                            "http/1.1",
                            "h2c"
                        ]
                    },
                    "filters": [
                        {
                            "name": "envoy.http_connection_manager",
                            "typedConfig": {
                                "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager",
                                "statPrefix": "outbound_0.0.0.0_9080",
                                "rds": {
                                    "configSource": {
                                        "ads": {}
                                    },
                                    "routeConfigName": "9080"
                                },
    ...
    ]
    
  4. 9080的路由配置中每個服務只有一個virtual host。由於應用的請求會傳遞到reviews服務,因此Envoy會選擇請求與域相匹配的virtual host。一旦匹配到域,Envoy會查看匹配請求的第一個路由。下面場景中,由於沒有配置任何高級路由,因此只有一條可以匹配的路由,該路由告訴Envoy將請求發送到 outbound|9080||reviews.default.svc.cluster.local集群。

    $ istioctl proxy-config routes productpage-v1-85b9bf9cd7-d8hm8.default  --name 9080 -o json
    [
        {
            "name": "9080",
            "virtualHosts": [
    ...
                {
                    "name": "reviews.default.svc.cluster.local:9080", 
                    "domains": [
                        "reviews.default.svc.cluster.local",
                        "reviews.default.svc.cluster.local:9080",
                        "reviews",
                        "reviews:9080",
                        "reviews.default.svc.cluster",
                        "reviews.default.svc.cluster:9080",
                        "reviews.default.svc",
                        "reviews.default.svc:9080",
                        "reviews.default",
                        "reviews.default:9080",
                        "10.84.110.152",
                        "10.84.110.152:9080"
                    ],
                    "routes": [
                        {
                            "name": "default",
                            "match": {
                                "prefix": "/"
                            },
                            "route": {
                                "cluster": "outbound|9080||reviews.default.svc.cluster.local",
                                "timeout": "0s",
                                "retryPolicy": {
                                    "retryOn": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
                                    "numRetries": 2,
                                    "retryHostPredicate": [
                                        {
                                            "name": "envoy.retry_host_predicates.previous_hosts"
                                        }
                                    ],
                                    "hostSelectionRetryMaxAttempts": "5",
                                    "retriableStatusCodes": [
                                        503
                                    ]
                                },
                                "maxGrpcTimeout": "0s"
                            },
                            "decorator": {
                                "operation": "reviews.default.svc.cluster.local:9080/*"
                            }
                        }
                    ],
                    "includeRequestAttemptCount": true
                }
            ],
            "validateClusters": false
        }
    ]
    
  5. cluster的配置用於從istiod中檢索後端。Envoy會使用serviceName作為key在Endpoints列表中進行查找,並將請求傳遞到這些後端。

    $  istioctl pc cluster productpage-v1-85b9bf9cd7-d8hm8.default  --fqdn reviews.default.svc.cluster.local -o json
    [
        {
           ...
            "name": "outbound|9080||reviews.default.svc.cluster.local",
            "type": "EDS",
            "edsClusterConfig": {
                "edsConfig": {
                    "ads": {}
                },
                "serviceName": "outbound|9080||reviews.default.svc.cluster.local"
            },
            "connectTimeout": "10s",
            "circuitBreakers": {
                "thresholds": [
                    {
                        "maxConnections": 4294967295,
                        "maxPendingRequests": 4294967295,
                        "maxRequests": 4294967295,
                        "maxRetries": 4294967295
                    }
                ]
            },
            "filters": [
                {
                    "name": "istio.metadata_exchange",
                    "typedConfig": {
                        "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
                        "typeUrl": "type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange",
                        "value": {
                            "protocol": "istio-peer-exchange"
                        }
                    }
                }
            ]
        }
    ]
    
  6. 使用proxy-config endpoint命令查看本集群中當前可用的後端

    $ istioctl pc endpoint productpage-v1-85b9bf9cd7-d8hm8.default --cluster "outbound|9080||reviews.default.svc.cluster.local"
    ENDPOINT            STATUS      OUTLIER CHECK     CLUSTER
    10.80.3.55:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
    10.80.3.56:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
    10.80.3.58:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
    

流量方向為:listener(應用出站port)->route(routeConfigName)->cluster(domain)->endpoint(serviceName)

檢查bootstrap配置

到目前為止已經查看了istiod的大部分配置,然而,Envoy需要一些如哪裡可以發現istiod的bootstrap配置,使用如下方式查看:

$  istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-569669bb67-dsd5h.istio-system
{
    "bootstrap": {
        "node": {
            "id": "router~10.83.0.14~istio-ingressgateway-569669bb67-dsd5h.istio-system~istio-system.svc.cluster.local",
            "cluster": "istio-ingressgateway",
            "metadata": {
                    "CLUSTER_ID": "Kubernetes",
                    "CONFIG_NAMESPACE": "istio-system",
                    "EXCHANGE_KEYS": "NAME,NAMESPACE,INSTANCE_IPS,LABELS,OWNER,PLATFORM_METADATA,WORKLOAD_NAME,MESH_ID,SERVICE_ACCOUNT,CLUSTER_ID",
                    "INSTANCE_IPS": "10.83.0.14,fe80::6871:95ff:fe5b:9e3e",
                    "ISTIO_PROXY_SHA": "istio-proxy:12cfbda324320f99e0e39d7c393109fcd824591f",
                    "ISTIO_VERSION": "1.6.0",
                    "LABELS": {
                                "app": "istio-ingressgateway",
                                "chart": "gateways",
                                "heritage": "Tiller",
                                "istio": "ingressgateway",
                                "pod-template-hash": "569669bb67",
                                "release": "istio",
                                "service.istio.io/canonical-name": "istio-ingressgateway",
                                "service.istio.io/canonical-revision": "latest"
                            },
                    "MESH_ID": "cluster.local",
                    "NAME": "istio-ingressgateway-569669bb67-dsd5h",
                    "NAMESPACE": "istio-system",
                    "OWNER": "kubernetes://apis/apps/v1/namespaces/istio-system/deployments/istio-ingressgateway",
...
                    "ROUTER_MODE": "sni-dnat",
                    "SDS": "true",
                    "SERVICE_ACCOUNT": "istio-ingressgateway-service-account",
                    "TRUSTJWT": "true",
                    "WORKLOAD_NAME": "istio-ingressgateway"
                },
...
}

校驗到istiod的連通性

服務網格中的所有Envoy代理容器都應該連接到istiod,使用如下步驟測試:

  1. 創建一個sleep pod

    $ kubectl create namespace foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
    
  2. 使用curl測試到istiod的連通性。下面調用v1註冊API,使用默認的istiod配置參數,並啟用雙向TLS認證

    $ kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl -sS istiod.istio-system:15014/debug/endpointz
    

通過istioctl的輸出理解網格

如下內容是一個實驗特性,僅用於評估

istio 1.3中包含一個istioctl experimental describe命令。該CLI命令提供了解影響pod的配置所需的信息。本節展示如何使用該experimental 子命令查看一個pod是否在網格中,以及檢查該pod的配置。該命令的基本使用方式為:

$ istioctl experimental describe pod <pod-name>[.<namespace>] #或
$ istioctl experimental describe pod <pod-name> -n <namespace> 

校驗pod是否在網格中

如果一個pod不在網格中,istioctl describe會显示一個告警信息,此外,如果pod缺少istio需要的配置時也會給出告警信息。

$ istioctl experimental describe pod  mutatepodimages-7575797d95-qn7p5
Pod: mutatepodimages-7575797d95-qn7p5
   Pod does not expose ports
WARNING: mutatepodimages-7575797d95-qn7p5 is not part of mesh; no Istio sidecar
--------------------
Error: failed to execute command on sidecar: error 'execing into mutatepodimages-7575797d95-qn7p5/default istio-proxy container: container istio-proxy is not valid for pod mutatepodimages-7575797d95-qn7p5

如果一個pod在網格中,則不會產生告警。

$ istioctl x describe pod ratings-v1-6c9dbf6b45-xlf2q
Pod: ratings-v1-6c9dbf6b45-xlf2q
   Pod Ports: 9080 (details), 15090 (istio-proxy)
--------------------
Service: details
   Port: http 9080/HTTP targets pod port 9080
Pilot reports that pod enforces HTTP/mTLS and clients speak HTTP

輸出為:

  • pod的服務容器端口,上述為ratings的9080端口
  • pod中的istio-proxy端口,15090
  • pod服務使用的協議,9080端口的http協議
  • pod設置的mutual TLS

校驗destination rule配置

可以使用istioctl describe檢查應用到一個pod的destination rule。例如執行如下命令部署destination rule

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

查看ratings pod

$ export RATINGS_POD=$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod $RATINGS_POD
Pod: ratings-v1-6c9dbf6b45-xlf2q
   Pod Ports: 9080 (ratings), 15090 (istio-proxy)
--------------------
Service: ratings
   Port: http 9080/HTTP targets pod port 9080
DestinationRule: ratings for "ratings"
   Matching subsets: v1
      (Non-matching subsets v2,v2-mysql,v2-mysql-vm)
   Traffic Policy TLS Mode: ISTIO_MUTUAL
Pilot reports that pod enforces HTTP/mTLS and clients speak mTLS

輸出為:

  • 應用到ratings 服務的ratings destination rule
  • 匹配pod的ratings destination rule,上述為v1
  • destination rule定義的其他subset
  • pod接收HTTP或mutual TLS,但客戶端使用mutual TLS

校驗virtual service配置

部署如下virtual service

$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml

查看v1版本的reviews服務:

$ export REVIEWS_V1_POD=$(kubectl get pod -l app=reviews,version=v1 -o jsonpath='{.items[0].metadata.name}')
istioctl x describe pod $REVIEWS_V1_POD
$ istioctl x describe pod $REVIEWS_V1_POD
Pod: reviews-v1-564b97f875-q5l9r
   Pod Ports: 9080 (reviews), 15090 (istio-proxy)
--------------------
Service: reviews
   Port: http 9080/HTTP targets pod port 9080
DestinationRule: reviews for "reviews"
   Matching subsets: v1
      (Non-matching subsets v2,v3)
   Traffic Policy TLS Mode: ISTIO_MUTUAL
VirtualService: reviews
   1 HTTP route(s)

輸出結果與前面的ratings pod類型,但多了到pod的virtual service路由。

istioctl describe命令不僅僅显示了影響pod的virtual service。如果一個virtual service配置的host為一個pod,但流量不可達,會輸出告警信息,這種請求可能發生在當一個virtual service如果沒有可達的pod subset時。例如:

$ export REVIEWS_V2_POD=$(kubectl get pod -l app=reviews,version=v2 -o jsonpath='{.items[0].metadata.name}')
istioctl x describe pod $REVIEWS_V2_POD
[root@bastion istio-1.6.0]# istioctl x describe pod $REVIEWS_V2_POD
Pod: reviews-v2-568c7c9d8f-vcd94
...
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 1 HTTP routes)
      Route to non-matching subset v1 for (everything)

告警信息給出導致問題的原因,檢查的路由數目,以及其他路由信息。例如,由於virtual service將所有的流量到導入了v1 subset,因此v2 pod無法接收到任何流量。

如果刪除如下destination rule:

$ kubectl delete -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

可以看到如下信息:

$ istioctl x describe pod $REVIEWS_V1_POD
Pod: reviews-v1-564b97f875-q5l9r
   Pod Ports: 9080 (reviews), 15090 (istio-proxy)
--------------------
Service: reviews
   Port: http 9080/HTTP targets pod port 9080
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 1 HTTP routes)
      Warning: Route to subset v1 but NO DESTINATION RULE defining subsets!

輸出展示了已刪除destination rule,但沒有刪除依賴它的virtual service。該virtual service將流量路由到v1 subset,但沒有定義v1 subset的destination rule。因此流量無法分發到v1版本的pod。

恢復環境:

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

校驗流量路由

istioctl describe也可以展示流量權重。如理如下命令會將90%的流量導入reviews服務的v1 subset,將10%的流量導入reviews服務的v2 subset。

$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-90-10.yaml

查看reviews v1` pod:

$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   Weight 90%

輸出显示90%的reviews服務的流量導入到了v1 subset中。

部署其他類型的路由,如部署指定HTTP首部的路由:

$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml

再次查看pod:

$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 2 HTTP routes)
      Route to non-matching subset v2 for (when headers are end-user=jason)
      Route to non-matching subset v3 for (everything)

由於查看了位於v1 subset的pod,而virtual service將包含 end-user=jason 的流量分發給v2 subset,其他流量分發給v3 subset,v1 subset沒有任何流量導入,此時會輸出告警信息。

檢查strict mutual TLS(官方文檔待更新)

根據mutual TLS遷移指南,可以給ratings服務啟用strict mutual TLS。

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: ratings-strict
spec:
  selector:
    matchLabels:
      app: ratings
  mtls:
    mode: STRICT
EOF

執行如下命令查看ratings pod,輸出显示ratings pod已經使用mutual TLS防護。

$ istioctl x describe pod $RATINGS_POD
Pilot reports that pod enforces mTLS and clients speak mTLS

有時,將mutual TLS切換位STRICT模式時會對部署的組件造成影響,通常是因為destination rule不匹配新配置造成的。例如,如果配置Bookinfo客戶端不使用mutualTLS,而使用明文的HTTP destination rules:

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml

如果在瀏覽器傻瓜打開Bookinfo,會显示Ratings service is currently unavailable,使用如下命令查看原因:

$ istioctl x describe pod $RATINGS_POD
...
WARNING Pilot predicts TLS Conflict on ratings-v1-f745cf57b-qrxl2 port 9080 (pod enforces mTLS, clients speak HTTP)
  Check DestinationRule ratings/default and AuthenticationPolicy ratings-strict/default

輸出中有一個描述destination rule和authentication policy衝突的告警信息。

使用如下方式恢復:

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

卸載

$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml
$ kubectl delete -f samples/bookinfo/networking/bookinfo-gateway.yaml
$ kubectl delete -f samples/bookinfo/networking/destination-rule-all-mtls.yaml
$ kubectl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml

使用istioctl analyse診斷配置

istioctl analyze是一個可以探測istio配置中潛在錯誤的診斷工具,它可以診斷現有的集群或一組本地配置文件,會同時診斷這兩者。

可以使用如下方式診斷當前的kubernetes:

$ istioctl analyze --all-namespaces

例如,如果某些命名空間沒有啟用istiod注入,會打印如下告警信息:

Warn [IST0102] (Namespace openshift) The namespace is not enabled for Istio injection. Run 'kubectl label namespace openshift istio-injection=enabled' to enable it, or 'kubectl label namespace openshift istio-injection=disabled' to explicitly mark it as not needing injection

分析現有的集群/本地文件或二者

上述的例子用於分析一個存在的集群,但該工具也可以支持分析本地kubernetes yaml的配置文件集,或同時分析本地文件和集群。當分析一個本地文件集時,這些文件集應該是完全自包含的。通常用於分析需要部署到集群的一個完整的配置文件集。

分析特定的本地kubernetes yaml文件集:

$ istioctl analyze --use-kube=false a.yaml b.yaml

分析當前目錄中的所有yaml文件:

$ istioctl analyze --use-kube=false *.yaml

模擬將當前目錄中的files部署到當前集群中:

$ istioctl analyze *.yaml

使用istioctl analyze --help命令查看完整的選項。更多analyse的使用參見Q&A.

組件內省

Istio組件是用一個靈活的內省框架構建的,它使檢查和操作運行組件的內部狀態變得簡單。組件會開放一個端口,用於通過web瀏覽器的交互式視圖獲取組件的狀態,或使用外部工具通過REST訪問。

Mixer, PilotGalley 都實現了ControlZ 功能(1.6版本可以查看istiod)。當啟用這些組件時將記錄一條消息,指示要連接的IP地址和端口,以便與ControlZ交互。

2018-07-26T23:28:48.889370Z     info    ControlZ available at 100.76.122.230:9876

可以使用如下命令進行端口轉發,類似kubectl的port-forward,用於遠程訪問。

$ istioctl dashboard controlz <podname> -n <namespaces>

組件日誌

日誌作用域

組件的日誌按照作用域進行分類。取決於組件提供的功能,不同的組件有不同的作用域。所有的組件都有一個default的作用域,用於未分類的日誌消息。

各個組件的日誌作用域參見:reference documentation。

每個作用域對應一個唯一的日誌級別:

  1. none
  2. error
  3. warning
  4. info
  5. debug

其中none表示沒有劃分作用域的輸出,debug會最大化輸出。默認的作用域為info,用於在一般情況下為istio提供何時的日誌輸出。

可以使用 --log_output_level 控制輸出級別:

控制輸出

日誌信息通常會發送到組件的標準輸出流中。 --log_target選項可以將輸出重定向到任意(數量的)位置,可以通過逗號分割的列表給出文件系統的路徑。stdoutstderr分別表示標準輸出和標準錯誤輸出流。

日誌滾動

istio組件能夠自動管理日誌滾動,將大的日誌切分為小的日誌文件。--log_rotate選項允許指定用於滾動的基本文件名。派生的名稱將用於單個日誌文件。

--log_rotate_max_age選項指定文件發生滾動前的最大時間(天為單位),--log_rotate_max_size選項用於指定文件滾動發生前的最大文件大小(MB為單位), --log_rotate_max_backups選項控制保存的滾動文件的最大數量,超過該值的老文件會被自動刪除。

組件調試

--log_caller--log_stacktrace_level選項可以控制日誌信息是否包含程序員級別的信息。在跟蹤組件bug時很有用,但日常用不到。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

網頁設計最專業,超強功能平台可客製化

Vue中key的作用

Vue中key的作用

key的特殊attribute主要用在Vue的虛擬DOM算法,在新舊Nodes對比時辨識VNodes。如果不使用keyVue會使用一種最大限度減少動態元素並且盡可能的嘗試就地修改、復用相同類型元素的算法,而使用key時,它會基於key的變化重新排列元素順序,並且會移除key不存在的元素。此外有相同父元素的子元素必須有獨特的key,重複的key會造成渲染錯誤。

描述

首先是官方文檔的描述,當Vue正在更新使用v-for渲染的元素列表時,它默認使用就地更新的策略,如果數據項的順序被改變,Vue將不會移動DOM元素來匹配數據項的順序,而是就地更新每個元素,並且確保它們在每個索引位置正確渲染。這個默認的模式是高效的,但是只適用於不依賴子組件狀態或臨時DOM狀態的列表渲染輸出,例如表單輸入值。為了給Vue一個提示,以便它能跟蹤每個節點的身份,從而重用和重新排序現有元素,你需要為每項提供一個唯一 key attribute,建議盡可能在使用v-for時提供key attribute,除非遍歷輸出的DOM內容非常簡單,或者是刻意依賴默認行為以獲取性能上的提升。
簡單來說,當在列表循環中使用key時,需要使用key來給每個節點做一個唯一標識,diff算法就可以正確的識別此節點,找到正確的位置直接操作節點,盡可能地進行重用元素,key的作用主要是為了高效的更新虛擬DOM。此外,使用index作為key是並不推薦的做法,其只能保證Vue在數據變化時強制更新組件,以避免原地復用帶來的副作用,但不能保證最大限度的元素重用,且使用index作為key在數據更新方面和不使用key的效果基本相同。

示例

首先定義一個Vue實例,渲染四個列表,分別為簡單列表與複雜列表,以及其分別攜帶key與不攜帶key時對比其更新渲染時的速度,本次測試使用的是Chrome 81.0,每次在Console執行代碼時首先會進行刷新重新加載界面,避免瀏覽器以及Vue自身優化帶來的影響。

<!DOCTYPE html>
<html>
<head>
    <title>Vue</title>
</head>
<body>
    <div id="app">
        <ul>
            <li v-for="item in simpleListWithoutKey" >{{item}}</li>
        </ul>

        <ul>
            <li v-for="item in simpleListWithKey" :key="item" >{{item}}</li>
        </ul>

        <ul>
            <li v-for="item in complexListWithoutKey">
                <span v-for="value in item.list" v-if="value > 5">{{value}}</span>
            </li>
        </ul>

        <ul>
            <li v-for="item in complexListWithKey" :key="item.id">
                <span v-for="value in item.list" :key="value" v-if="value > 5">{{value}}</span>
            </li>
        </ul>

    </div>
</body>
<script src="https://cdn.staticfile.org/vue/2.2.2/vue.min.js"></script>
<script type="text/javascript">
    var vm = new Vue({
        el: '#app',
        data: {
            simpleListWithoutKey: [1, 2, 3, 4, 5, 6],
            simpleListWithKey: [1, 2, 3, 4, 5, 6],
            complexListWithoutKey:[
                {id: 1, list: [1, 2, 3]},
                {id: 2, list: [4, 5, 6]},
                {id: 3, list: [7, 8, 9]}
            ],
            complexListWithKey:[
                {id: 1, list: [1, 2, 3]},
                {id: 2, list: [4, 5, 6]},
                {id: 3, list: [7, 8, 9]}
            ],
        }
    })
</script>
</html>

簡單列表

在簡單列表的情況下,不使用key可能會比使用key的情況下在更新時的渲染速度更快,這也就是官方文檔中提到的,除非遍歷輸出的DOM內容非常簡單,或者是刻意依賴默認行為以獲取性能上的提升。在下面的例子中可以看到沒有key的情況下列表更新時渲染速度會快,當不存在key的情況下,這個列表直接進行原地復用,原有的節點的位置不變,原地復用元素,將內容更新為5678910,並添加了1112兩個節點,而存在key的情況下,原有的1234節點被刪除,56節點保留,添加了789101112六個節點,由於在DOM的增刪操作上比較耗時,所以表現為不帶key的情況下速度更快一些。

// 沒有key的情況下
console.time();
vm.simpleListWithoutKey = [5, 6, 7, 8, 9, 10, 11, 12];
vm.$nextTick(() => console.timeEnd());
// default: 2.193056640625ms
// 存在key的情況下
console.time();
vm.simpleListWithKey = [5, 6, 7, 8, 9, 10, 11, 12];
vm.$nextTick(() => console.timeEnd());
// default: 3.2138671875ms

原地復用可能會帶來一些副作用,文檔中提到原地復用這個默認的模式是高效的,但是只適用於不依賴子組件狀態或臨時DOM狀態的列表渲染輸出,例如表單輸入值。在不設置key的情況下,元素中沒有與數據data綁定的部分,Vue會默認使用已經渲染的DOM,而綁定了數據data的部分會進行跟隨數據渲染,假如操作了元素位置,則元素中未綁定data的部分會停留在原地,而綁定了data的部分會跟隨操作進行移動,在下面的例子中首先需要將兩個A之後的輸入框添加數據信息,這樣就製作了一個臨時狀態,如果此時點擊下移按鈕,那麼不使用key的組中的輸入框將不會跟隨下移,且B到了頂端並成為了紅色,而使用key的組中會將輸入框進行下移,且A依舊是紅色跟隨下移。

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>就地復用</title>
</head>
<body>

  <div id="app">
    <h3>採用就地復用策略(vuejs默認情況)</h3>
    <div  v-for='(p, i) in persons'>
      <span>{{p.name}}<span>  
      <input type="text"/>  
      <button @click='down(i)' v-if='i != persons.length - 1'>下移</button>
    </div> 

    <h3>不採用就地復用策略(設置key)</h3>
    <div  v-for='(p, i) in persons' :key='p.id'>
      <span>{{p.name}}<span> 
      <input type="text"/>  
      <button @click='down(i)' v-if='i != persons.length - 1'>下移</button>
    </div>

  </div>
<script src="https://cdn.staticfile.org/vue/2.2.2/vue.min.js"></script>
  <script>
    new Vue({
      el: '#app',
      data: {
        persons: [
            { id: 1, name: 'A' },
            { id: 2, name: 'B' },
            { id: 3, name: 'C' }
        ]
      },
      mounted: function(){
        // 此DOM操作將兩個A的顏色設置為紅色 主要是為了演示原地復用
        document.querySelectorAll("h3 + div > span:first-child").forEach( v => v.style.color="red");
      },
      methods: {
        down: function(i) {
            if (i == this.persons.length - 1) return;
          var listClone = this.persons.slice();
          var one = listClone[i];
          listClone[i] = listClone[i + 1];
          listClone[i + 1] = one;
          this.persons = listClone;
        }
      }
    });
  </script>
</body>
</html>
<!-- 源於 https://www.zhihu.com/question/61078310 @霸都丶傲天 有修改-->

複雜列表

使用key不僅能夠避免上述的原地復用的副作用,且在一些操作上可能能夠提高渲染的效率,主要體現在重新排序的情況,包括在中間插入和刪除節點的操作,在下面的例子中沒有key的情況下重新排序會原地復用元素,但是由於v-if綁定了data所以會一併進行操作,在這個DOM操作上比較消耗時間,而使用key得情況則直接復用元素,v-if控制的元素在初次渲染就已經決定,在本例中沒有對其進行更新,所以不涉及v-ifDOM操作,所以在效率上會高一些。

console.time();
vm.complexListWithoutKey = [
        {id: 3, list: [7, 8, 9]},
        {id: 2, list: [4, 5, 6]},
        {id: 1, list: [1, 2, 3]},
    ];
vm.$nextTick(() => console.timeEnd());
vm.$nextTick(() => console.timeEnd());
// default: 4.100244140625ms
console.time();
vm.complexListWithKey = [
        {id: 3, list: [7, 8, 9]},
        {id: 2, list: [4, 5, 6]},
        {id: 1, list: [1, 2, 3]},
    ];
vm.$nextTick(() => console.timeEnd());
// default: 3.016064453125ms

每日一題

https://github.com/WindrunnerMax/EveryDay

參考

https://cn.vuejs.org/v2/api/#key
https://www.jianshu.com/p/4bdd2690859c
https://www.zhihu.com/question/61078310
https://segmentfault.com/a/1190000012861862
https://www.cnblogs.com/zhumingzhenhao/p/7688336.html
https://blog.csdn.net/hl18730262380/article/details/89306500
https://github.com/Advanced-Frontend/Daily-Interview-Question/issues/1
https://cn.vuejs.org/v2/guide/list.html#%E7%BB%B4%E6%8A%A4%E7%8A%B6%E6%80%81

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計最專業,超強功能平台可客製化

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

.NET 技術棧 思維導圖

    背景介紹

  • 根據網上招聘網站的一些.NET技能需求,畫了一個圖,便於在自修和學習的過程當中有一個方向。

    技能棧

  • Web front-end
    o 框架技術

    ▣ Vue

    ▣ Bootstrap

    ▣ LayUI

    ▣ EasyUI

    ▣ Node.js

    ▣ ReactJS

    ▣ Angular

    ▣ Webpack

    o 開發工具

    ▨ 編碼工具
    ▣ HBuilder X

    ▨ 設計工具
    ▣ PxCook — 像素大廚
    ▣ 藍湖
    ▣ Visio
    ▣ 迅捷流程圖軟件

  • Website
    o 框架技術

    ▨ 雲服務模型
    ▣ Saas — 軟件即服務
    ▣ IaaS — 基礎設施即服務
    ▣ PaaS — 平台即服務

    ▨ 緩存技術
    ▣ Redis
    ▣ MemoryCache
    ▣ Session

    ▨ 消息隊列
    ▣ Windows Message Queue
    ▣ RabbitMQ
    ▣ Kafka

    ▨ 數據操作
    ▤ ORM — 對象關係映射(Object Relational Mapping)
    ▣ Entity framework
    〼 Code First
    〼 Database First
    〼 Model First
    ▣ NHibernate
    ▣ Dapper

    ▨ 框架概念
    ▤ OOD — 面向對象設計(Object-Oriented Design)
    ▤ DDD — 領域驅動設計(Domain-DrivenDesign)
    ▤ AOP — 面向切面編程(Aspect Oriented Programming)
    ▤ IOC — 控制反轉(Inversion of Control)
    ▣ 概念
    〼 依賴注入DI(Dependency Injection)
    〼 依賴查找(Dependency Lookup)
    ▣ 框架
    〼 Autofac
    〼 Spring.NET
    〼 MEF(Managed Extensibility Framework)
    〼 Unity
    〼 PostSharp

  • Windows app
    o 框架技術

    ▣ Winform

    ▣ WPF

    ▤ 通訊技術
    〼 即時通訊
    ▣ SignalR
    ▣ Socket
    〼 通訊協議
    ▣ TCP/IP
    ▣ UDP
    ▣ SSH
    ▣ PCI/PCIE
    ▣ Canbus
    ▣ Modbus
    〼 串口通訊

    ▤ 異步編程
    ▣ 多線程
    ▣ 隊列

    o 控件倉庫

    ▣ DevExpress

    ▣ Metroframework UI

    o 打包加密

    ▤ 打包
    ▣ InnoSetup

    ▤ 混淆/加密
    ▣ .NET Reactor

    ▤ 簽名

  • Web api
    o 框架技術

    ▤ 接口規範
    ▣ Resultful
    ▣ OpenAPI

    ▤ 接口管理
    ▣ Yapi
    ▣ Swagger

  • Windows services
    o WCF
    o Windows services
  • Devops
    o CI — 持續集成(Continuous integration)

    ▤ 代碼倉庫
    ▣ Git
    ▣ Svn

    ▤ 構建工具
    〼 Maven
    〼 Jenkins
    ▣ SonarQube — 自動化測試工具
    〼 Daily build
    〼 Puppet
    ▣ 供應(Provisioning)
    ▣ 配置(Configuration)
    ▣ 聯動(Orchestration)
    ▣ 報告(Reporting)

    ▤ 測試工具
    ▣ Selenium
    ▣ QTP
    ▣ Loadrunner
    ▣ Robot Framework
    ▣ Postman
    ▣ Soapui

    ▤ 配置管理
    ▣ Zookeeper

    ▤ 日誌監控
    〼 ELK
    ▣ Elasticsearch — 實時搜索
    ▣ Logstash — 中央數據流引擎
    ▣ Kibana — 實時分析

    ▤ 文件存儲
    ▣ TFS — 淘寶分佈式文件存儲(Taobao File System)
    ▣ NAS網絡存儲
    ▣ 阿里雲OSS對象存儲

    ▤ 高可用性
    〼 容器技術 — Docker + kubernetes
    〼 讀寫分離
    ▣ 數據庫複製和訂閱
    ▣ 集群服務
    〼 分庫分表
    ▣ 水平拆分
    ▣ 垂直拆分
    〼 邏輯分區

    o CD

    ▤ 持續交付(Continuous Delivery)
    ▣ 預發布環境
    ▣ 灰度環境

    ▤ 持續部署(Continuous Deployment)
    ▣ 自動發布到生產環境

    o 雲

    ▤ 雲平台
    ▣ 阿里雲
    ▣ 華為雲
    ▣ 騰訊雲
    ▣ Microsoft Azure

    ▤ 雲概念
    ▣ 公有雲
    ▣ 私有雲

    o SRE

    ▤ 網站可靠性工程師

    o 開發語言

    ▤ Python — 人工智能、系統運維

    ▤ Go語言 — 服務器編程、分佈式系統、網絡編程、雲平台

    思維導圖

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

[源碼解析] Flink的groupBy和reduce究竟做了什麼

[源碼解析] Flink的groupBy和reduce究竟做了什麼

目錄

  • [源碼解析] Flink的groupBy和reduce究竟做了什麼
    • 0x00 摘要
    • 0x01 問題和概括
      • 1.1 問題
      • 1.2 概括
    • 0x02 背景概念
      • 2.1 MapReduce細分
      • 2.2 MapReduce細分
      • 2.3 Combine
      • 2.4 Partition
      • 2.5 Shuffle
      • 2.6 Reducer
    • 0x03 代碼
    • 0x04 從Flink JAVA API入手挖掘
      • 4.1 GroupBy是個輔助概念
        • 4.1.1 Grouping
        • 4.1.2 UnsortedGrouping
      • 4.2 reduce才是算子
    • 0x05 批處理執行計劃(Plan)
    • 0x06 批處理優化計劃(Optimized Plan)
    • 0x07 JobGraph
    • 0x08 Runtime
      • 8.1 FlatMap
        • 8.1.1 Combine
        • 8.1.2 Partition
      • 8.2 UnilateralSortMerger
        • 8.2.1 三種線程
        • 8.2.2 MutableObjectIterator
      • 8.3 ReduceDriver
    • 0x09 參考

0x00 摘要

Groupby和reduce是大數據領域常見的算子,但是很多同學應該對其背後機制不甚了解。本文將從源碼入手,為大家解析Flink中Groupby和reduce的原理,看看他們在背後做了什麼。

0x01 問題和概括

1.1 問題

探究的原因是想到了幾個問題 :

  • groupby的算子會對數據進行排序嘛。
  • groupby和reduce過程中究竟有幾次排序。
  • 如果有多個groupby task,什麼機制保證所有這些grouby task的輸出中,同樣的key都分配給同一個reducer。
  • groupby和reduce時候,有沒有Rebalance 重新分配。
  • reduce算子會不會重新劃分task。
  • reduce算子有沒有可能和前後的其他算子組成Operator Chain。

1.2 概括

為了便於大家理解,我們先總結下,對於一個Groupby + Reduce的操作,Flink做了如下處理:

  • Group其實沒有真實對應的算子,它只是在在reduce過程之前的一个中間步驟或者輔助步驟。
  • 在Flink生成批處理執行計劃后,有意義的結果是Reduce算子。
  • 為了更好的reduce,Flink在reduce之前大量使用了Combine操作。Combine可以理解為是在map端的reduce的操作,對單個map任務的輸出結果數據進行合併的操作。
  • 在Flink生成批處理優化計劃(Optimized Plan)之後,會把reduce分割成兩段,一段是SORTED_PARTIAL_REDUCE,一段是SORTED_REDUCE。
  • SORTED_PARTIAL_REDUCE就是Combine。
  • Flink生成JobGraph之後,Flink形成了一個Operator Chain:Reduce(SORTED_PARTIAL_REDUCE)和其上游合併在一起。
  • Flink用Partitioner來保證多個 grouby task 的輸出中同樣的key都分配給同一個reducer。
  • groupby和reduce過程中至少有三次排序:
    • combine
    • sort + merge
    • reduce

這樣之前的疑問就基本得到了解釋。

0x02 背景概念

2.1 MapReduce細分

MapReduce是一種編程模型,用於大規模數據集的并行運算。概念 “Map(映射)”和”Reduce(歸約)” 是它們的主要思想,其是從函數式編程語言,矢量編程語言里借來的特性。

我們目前使用的Flink,Spark都出自於MapReduce,所以我們有必有追根溯源,看看MapReduce是如何區分各個階段的。

2.2 MapReduce細分

如果把MapReduce細分,可以分為一下幾大過程:

  • Input-Split(輸入分片):此過程是將從HDFS上讀取的文件分片,然後送給Map端。有多少分片就有多少Mapper,一般分片的大小和HDFS中的塊大小一致。
  • Shuffle-Spill(溢寫):每個Map任務都有一個環形緩衝區。一旦緩衝區達到閾值80%,一個後台線程便開始把內容“溢寫”-“spill”到磁盤。在溢寫過程中,map將繼續輸出到剩餘的20%空間中,互不影響,如果緩衝區被填滿map會被堵塞直到寫磁盤完成。
  • Shuffle-Partition(分區):由於每個Map可能處理的數據量不同,所以到達reduce有可能會導致數據傾斜。分區可以幫助我們解決這一問題,在shuffle過程中會按照默認key的哈希碼對分區數量取余,reduce便根據分區號來拉取對應的數據,達到數據均衡。分區數量對應Reduce個數。
  • Shuffle-Sort(排序):在分區后,會對此分區的數據進行內排序,排序過程會穿插在整個MapReduce中,在很多地方都存在。
  • Shuffle-Group(分組):分組過程會把key相同的value分配到一個組中,wordcount程序就利用了分組這一過程。
  • Shuffle-Combiner(組合):這一過程我們可以理解為一個小的Reduce階段,當數據量大的時候可以在map過程中執行一次combine,這樣就相當於在map階段執行了一次reduce。由於reduce和map在不同的節點上運行,所以reduce需要遠程拉取數據,combine就可以有效降低reduce拉取數據的量,減少網絡負荷(這一過程默認是不開啟的,在如求平均值的mapreduce程序中不要使用combine,因為會影響結果)。
  • Compress(壓縮):在緩衝區溢寫磁盤的時候,可以對數據進行壓縮,節約磁盤空間,同樣減少給reducer傳遞的數據量。
  • Reduce-Merge(合併):reduce端會拉取各個map輸出結果對應的分區文件,這樣reduce端就會有很多文件,所以在此階段,reduce再次將它們合併/排序再送入reduce執行。
  • Output(輸出):在reduce階段,對已排序輸出中的每個鍵調用reduce函數。此階段的輸出直接寫到輸出文件系統,一般為HDFS。

2.3 Combine

Combine是我們需要特殊注意的。在mapreduce中,map多,reduce少。在reduce中由於數據量比較多,所以我們乾脆在map階段中先把自己map裏面的數據歸類,這樣到了reduce的時候就減輕了壓力。

Combine可以理解為是在map端的reduce的操作,對單個map任務的輸出結果數據進行合併的操作。combine是對一個map的,而reduce合併的對象是對於多個map

map函數操作所產生的鍵值對會作為combine函數的輸入,經combine函數處理后再送到reduce函數進行處理,減少了寫入磁盤的數據量,同時也減少了網絡中鍵值對的傳輸量。在Map端,用戶自定義實現的Combine優化機制類Combiner在執行Map端任務的節點本身運行,相當於對map函數的輸出做了一次reduce。

集群上的可用帶寬往往是有限的,產生的中間臨時數據量很大時就會出現性能瓶頸,因此應該盡量避免Map端任務和Reduce端任務之間大量的數據傳輸。使用Combine機制的意義就在於使Map端輸出更緊湊,使得寫到本地磁盤和傳給Reduce端的數據更少。

2.4 Partition

Partition是分割map每個節點的結果,按照key分別映射給不同的reduce,mapreduce使用哈希HashPartitioner幫我們歸類了。這個我們也可以自定義。

這裏其實可以理解歸類。我們對於錯綜複雜的數據歸類。比如在動物園裡有牛羊雞鴨鵝,他們都是混在一起的,但是到了晚上他們就各自牛回牛棚,羊回羊圈,雞回雞窩。partition的作用就是把這些數據歸類。只不過是在寫程序的時候,

在經過mapper的運行后,我們得知mapper的輸出是這樣一個key/value對: key是“aaa”, value是數值1。因為當前map端只做加1的操作,在reduce task里才去合併結果集。假如我們知道這個job有3個reduce task,到底當前的“aaa”應該交由哪個reduce task去做呢,是需要立刻決定的。

MapReduce提供Partitioner接口,它的作用就是根據key或value及reduce task的數量來決定當前的這對輸出數據最終應該交由哪個reduce task處理。默認對key hash后再以reduce task數量取模。默認的取模方式只是為了平均reduce的處理能力,如果用戶自己對Partitioner有需求,可以訂製並設置到job上。

在我們的例子中,假定 “aaa”經過Partitioner后返回0,也就是這對值應當交由第一個reducer來處理。

2.5 Shuffle

shuffle就是map和reduce之間的過程,包含了兩端的combine和partition。它比較難以理解,因為我們摸不着,看不到它。它屬於mapreduce的框架,編程的時候,我們用不到它。

Shuffle的大致範圍就是:怎樣把map task的輸出結果有效地傳送到reduce端。也可以這樣理解, Shuffle描述着數據從map task輸出到reduce task輸入的這段過程。

2.6 Reducer

簡單地說,reduce task在執行之前的工作就是不斷地拉取當前job里每個map task的最終結果,然後對從不同地方拉取過來的數據不斷地做merge,最終形成一個文件作為reduce task的輸入文件。

0x03 代碼

我們以Flink的KMeans算法作為樣例,具體摘要如下:

public class WordCountExampleReduce {

    DataStream ds;

    public static void main(String[] args) throws Exception {
        //構建環境
        final ExecutionEnvironment env =
                ExecutionEnvironment.getExecutionEnvironment();
        //通過字符串構建數據集
        DataSet<String> text = env.fromElements(
                "Who‘s there?",
                "I think I hear them. Stand, ho! Who‘s there?");
        //分割字符串、按照key進行分組、統計相同的key個數
        DataSet<Tuple2<String, Integer>> wordCounts = text
                .flatMap(new LineSplitter())
                .groupBy(0)
                .reduce(new ReduceFunction<Tuple2<String, Integer>>() {
                    @Override
                    public Tuple2<String, Integer> reduce(Tuple2<String, Integer> value1,
                                          Tuple2<String, Integer> value2) throws Exception {
                        return new Tuple2(value1.f0, value1.f1 + value2.f1);
                    }
                });
        //打印
        wordCounts.print();
    }
    //分割字符串的方法
    public static class LineSplitter implements FlatMapFunction<String, Tuple2<String, Integer>> {
        @Override
        public void flatMap(String line, Collector<Tuple2<String, Integer>> out) {
            for (String word : line.split(" ")) {
                out.collect(new Tuple2<String, Integer>(word, 1));
            }
        }
    }
}

輸出是:

(hear,1)
(ho!,1)
(them.,1)
(I,2)
(Stand,,1)
(Who‘s,2)
(there?,2)
(think,1)

0x04 從Flink JAVA API入手挖掘

首先,我們從Flink基本JAVA API來入手開始挖掘。

4.1 GroupBy是個輔助概念

4.1.1 Grouping

我們需要留意的是:GroupBy並沒有對應的Operator。GroupBy只是生成DataSet轉換的一个中間步驟或者輔助步驟

GroupBy功能的基類是Grouping,其只是DataSet轉換的一个中間步驟。其幾個主要成員是:

  • 對應的輸入數據DataSet
  • 分組所基於的keys
  • 用戶自定義的Partitioner
// Grouping is an intermediate step for a transformation on a grouped DataSet.
public abstract class Grouping<T> {
   protected final DataSet<T> inputDataSet;
   protected final Keys<T> keys;
   protected Partitioner<?> customPartitioner;
}

Grouping並沒有任何業務相關的API,具體API都是在其派生類中,比如UnsortedGrouping。

4.1.2 UnsortedGrouping

我們代碼中對應的就是UnsortedGrouping類。我們看到它提供了很多業務API,比如:sum,max,min,reduce,aggregate,reduceGroup,combineGroup…..

回到我們的示例,groupBy做了如下操作

  • 首先,groupBy返回的就是一個UnsortedGrouping,這個UnsortedGrouping是用來轉換DataSet。
  • 其次,.groupBy(0).reduce(new CentroidAccumulator()) 返回的是ReduceOperator。這就對應了前面我們提到的,groupBy只是中間步驟,reduce才能返回一個Operator
public class UnsortedGrouping<T> extends Grouping<T> {
  
    // groupBy返回一個UnsortedGrouping
    public UnsortedGrouping<T> groupBy(int... fields) {
       return new UnsortedGrouping<>(this, new Keys.ExpressionKeys<>(fields, getType()));
    }
  
    // reduce返回一個ReduceOperator
 		public ReduceOperator<T> reduce(ReduceFunction<T> reducer) {
      return new ReduceOperator<T>(this, inputDataSet.clean(reducer), Utils.getCallLocationName());
    } 
}

4.2 reduce才是算子

對於業務來說,reduce才是真正有意義的邏輯算子。

從前文的函數調用和ReduceOperator定義可以看出,.groupBy(0).reduce() 的調用結果是生成一個ReduceOperator,而 UnsortedGrouping 被設置為 ReduceOperator 的 grouper 成員變量,作為輔助操作

public class ReduceOperator<IN> extends SingleInputUdfOperator<IN, IN, ReduceOperator<IN>> {
  
	private final ReduceFunction<IN> function;
	private final Grouping<IN> grouper; // UnsortedGrouping被設置在這裏,後續reduce操作中會用到。

	public ReduceOperator(Grouping<IN> input, ReduceFunction<IN> function, 
                        String defaultName) {
		this.function = function;
		this.grouper = input; // UnsortedGrouping被設置在這裏,後續reduce操作中會用到。
    this.hint = CombineHint.OPTIMIZER_CHOOSES; // 優化時候會用到。
	}
}

讓我們順着Flink程序執行階段繼續看看系統都做了些什麼。

0x05 批處理執行計劃(Plan)

程序執行的第一步是:當程序運行時候,首先會根據java API的結果來生成執行plan。

public JobClient executeAsync(String jobName) throws Exception {
   final Plan plan = createProgramPlan(jobName);
} 

其中重要的函數是translateToDataFlow,因為在translateToDataFlow方法中,會從批處理Java API模塊中operators包往核心模塊中operators包的轉換

對於我們的示例程序,在生成 Graph時,translateToDataFlow會生成一個 SingleInputOperator,為後續runtime使用。下面是代碼縮減版。

protected org.apache.flink.api.common.operators.SingleInputOperator<?, IN, ?> translateToDataFlow(Operator<IN> input) {
    
    ......
      
    // UnsortedGrouping中的keys被取出,  
		else if (grouper.getKeys() instanceof Keys.ExpressionKeys) {

			// reduce with field positions
			ReduceOperatorBase<IN, ReduceFunction<IN>> po =
					new ReduceOperatorBase<>(function, operatorInfo, logicalKeyPositions, name);

			po.setCustomPartitioner(grouper.getCustomPartitioner());
			po.setInput(input);
			po.setParallelism(getParallelism()); // 沒有并行度的變化

			return po;//translateToDataFlow會生成一個 SingleInputOperator,為後續runtime使用
		}	    
  }  
}

我們代碼最終生成的執行計劃如下,我們可以看出來,執行計劃基本符合我們的估計:簡單的從輸入到輸出。中間有意義的算子其實只有Reduce

GenericDataSourceBase ——> FlatMapOperatorBase ——> ReduceOperatorBase ——> GenericDataSinkBase

具體在代碼中體現如下是:

plan = {Plan@1296} 
 sinks = {ArrayList@1309}  size = 1
  0 = {GenericDataSinkBase@1313} "collect()"
   formatWrapper = {UserCodeObjectWrapper@1315} 
   input = {ReduceOperatorBase@1316} "ReduceOperatorBase - Reduce at main(WordCountExampleReduceCsv.java:25)"
    hint = {ReduceOperatorBase$CombineHint@1325} "OPTIMIZER_CHOOSES"
    customPartitioner = null
    input = {FlatMapOperatorBase@1326} "FlatMapOperatorBase - FlatMap at main(WordCountExampleReduceCsv.java:23)"
     input = {GenericDataSourceBase@1339} "at main(WordCountExampleReduceCsv.java:20) (org.apache.flink.api.java.io.TextInputFormat)"

0x06 批處理優化計劃(Optimized Plan)

程序執行的第二步是:Flink對於Plan會繼續優化,生成Optimized Plan。其核心代碼位於PlanTranslator.compilePlan 函數,這裏得到了Optimized Plan。

這個編譯的過程不作任何決策與假設,也就是說作業最終如何被執行早已被優化器確定,而編譯也是在此基礎上做確定性的映射。所以我們將集中精力看如何優化plan。

private JobGraph compilePlan(Plan plan, Configuration optimizerConfiguration) {
   Optimizer optimizer = new Optimizer(new DataStatistics(), optimizerConfiguration);
   OptimizedPlan optimizedPlan = optimizer.compile(plan);

   JobGraphGenerator jobGraphGenerator = new JobGraphGenerator(optimizerConfiguration);
   return jobGraphGenerator.compileJobGraph(optimizedPlan, plan.getJobId());
}

在內部調用plan的accept方法遍歷它。accept會挨個在每個sink上調用accept。對於每個sink會先preVisit,然後 postVisit。

這裏優化時候有幾個注意點:

  1. 在 GraphCreatingVisitor.preVisit 中,當發現Operator是 ReduceOperatorBase 類型的時候,會建立ReduceNode。

    else if (c instanceof ReduceOperatorBase) {
       n = new ReduceNode((ReduceOperatorBase<?, ?>) c);
    }
    
  2. ReduceNode是Reducer Operator的Optimizer表示。

    public class ReduceNode extends SingleInputNode {
    	private final List<OperatorDescriptorSingle> possibleProperties;	
    	private ReduceNode preReduceUtilityNode;
    }
    
  3. 生成ReduceNode時候,會根據之前提到的 hint 來決定 combinerStrategy = DriverStrategy.SORTED_PARTIAL_REDUCE;

    public ReduceNode(ReduceOperatorBase<?, ?> operator) {
    			DriverStrategy combinerStrategy;
    			switch(operator.getCombineHint()) {
    				case OPTIMIZER_CHOOSES:
    					combinerStrategy = DriverStrategy.SORTED_PARTIAL_REDUCE;
    					break;
          }  
    }
    

生成的優化執行計劃如下,我們可以看到,這時候設置了并行度,也把reduce分割成兩段,一段是SORTED_PARTIAL_REDUCE,一段是SORTED_REDUCE

Data Source  ——> FlatMap ——> Reduce(SORTED_PARTIAL_REDUCE)   ——> Reduce(SORTED_REDUCE)  ——> Data Sink

具體在代碼中體現如下是:

optimizedPlan = {OptimizedPlan@1506} 
 
 allNodes = {HashSet@1510}  size = 5
   
  0 = {SourcePlanNode@1512} "Data Source "at main(WordCountExampleReduceCsv.java:20) (org.apache.flink.api.java.io.TextInputFormat)" : NONE [[ GlobalProperties [partitioning=RANDOM_PARTITIONED] ]] [[ LocalProperties [ordering=null, grouped=null, unique=null] ]]"
   parallelism = 4

  1 = {SingleInputPlanNode@1513} "FlatMap "FlatMap at main(WordCountExampleReduceCsv.java:23)" : FLAT_MAP [[ GlobalProperties [partitioning=RANDOM_PARTITIONED] ]] [[ LocalProperties [ordering=null, grouped=null, unique=null] ]]"
   parallelism = 4

  2 = {SingleInputPlanNode@1514} "Reduce "Reduce at main(WordCountExampleReduceCsv.java:25)" : SORTED_REDUCE [[ GlobalProperties [partitioning=RANDOM_PARTITIONED] ]] [[ LocalProperties [ordering=null, grouped=null, unique=null] ]]"
   parallelism = 4

  3 = {SinkPlanNode@1515} "Data Sink "collect()" : NONE [[ GlobalProperties [partitioning=RANDOM_PARTITIONED] ]] [[ LocalProperties [ordering=null, grouped=null, unique=null] ]]"
   parallelism = 4

  4 = {SingleInputPlanNode@1516} "Reduce "Reduce at main(WordCountExampleReduceCsv.java:25)" : SORTED_PARTIAL_REDUCE [[ GlobalProperties [partitioning=RANDOM_PARTITIONED] ]] [[ LocalProperties [ordering=null, grouped=null, unique=null] ]]"
   parallelism = 4

0x07 JobGraph

程序執行的第三步是:建立JobGraph。LocalExecutor.execute中會生成JobGraph。Optimized Plan 經過優化後生成了 JobGraph, JobGraph是提交給 JobManager 的數據結構。

主要的優化為,將多個符合條件的節點 chain 在一起作為一個節點,這樣可以減少數據在節點之間流動所需要的序列化/反序列化/傳輸消耗。

JobGraph是唯一被Flink的數據流引擎所識別的表述作業的數據結構,也正是這一共同的抽象體現了流處理和批處理在運行時的統一

public CompletableFuture<JobClient> execute(Pipeline pipeline, Configuration configuration) throws Exception {
   final JobGraph jobGraph = getJobGraph(pipeline, configuration);
}

我們可以看出來,這一步形成了一個Operator Chain:

CHAIN DataSource -> FlatMap -> Combine (Reduce) 

於是我們看到,Reduce(SORTED_PARTIAL_REDUCE)和其上游合併在一起

具體在程序中打印出來:

jobGraph = {JobGraph@1739} "JobGraph(jobId: 30421d78d7eedee6be2c5de39d416eb7)"
 taskVertices = {LinkedHashMap@1742}  size = 3
  
  {JobVertexID@1762} "e2c43ec0df647ea6735b2421fb7330fb" -> {InputOutputFormatVertex@1763} "CHAIN DataSource (at main(WordCountExampleReduceCsv.java:20) (org.apache.flink.api.java.io.TextInputFormat)) -> FlatMap (FlatMap at main(WordCountExampleReduceCsv.java:23)) -> Combine (Reduce at main(WordCountExampleReduceCsv.java:25)) (org.apache.flink.runtime.operators.DataSourceTask)"
  
  {JobVertexID@1764} "2de11f497e827e48dda1d63b458dead7" -> {JobVertex@1765} "Reduce (Reduce at main(WordCountExampleReduceCsv.java:25)) (org.apache.flink.runtime.operators.BatchTask)"
  
  {JobVertexID@1766} "2bee17f2c86aa1e9439e3dedea58007b" -> {InputOutputFormatVertex@1767} "DataSink (collect()) (org.apache.flink.runtime.operators.DataSinkTask)"

0x08 Runtime

Job提交之後,就是程序正式運行了。這裏實際上涉及到了三次排序,

  • 一次是在FlatMap發送時候調用到了ChainedReduceCombineDriver.sortAndCombine。這部分對應了我們之前提到的MapReduce中的Combine和Partition。
  • 一次是在 ReduceDriver 所在的 BatchTask中,由UnilateralSortMerger完成了sort & merge操作。
  • 一次是在ReduceDriver,這裏做了最後的reducer排序。

8.1 FlatMap

這裡是第一次排序

當一批數據處理完成之後,在ChainedFlatMapDriver中調用到close函數進行發送數據給下游。

public void close() {
   this.outputCollector.close();
}

Operator Chain會調用到ChainedReduceCombineDriver.close

public void close() {
   // send the final batch
   try {
      switch (strategy) {
         case SORTED_PARTIAL_REDUCE:
            sortAndCombine(); // 我們是在這裏
            break;
         case HASHED_PARTIAL_REDUCE:
            reduceFacade.emit();
            break;
      }
   } catch (Exception ex2) {
      throw new ExceptionInChainedStubException(taskName, ex2);
   }

   outputCollector.close();
   dispose(false);
}

8.1.1 Combine

sortAndCombine中先排序,然後做combine,最後會不斷髮送數據

private void sortAndCombine() throws Exception {
   final InMemorySorter<T> sorter = this.sorter;

   if (!sorter.isEmpty()) {
      sortAlgo.sort(sorter); // 這裡會先排序

      final TypeSerializer<T> serializer = this.serializer;
      final TypeComparator<T> comparator = this.comparator;
      final ReduceFunction<T> function = this.reducer;
      final Collector<T> output = this.outputCollector;
      final MutableObjectIterator<T> input = sorter.getIterator();

      if (objectReuseEnabled) {
        ......
      } else {
         T value = input.next();

         // 這裏就是combine
         // iterate over key groups
         while (running && value != null) {
            comparator.setReference(value);
            T res = value;

            // iterate within a key group
            while ((value = input.next()) != null) {
               if (comparator.equalToReference(value)) {
                  // same group, reduce
                  res = function.reduce(res, value);
               } else {
                  // new key group
                  break;
               }
            }

            output.collect(res); //發送數據
         }
      }
   }
}

8.1.2 Partition

最後發送給哪個下游,是由OutputEmitter.selectChannel決定的。有如下幾種決定方式:

hash-partitioning, broadcasting, round-robin, custom partition functions。這裏採用的是PARTITION_HASH。

每個task都會把同樣字符串統計結果發送給同樣的下游ReduceDriver。這就保證了下游Reducer一定不會出現統計出錯。

public final int selectChannel(SerializationDelegate<T> record) {
   switch (strategy) {
   ...
   case PARTITION_HASH:
      return hashPartitionDefault(record.getInstance(), numberOfChannels);
   ...
   }
}

private int hashPartitionDefault(T record, int numberOfChannels) {
	int hash = this.comparator.hash(record);
	return MathUtils.murmurHash(hash) % numberOfChannels;
}

具體調用棧:

hash:50, TupleComparator (org.apache.flink.api.java.typeutils.runtime)
hash:30, TupleComparator (org.apache.flink.api.java.typeutils.runtime)
hashPartitionDefault:187, OutputEmitter (org.apache.flink.runtime.operators.shipping)
selectChannel:147, OutputEmitter (org.apache.flink.runtime.operators.shipping)
selectChannel:36, OutputEmitter (org.apache.flink.runtime.operators.shipping)
emit:60, ChannelSelectorRecordWriter (org.apache.flink.runtime.io.network.api.writer)
collect:65, OutputCollector (org.apache.flink.runtime.operators.shipping)
collect:35, CountingCollector (org.apache.flink.runtime.operators.util.metrics)
sortAndCombine:254, ChainedReduceCombineDriver (org.apache.flink.runtime.operators.chaining)
close:266, ChainedReduceCombineDriver (org.apache.flink.runtime.operators.chaining)
close:40, CountingCollector (org.apache.flink.runtime.operators.util.metrics)
close:88, ChainedFlatMapDriver (org.apache.flink.runtime.operators.chaining)
invoke:215, DataSourceTask (org.apache.flink.runtime.operators)
doRun:707, Task (org.apache.flink.runtime.taskmanager)
run:532, Task (org.apache.flink.runtime.taskmanager)
run:748, Thread (java.lang)

8.2 UnilateralSortMerger

這裡是第二次排序

在 BatchTask中,會先Sort, Merge輸入,然後才會交由Reduce來具體完成過。sort & merge操作具體是在UnilateralSortMerger類中完成的。

getIterator:646, UnilateralSortMerger (org.apache.flink.runtime.operators.sort)
getInput:1110, BatchTask (org.apache.flink.runtime.operators)
prepare:95, ReduceDriver (org.apache.flink.runtime.operators)
run:474, BatchTask (org.apache.flink.runtime.operators)
invoke:369, BatchTask (org.apache.flink.runtime.operators)
doRun:707, Task (org.apache.flink.runtime.taskmanager)
run:532, Task (org.apache.flink.runtime.taskmanager)
run:748, Thread (java.lang)

UnilateralSortMerger是一個full fledged sorter,它實現了一個多路merge sort。其內部的邏輯被劃分到三個線程上(read, sort, spill),這三個線程彼此之間通過一系列blocking queues來構成了一個閉環。

其內存通過MemoryManager分配,所以這個組件不會超過給其分配的內存。

該類主要變量摘錄如下:

public class UnilateralSortMerger<E> implements Sorter<E> {
	// ------------------------------------------------------------------------
	//                                  Threads
	// ------------------------------------------------------------------------

	/** The thread that reads the input channels into buffers and passes them on to the merger. */
	private final ThreadBase<E> readThread;

	/** The thread that merges the buffer handed from the reading thread. */
	private final ThreadBase<E> sortThread;

	/** The thread that handles spilling to secondary storage. */
	private final ThreadBase<E> spillThread;
	
	// ------------------------------------------------------------------------
	//                                   Memory
	// ------------------------------------------------------------------------
	
	/** The memory segments used first for sorting and later for reading/pre-fetching
	 * during the external merge. */
	protected final List<MemorySegment> sortReadMemory;
	
	/** The memory segments used to stage data to be written. */
	protected final List<MemorySegment> writeMemory;
	
	/** The memory manager through which memory is allocated and released. */
	protected final MemoryManager memoryManager;
	
	// ------------------------------------------------------------------------
	//                            Miscellaneous Fields
	// ------------------------------------------------------------------------
	/**
	 * Collection of all currently open channels, to be closed and deleted during cleanup.
	 */
	private final HashSet<FileIOChannel> openChannels;
	
	/**
	 * The monitor which guards the iterator field.
	 */
	protected final Object iteratorLock = new Object();
	
	/**
	 * The iterator to be returned by the sort-merger. This variable is null, while receiving and merging is still in
	 * progress and it will be set once we have &lt; merge factor sorted sub-streams that will then be streamed sorted.
	 */
	protected volatile MutableObjectIterator<E> iterator; 	// 如果大家經常調試,就會發現driver中的input都是這個兄弟。

	private final Collection<InMemorySorter<?>> inMemorySorters;
}

8.2.1 三種線程

ReadingThread:這種線程持續讀取輸入,然後把數據放入到一個待排序的buffer中。The thread that consumes the input data and puts it into a buffer that will be sorted.

SortingThread : 這種線程對於上游填充好的buffer進行排序。The thread that sorts filled buffers.

SpillingThread:這種線程進行歸併操作。The thread that handles the spilling of intermediate results and sets up the merging. It also merges the channels until sufficiently few channels remain to perform the final streamed merge.

8.2.2 MutableObjectIterator

UnilateralSortMerger有一個特殊變量:

protected volatile MutableObjectIterator<E> iterator;

這個變量就是最終sort-merger的輸出。如果大家調試過算子,就會發現這個變量就是具體算子的輸入input類型。最終算子的輸入就是來自於此。

8.3 ReduceDriver

這裡是第三次排序,我們可以看出來reduce是怎麼和groupby一起運作的。

  1. 針對 .groupBy(0),ReduceDriver就是單純獲取輸入的第一個數值 T value = input.next();
  2. 後續代碼中有嵌套的兩個while,分別是 :遍歷各種key,以及某一key中reduce。
  3. 遍歷 group keys的時候,把value賦於比較算子comparator(這個算子概念不是Flink算子,就是為了說明邏輯概念) comparator.setReference(value); 因為groubBy只是指定按照第一個位置比較,沒有指定具體key數值,所以這個value就是key了。此處記為while (1) ,代碼中有註解。
  4. 從輸入中讀取後續的數值value,如果下一個數值是同一個key,就reduce;如果下一個數值不是同一個key,就跳出循環。放棄比較,把reduce結果輸出。此處記為 while (2)
  5. 跳出 while (2) 之後,代碼依然在 while (1) ,此時value是新值,所以繼續在 while (1)中運行 。把value繼續賦於比較算子 comparator.setReference(value);,於是進行新的key比較
public class ReduceDriver<T> implements Driver<ReduceFunction<T>, T> {
	@Override
	public void run() throws Exception {

		final Counter numRecordsIn = this.taskContext.getMetricGroup().getIOMetricGroup().getNumRecordsInCounter();
		final Counter numRecordsOut = this.taskContext.getMetricGroup().getIOMetricGroup().getNumRecordsOutCounter();

		// cache references on the stack
		final MutableObjectIterator<T> input = this.input;
		final TypeSerializer<T> serializer = this.serializer;
		final TypeComparator<T> comparator = this.comparator;		
		final ReduceFunction<T> function = this.taskContext.getStub();		
		final Collector<T> output = new CountingCollector<>(this.taskContext.getOutputCollector(), numRecordsOut);

		if (objectReuseEnabled) {
      ......
		} else {
      // 針對 `.groupBy(0)`,ReduceDriver就是單純獲取輸入的第一個數值 `T value = input.next();`
			T value = input.next();

      // while (1)
			// iterate over key groups
			while (this.running && value != null) {
				numRecordsIn.inc();
        // 把value賦於比較算子,這個value就是key了。
				comparator.setReference(value);
				T res = value;

        // while (2)
				// iterate within a key group,循環比較這個key
				while ((value = input.next()) != null) {
					numRecordsIn.inc();
					if (comparator.equalToReference(value)) {
						// same group, reduce,如果下一個數值是同一個key,就reduce
						res = function.reduce(res, value);
					} else {
						// new key group,如果下一個數值不是同一個key,就跳出循環,放棄比較。
						break;
					}
				}
        // 把reduce結果輸出
				output.collect(res);
			}
		}
	}  
}

0x09 參考

mapreduce里的shuffle 里的 sort merge 和combine

實戰錄 | Hadoop Mapreduce shuffle之Combine探討

Hadoop中MapReduce中combine、partition、shuffle的作用是什麼?在程序中怎麼運用?

Flink運行時之生成作業圖

mapreduce過程

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

神仙也難救! Segway 7月15日停產

摘錄自2020年6月24日自由財經報導

曾經風靡一時、被視為會改變人類社會的創新科技Segway(賽格威)電動平衡車,將於今年7月15日起終止開發。

根據統計,在Segway推出近20年期間,總共只賣出14萬台,產品大多被用作安全人員的巡邏和遊客遊覽的代步工具。

因 Segway的設計獨特,使它看起來極具科技感,各國交通監理單位卻無法給予它明確定位。在美國有將近一半的地區,禁止Segway行駛於人行道上;在歐洲則被視為動力車輛,許多國家禁止它在公共道路上行駛。台灣對於 Segway則沒有分類,但基本上是不允許在道路上行駛。

生活環境
能源轉型
國際新聞
電動概念車
交通運輸

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

網頁設計最專業,超強功能平台可客製化

※回頭車貨運收費標準