<Google Cloud Logging>调研-CSDN博客

(2015年3月做的调研，转给感兴趣的同学）

背景：

在Google之前Amazon在2014年已推出Kinesis，LogTail，CloudWatch for Logs等一系列围绕日志产品，用以对云平台产生的日志进行收集、分发、报警与监控，在更早之前S3访问日志已早被作为一个特性集成到S3中，供用户进行下载分析。日志作为云平台从计算到数据一环的载体，逐渐为云平台的增值服务开始创造新一轮价值。

Cloud Logging体系：

功能：收集并转储Google Platform产生日志

提供Log Viewer查询日志
将日志同步Cloud Storage(S3)或BigQuery
提供google-fluentd Agent收集第三方日志

支持平台：一种为Container，后者为常规的虚拟机

App Engine
Compute Engine

收费：日志收集、查看（搜索）是免费的，但到其他系统过程中需要计算导入费用

LogViewer中查看免费（30天）
导入Cloud Storage，BigQuery额外收费

限额Quota：

日志流数目：100个/Project
单实例最大流量：10GB/月
LogViewer保存时间：30天

权限控制：比较简单

“Can view” access can list logs and read log entries.
“Can edit” access can both view and write log entries.
“Owner” access can additionally configure log export.

数据模型: 单条日志叫Log Entry，Log Entry属于特定Log Type（例如access log，appengine log等），每一条日志有如下类型：

LogType：文本类型
MetaData
Time：必填字段，代表日志产生时间
其他字段：非必填字段
1. PayLoad （两者选其一）
2. TextPayLoad：全文本、非结构化
3. ProtoPayload：结构化，通过Json方式编码，Json对应格式描述在“@type”这个Field中

如下是两个例子:

ProtoPayload 例子：requestLog

{
"log": "appengine.googleapis.com/request_log",
"insertId": "54b56b5700ff0c26090e5f49ae0001737e6d792d6763702d70726f6a6563742d69640001737e6d792d6763702d70726f6a6563742d69642f31000100",
"metadata": {
"timestamp": "2015-01-13T19:00:39.796169Z",
"labels": {
"appengine.googleapis.com/clone_id": "00c61b117c5cc80afb2d2c7c3a2a0259eddd",
"appengine.googleapis.com/version_id": "1",
"appengine.googleapis.com/module_id": "default"
},
"zone": "us2",
"serviceName": "appengine.googleapis.com"
},
"protoPayload": {
"@type": "type.googleapis.com/google.appengine.logging.v1.RequestLog"
"versionId": "1",
"userAgent": "Stackdriver_terminus_bot(http://www.stackdriver.com)",
"urlMapEntry": "myproject.wsgi.application",
"status": 200,
"startTime": "2015-01-13T19:00:39.796169Z",
# ...
"appId": "s~my-gcp-project-id",
"appEngineRelease": "1.9.17",
}
}```
2. TextPayload 例子：syslog

"log": "syslog",
"insertId": "2015-01-13|11:17:03.030166-08|10.106.208.12|301990226",
"metadata": {

 "timestamp": "2015-01-13T19:17:01Z",
 "labels": {
   "compute.googleapis.com/resource_id": "15543007601548826368",
   "compute.googleapis.com/resource_type": "instance"
 },
 "zone": "us-central1-a",
 "serviceName": "compute.googleapis.com",
 "projectId": "my-gcp-project-id"

},
"textPayload": "Jan 13 19:17:01 my-gce-instance /USR/SBIN/CRON[29980]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)"
}`

关于LogViewer

搜索是Google绝活，所以LogViewer这个功能应该不在话下，LogViewer向用户提供两种模式：

TAIL：就像tail -f一样，可以通过流的方式刷新当前最新的日志，这个功能对于在AppEngine中调试程序的开发着而言，非常方便
搜索：通过选择LogType，Time（结束时间，开始时间默认为30天前），以及Query

其中Query支持三个维度的逻辑：

指定Label：对于类型为protopayload（既带自描述日志），可以增加限定词。例如status:404，则会限定404这个term出现在status这field的日志才会被返回
数值类比较：可以输入一个数值范围，例如返回[404 499]范围内的错误，则可以输入status:404…499（数字之间的三个dot代表区间）
布尔逻辑：在Query中不需要显示指定AND OR等逻辑运算符，而是用一种简化的逻辑。当Query中出现两个相同的label时，语义为or，例如”status:404 status:500″，则表达语义为OR。当不同label出现时，语义为AND。例如“status:200 latency:100…10000 operation:get”，三者都满足时才会被返回。

一些观察：

Google可以支持case sensitive，估计建了两遍索引。
不支持分词，不支持前缀与后缀搜索，可能是因为成本问题，没有在index中放term pos
非严格有序，官方文档提到搜索结果返回时间可能会有分钟级的乱序。猜想的原因是对于AppEngine这样的环境，无法保证一个严格的日志序，而是以日志到达的时间作为索引的顺序，减少全局排序的代价
LogViewer未提供API，只是作为Tool来提供。估计有两种原因，第一怕被机器调用，减少运行代价。日志查询与搜索引擎返回不同，在API层面难以确保严格的确定性，例如3提到的问题，或有丢日志、延迟搜索等隐患。

日志分发功能（Export）

Google目前提供两种目标：

Google Storage：
- 路径：my-gcs-bucket/syslog/YYYY/MM/DD/
- 格式：08:00:00_08:59:59_S0.json 08:00:00_08:59:59_S1.json
- 周期：小时
Google BigQuery：
- 路径：以不同虚拟表作为目标节点
- my_bq_dataset.apache_access_YYYYMMDD
- my_bq_dataset.compute_googleapis_com_activity_log_YYYYMMDD
周期：实时
- Schema：基于LogEntry Schema
  *日志收集（针对第三方应用）
*对于大量的第三方日志，Google没有使用通用的方法（例如正则表达式，Gork等）而是使用了开源Agent(google-fluentd )，并且为每种日志提供了个性化的配置，方便用户更快接入。