集中式日志解決方案

背景

隨著業(yè)務(wù)的快速發(fā)展槐瑞，各種服務(wù)和組件也要隨著增加或擴(kuò)容邑滨，服務(wù)器的臺(tái)數(shù)隨之增加诊霹，這樣給日志運(yùn)維帶來(lái)很大的問(wèn)題搀绣。如果你要查閱某個(gè)項(xiàng)目的日志，服務(wù)器數(shù)十上百臺(tái)的話陕悬，這將是一件非常繁瑣和低效的事习柠。另外疏魏，如果你想對(duì)這些日志進(jìn)行實(shí)時(shí)的分析統(tǒng)計(jì)蛉艾，也無(wú)從下手钳踊。因此，我們需要一種數(shù)據(jù)收集框架勿侯，它可以將不同服務(wù)器上的日志數(shù)據(jù)拓瞪，高效地收集匯總在一起，供在線或者離線查閱和分析助琐，并且還可以對(duì)系統(tǒng)實(shí)施監(jiān)控和故障告警吴藻。

本文檔通過(guò)介紹Flume NG、Scribe弓柱、Kafka沟堡、Chukwa和ELK的特點(diǎn)，結(jié)構(gòu)模型矢空，使用時(shí)的優(yōu)勢(shì)和劣勢(shì)航罗，以及我們自定義的指標(biāo)項(xiàng)對(duì)比，最后得出它們各自的應(yīng)用場(chǎng)景屁药，為框架選型提供技術(shù)參考粥血。

數(shù)據(jù)收集系統(tǒng)

Flume NG

Flume NG的介紹

Flume NG 是Cloudera提供的分布式數(shù)據(jù)收集系統(tǒng)，它能夠?qū)⒉煌瑪?shù)據(jù)源的海量日志數(shù)據(jù)進(jìn)行高效的收集酿箭、聚合复亏、移動(dòng)，最后存儲(chǔ)到存儲(chǔ)中心缭嫡。Flume NG支持（故障轉(zhuǎn)移）failover和負(fù)載均衡缔御。

Flume NG的結(jié)構(gòu)

Flume NG傳輸數(shù)據(jù)的基本單元是event，如果是文件妇蛀，通常是一行記錄耕突。運(yùn)行的核心是Agent，包含三個(gè)核心組件评架，分別是Source眷茁、Channel和Sink，其結(jié)構(gòu)模型圖如下：

Flume NG的介紹
  • Source：接收外部源發(fā)送過(guò)來(lái)的數(shù)據(jù)纵诞，支持Avro上祈、Thrift、JMS浙芙、Syslog登刺、Kafka和Http post（自己代碼實(shí)現(xiàn)）等多種方式的日志接收。提供ExecSource以tail -f等命令的方式實(shí)現(xiàn)實(shí)時(shí)日志收集茁裙；提供SpoolSource以讀取新增的文件的方式實(shí)現(xiàn)低延時(shí)的日志收集塘砸。
  • Channel：是一個(gè)存儲(chǔ)池，接收Source的輸出晤锥。有MemoryChannel掉蔬、JDBC Channel、MemoryRecoverChannel和FileChannel等主要類型矾瘾。其中MemoryChannel可以實(shí)現(xiàn)高速吞吐女轿，但無(wú)法保證數(shù)據(jù)的完整性。FileChannel能實(shí)現(xiàn)數(shù)據(jù)的完整性和一致性壕翩。Channel中的數(shù)據(jù)僅會(huì)在數(shù)據(jù)保存在下一個(gè)Channel或最終的存儲(chǔ)中心時(shí)蛉迹，才會(huì)被刪除。
  • Sink：消費(fèi)Channel中的數(shù)據(jù)放妈，然后發(fā)送給數(shù)據(jù)存儲(chǔ)系統(tǒng)（HDFS北救、Elasticsearch或者HBase等)荐操。一個(gè)Agent可以存在多個(gè)Sink，Sink支持負(fù)載均衡和failover珍策。
