# [email protected]

 一 程序的功能
	完成收集应用日志的功能，配合scribe一起工作，相当与scribe的客户端，还有一些问题，希望能够和大家一起解决
 二 程序架构

 1 关于配置文件：配置文件按照[model] 来区分每个模块，每个模块会启动相应的线程来监听用户的日志的变化，把用户和的日志增量通过scribe收集，
     [modelname] modelname用户来自定义，在配置文件中必须是唯一的，用来区分每个模块的不同
	  
	 port   连接用户本机的scribe的端口：（必填项），
	 host   连接用户的scribe的ip ； 在当前的架构中为：127.0.0.1 （必填项）
	 path   用户的日志路径；        （必填项）
	 backup_path  用户日志发生回滚时的日志路径，例如： 用户日志为 /data/access_log 在发生回滚后： /data/access_log1 程序会把backup_path 中没有发送的日志发送过去，再去追path中的日志，这样的操作是为了保证在日志发生回滚时不会发生丢失日志的情况（必填项）
	 accesskey  在dip平台中申请，作为用户上传日志的标示，也是用户category的一部分（必填项）
	 secrekey   与accesskey对应，用来进行用户上传日志的验证（后续操作）
	 type       日志类型   www 访问日志，error 错误日志，app 应用日志  (必填项)
	 set        自定义数据集（按照应用）需要用户自定义，命名中不能包含  "_" "空格" 例如 apache （必填项）
	 log_server_port   日志产生的服务的端口  （必填项）
	 from              用户日志的来源ip       （必填项）
	 mailto_alarm      用户组使用的报警组 多个组用英文“,"隔开
	 phone_alarm       报警电话的报警组  多个组用英文“,"隔开
	 max_send_msg      一次最多发送的日志条数  默认5000
	 timeout           连接scribe的超时时间  单位ms  默认5000ms
	 checkpoint_time   记录检查点的时间间隔 单位 s  默认5s（也就是在程序发生异常的情况下，为了防止丢失日志的情况，重启的时候会通过checkpoint来得到用户日志已经发送到的位置）；

 2  关于程序架构：
     
	 1 正常情况下程序会把用户配置的 “path”中的日志增量发送到scribe的接收端，
	 2 在日志发生回滚的情况下 监听到path中的日志文件句柄发生变化，程序会读取用户配置的backup_path中的文件（把回滚后没有发送的日志全部发送到scribe接收端）
     3 在程序在异常情况下退出的情况下，或者用户修改配置文件需要重启的情况下，  用户使用[./dip_logtail -r  config.conf] 回去读取checkpoint，通过checkpoint去发送日志
	 以防止用户的日志发送丢失，  现在的架构只能精确到 秒级，如果用户的日志增量很大，使用这种配置可能会出现日志的一定量的重复（只是在程序出现异常的情况下），
	 4 checkpoint会记录在当前执行文件下的 checkpoint目录下 ，按照modelname来进行命名，
 3 关于使用logtail：
     -h   帮助信息
	 -f   启动logtail  dip_logtail -f config.conf
	 -r   reload       dip_logtail -r config.conf
	 -v   版本号       
 4 关于报警信息：
     backup_path_not_exist        不能打开backup_path 
	 can_not_link                 连接 scribe失败
	 can_not_open_file            打开path失败