日志数据是典型的时序数据，因此，日志场景是时序数据库CTSDB的典型应用场景。下文主要描述如何用CTSDB搭建日志系统。
搭建日志系统面临的问题包括如何归档大量日志数据、如何快速检索文本日志、如何多维度查询日志。并且需要集中化的日志管理和收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。常见的日志系统有ELK系统，社区也有使用InfluxDB来搭建日志系统的。时序数据库CTSDB 完全兼容ElasticSearch 接口，同时有自研的用户授权与鉴权模块，数据生命周期管理模块，数据降精度和Rollup模块，让您使用时序数据库存日志安全可靠，无后顾之忧。另外，CTSDB商业化首发期间，官网推出限时5折活动，优惠多多，更多详情请点击链接。
自建数据库的劣势
自建数据库存储日志数据坑很多，并且很多风险都需要自行承担，现在贴出来供大家参考。
1. Elasticsearch支持给索引添加TTL属性自动过期删除。由于使用TTL，在文档量很大的时候，如果同时有大量文档过期，可能会导致集群节点OOM。
2. 自建数据库没有数据降精度和数据上卷（Rollup）功能，有了Rollup功能将能实现多年数据的降精度保存，节省存储成本。例如，有一种使用场景是分析用户的实时点击行为（天/周/季/年的同/环比），功能性接口的调用离线分析等都需要提前配置数据的聚合分析并存储下来，以便能快速检索。而如果业务在存储之外开发旁路模块来处理该功能将使真个系统由于过于庞大而无法维护。
3. 自建ElasticSearch存日志需要的虚拟机的配置不能太低（否则OOM风险很高），为保证业务高可用，至少需要三台虚拟机，其自建成本并不低。
4. 如果自建InfluxDB，社区版为单机版，无法保证系统的高可用。需要业务通过开发或者通过监控来保证高可用。
5. 监控是线上系统的可用性和健壮性的有力保证。而自建数据库的监控需要业务自行开发来进行保证。
6. 自建数据库无用户的授权和鉴权，只能通过虚拟网络来保证安全性。一份日志数据几乎成为所有业务模块共享，数据的安全性非常低。
可见自建数据库来存储日志数据不方便，难以维护，费用高。基于以上情况，下面介绍如何用时序数据库CTSDB搭建日志系统。大致架构如下：通过Filebeat采集数据到Logstash，然后利用Logstash的数据解析功能，将日志解析为多个字段，然后写入CTSDB，最后利用Grafana或者Kibana展示和分析数据。同时利用CTSDB的数据管理能力来管理日志。其中，日志数据的存入、展示可参考官网指引。下面详细讲述日志数据的日常管理和分析举例。
管理日志数据
（一） 基于业务设置Metric
一个Metric即为一个表格。如果当前业务的日志系统为一个多个系统模块的日志系统，例如有前台用户行为日志，后台系统功能调用日志，软件系统运行监控日志等三个模块。则，可以分别建三个Metric分别存储三个模块的日志数据。更多新建Metric及Metric配置请参照指引。
（二） 设置日志有效期
因为日志数据具有时效性，例如实时分析大多只需分析7天内的数据即可。则可以设置Metric中数据的过期时间参数，数据过期后系统会自动清理，不需要手工删除。设置数据的有效期请参照指引。
（三）配置日志数据降精度
日志数据主要用来定位问题和分析历史问题。定位问题主要针对最近一段时间的热数据，而分析问题主要是对历史数据的大致分析。时序数据库比较好的一点是可以设置数据的有效期，历史日志过期后自动会被清理。而针对历史数据的分析，可以配置任务，系统自动分析并保存下来，需要分析时直接拉取，非常方便。数据配置降精度请参考指引。
分析日志数据
分析日志数据可以通过Grafana或者Kibana的仪表盘进行数据配置。系统也提供了很多常用的数据分析接口例如时间直方图分析、Percentiles 分析、Cardinality 分析等。具体的请参考指引。