Flume NG的結(jié)構(gòu)圖：

  • 多個(gè)Agent順序連接：

    最簡(jiǎn)單的部署方式托启，通過(guò)多個(gè)Agent連接，將原始數(shù)據(jù)傳送到下一個(gè)Agent或者是最終的存儲(chǔ)中心攘宙，適合初學(xué)者屯耸。

多個(gè)Agent順序連接
  • 多個(gè)Agent的數(shù)據(jù)匯聚在同一個(gè)Agent中：
多個(gè)Agent的數(shù)據(jù)匯聚在同一個(gè)Agent中

最常見(jiàn)的部署方式，比如在各個(gè)應(yīng)用服務(wù)器上部署Flume NG蹭劈，將原始數(shù)據(jù)同步到一臺(tái)agent上疗绣。

  • 多路Agent連接：
多路Agent連接

包括分流和復(fù)制兩種方式，分流是根據(jù)header信息進(jìn)行數(shù)據(jù)的分類存儲(chǔ)數(shù)據(jù)铺韧，復(fù)制是將數(shù)據(jù)復(fù)制多份多矮。

  • 負(fù)載均衡數(shù)據(jù)模型：
負(fù)載均衡數(shù)據(jù)模型

Agent1負(fù)責(zé)路由，每個(gè)Sink連接一個(gè)Agent祟蚀，Sink支持負(fù)載均衡和Failover工窍。

Flume NG的優(yōu)勢(shì)劣勢(shì)

  • 優(yōu)勢(shì)：Flume NG通過(guò)事務(wù)保證數(shù)據(jù)的完整性和一致性；支持負(fù)載均衡前酿；很容易進(jìn)行水平擴(kuò)展患雏；社區(qū)活躍度高；文檔資料比較豐富罢维；依賴第三方庫(kù)少淹仑；部署簡(jiǎn)單；支持多種存儲(chǔ)系統(tǒng)肺孵。
  • 劣勢(shì)：Flume NG需要自己實(shí)現(xiàn)客戶端代碼匀借；ExecSource方式會(huì)存在數(shù)據(jù)丟失的可能，SpoolSource方式做不到監(jiān)控文件的新增記錄平窘；對(duì)數(shù)據(jù)的過(guò)濾能力較差吓肋。

Scribe

Scribe介紹

Scribe是Facebook開(kāi)源的一個(gè)基于thrift框架的日志收集系統(tǒng)，在facebook內(nèi)部已經(jīng)得到大量的應(yīng)用瑰艘。Scribe可以從不同數(shù)據(jù)源是鬼，不同機(jī)器上收集日志，然后將它們存入存儲(chǔ)中心紫新，目前Facebook已停止對(duì)Scribe的更新和維護(hù)均蜜。

Scribe結(jié)構(gòu)
  • Scribe結(jié)構(gòu)圖：
Scribe結(jié)構(gòu)圖
  • Scribe 客戶端：需要自己基于Thrift框架實(shí)現(xiàn)，每條消息包含一個(gè)category和一個(gè)message信息芒率，Scribe Server根據(jù)category將數(shù)據(jù)存儲(chǔ)在不同的存儲(chǔ)系統(tǒng)囤耳。
  • Scribe Server：根據(jù)配置，將各個(gè)category類型的日志發(fā)到不同的存儲(chǔ)系統(tǒng)。Scribe Server收集到數(shù)據(jù)后充择，將數(shù)據(jù)放到共享隊(duì)列德玫，然后Push到存儲(chǔ)中心，當(dāng)存儲(chǔ)中心出現(xiàn)故障時(shí)聪铺，Scribe 會(huì)將數(shù)據(jù)保存在本地文件中化焕，待存儲(chǔ)中心恢復(fù)后再Push數(shù)據(jù)。
  • 存儲(chǔ)中心：包括HDFS铃剔、File和Scribe。
Scribe優(yōu)勢(shì)和劣勢(shì)
  • 優(yōu)勢(shì)：具有很高的容錯(cuò)性查刻；支持水平擴(kuò)展键兜；
  • 劣勢(shì)：依賴zookeeper或Hash等其他工具；需要自己實(shí)現(xiàn)客戶端代碼穗泵；社區(qū)活躍度低普气；文檔資料極少；依賴第三方庫(kù)多佃延；部署較為復(fù)雜现诀；存儲(chǔ)系統(tǒng)類型較少；數(shù)據(jù)過(guò)濾解析能力差履肃；Facebook公司已停止更新和技術(shù)支持仔沿。

