網上有很多關于pos機銷售日志,企業郵件服務日志收集的知識，也有很多人為大家解答關于pos機銷售日志的問題，今天pos機之家(www.shbwcl.net)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機銷售日志

pos機銷售日志

0×01.概要背景

這次我們舉個接近實際生產的例子，來說明開源SOC系統如何采集數據，如果之前介紹系統是抽象的，現在就是實例具象的。平時我們利用日志系統收集了大量的各類的日志數據，如：Openresty訪問日志、防護墻日志、VPN日志、郵件服務器相關日志、用戶權限審計日志、路由器操作日志、甚至包括辦公區AP的日志，DHCP日志。

這些不能一一列舉，如果要選出一個比較典型的日志收集例子， 企業郵件的日志收集可以作為例子。遍布國內相關業務城市，都有員工使用郵件服務，企業郵件服務是一種基礎服務，在運營的過程中我們遇到用戶相關各種問題的出現，不能第一時間取得更多用戶一手的現場問題資料， 通過分析用戶日志，可以找出問題的發生當點，可能引起的問題根因。還可以得用日志系統數據：解決IP異地登陸檢查，未備案設備暴力破解賬號，賬號被鎖自動提醒，管理員操作審計等有之相關的功能操作，這一切都是建立在，構建日志收集系統前提下，如果沒日志系統，這些數據和相應功能實現不了。

0×02.架構業務

我們整體上要理解業務架構和運作原理，才能有針對性的收集相關日志的數據，遇到問題時，可以通過有效的日志數據指導問題的解決。

一直以來都想找到一種比較好的表達方式來說明，企業郵件系統的構成，那種方式比較簡單明了？找到了上面這種系統切面圖方式，用2.5D的展示方法，展示從用戶郵件客戶端，到最后取得郵件的整個系統間的數據處理流程。如圖所示，我們從整體上把系統交互分成6個切片，兩次域名解析，兩次負載均衡， 并且第二次從mai_server.com解析到具體的郵件服務器時，可以不使用負載部署方案，使用DNS輪詢的方式。如果采用負載的方式，一臺機器掛掉也可以把流量負載到其它機器上，備機也可以正常工作，不受影響。 如果使用域名輪詢解析的方案，因為沒有探活機制，需要在此之外建立報警機制，一定發現一臺郵件服務器掛掉就要去掉到這機器的域名解析。mail_server.com在此處由一個內部的域名解析服務解析，郵件服務器可部署在公司機房，這種情況使用nat或是dr模式的負載均衡，可以緩解需要手動更改域名解析的尷尬，一旦出現問題不需要太多人工干預，這種根本機制上解決了服務的穩定性。

0×03.系統原理切片描述

我們簡述一下這6個系統交互切片的含義。

第1層. 郵件客戶端：用戶收發郵件使用的郵件客戶端程序。像Exchange這種郵件服務都支持針對PC端口和移動手機端的區分針對性配置。

第2層.域名解析：上面也說過，這個系統有兩次負載均衡，有兩次域名解析，問題是為什么有兩個域名，mail_proxy.com和mail_server.com， mail_server.com是真正的郵件服務器的域名，在內網中可以直接訪問，在某些場景下，我們希望在外網的員工也可以訪問郵件服務，這時我們就用一個基于Openresty的代理服務，部署內網郵件服務的代理系統，將外網域名反代指向內網的mail_server.com。出于安全考慮，我們在服務器上添加了的用戶設備ID的限制，讓那些沒有在冊的設備不可以直接通過mail_proxy.com，這個代理訪問內網的mail_server.com域名進行郵件收發。并且一旦手機發生丟失的情況下，去掉丟失自己的設備ID授權，被盜手機有用戶名和密碼，也不能正常使用郵箱服務，并且我們還可在代理服務器上限速，限制附件大小。這些的出發點都是為了安全出發。

第3層.mail_proxy.com的vip負載均衡：為了多點備份，我們在解析mail_proxy.com時，對應解析了三個機房的VIP，三個機房對應三個不同運營商的線路，優化線路后，讓用戶的訪問效率更高。然后把對應運營商線路的請求負載到3臺不同的郵件代服務器上，三臺機器，其中一兩臺服務器掛掉，也不會影響郵件代理的整體運作服務。

