(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： 必填字段，代表日志产生时间
- 其他字段：非必填字段
- PayLoad （两者选其一）
- TextPayLoad：全文本、非结构化
- 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 )，并且为每种日志提供了个性化的配置，方便用户更快接入。
- Schema：基于LogEntry Schema
支持操作系统列表：
- Debian 7 “Wheezy” and Debian-7-backports
- Ubuntu 12.04 “Precise”, 14.04.1 LTS “Trusty Tahr”, and 14.10 “Utopic”
- Red Hat Enterprise Linux 6 and 7
- CentOS 6 and 7
参考链接
https://cloud.google.com/logging/docs/
时间： 2024-11-01 12:37:37