Kafka

Kafka的介紹

Kafka 是一個(gè)基于分布式的消息系統(tǒng)，開(kāi)發(fā)自 LinkedIn ['l??kt?n]尺棋，作為 LinkedIn 的活動(dòng)流和運(yùn)營(yíng)數(shù)據(jù)處理管道封锉。活動(dòng)流數(shù)據(jù)包括頁(yè)面訪問(wèn)量膘螟、被查看內(nèi)容方面的信息以及搜索情況等成福。運(yùn)營(yíng)數(shù)據(jù)指服務(wù)器的性能數(shù)據(jù)，包括CPU荆残、IO使用率奴艾、請(qǐng)求時(shí)間、服務(wù)日志等内斯。

Kafka結(jié)構(gòu)模型：
Kafka結(jié)構(gòu)模型
  • Producer：消息發(fā)送者蕴潦，負(fù)責(zé)發(fā)送消息給Broker。
  • Kafka Cluster：由多個(gè)Kafka實(shí)例組成嘿期，每個(gè)實(shí)例（Server）成為Broker品擎。集群的搭建依賴Zookeeper。
  • Consumer：消息消費(fèi)者备徐，從Kafka讀取消息萄传。
  • Topic：一類消息，類似Queue的概念，Topic在物理上是分節(jié)點(diǎn)存儲(chǔ)秀菱。
  • Consumer Group：實(shí)現(xiàn)一個(gè)Topic消息單播和廣播的一個(gè)手段振诬。要實(shí)現(xiàn)廣播，只要每個(gè)consumer有一個(gè)獨(dú)立的Group就可以衍菱。要實(shí)現(xiàn)單播赶么，只要所有的Consumer在同一個(gè)Group里即可。
Kafka的優(yōu)勢(shì)和劣勢(shì)

Kafka 通過(guò)系統(tǒng)解耦脊串、Partition（分片存儲(chǔ)）辫呻、復(fù)制備份、持久化琼锋、緩存放闺、集群和異步通信等策略提供了一個(gè)高性能、高可靠缕坎、可擴(kuò)展的數(shù)據(jù)管道和消息系統(tǒng)怖侦。

  • 優(yōu)勢(shì)：高性能；高可靠谜叹；通過(guò)Kafka Conenector對(duì)接HDFS匾寝、Elasticsearch、JDBC等其它系統(tǒng)荷腊；支持水平擴(kuò)展艳悔；社區(qū)活躍度高；文檔資料豐富停局；依賴第三方庫(kù)較少很钓。
  • 劣勢(shì)：依賴Zookeeper；需要自己實(shí)現(xiàn)客戶端代碼董栽；數(shù)據(jù)過(guò)濾解析能力差码倦。

Chukwa

Chukwa的介紹

chukwa 是一個(gè)用于監(jiān)控大型分布式系統(tǒng)的數(shù)據(jù)收集系統(tǒng)，構(gòu)建在 Hadoop 的 HDFS 和 map/reduce 框架之上的锭碳，繼承了 hadoop 的擴(kuò)展性和健壯性袁稽，還包含HICC，可用于展示擒抛、監(jiān)控和分析已收集的數(shù)據(jù)推汽。

Chukwa的結(jié)構(gòu)
image.png
  • Agent：負(fù)責(zé)采集數(shù)據(jù)，并發(fā)送給Collector歧沪。agent采用“watchdog”的機(jī)制歹撒，自動(dòng)重啟終止的數(shù)據(jù)采集進(jìn)程，防止數(shù)據(jù)丟失诊胞。
  • Adaptor：直接采集數(shù)據(jù)的接口和工具暖夭，支持命令行，log文件和httpSender輸出,可以按自己的需求實(shí)現(xiàn)Adaptor，一個(gè)Agent可以管理多個(gè)Adaptor的數(shù)據(jù)采集迈着。
  • Collectors：負(fù)責(zé)收集Agents發(fā)送過(guò)來(lái)的數(shù)據(jù)竭望，并定時(shí)寫(xiě)入集群。
  • Map/Reduce jobs：定時(shí)啟動(dòng)裕菠，在此階段咬清，Chukwa提供了demux [d?m'ju:ks]和archive [?ɑ:ka?v]兩種內(nèi)置的作業(yè)類型，其中奴潘，demux作為負(fù)責(zé)對(duì)數(shù)據(jù)分類旧烧、排序、去重萤彩，archive作業(yè)負(fù)責(zé)把同類型的數(shù)據(jù)合并粪滤。
  • HICC：負(fù)責(zé)數(shù)據(jù)的展示。
Chukwa的優(yōu)勢(shì)和劣勢(shì)
  • 優(yōu)勢(shì)：高可靠雀扶，易擴(kuò)展；社區(qū)活躍度較高肆汹；文檔資料較豐富愚墓；
  • 劣勢(shì)：依賴hadoop。

ELK

ELK的介紹

ELK 不是一款軟件昂勉，而是Elasticsearch浪册、Logstash和Kibana首字母的縮寫(xiě)。這三者是開(kāi)源軟件岗照，通常配合一起使用村象，而且先后歸于Elasic.co公司的名下，所以簡(jiǎn)稱ELK Stack攒至。根據(jù)Google Trend的信息顯示厚者，ELK已經(jīng)成為目前最流行的的集中式日志解決方案。

  • Elasticsearch：是一個(gè)分布式搜索和分析引擎迫吐，具有高可伸縮库菲、高可靠和易管理等特點(diǎn)≈景颍基于Apache Lucene構(gòu)建熙宇，能對(duì)大容量的數(shù)據(jù)進(jìn)行接近實(shí)時(shí)的存儲(chǔ)、搜索和分析操作溉浙。通過(guò)簡(jiǎn)單的配置烫止，Elasticsearch就會(huì)幫你管理集群、分片戳稽、故障轉(zhuǎn)移馆蠕、主節(jié)點(diǎn)選舉等，還提供集群狀態(tài)的監(jiān)控接口。

  • Logstash：數(shù)據(jù)收集引擎荆几。它支持從各種數(shù)據(jù)源收集數(shù)據(jù)吓妆，并對(duì)數(shù)據(jù)進(jìn)行過(guò)濾、分析吨铸、豐富行拢、統(tǒng)一格式等操作，然后存儲(chǔ)到用戶指定的位置诞吱。Logstash支持file舟奠、syslog、tcp房维、stdin沼瘫、redis和kafka等多種接收方式。支持elasticrsearch咙俩、email耿戚、exec、nagios阿趁、tcp膜蛔、hdfs等多種方式輸出。

  • Kibana：數(shù)據(jù)分析和可視化平臺(tái)脖阵。通常與Elasticsearch配合使用皂股，對(duì)其中的數(shù)據(jù)進(jìn)行搜索、分析并能以圖表的方式顯示命黔。

  • Filebeat：ELK協(xié)議棧的新成員呜呐，一個(gè)輕量級(jí)開(kāi)源日志文件數(shù)據(jù)搜集器。我們?cè)谛枰杉罩緮?shù)據(jù)的服務(wù)器上安裝Filebeat悍募，并指定日志目錄或日志文件后蘑辑，F(xiàn)ilebeat就能讀取數(shù)據(jù)，迅速發(fā)送到Logstash進(jìn)行解析搜立，亦或直接發(fā)送到Elasticsearch進(jìn)行集中式存儲(chǔ)和分析以躯。FileBeat可以監(jiān)聽(tīng)指定目錄下是否新增文件，監(jiān)聽(tīng)文件是否新增記錄啄踊，文件在一定時(shí)間內(nèi)沒(méi)更新取消監(jiān)聽(tīng)忧设，支持批量數(shù)據(jù)傳送，支持負(fù)載均衡的方式傳送數(shù)據(jù)到Logstash或Elasticsearch颠通。支持SSL/TLS協(xié)議傳送址晕。