第4層.mail_server.com域名解析：前三層的服務并沒用直正的涉及到郵件服務器的核心服務器，從各個域名解析mail_server.com開始，下面都是郵件服務相關的服務，從mail_server.com解析到真實的郵件服務器有兩種方式，如上所述，第一種是域名解析輪詢，另一種就是加負載均衡層。

第5層.郵件負載均衡與郵件真實服務器：如果我在內網機房，使用基于tcp協議的負載均衡，一旦遇到機房或是服務本身的原因造成一臺服務斷掉也不會影響整體郵件服務。

第6層.郵件：經過前面階段的處理才能到真實地的郵件，其實還有更深的一層交互沒有在圖上畫出來就是附件服務器，正常的郵件服務，還會配置2或是3臺郵件附件服務。

0×04.關鍵的日志數據收集

在整個系統的層次上，很多服務器都會相應的產生日志數據， 刨除負載均衡的日志數據，我們真正關心的是真實服務器的產生的日志(Real Server)，這些日志的收集才能完成最開始概要里所的那些功能：

1.郵件代理服務器日志：代理服務器使用的是基于Openresty的反向代量服務器。其中最主要的日志，其實就是WEB訪問日志。

日志形式：形式上可以是標準文本格式，也可以是JSON格式。

log_format accessjson escape=json ‘{“source”:”192.168.0.8″, “ip”:”$remote_addr”,”user”:”$remote_user”,”time_local”:”$time_local”,”statuscode”:$status,”bytes_sent”:$bytes_sent,”http_referer”:”$http_referer”,”http_user_agent”:”$http_user_agent”,”request_uri”:”$request_uri”,”request_time”:$request_time,”gzip_ration”:”$gzip_ratio”,”query_string”:”$query_string”}’;

日志協議：可以使用syslog協議直接發送JSON形式的日志到syslog服務器，也可以通過catkafka將JSON文體推送到Kafka隊列上。

syslog方式：

access_log syslog:server=192.168.0.8:10001;

catkafka方式發送：

tail -F -q access-json.log | kafkacat -b 1.kafka1.yqfy.net:9091,2.kafka1.yqfy.net:9091,3.kafka1.yqfy.net:9091,4.kafka1.yqfy.net:9091 -t candylab_topic

2.郵件服務器日志：郵件服務的日志種類相對就比較多了，1.Exchange IIS日志。2.Exchange Server系統日志。3. IMAP郵件協議日志。4.POP3郵件協議日志。5.管理員審計日志。

因為郵件服務器是基于Windows的，所以我們有一種日志發送方案是使用nxlog發送客戶端代理服務，把郵件服務器上系統日志和文本文件日志發送到syslog服務器上。

典型nxlog發送文本日志配置舉例，以下：

<Extension _syslog>Module xm_syslog</Extension><Input in>Module im_file file \'C:\\\log\\\\*.log\'SavePos TRUE</Input><Output out>Module om_udpHost 192.168.0.8Port 10001Exec parse_syslog(); </Output><Route 1>Path in => out</Route>

0×05.日志的收集與轉存

之前我們說的都是系統構成和日志的普通形式的存儲，而這次比較特別的是，我們將日志通過nxlog這種syslog日志發送代理發送數據到syslog server， 再由syslog server轉發到graylog的syslog udp監聽。再由Graylog收集發送過來的文本存到ES中，因為ES的索引是有生命周期的，可以指定郵件日志的存活時間，比如說某個指定時間長度，然后數據被揮發掉，釋放出來的空間存放新的日志。但同時，當Graylog收到日志的同時，通過Graylog Kafka的Output插件，可以把數據復制轉發到Kafka上，然后由Kafka消費者程序，消費這些日志數據復制一份到Clickhouse中， 只要服務運轉良好，沒人天災人禍，服務不被莫名重裝、機房空調溫度不過高、Raid硬盤不壞，網絡不抖，數據就會安然的保存住。

1.SyslogNG服務器：Syslog服務器在那種數據需要落地，并且數據需要轉發的場景，是必選服務，Graylog也可以打開udp監聽，但不會保存文本文件到本地，直接存到了es里。

