面向對象的語言中，key為對象的屬性,value為對應的屬性值,取值方法為對象key獲取屬性值，這個屬性值的類型可以是數字、字符串、數組、對象等等。數組在JSON中是中括號“[]”括起來的內容，數據結構為[……]。
[0094]假定客戶端獲取的原始的日志文件的日志數據的數據格式為:
[0095]時間I版本號I記錄11記錄I信息11記錄I信息2 I記錄2 |記錄2信息11記錄2信息2
[0096]200140404 I 0.111 szx | szx:22 | szx:175|s|s:23 |s:176
[0097]則當該客戶端將該日志文件轉換為JSON數據格式的文件后，轉換后的該日志文件中的日志數據的數據格式可如下所示:
[0098]{
[0099]“Time”: “200140404”
[0100]“Vers1n”: “0.11”
[0101]“People” [
[0102]{“name”: “szx”，“age”: “22”，“height”: “175”}，
[0103]{“name”: “s”，“age”: “23”，“height”: “176”}，
[0104]]
[0105]}
[0106]通過數據格式的轉換，如果日后原始的日志文件的數據格式有了修改，則修改的內容直接就會在客戶端上報的JSON數據格式的文件中體現，這樣一來，服務器即便不知道原始的該日志文件的數據格式，也能通過該JSON數據格式的日志文件完整而準確地獲得原始的該日志文件中的日志數據，從而可省去現有技術中服務器為配合日志文件的數據格式的修改而修改日志解析程序的流程。舉例來說，假設上述該客戶端獲取的該原始的該日志文件中增加了教育水平(edu)這一字段，則轉換后的日志文件的日志數據可表現為:
[0107]{
[0108]“Time”: “200140404”
[0109]“Vers1n”: “0.11”
[0110]“Status”: “ok”
[0111]“People” [
[0112]{“name”: “szx”, “age”: “22”，“height”: “ 175，，，“edu，，:“master” }，
[0113]{“name”: “s”，“age”: “23”，“height”: “ 176”，“edu”:“phd” }，
[0114]]
[0115]}
[0116]步驟S33，將轉換后的JSON數據格式的該日志文件上報給服務器。
[0117]終端設備100將轉換后的JSON數據格式的該日志文件上報給服務器200，使得服務器200將該日志文件中的日志數據直接存儲在文檔型數據庫中，從而完成日志收集的工作。
[0118]本發(fā)明實施例提供的日志收集方法，由于終端設備通過客戶端統(tǒng)一在上報前將日志文件轉換為JSON數據格式的文件后再上報給服務器，使得該服務器只需要將該客戶端上報的JSON數據格式的文件中的日志數據直接存儲在文檔型數據庫中即可完成日志收集的工作，省去了服務器一側日志數據清洗過濾與日志結構化分析解析的程序，并可有效解決現有技術中存在的客戶端每修改一次日志文件的數據格式，服務器就需要配合進行日志解析程序的修改，否則就無法正確讀取日志文件中各個字段的信息，也就無法做到結構化的存儲的問題，從而可解放服務器一側的日志解析開發(fā)工作，并進一步實現與業(yè)務無關的通用存儲，提高日志收集的效率。
[0119]第四實施例
[0120]請參閱圖7，圖7為本發(fā)明第四實施例提供的日志收集方法。本實施例提供的日志收集方法可通過圖1所示的服務器200，實現高效地日志收集。如圖7所示，該方法包括:
[0121]步驟S41，接收終端設備上報的JSON數據格式的日志文件；
[0122]該日志文件由終端設備100根據預設的上報策略上報。JSON是一種輕量級的數據交換格式。它基于JavaScript的一個子集。JSON數據的格式為名稱/值對，其中名稱寫在前面(在雙引號中)，值對寫在后面(同樣在雙引號中)，中間用冒號隔開。JSON的數據結構可以由對象和數組構成。其中對象在JSON中表示為“ {} ”括起來的內容，數據結構為{key:value, key:value,......}的鍵值對的結構,在面向對象的語言中，key為對象的屬性，value為對應的屬性值，取值方法為對象key獲取屬性值，這個屬性值的類型可以是數字、字符串、數組、對象等等。數組在JSON中是中括號“ □”括起來的內容，數據結構為
[“，，“，，“，，......J
[0123]步驟S42，將該JSON數據格式的日志文件中的日志數據直接存儲在文檔型數據庫中。
[0124]文檔型數據庫屬于非關系型數據庫(NoSQL)，主要用來存儲、索引并管理面向文檔的數據或者類似的半結構化數據。
[0125]進一步地，該文檔型數據庫可以包括Mongo數據庫。Mongo數據庫中的數據以集合的方式進行分組，每個集合都有單獨的名稱并可以包含無限數量的文檔。這里的集合同關系型數據庫中的表(table)類似。Mongo數據庫以一系列鍵值對集合的方式存儲數據，其中鍵(Key)是字符串，值(Value)是任何一種數據類型的集合，包括數組和文檔。Mongo數據庫原生的存儲格式為BS0N，這是一個類JSON的二進制存儲格式，簡稱Binary JSON0 Mongo數據庫支持JSON數據格式與BSON數據格式的轉化。
[0126]本步驟進一步可包括以下步驟:
[0127]第一步，調用預置的導入程序將所述JSON數據格式的日志文件中的日志數據直接導入所述Mongo數據庫中；
[0128]第二步驟，在所述Mongo數據庫為導入的所述日志數據添加基本信息，所述基本信息包括:導入時間、上報時間以及所述客戶端的標識信息。
[0129]其中該客戶端的標識信息包括但不限于:對應的終端設備的IP地址或版本號。由于日志文件中的日志數據被原封不動地直接導入Mongo數據庫中，因此可免去為保證服務器正常解析日志數據并正常存儲而帶來的開發(fā)維護工作。
[0130]進一步地,服務器200可根據用戶通過Mongo數據庫的操作語法(javascript語言)發(fā)送的日志分析指令，對該Mongo數據庫中存儲的日志數據進行分析操作。
[0131]本發(fā)明實施例提供的日志收集方法，由于服務器只需要將終端設備通過客戶端上報的JSON數據格式的文件中的日志數據直接存儲在文檔型數據庫中即可完成日志收集的工作，省去了服務器一側日志數據清洗過濾與日志結構化分析解析的程序，并可有效解決現有技術中存在的客戶端每修改一次日志文件的數據格式，服務器就需要配合進行日志解析程序的修改，否則就無法正確讀取日志文件中各個字段的信息，也就無法做到結構化的存儲的問題，從而可解放服務器一側的日志解析開發(fā)工作，并進一步實現與業(yè)務無關的通用存儲，提高日志收集的效率。
[0132]第五實施例
[0133]請參閱圖8，圖8為本發(fā)明第五實施例與第六實施例提供的日志收集裝置50的結構示意圖，日志收集裝置50可應用于圖1所示終端設備100中，以實現上述實施例提供的日志收集方法。如圖8所示，日志收集裝置50包括:
[0134]獲取模塊51，用于通過預置的客戶端獲取日志文件；
[0135]轉換模塊52，用于根據預設的上報策略將獲取模塊51獲取的該日志文件轉換為JSON數據格式的文件；
[0136]上報模塊53，用于將轉換模塊52轉換后的JSON數據格式的該日志文件上報給服務器。
[0137]第六實施例
[0138]與第五實施例不同的是:獲取模塊51，還用于從該服務器獲取該上報策略。
[0139]本發(fā)明第五實施例與第六實施例中的日志收集裝置50中的各模塊執(zhí)行各自功能的過程，參見上述圖1至圖7中各實施例的描述，此處不再贅述。
[0140]本發(fā)明第五實施例與第六實施例提供的日志收集裝置，通過在終端設備一側通過客戶端統(tǒng)一在上報前將日志文件轉換為JSON數據格式的文件后再上報給服務器，使得該服務器只需要將該客戶端上報的JSON數據格式的文件中的日志數據直接存儲在文檔型數據庫中即可完成日志收集的工作，省去了服務器一側日志數據清洗過濾與日志結構化分析解析的程序，并可有效解決現有技術