ELK的結(jié)構(gòu)
  • 最簡(jiǎn)單的結(jié)構(gòu)模型：
最簡(jiǎn)單的結(jié)構(gòu)模型

這種結(jié)構(gòu)很簡(jiǎn)單，適合初學(xué)者顿锰。初學(xué)者可以搭建此結(jié)構(gòu)谨垃，了解ELK如何工作启搂。

  • Logstash作為日志收集器：
Logstash作為日志收集器

這種結(jié)構(gòu)模型需要在各個(gè)應(yīng)用服務(wù)器上部署Logstash，但Logstash比較消耗CPU和內(nèi)存資源刘陶，所以比較適合資源豐富的服務(wù)器胳赌，否則可能會(huì)導(dǎo)致應(yīng)用服務(wù)器無(wú)法工作。

  • Beats作為日志收集器匙隔，Beats包括四種：
    • Packetbeat(搜集網(wǎng)絡(luò)流量數(shù)據(jù))
    • Topbeat(搜集系統(tǒng)疑苫、進(jìn)程、文件系統(tǒng)級(jí)別的CPU和內(nèi)存使用情況等數(shù)據(jù))
    • Filebeat(收集文件數(shù)據(jù))
    • Winlogbeat(收集Window時(shí)間日志數(shù)據(jù))