2.Graylog服務：如果說Superset是Clickhouse的靈魂伴侶，Graylog也是ES一個很好應用，Graylog可以輕松開啟各種數據監聽服務，當然也包括UDP Syslog日志監聽。并且，Graylog是內置了Kafka隊列和MongoDB，簡化了ELK系統的構件成本。

3.Kafka隊列： 當數據量特別大的時候，用隊列緩存數據（Queue），上圖的Kafka，其實是為Clickhouse寫入數據服務的，我們用Graylog把日志數據推到Kafka上，相當于把到Graylog里的日志數據，復制ClickHouse上一份，只是這個存的動作，是由后續的消費程序插入數據完成的，Clickhouse里的日志數據可以存的時間較長，SQL聚合的效率也更高。

4.Clickhouse數據庫：ClickHouse的效率強大的令人發指，我們可以用Clickhouse操作上億的數據量。

0×06.如何拿到數據

之前介紹都是，如何把郵件代理的數據存到Graylog和Clichouse里，后續的操作就是針對數據的分析操作。

1.數據輸入處理： 對于我們的分析模塊程序來說，有兩個強大的數據源，Graylog和Clickhouse， Graylog提供REST查詢服務，Clickhouse提供多種訪問驅動，python,java,c++，go的數據驅動都有。

2.黑白名單處理： 這個是業務處理，我們在同時的威脅情報處理中，一定會遇到很多的誤盼和數據噪音， 使用黑白名單機制可以改善噪音對我們的影響。對于企業郵箱的日志服務來說 ，最重要的白名單管理，其實是在nginx中，對特定用戶設備的限制管理，這個和本文無關，不表。

3.威脅檢查：核心威脅分析策略模塊（略）。如果郵箱服務，可以通過數據分析，分析出賬號被鎖用戶是誰，正在爆破郵箱的人誰， 密碼錯誤，惡意提交訪問請是誰，等等操作。

最近，當我們面臨DDOS攻擊時，基于Clickhouse構建監控分析策略，可以敏捷的應臨時監控統計需求，只要前期有數據，構建分析策略速度經人。

而Clickhouse操作其數據很簡單，以下舉例，具體復雜度看后續需求。

docker客戶端：

docker run -it –rm yandex/clickhouse-client -h yqfy.net –port 9006 -m -u yqfy–password nicaishisha -d yqfy

Python客戶端：

from clickhouse_driver import Clientclient = Client(host=\'yqfy.net\', port=9006, user=\'yqfy\', database=\'yqfy\',password=\'nicaishisha\')client.execute(\'INSERT INTO threat_table (date,hour,ts,src_ip,src_port,dst_ip,dst_port,threat,level,type,payloads,message) VALUES\', threat_infos)

新版的Clickhouse加入了更強大的功能，而我們驅動如此大的數據庫引擎，只需要區區幾行代碼，大大的提高安全人員的生產率。

4.數據輸出處理：我們可以通過syslog協議和Clickhouse，對經過處理的數據，再轉存回去。并且，有很多可視化軟件和BI處理程序對數據源數據進行分析和展示。

0×07.總結

上文介紹的內容中，關于服務器負載均衡、WEB服務器與客戶端數據采集、ES到Clickhouse遷移數據，這些都可以到Freebuf中找到更具體的文章。至此，不同以住，我們介紹了更真實的日志存儲的案例。生產環境中，我們存儲了海量的日志數據，用郵件的例子是因為郵件的業務相對好理解，不涉及到更多的術語業務，而關于數據Agent分類及部署方式。Graylog的高級使用技巧，Clickhouse聚合數據，這些軟件實際操作使用，后續介紹，那些讓人意想不到飄逸操作，讓數據分析更高效，強大的工具將我們從繁重的腦力勞動中解救出來，這也是我們可以戰勝普通猿人以及北京猿人，成為智人的原因之一，放棄香蕉，從樹上下來，我們學會了使用工具。

以上就是關于pos機銷售日志,企業郵件服務日志收集的知識，后面我們會繼續為大家整理關于pos機銷售日志的知識，希望能夠幫助到大家！