① rsyslog收集日誌怎麼傳輸給elasticsearch
nput {
file {
path => "/yang/apache-tomcat-7.0.55/logs/*" //收集tomcat/logs/目錄下所有文件
start_position => end //從文件結尾處收集
}
}
filter {
if ([message] =~ "^debug") { //過濾掉debug開頭的信息
drop {} //過濾的信息丟棄掉
}
}
output {
stdout { codec => json}
elasticsearch { hosts =>["} //將日誌信息輸出
Elasticsearch
}
就是這么簡單，不過還有很多細節沒有搞定
② Redhat7怎麼開始日誌服務
日誌管理
/var/log
常用的系統日誌如下:
核心啟動日誌:/var/log/dmesg
系統報錯或重啟服務等日誌:/var/log/messages
郵件系統日誌:/var/log/maillog
cron(定製任務日誌)日誌:/var/log/cron #計劃日誌執行成功與否，在這個文件中看
var/log/secure #驗證系統用戶登錄
文件 /var/log/wtmp 記錄所有的登入和登出
[root@xuegod60 log]# > /var/log/wtmp
[root@xuegod60 log]# last
wtmp begins Mon Feb 29 21:38:36 2016
文件 /var/log/lastlog 記錄每個用戶最後的登入信息。
[root@xuegod60 ~]# lastlog
Username Port From Latest
root pts/0 192.168.1.100 Mon Feb 29 20:29:57 +0800 2016
文件 /var/log/btmp 記錄錯誤的登入嘗試。
測試：
[root@xuegod61 ~]# ssh [email protected]
故意輸錯密碼
[root@xuegod60 ~]# lastb
root ssh:notty 192.168.1.61 Mon Feb 29 21:43 - 21:43 (00:00)
[root@xuegod60 ~]# ll -h /var/log/btmp
-rw-------. 1 root utmp 768 Feb 29 21:43 /var/log/btmp
#如果btmp文件特別大，說明有人在暴力破解你的伺服器
日誌的記錄方式：先分類，然後每個類中再分級別
主要7種日誌分類(FACILITY):
authpriv 安全認證相關
cron at和cron定時相關
daemon 後台進程相關
kern 內核產生
lpr 列印系統產生
mail 郵件系統相關
syslog 日誌服務本身
news 新聞系統 （和BBS差不多，新聞組）
uucp uucp系統產生 。Unix-to-Unix Copy(UNIX至UNIX的拷貝)，Unix系統的一項功能，允許計算機之間以存儲-轉發方式交換e-mail和消息。在Internet興起之前是Unix系統之間連網的主要方式。
local0到local7 #共8個類型，系統保留的：8個系統日誌類型，給其它程序使用。或用戶自定義用
8個日誌級別：以下排列，由輕到重
級別(PRIOROTY):
debug 排錯信息。開發人
info 正常信息
notice 稍微要注意的
warn 警告
err(error) 錯誤
crit(critical) 關鍵的錯誤
alert 警報警惕
emerg(emergency) 緊急，突發事件
日誌服務：
1).rhel5：
服務名稱：syslog
配置文件：
#vim /etc/syslog.conf
2) .RHEL6/7:rsyslog
配置文件：
#vim /etc/rsyslog.conf
進入配置文件顯示內容如下：
1. kern.* 內核類型的所級別日誌
2 *.info;mail.none;news.none;authpriv.none;cron.none：由於 mail, news, authpriv, cron 等類別產生的訊息較多，因此在 /var/log/messages 裡面不記錄這些項目。除此其他訊息都寫入 /var/log/messages 中。所以messages 文件很重要
3. authpriv.* 認證方面的訊息均寫入 /var/log/secure 檔案；
4. mail.*：郵件方面的訊息則均寫入 /var/log/maillog 檔案；
5. cron.*：例行性工作排程均寫入 /var/log/cron 檔案；
6. local7.*：將本機開機時應該顯示到屏幕的訊息寫入到 /var/log/boot.log 檔案中；
/etc/rsyslog.conf 中日誌輸入規則：
例：
. ：代表『比後面還要高的等級都被記錄下來』的意思，
例如： mail.info 代表只要是 mail 類型的信息，而且該信息等級高於 info (包括 info 本身)時，就會被記錄下來的意思。
.= ：代表所需要的等級就是後面接的等級而已， 其他的都不要！
.! ：代表不等於， 亦即是除了該等級外的其他等級都記錄。
舉例：
cron.none 對於cron類型日誌不記錄任何信息
cron.=err 對於cron類型日誌只記錄err級別的信息
cron.err 對於cron類型日誌記錄大於err級別的信息
cron.!err 對於cron類型日誌不記錄err級別的信息，其他級別都記錄。
擴展
wall命令介紹：
wall -- send a message to everybody』s terminal.
[root@xuegod60 ~]# wall Today is nice day
Broadcast message from [email protected] (pts/0) (Mon Feb 29 22:01:30 2016):
Today is nice day
[root@xuegod60 ~]# vim /etc/rsyslog.conf
mail.* -/var/log/maillog
在上面的第四行關於 mail 的記錄中，在記錄的檔案 /var/log/maillog 前面還有個減號『 - 』是幹嘛用的？
由於郵件所產生的訊息比較多，因此我們希望郵件產生的訊息先儲存在速度較快的內存中 (buffer) ，等到數據量夠大了才一次性的將所有數據都填入磁碟內，這樣將有利於減少對磁碟讀寫的次數，減少IO讀寫開銷。另外，由於訊息是暫存在內存內，因此若不正常關機導致登錄信息未寫入到文檔中，可能會造成部分數據的遺失。
自定義sshd服務的日誌
[root@xuegod60 ~]# vim /etc/rsyslog.conf
local0.* /var/log/sshd.log
[root@xuegod60 ~]# systemctl restart rsyslog
定義sshd遠程服務日誌的類別
[root@xuegod60 ~]# vim /etc/ssh/sshd_config
#SyslogFacility AUTHPRIV
SyslogFacility local0
[root@xuegod60 ~]# systemctl restart sshd
[root@xuegod60 ~]# ls /var/log/sshd.log
/var/log/sshd.log
[root@xuegod60 ~]# cat !$
cat /var/log/sshd.log
Feb 29 22:11:19 xuegod60 sshd[41268]: Received signal 15; terminating.
Feb 29 22:11:19 xuegod60 sshd[41525]: Server listening on 0.0.0.0 port 22.
Feb 29 22:11:19 xuegod60 sshd[41525]: Server listening on :: port 22.
日誌查看方式
時間 主機 進程ID 描述信息
如何防止日誌被黑客刪除呢？
[root@xuegod60 ~]# chattr +a /var/log/sshd.log
[root@xuegod60 ~]# lsattr /var/log/sshd.log
-----a---------- /var/log/sshd.log
加入了這個屬性後，你的 /var/log/messages 登錄檔從此就僅能被增加，而不能被刪除，直到 root 以『 chattr -a /var/log/messages 』取消這個 a 的參數後，才能被刪除移！
日誌回滾：
[root@xuegod60 ~]# vim /etc/logrotate.conf
weekly <==預設每個禮拜對日誌檔進行一次 rotate 的工作
rotate 4 <==保留幾個日誌文檔呢？預設是保留四個！
create <== 回滾日誌後，創建一個新的空文件來存儲新的數據。
/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}
說明：
/var/log/wtmp { <==僅針對 /var/log/wtmp 所設定的參數
monthly <==每個月一次，取代每周！
minsize 1M <==檔案容量一定要超過 1M 後才進行 rotate (略過時間參數)
create 0664 root utmp <==設定新建文件的許可權 、所有者、用戶組
rotate 1 <==僅保留一個，亦即僅有 wtmp.1 保留而已。 }
配置遠程日誌伺服器，實現日誌集中管理：
1. 配置SERVER端（接收端）： xuegod60服務端。 xuegod61做客戶端
服務端配置
[root@xuegod60 ~]# vim /etc/rsyslog.conf
改：
#$ModLoad imtcp
#$InputTCPServerRun 514
為：
$ModLoad imtcp
$InputTCPServerRun 514
重啟服務
[root@xuegod60 ~]# systemctl restart rsyslog
查看服務監聽狀態
[root@xuegod60 ~]# netstat -anput | grep 514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 42163/rsyslogd
tcp 0 64 192.168.1.60:22 192.168.1.100:51497 ESTABLISHED 2212/sshd:root@pts
tcp6 0 0 :::514 :::* LISTEN 42163/rsyslogd
2、配置CLIENT端（客戶端）
[root@xuegod61 ~]# vim /etc/rsyslog.conf
*.* @@192.168.1.60:514
[root@xuegod61 ~]# systemctl restart rsyslog
驗證：
服務端關閉防火牆
[root@xuegod60 ~]# systemctl stop firewalld
在服務端查看
[root@xuegod60 ~]# tail -f /var/log/messages
在客戶端
[root@xuegod61 ~]# systemctl restart NetworkManager
③ 怎樣規劃linux網路安全學習路線
先學習幾個常用的網路伺服器。
1.文件伺服器：samba2.FTP：vsftp3.DNS
4.網站伺服器：apache 5.郵件伺服器:sendmail
然後轉到防火牆牆iptables.
④ 如何在Linux上使用HAProxy配置HTTP負載均衡系統
TTP負載均衡簡介
HTTP負載均衡是一種網路解決方案，負責在託管相同應用內容的幾台伺服器之間分配進入的HTTP或HTTPS流量。由於在多台可用伺服器之間均衡了應用請求，負載均衡系統就能防止任何應用伺服器變成單一故障點，因而提高了整體的應用可用性和響應能力。它還讓你可以隨著不斷變化的工作負載，輕松地縮小/擴大部署的應用系統的規模，只需添加或刪除額外的應用伺服器。
哪裡使用負載均衡、何時使用？
由於負載均衡系統改進了伺服器的利用率，最大限度地提高了可用性，只要你的伺服器開始面臨繁重負載，或者正為一個較龐大的項目規劃架構，就應該使用它。事先規劃好負載均衡系統的用途是個好習慣。那樣，未來你需要擴展環境規模時，它會證明其用途。
HAProxy是什麼東東？
HAProxy是一種流行的開源負載均衡和代理系統，面向GNU/Linux平台上的TCP/HTTP伺服器。HAProxy採用了單一線程的事件驅動型架構而設計，它能夠輕松地處理10G網卡線路速度，現廣泛應用於許多生產環境中。其功能特性包括：自動檢查健康狀況、可定製的負載均衡演算法、支持HTTPS/SSL以及會話速率限制等。
我們在本教程中要達到什麼樣的目的？
在本教程中，我們將逐步介紹為HTTP網站伺服器配置基於HAProxy的負載均衡系統這個過程。
前提條件
你至少需要一台（最好是兩台）網站伺服器來證實所搭建負載均衡系統的功能。我們假設，後端HTTP網站伺服器已經搭建並運行起來。
將HAProxy安裝到Linux上
就大多數發行版而言，我們可以使用你所用發行版的軟體包管理器來安裝HAProxy。
將HAProxy安裝到Debian上
在Debian中，我們需要為Wheezy添加向後移植功能。為此，請在/etc/apt/sources.list.d中創建一個名為「backports.list」的新文件，其內容如下：
deb http://cdn.debian.net/debian wheezybackports main
更新你的軟體庫數據，並安裝HAProxy。
# apt get update
# apt get install haproxy
將HAProxy安裝到Ubuntu上
# apt get install haproxy
將HAProxy安裝到CentOS和RHEL上
# yum install haproxy
配置HAProxy
在本教程中，我們假設有兩台HTTP網站伺服器已搭建並運行起來，其IP地址分別為192.168.100.2和192.168.100.3。我們還假設，負載均衡系統將在IP地址為192.168.100.4的那台伺服器處進行配置。
為了讓HAProxy發揮功用，你需要更改/etc/haproxy/haproxy.cfg中的幾個項目。這些變更在本章節中予以描述。萬一某個配置對不同的GNU/Linux發行版而言有所不同，會在相應段落中加以註明。
1. 配置日誌功能
你首先要做的工作之一就是，為你的HAProxy建立合適的日誌功能，這對將來進行調試大有用處。日誌配置內容位於/etc/haproxy/haproxy.cfg的global部分。下面這些是針對特定發行版的指令，用於為HAProxy配置日誌。
CentOS或RHEL：
要想在CentOS/RHEL上啟用日誌功能，把：
log 127.0.0.1 local2
換成：
log 127.0.0.1 local0
下一步，在/var/log中為HAProxy創建單獨的日誌文件。為此，我們需要改動當前的rsyslog配置。為了讓配置簡單而清楚，我們將在/etc/rsyslog.d/中創建一個名為haproxy.conf的新文件，其內容如下。
$ModLoad imudp
$UDPServerRun 514
$template Haproxy,"%msg%\n"
local0.=info /var/log/haproxy.log;Haproxy
local0.notice /var/log/haproxystatus.log;Haproxy
local0.* ~
該配置將把基於$template的所有HAProxy消息隔離到/var/log中的日誌文件。現在，重啟rsyslog，讓變更內容生效。
# service rsyslog restart
Debian或Ubuntu：
要想在Debian或Ubuntu上為HAProxy啟用日誌功能，把：
log /dev/log local0
log /dev/log local1 notice
換成：
log 127.0.0.1 local0
下一步，為HAProxy配置單獨的日誌文件，編輯/etc/rsyslog.d/中一個名為haproxy.conf的文件（或者Debian中的49-haproxy.conf），其內容如下。
$ModLoad imudp
$UDPServerRun 514
$template Haproxy,"%msg%\n"
local0.=info /var/log/haproxy.log;Haproxy
local0.notice /var/log/haproxystatus.log;Haproxy
local0.* ~
該配置將把基於$template的所有HAProxy消息隔離到/var/log中的日誌文件。現在，重啟rsyslog，讓變更內容生效。
# service rsyslog restart
2. 設置默認值
下一步是為HAProxy設置默認變數。找到/etc/haproxy/haproxy.cfg中的defaults部分，把它換成下列配置。
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 20000
contimeout 5000
clitimeout 50000
srvtimeout 50000
上述配置推薦HTTP負載均衡器使用，但可能不是最適合你環境的解決方案。如果那樣，請參閱HAProxy參考手冊頁，進行適當的改動和調整。
3. 網站伺服器集群的配置
網站伺服器集群（Webfarm）的配置定義了可用的HTTP伺服器集群。我們所建負載均衡系統的大部分設置都將放在這里。現在，我們將創建一些基本的配置，我們的節點將在這里加以定義。把從frontend部分到文件末尾的所有配置換成下列代碼：
listen webfarm *:80
mode http
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
balance roundrobin
cookie LBN insert indirect nocache
option httpclose
option forwardfor
server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check
「listen webfarm *:80」這一行定義了我們的負載均衡系統將偵聽哪些介面。出於本教程的需要，我將該值設為「*」，這讓負載均衡系統偵聽我們的所有介面。在實際場景下，這可能不合意，應該換成可從互聯網來訪問的某個介面。
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
上述設置聲明，可以在http://<load-balancer-IP>/haproxy?stats處訪問負載均衡系統的統計數字。這種訪問由簡單的HTTP驗證以及登錄名「haproxy」和密碼「stats」來確保安全。這些設置應該換成你自己的登錄信息。如果你不想讓這些統計數字被人看到，那麼可以完全禁用它們。
下面是HAProxy統計數字的一個例子。
「balance roundrobin」這一行定義了我們將使用哪種類型的負載均衡。在本教程中，我們將使用簡單的輪叫調度演算法，這對HTTP負載均衡來說完全綽綽有餘。HAProxy還提供了其他類型的負載均衡：
•leastconn：連接數最少的伺服器優先接收連接。
•source：對源IP地址進行哈希處理，用運行中伺服器的總權重除以哈希值，即可決定哪台伺服器將接收請求。
•uri：URI的左邊部分（問號前面）經哈希處理，用運行中伺服器的總權重除以哈希值。所得結果決定哪台伺服器將接收請求。
•url_param：變數中指定的URL參數將在每個HTTP GET請求的查詢串中進行查詢。你基本上可以將使用蓄意製作的URL（crafted URL）的請求鎖定於特定的負載均衡節點。
•hdr(name)：HTTP頭<name> 將在每個HTTP請求中進行查詢，被定向到特定節點。
「cookie LBN insert indirect nocache」這一行讓我們的負載均衡系統存儲持久性cookie，這讓我們得以准確查明集群中的哪個節點用於某一個會話。這些節點cookie將與指定的名稱一並存儲起來。在我們這個例子中，我使用了「LBN」，但你可以指定自己喜歡的任意名稱。節點將為該cookie把字元串作為一個值而存儲起來。
server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check
上述部分對網站伺服器節點集群進行了定義。每台伺服器都用內部名稱（比如web01和web02）、IP地址和獨特的cookie串來表示。cookie串可以定義為你需要的任何名稱。我使用了簡單的node1、node2 ... node(n)。
啟動HAProxy
你完成了配置工作後，可以啟動HAProxy，驗證一切按預期運行。
在Centos/RHEL上啟動HAProxy
使用下列指令，讓HAProxy能夠在系統啟動後啟動，並打開它：
# chkconfig haproxy on
# service haproxy start
當然，別忘了啟用防火牆中的埠80，如下所示。
CentOS/RHEL 7上的防火牆：
# firewallcmd permanent zone=public addport=80/tcp
# firewallcmd reload
CentOS/RHEL 6上的防火牆：
把下面這一行添加到/etc/sysconfig/iptables中的這部分「:OUTPUT ACCEPT」：
A INPUT m state state NEW m tcp p tcp dport 80 j ACCEPT
然後重啟iptables：
# service iptables restart
在Debian上啟動HAProxy
使用下列指令啟動HAProxy：
# service haproxy start
別忘了啟用防火牆中的埠80，為此把下面這一行添加到/etc/iptables.up.rules：
A INPUT p tcp dport 80 j ACCEPT
在Ubuntu上啟動HAProxy
讓HAProxy能夠在系統啟動後啟動，只要在/etc/default/haproxy中將「ENABLED」選項設為「1」：
ENABLED=1
啟動HAProxy：
# service haproxy start
然後啟用防火牆中的埠80：
# ufw allow 80
測試HAProxy
為了檢查HAproxy是否在正常工作，我們可以執行下列步驟：
首先，用下列內容准備好test.php文件：
<?php
header('Content-Type: text/plain');
echo "Server IP: ".$_SERVER['SERVER_ADDR'];
echo "\nX-Forwarded-for: ".$_SERVER['HTTP_X_FORWARDED_FOR'];
?>
該PHP文件將告訴我們哪台伺服器（即負載均衡系統）轉發請求，哪台後端網站伺服器實際處理請求。
把該PHP文件放到這兩台後端網站伺服器的根目錄下。現在，使用curl命令，從負載均衡系統（192.168.100.4）提取這個PHP文件。
$ curl http://192.168.100.4/test.php
我們多次運行這個命令時，應該會看到下面兩個輸出交替出現（由於輪叫調度演算法）。
Server IP: 192.168.100.2
X-Forwarded-for: 192.168.100.4
Server IP: 192.168.100.3
X-Forwarded-for: 192.168.100.4
如果我們停止這兩台後端網站伺服器中的其中一台，curl命令應該仍會執行，將請求定向到另一台可用的網站伺服器。
結束語
至此，你應該有了一套完全實用的負載均衡系統，能夠在輪叫循環模式下為你的網站節點提供請求。與往常一樣，你可以隨意更改配置，讓它更適合自己的基礎設施。希望本教程幫助你讓自己的網站項目具有更強的抗壓力和更高的可用性。
正如大家已經注意到的那樣，本教程所含的設置適用於僅僅一套負載均衡系統。這意味著，我們把一個單一故障點換成了另一個單一故障點。在實際場景下，你應該部署至少兩套或三套負載均衡系統，以防範可能出現的任何故障，但這不在本教程的討論范圍之內。
⑤ 如何使用rsyslog收集docker日誌
由於開發的原因沒有採用他的方法方法：修改log4j.properties
文件，將日誌修改為
syslog
的類型。
這個方法沒有親測過，如果後面還是不能轉發
非syslog的話，可能會先嘗試測試一下。
⑥ 技術面試會問很多技術問題嗎
筆者其實沒有想到去面試，只是在智聯上更新了一下簡歷，就陸陸續續接到很多獵頭的郵件和電話，實在是沒准備好要去面試，就推掉了幾家公司的面試了。正因為筆者也很久沒有面試了，筆者也想去面試學習一下，閑話少說，下面就分享給大家筆者在2018年1月4號上午10點30分的面試經歷：
首先，獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱（或者QQ、微信），下面這份是獵頭發給我的崗位說明，為了職業道德操守，公司的介紹和面試通知信息我就不貼出來了，我就把崗位要求貼出來：
職位描述：
1、 負責應用伺服器的安裝、配置、優化與維護；
2、 負責應用系統的日誌信息備份、管理、維護與分析；
3、 負責應用系統的日常監測於維護、故障處理、性能分析與優化；
4、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護，建設高性能的運維平台。
崗位要求:
1、 熟悉Linux操作系統的基礎知識，熟練使用Linux常用操作命令；
2、 熟練配置Nginx、HAproxy 等應用相關軟體的部署、配置與優化維護；
3、 熟悉網路基礎知識、熟悉TCP/IP的工作原理，會配交換機或路由器，能熟練的對網路情況進行分析
4、 熟悉shell/perl/python中的一種或多種進行運維程序的開發；
5、 熟悉Nagios,Ganglia等監控軟體
看著上面的要求大家是不是覺得要求也不高啊，你要細看就會發現，這家公司要求的還挺多，不僅要會網路知識（熟悉TCP/IP好像是每家單位的都會寫這樣的要求），還要會開發技能。相信很多做運維的兄弟在網路這一塊是個頭疼的事情，都對交換機和路由器不怎麼會配置和管理。
然後，筆者詳細了解他們公司，了解崗位要求，在突擊復習一下可能會問到的知識點和技術點。到了面試的這天時間，早早的起床，把牙一定要刷干凈，特別是有口臭的兄弟，最好准備點口香糖，到達面試公司前嚼塊口香糖，以免因為口氣的原因熏到面試官，讓你在面試官心裡減分。早點要記得吃，如果你是下午面試的話也要吃午飯，吃早點了精氣神就有了。還要注意，帶上你的簡歷和一支筆，雖然他們那邊也會有你的簡歷，為了以防萬一還是准備好簡歷。
最後，關鍵點來了，就是和面試官溝通了，有筆試的公司會讓你做些面試題，沒有筆試就直接和面試官聊了，下面是我和面試官溝通完之後記住的一些問題，分享給大家看一下，筆者一共記住了7個問題，好像還有兩個問題實在想不起來了，如果大家有更恰當的回答一定要貼出來一起探討和進步：
1、介紹下自己？（幾乎每家公司首先都會讓你做個自我介紹，好像是必修課一樣）
筆者回答：此處省略筆者的自我介紹，筆者建議介紹自己的時間不宜過長，3-4分鍾為宜，說多了面試官會覺得你太啰嗦了。說太少了也不行，那樣會讓人感覺你的經歷太簡單了、太空了。正常情況下，一般你在做自我介紹的同時，面試官這個時候在看你的簡歷，他需要一邊看簡歷、一邊聽你介紹自己，如果你說個幾句話就把自己介紹完了，他肯定還沒緩過神來，對你的映像會減分的。在介紹的同時思維要清晰，邏輯要清楚，最好是根據你簡歷上寫的經歷來介紹，這樣可以把面試官的思路帶到你這里來，讓他思路跟著你走。不要東扯一句，西扯一句。竟量少介紹自己的性格、愛好（最好能不說就不說），你可以簡單羅列干過幾家公司（最多羅列3家公司/也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什麼工作，都用過什麼技術，在著重介紹一下你目前所在的公司是負責哪些工作的，可以稍微詳細一點介紹，不要讓面試官聽著暈頭轉向的感覺。
2、灰度發布如何實現？
筆者回答：其實對這個問題筆者也答的不好，就不寫出來誤導大家了。大家有好的方法可以共享出來。不過筆事後在知呼上看到了一位網友的建議覺得不錯，大家可以參考看一下 ：https://www.hu.com/question/20584476
3、Mongodb熟悉嗎，一般部署幾台？
筆者回答：部署過，沒有深入研究過，一般mongodb部署主從、或者mongodb分片集群；建議3台或5台伺服器來部署。MongoDB分片的基本思想就是將集合切分成小塊。這些塊分散到若乾片裡面，每個片只負責總數據的一部分。 對於客戶端來說，無需知道數據被拆分了，也無需知道服務端哪個分片對應哪些數據。數據在分片之前需要運行一個路由進程，進程名為mongos。這個路由器知道所有數據的存放位置，知道數據和片的對應關系。對客戶端來說，它僅知道連接了一個普通的mongod，在請求數據的過程中，通過路由器上的數據和片的對應關系，路由到目標數據所在的片上，如果請求有了回應，路由器將其收集起來回送給客戶端。
4、如何發布和回滾，用jenkins又是怎麼實現？
筆者回答：發布：jenkins配置好代碼路徑（SVN或GIT），然後拉代碼，打tag。需要編譯就編譯，編譯之後推送到發布伺服器（jenkins裡面可以調腳本），然後從分發伺服器往下分發到業務伺服器上。
回滾：按照版本號到發布伺服器找到對應的版本推送
5、Tomcat工作模式？
筆者回答：Tomcat是一個JSP/Servlet容器。其作為Servlet容器，有三種工作模式：獨立的Servlet容器、進程內的Servlet容器和進程外的Servlet容器。
進入Tomcat的請求可以根據Tomcat的工作模式分為如下兩類：
Tomcat作為應用程序伺服器：請求來自於前端的web伺服器，這可能是Apache, IIS, Nginx等；
Tomcat作為獨立伺服器：請求來自於web瀏覽器；
6、監控用什麼實現的？
筆者回答：現在公司的業務都跑在阿里雲上，我們首選的監控就是用阿里雲監控，阿里雲監控自帶了ECS、RDS等服務的監控模板，可結合自定義報警規則來觸發監控項。上家公司的業務是託管在IDC，用的是zabbix監控方案，zabbix圖形界面豐富，也自帶很多監控模板，特別是多個分區、多個網卡等自動發現並進行監控做得非常不錯，不過需要在每台客戶機（被監控端）安裝zabbix agent。
7、你是怎麼備份數據的，包括資料庫備份？
筆者回答：在生產環境下，不管是應用數據、還是資料庫數據首先在部署的時候就會有主從架構、或者集群，這本身就是屬於數據的熱備份；其實考慮冷備份，用專門一台伺服器做為備份伺服器，比如可以用rsync+inotify配合計劃任務來實現數據的冷備份，如果是發版的包備份，正常情況下有台發布伺服器，每次發版都會保存好發版的包。
總結
總結一下面試注意幾點事項，可能筆者也說得不太對，為了我們運維工作的兄弟們都能拿到高薪，大家一定要指證出來一起進步、一起探討：
第一，你要對自己的簡歷很熟悉，簡歷上的寫的技能自己一定要能說出個一二，因為面試官的很多問題都會挑你簡歷上寫的問。比如你簡歷上寫了這么一條技能「熟悉mysql資料庫的部署安裝及原理」。你即然寫了這么一條技能，你在怎麼不熟悉你也要了解mysql的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他心裡你又減分了，基本上這次面試希望不大。
第二，如果面試官問到你不會的問題，你就說這個不太熟悉，沒有具體研究過，千萬別不懂裝懂，還扯一堆沒用的話題來掩飾，這樣只會讓面試官反感你。
第三，准備充分，竟可能多的記住原理性的知識，一般面試問的多的就是原理。很少問具體的配置文件是怎麼配置的。面試前也要了解清楚「職位描述」和「崗位要求」，雖然有時候大多數不會問到崗位要求的問題，但也要了解和熟悉。
第四，面試完後一定要總結，盡量記住面試官問的每一個問題，回去記錄下來，如果問到不會的問題，事後要立馬查網路或者找朋友搞清楚、弄明白，這樣你才能記勞，下次面試說不定又問到同樣的問題。
問完之後，面試官就跟我聊薪資待遇了，問我多少錢能達到自己的要求，我就不便透露了，可以私聊，哈哈，後續筆者會陸陸續續更新以前面試的經歷和問題，有需要的朋友可以轉載或者收藏起來一起討論。
基於大家熱情高昂的氣氛，筆者又花了一個下午的時間回憶並整理在2017年2月24號筆者在東三環邊上（快到東四環了，沒有地鐵過去，到了四惠還要轉公交車）的一家傳媒公司的面試經歷，還好筆者有做筆記的習慣，把之前面試的問題都記錄在案，這一次的面試筆者可是記憶猶新，因為這次這家公司都跟筆者發offer了，實在是真心不想去這家公司就找原因推掉了，大家可別學我這么不靠譜。下面是這家公司中的崗位要求說明：
崗位職責：
1、負責公司產品的版本控制、構建和發布管理；
2、負責公司統一配置庫管理工作，許可權管理與分配准確及時，定期完成配置備份；
3、負責公司內部開發/測試伺服器的運行管理工作；
4、負責Linux操作系統的安裝、配置、監控和維護、問題處理、軟體升級、 數據備份、應急響應、故障排除等、保證線上環境的穩定運行；
5、負責支撐平台24×7穩定運行，並進行前瞻性容量規劃；
6、負責公司機房伺服器日常維護及網路系統安裝、部署、維護工作。
崗位要求：
1、計算機相關專業本科及以上學歷，2年以上運維或配置管理工作經驗；
2、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
3、至少熟悉一種集群管理工具，如Ansible/SaltStack等；
4、有使用集成發布工具發布構建經驗優先。比如：bamboo或者Jenkins；
5、熟悉Unix/Linux操作系統，熟悉Weblogic/tomcat等中間件，能夠編寫shell腳本，熟悉軟體開發過程及過程產品，有一定的網路基礎；
6、熟悉rsyslog, flume等日誌收集和處理系統；
7、具有強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合作精神，工作積極主動。
過去之後，前台美眉把我帶到他們公司的地下室，我掃視了一下周圍的環境，貌似旁邊就是機房，因為我聽到伺服器的聲音。等了幾分鍾，面試官下來了，面試官目測比較瘦，看著跟我身材差不多（應該不到120），他說他是負責運維部的，然後開始就叫我先自我介紹，都是一個套路，免不了介紹的，所以兄弟們一定要把自我介紹練好。然後開始問我問題了，跟面試官聊得還行，問我應該有不下10個以上的問題，我記住了下面有10個問題：
1、LVS負載的原理，和Nginx負載有啥區別？
筆者回答：這個問題我覺得面試官司沒問好，正常都會這么問「LVS有哪些負載均衡技術和調度演算法?"。我回答就是按我說的這種問法回答的，反正他也頻繁點頭，當然，筆者回答的可能沒有下面我整理出來的那麼詳細，大概意思我都說明白了。
LVS是Liunx虛擬伺服器的簡稱，利用LVS提供的負載均衡技術和linux操作系統可實現高性能、高可用的伺服器集群，一般LVS都是位於整個集群系統的最前端，由一台或者多台負載調度器（Director Server）組成，分發給應用伺服器（Real Server）。它是工作在4層（也就是TCP/IP中的傳輸層），LVS是基於IP負載均衡技術的IPVS模塊來實現的，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR，詳述如下：
VS/NAT： 即（Virtual Server via Network Address Translation）
也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，最後將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。
可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。
VS/TUN ：即（Virtual Server via IP Tunneling）
也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。
VS/DR： 即（Virtual Server via Direct Routing）
也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。
回答負載調度演算法，IPVS實現在八種負載調度演算法，我們常用的有四種調度演算法（輪叫調度、加權輪叫調度、最少鏈接調度、加權最少鏈接調度）。一般說了這四種就夠了，也不會需要你詳細解釋這四種演算法的。你只要把上面3種負載均衡技術講明白面試官就對這道問題很滿意了。接下來你在簡單說下與nginx的區別：
LVS的優點：
抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
應用范圍比較廣，可以對所有應用做負載均衡；
配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率。
LVS的缺點：
軟體本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。
如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單一點
Nginx的優點：
工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；
Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；
Nginx安裝和配置比較簡單，測試起來比較方便；
可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的並發量；
Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點；
Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高並發方面相對apache有優勢；
Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；
Nginx的缺點：
Nginx不支持url來檢測。
Nginx僅能支持http和Email，這個它的弱勢。
Nginx的Session的保持，Cookie的引導能力相對欠缺。
2、redis集群的原理，redis分片是怎麼實現的，你們公司redis用在了哪些環境？
筆者回答：reids集群原理：
其實它的原理不是三兩句話能說明白的，redis 3.0版本之前是不支持集群的，官方推薦最大的節點數量為1000，至少需要3(Master)+3(Slave)才能建立集群，是無中心的分布式存儲架構，可以在多個節點之間進行數據共享，解決了Redis高可用、可擴展等問題。集群可以將數據自動切分(split)到多個節點，當集群中的某一個節點故障時，redis還可以繼續處理客戶端的請求。
redis分片：
分片(partitioning)就是將你的數據拆分到多個 Redis 實例的過程，這樣每個實例將只包含所有鍵的子集。當數據量大的時候,把數據分散存入多個資料庫中,減少單節點的連接壓力,實現海量數據存儲。分片部署方式一般分為以下三種：
（1）在客戶端做分片；這種方式在客戶端確定要連接的redis實例，然後直接訪問相應的redis實例；
（2）在代理中做分片；這種方式中，客戶端並不直接訪問redis實例，它也不知道自己要訪問的具體是哪個redis實例，而是由代理轉發請求和結果；其工作過程為：客戶端先將請求發送給代理，代理通過分片演算法確定要訪問的是哪個redis實例，然後將請求發送給相應的redis實例，redis實例將結果返回給代理，代理最後將結果返回給客戶端。
（3）在redis伺服器端做分片；這種方式被稱為「查詢路由」，在這種方式中客戶端隨機選擇一個redis實例發送請求，如果所請求的內容不再當前redis實例中它會負責將請求轉交給正確的redis實例，也有的實現中，redis實例不會轉發請求，而是將正確redis的信息發給客戶端，由客戶端再去向正確的redis實例發送請求。
redis用在了哪些環境：
java、php環境用到了redis，主要緩存有登錄用戶信息數據、設備詳情數據、會員簽到數據等
3、你會怎麼統計當前訪問的IP，並排序？
筆者回答：統計用戶的訪問IP，用awk結合uniq、sort過濾access.log日誌就能統計並排序好。一般這么回答就夠了，當然你還可以說出其它方式來統計，這都是你的加分項。
4、你會使用哪些虛擬化技術？
筆者回答：vmware vsphere及kvm，我用得比較多的是vmware vsphere虛擬化，幾本上生產環境都用的vmware vsphere，kvm我是用在測試環境中使用。vmware 是屬於原生架構虛擬化技術，也就是可直接在硬體上運行。kvm屬於寄居架構的虛擬化技術，它是依託在系統之上運行。vmware vcenter
管理上比較方便，圖形管理界面功能很強大，穩定性強，一般比較適合企業使用。KVM管理界面稍差點，需要管理人員花費點時間學習它的維護管理技術。
5、假如有人反應，調取後端介面時特別慢，你會如何排查？
筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這么說的：問清楚反應的人哪個服務應用或者頁面調取哪個介面慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網路載入、大圖片、還是某個文件內容等），如果有，就對症下葯去解決（圖片慢就優化圖片、網路慢就查看內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問介面日誌才會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。
6、mysql資料庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫無法讀取了、或者從庫讀取特別慢，你會如何解決？
筆者回答：這個問題筆者覺得回答的不太好，對mysql比較在行的朋友希望能給點建議。以解決問題為前提條件，先添加從庫數量，臨時把問題給解決，然後抓取slow log ，分析sql語句，該優化就優化處理。慢要不就是硬體跟不上，需要升級；要不就是軟體需要調試優化，等問題解決在細化。
7、cpu單核和多核有啥區別？
筆者回答：很少有面試官會問這樣的問題，即然問到了，也要老實回答。還好筆者之前了解過CPU，我是這么說的：雙核CPU就是能處理多份任務，順序排成隊列來處理。單核CPU一次處理一份任務，輪流處理每個程序任務。雙核的優勢不是頻率，而是對付同時處理多件事情。單核同時只能幹一件事，比如你同時在後台BT下載，前台一邊看電影一邊拷貝文件一邊QQ。
8、機械磁碟和固態硬碟有啥區別？
筆者回答：我擦，啥年代了，還問磁碟的問題，這面試官有點逗啊。那也要回答啊：
HDD代表機械硬碟，SSD代表固態硬碟。首先，從性能方面來說，固態硬碟幾乎完勝機械硬碟，固態硬碟的讀寫速度肯定要快機械硬碟，因為固態硬碟和機械硬碟的構造是完全不同的（具體的構造就沒必要解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場情況來看，一般機械盤容量大，價格低；固態盤容量小，價格偏高。但是企業還是首選固態盤。
9、說一下用過哪些監控系統？
筆者回答：這個監控的問題又問到了，筆者在2018年1月4號也被問到類似這樣的問題，筆者曾經用過zabbix、nagios、 cacit等。但是在這次面試中只說用過zabbix和nagios。說完了之後，面試官就讓我說一下這兩個監控有啥區別：
從web功能及畫圖來講：
Nagios簡單直觀，報警與數據都在同一頁面， 紅色即為問題項。Nagios web端不要做任何配置。 Nagios需要額外安裝插件，且插件畫圖不夠美觀。
Zabbix監控數據與報警是分開的，查看問題項需要看觸發器，查看數據在最新數據查看。而且zabbix有很多其它配置項， zabbix攜帶畫圖功能，且能手動把多個監控項集在一個圖中展示。
從監控服務來講：
Nagios自帶的監控項很少。對一些變動的如多個分區、多個網卡進行監控時需要手動配置。
Zabbix自帶了很多監控內容，感覺zabbix一開始就為你做了很多事，特別是對多個分區、多個網卡等自動發現並進行監控時，那一瞬間很驚喜，很省心的感覺。
從批量配置和報警來講：
Nagios對於批量監控主機，需要用腳本在server端新增host，並拷貝service文件。 Nagios用腳本來修改所有主機的services文件，加入新增服務。
Zabbix在server端配置自動注冊規則，配置好規則後，後續新增client端不需要對server端進行操作。 Zabbix只需手動在模板中新增一監控項即可。
總體來講：
Nagios要花很多時間寫插件，Zabbix要花很多時間探索功能。
Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。
Zabbix畫圖功能比Nagios更強大
Zabbix對於批量監控與服務更改，操作更簡潔；Nagios如果寫好自動化腳本後，也很簡單，問題在於寫自動化腳本很費神。
10、給你一套環境，你會如何設計高可用、高並發的架構？
筆者回答：如果這套環境是部署在雲端(比如阿里雲)，你就不用去考慮硬體設計的問題。可直接上阿里雲的SLB+ECS+RDS這套標準的高可用、高並發的架構。對外服務直接上SLB負載均衡技術，由阿里的SLB分發到後端的ECS主機；ECS主機部署多台，應用拆分在不同的ECS主機上，盡量細分服務。資料庫用RDS高可用版本（一主一備的經典高可用架構）、或者用RDS金融版（一主兩備的三節點架構）。在結合阿里其它的服務就完全OK，業務量上來了，主機不夠用了，直橫向擴容ECS主機搞定。
如果這套環境託管在IDC，那麼你就要從硬體、軟體（應用服務）雙面去考慮了。硬體要達到高可用、高並發公司必須買多套網路硬體設備（比如負載設備F5、防火牆、核心層交換、接入層交換）都必須要冗餘，由其是在網路設計上，設備之間都必須有雙線連接。設備如果都是跑的單機，其中一個設備掛了，你整個網路都癱瘓了，就談不上高可用、高並發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，緩存層可以考慮redis集群及Mongodb集群，中間件等其它服務可以用kafka、zookeeper，圖片存儲可以用fastDFS或MFS，如果數據量大、又非常多，那麼可採用hadoop這一套方案。後端資料庫可採用 「主從+MHA」。這樣一套環境下來是絕對滿足高可用、高並發的架構
⑦ docker 程序日誌怎麼處理
Docker日誌發送到Loggly可以有多種途徑
我們為您提供了多種靈活的日誌傳送方法，你可以選擇其中最適合你特定環境的那個——當然，所有的方法都不需要專門的agent。以下是為每種logging類型提供的最佳方案：
1. Syslog
現在您可以使用 Loggly Docker container。它同樣託管在 Docker Hub上。SendGrid Labs推薦使用這種方案。
2. 自定義應用日誌
通過我們的 HTTP端點發送數據：如果你正在使用我們為通用開發語言提供的 logging庫的其中之一做logging的話，這種方式可能會工作的很好。
3. 文件和socket結合
掛載到宿主機，之後rsyslog將會幫你讀取已經掛載的卷，並且隔一段時間會將你的log events轉發到Loggly。下次我會找個時間針對這種方法作出更為詳細的介紹。
在這篇文章中，我將會詳細介紹第一種方案，這種方案適用於可以生成兼容於syslog日誌的應用程序。兼容於syslog日誌的應用包括Apache、Nginx和使用logback或是Log4j的Java程序。
使用容器技術有以下優點：
你只需要維護單獨的進程（一個容器就是一個進程），並且它們相對獨立於宿主機本身；
你可以更高效的使用你的資源。在一台宿主機上，一個Loggly的Docker容器可以支持同一主機上的數十個其它容器；
你可以保證你的核心應用的性能和可靠性。
由於Loggly容器是作為一個單獨的進程運行，你可以確保以一種可靠的方式從Loggly獲取你的日誌，而無需阻塞你的應用程序的處理；
你可以單點控制發送到Loggly的日誌。例如，由於日誌會發送到外網，你可能希望對其設置TLS加密，又或者，你想對你的日誌做下過濾，只是想把特定日誌級別的日誌內容發送到Loggly。
⑧ 如何使用rsyslog遠程同步tomcat的日誌
由於開發的原因沒有採用他的方法方法：修改log4j.properties 文件，將日誌修改為 syslog 的類型。
這個方法沒有親測過，如果後面還是不能轉發 非syslog的話，可能會先嘗試測試一下。
⑨ haproxy 怎麼代理udp
haproxy的日誌需要打開才能夠查看，一般haproxy會將日誌輸出到系統日誌中。
haproxy 日誌配置步驟如下：
1.vim /etc/rsyslog.conf
添加local0.* /var/log/haproxy.log
這里對路徑如果修改為/home/xinz/haproxytest/log目錄下，由於rsyslog默認情況下，沒有訪問home目錄下的許可權，可以參考：
You can generate a local policy mole to allow this access.
Do
allow this access for now by executing:
# grep rsyslogd /var/log/audit/audit.log | audit2allow -M mypol
# semole -i mypol.pp
2.
rsyslog 默認情況下，需要在514埠監聽UDP，所以可以把/etc/rsyslog.conf如下的注釋去掉
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
3.重啟 rsyslog
service rsyslog restart
service rsyslog status
4.在任意工作目錄下，配置如下文件
Haproxy.conf代碼
global
log 127.0.0.1 local0 info
......
5. 日誌輸出在/var/log/haproxy.log下
請採納。
⑩ rsyslog收集日誌怎麼傳輸給elasticsearch
nput {
file {
path => "/yang/apache-tomcat-7.0.55/logs/*" //收集tomcat/logs/目錄下所有文件
start_position => end //從文件結尾處收集
}
}
filter {
if ([message] =~ "^debug") { //過濾掉debug開頭的信息回
drop {} //過濾的信息丟答棄掉
}
}
output {
stdout { codec => json}
elasticsearch { hosts =>["} //將日誌信息輸出
Elasticsearch
}
就是這么簡單，不過還有很多細節沒有搞定