Beats作為日志收集器

這種結(jié)構(gòu)解決了Logstash在各服務(wù)器節(jié)點(diǎn)上占用資源高的問(wèn)題纷责。另外捍掺，數(shù)據(jù)格式規(guī)范的情況下，可以移出Logstash節(jié)點(diǎn),Beats直接發(fā)送數(shù)據(jù)到Elasticsearch再膳，解決Logstash占用資源高的問(wèn)題挺勿。

  • 引入消息隊(duì)列機(jī)制
引入消息隊(duì)列機(jī)制

這種結(jié)構(gòu)適合日志規(guī)模比較大的情況。引入消息隊(duì)列喂柒，將上下游服務(wù)解耦不瓶，減輕下游服務(wù)的壓力，解決在巨量日志下灾杰，網(wǎng)絡(luò)阻塞延遲湃番、數(shù)據(jù)丟失的問(wèn)題，使得網(wǎng)絡(luò)傳輸更穩(wěn)定吭露、更高效，避免級(jí)聯(lián)效應(yīng)尊惰。在巨量日志的情況下讲竿，Logstash節(jié)點(diǎn)和Elasticsearch節(jié)點(diǎn)負(fù)荷比較重，可將它們配置成集群模式弄屡，分擔(dān)負(fù)荷题禀。在日志比較規(guī)范的情況下，可以去掉Logstash,Beats直接發(fā)送數(shù)據(jù)到Elasticsearch膀捷，解決Logstash占用資源高的問(wèn)題迈嘹。

ELK的優(yōu)勢(shì)和劣勢(shì)
  • 優(yōu)勢(shì)：提供一套完整的日志收集、分析全庸、存儲(chǔ)和數(shù)據(jù)展示的解決方案秀仲；Logstash支持集群部署和水平擴(kuò)展；Elasticsearch高可用壶笼，支持集群部署和水平擴(kuò)展神僵；社區(qū)活躍度高；文檔資料較豐富覆劈；部署簡(jiǎn)單保礼。
  • 劣勢(shì)：Logstash占用資源比較高沛励。

指標(biāo)項(xiàng)對(duì)比

指標(biāo)項(xiàng)對(duì)比

結(jié)論

結(jié)論

ELK告警策略

ELK告警策略

參考資料

Flume NG

http://blog.csdn.net/zhaodedong/article/details/52541688
http://www.gegugu.com/2016/04/11/5484.html

Scribe

http://www.itdadao.com/articles/c15a502872p0.html
http://www.36dsj.com/archives/66047

Kafka

http://www.cnblogs.com/likehua/p/3999538.html
http://www.infoq.com/cn/articles/kafka-analysis-part-1

Chukwa

http://www.it165.net/admin/html/201403/2507.html
http://f.dataguru.cn/thread-97612-1-1.html

ELK Stack 中文指南

http://kibana.logstash.es/content/

Logstash最佳實(shí)踐

http://udn.yyuap.com/doc/logstash-best-practice-cn/index.html

Elasticsearch 權(quán)威指南

https://es.xiaoleilu.com/

Elasticsearche配置：

https://my.oschina.net/topeagle/blog/405149
https://my.oschina.net/Yumikio/blog/805877

Filebeat配置：

http://m.blog.csdn.net/article/details?id=53584173
http://michaelkang.blog.51cto.com/1553154/1864225

Search Guard:

https://github.com/floragunncom/search-guard-docs
http://www.cnblogs.com/Orgliny/p/6168986.html
http://kibana.logstash.es/content/elasticsearch/auth/searchguard-2.html

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市炮障，隨后出現(xiàn)的幾起案子目派，更是在濱河造成了極大的恐慌，老刑警劉巖胁赢，帶你破解...
    沈念sama閱讀 222,104評(píng)論 6贊 515
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件企蹭，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡徘键，警方通過(guò)查閱死者的電腦和手機(jī)练对，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,816評(píng)論 3贊 399
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門(mén)，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)吹害，“玉大人螟凭，你說(shuō)我怎么就攤上這事∷剑” “怎么了螺男？”我有些...
    開(kāi)封第一講書(shū)人閱讀 168,697評(píng)論 0贊 360
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長(zhǎng)纵穿。 經(jīng)常有香客問(wèn)我下隧，道長(zhǎng)，這世上最難降的妖魔是什么谓媒？ 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 59,836評(píng)論 1贊 298
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任淆院，我火速辦了婚禮，結(jié)果婚禮上句惯，老公的妹妹穿的比我還像新娘土辩。我一直安慰自己，他們只是感情好抢野，可當(dāng)我...
    茶點(diǎn)故事閱讀 68,851評(píng)論 6贊 397
  • 惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
    文/花漫 我一把揭開(kāi)白布拷淘。 她就那樣靜靜地躺著，像睡著了一般指孤。 火紅的嫁衣襯著肌膚如雪启涯。 梳的紋絲不亂的頭發(fā)上，一...
    開(kāi)封第一講書(shū)人閱讀 52,441評(píng)論 1贊 310
  • 城市分裂傳說(shuō)
    那天恃轩，我揣著相機(jī)與錄音结洼，去河邊找鬼。 笑死详恼，一個(gè)胖子當(dāng)著我的面吹牛补君，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播昧互，決...
    沈念sama閱讀 40,992評(píng)論 3贊 421
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開(kāi)眼挽铁，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼伟桅！你這毒婦竟也來(lái)了？” 一聲冷哼從身側(cè)響起叽掘，我...
    開(kāi)封第一講書(shū)人閱讀 39,899評(píng)論 0贊 276
  • 萬(wàn)榮殺人案實(shí)錄
    序言：老撾萬(wàn)榮一對(duì)情侶失蹤楣铁，失蹤者是張志新（化名）和其女友劉穎，沒(méi)想到半個(gè)月后更扁，有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體盖腕，經(jīng)...
    沈念sama閱讀 46,457評(píng)論 1贊 318
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,529評(píng)論 3贊 341
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年浓镜，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了溃列。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,664評(píng)論 1贊 352
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡膛薛，死狀恐怖听隐，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情哄啄，我是刑警寧澤雅任，帶...
    沈念sama閱讀 36,346評(píng)論 5贊 350
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站咨跌，受9級(jí)特大地震影響沪么，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜锌半，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,025評(píng)論 3贊 334
  • 男人毒藥：我在死后第九天來(lái)索命
    文/蒙蒙 一禽车、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧刊殉，春花似錦哭当、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 32,511評(píng)論 0贊 24
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)陋葡。三九已至亚亲，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間腐缤，已是汗流浹背捌归。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 33,611評(píng)論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來(lái)泰國(guó)打工， 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留岭粤，地道東北人惜索。 一個(gè)月前我還...
    沈念sama閱讀 49,081評(píng)論 3贊 377
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像剃浇，于是被迫代替她去往敵國(guó)和親巾兆。 傳聞我的和親對(duì)象是個(gè)殘疾皇子猎物，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,675評(píng)論 2贊 359

推薦閱讀更多精彩內(nèi)容