提高日志存储

㈠ 阿里云的高效云盘扩容到2T就不支持扩容了！

1. 为了方便存储日志和转化透传点击，当初选定使用mongodb。于是买了一台ECS服务器，挂上了300GB高效云盘，慢慢开始跑广告业务。

2. 跑了半个月，300GB眼看不够了，赶紧学习巩固阿里云的扩容linux数据盘的操作。

3. 前后扩容到800G，1.4T，最后扩容到2T。再一看，已经不让扩容了。

4. 尤记得创建云盘时，有说明不同的云盘类型支持的最大容量不同。

5.于是翻了翻阿里云的文档——ssd和高效云盘最大支持32T。普通云盘最大支持2T。

6.于是怀疑难道我购买的是普通云盘，所以只能扩容到2T？

7. 进入实例中却看到是高效云盘啊！那为何不能继续扩容？

8.于是创建一个新的云盘试试，发现可以指定2T以上的存储空间。

9. 回到磁盘扩容页面，发现2T后，鼠标悬停过去显示"当前大于2TB磁盘暂不支持扩容"！

10. 我在想这表示哪怕我之前一下子买了2个T，3个T的高效云盘，然后想扩容了，是不是也不行？必须得创建数据盘快照，然后恢复到更大的硬盘上？我怎么对这样的数据盘快照一点儿都没有信心呢？

11. 可悲的是，这表明我只能此刻看到mongo服务器还有500GB存储空间。以后会越来越少。我将不得不重新考虑存储方案，一是2T以上的日志存储并没有比以前的文件存储提高多少价值，反而存储空间要求更大，每月的纯粹存储费用达到720元以上。这已经是一台性能好的服务器的价格了。

12. 曾经想过应该在公司内部保留一台服务器存储mongo日志。购买一块大容量硬盘就好了。但是数据透传怎么办？也在这台服务器做？还是本地网络挂到公网上？

13. 不得不思考替代的存储方案了。日志的用处一是为了透传，二则是解决一些渠道或这检测方偶尔提出的问题。也许oss存储会降低成本，但是如何使用才能更好的满足我们的需求呢？

㈡ 如何设计日志采集存储分析的架构

如何设计日志采集存储分析的架构
架构方面：
□ Flume OG有三种角色的节点：代理节点agent、收集节点collector、主节点master
□ agent负责从各个数据源收集日志数据、将收集到的数据集中到collector,再由collector节点汇总存入到HDFS.而master负责管理agent\collector的活动
□ agent、collector都称为node,node的角色根据配置的不同分为逻辑节点和物理节点,对于逻辑节点的区分、配置、使用非常复杂.
□ agent、collector由source、sink组成,表示当前节点的数据从source传送到sink
以上相对于Flume NG来说:
□ Flume NG只有一种角色节点：代理节点agent
□ 没有collector、master节点,这是最核心的变化.
□ 去除逻辑节点和物理节点的概念和内容
□ agent节点的组成发生变化,由source 、sink、channel三个组件组成
Zookeeper方面：
□ Flume OG的稳定性依赖zookeeper,它需要zookeeper对其多类节点的工作进行管理,虽然OG可以使用内存的方式对各类节点进行管理,但需要用户忍受机器出现故障时信息丢失的出现.
□ Flume NG的节点角色数量由原来的3个缩减为1个,不存在多类角色的问题,所以不再需要zookeeper对各类节点协调的作用,由此脱离了对zookeeper的依赖.

㈢ 如何实现日志的集中化存储以及使用loganalyzer做日志分析

一、安装Mysql数据库
选择使用编译好的二进制格式的MySQL程序包

1

mysql-5.5.22-linux2.6-i686.tar.gz

1、创建MySQL的数据存放位置
为了备份日志方便把数据放在LVM卷中。还可以利用LVM的扩容功能，当我们的空间不够使用时。
查看，已经存在的卷组是否还有剩余空间，来创建LV。

1
2
3

[root@mysql local]# vgdisplay | grep -i"PE[[:space:]]*/[[:space:]]*Size"
Alloc PE / Size 6656 / 52.00GiB
Free PE / Size 1023 / 7.99 GiB

说明：还有7.99GB，空间可以创建LV。
注意：
如果存在的文件很大的话，见议我们在创建逻辑卷时最好把PE的大小设置大点。

创建LV

1
2
3
4

root@mysql local]# lvcreate -L 4G -n loglv vg0
Logical volume "loglv" created
[root@mysql local]# lvscan | grep "loglv"
ACTIVE '/dev/vg0/loglv'[4.00 GiB] inherit

格式化逻辑卷loglv

1
2
3

[root@mysql local]# mke2fs -t ext4 -L LOGDATA /dev/vg0/loglv
[root@mysql local]# echo $?
0

挂载逻辑卷

设置开机自动挂载.编辑/etc/fstab文件增加下面一行。

1

/dev/mapper/vg0-loglv /logdata ext4 defaults 0 0

自动挂载测试

1
2
3

root@mysql local]# mount -a
[root@mysql local]# mount | grep"loglv"
/dev/mapper/vg0-loglv on /logdata type ext4(rw)

2、准备好安装MySQL数据库的必需条件
(1)、创建用户mysql，用来被始化数据库使用的。

说明：最好mysql是系统用户，这样就算mysql用户被人劫持，也无法登陆系统的。

1
2
3

[root@mysql local]# useradd -r mysql
[root@mysql local]# id mysql
uid=399(mysql) gid=399(mysql)groups=399(mysql)

(2)、设置MySQL数据库的数据存放位置：在/logdata中创建data，且属主属组为mysql

1
2
3
4

[root@mysql logdata]# mkdir data
[root@mysql logdata]# chown mysql:mysql./data/
[root@mysql logdata]# ll -d data
drwxr-xr-x 2 mysql mysql 4096 Aug 20 15:40data

3、安装MySQL数据库
(1)、把程序包解压到”/uer/local”目录，为了后续维护方便并创建一个软链接。

1
2
3
4
5
6

[root@mysql user]# tar -xfmysql-5.5.22-linux2.6-i686.tar.gz -C/usr/local/
[root@mysql user]# cd /usr/local/
[root@mysql local]# ln -svmysql-5.5.22-linux2.6-i686 mysql
`mysql' -> `mysql-5.5.22-linux2.6-i686'
[root@mysql local]# ll | grep mysql
lrwxrwxrwx 1 root root 26 Aug 20 15:03mysql -> mysql-5.5.22-linux2.6-i686

(2)、我们要以:mysql用户的身份来初始化数据库，要有权限操作一些文件所以要修改解压后Mysql程序的属主属组为mysql

1

[root@mysql mysql]# chown -R mysql:mysql./*

说明：安装完数据后，把属主改为：root
(3)、初始化数据库

1
2
3
4
5

[root@node1 mysql]#./scripts/mysql_install_db --datadir=/logdata/data --user=mysql
Installing MySQL system tables...
OK
Filling help tables...
OK

说明：

1
2

--datadir 指定数据库的数据目录的位置(不使用默认的位置)
--user 指定初始化数据库的用户名(使用二进制格式MySQL程序包一定要使用mysql)

(4)、根据物理机的硬件情况与实际需要选择MySQL的配置文件

1
2
3
4
5
6

[root@node1 mysql]# ll support-files/*.cnf
-rw-r--r-- 1 mysql mysql 4691 Mar 3 2012 support-files/my-huge.cnf
-rw-r--r-- 1 mysql mysql 19759 Mar 3 2012 support-files/my-innodb-heavy-4G.cnf
-rw-r--r-- 1 mysql mysql 4665 Mar 3 2012 support-files/my-large.cnf
-rw-r--r-- 1 mysql mysql 4676 Mar 3 2012 support-files/my-medium.cnf
-rw-r--r-- 1 mysql mysql 2840 Mar 3 2012 support-files/my-small.cnf

说明：
不同的配置文件，要求的内存都不一样。

复制配置文件到/etc/mysql 目录下，并命名为：my.cnf

1

[root@node1 mysql]# cp support-files/my-large.cnf /etc/mysql/my.cnf

4、启动MySQL数据库服务器之前要做的一些设置
(1)、修改MySQL的配置文件

1
2
3

[root@node1 mysql]# vim /etc/mysql/my.cnf
thread_concurrency = 4 设置线程数
datadir = /logdata/data 告诉MySQL服务器数据目录的位置

说明：
由于这些配置是作用于MySQL服务器的。要把它写在:[mysqld]段中。
(2)、复制启动MySQL数据库服务器的启动脚本，并命名为：mysqld

1

[root@node1 mysql]# cp support-files/mysql.server /etc/init.d/mysqld

检查是否执行权限

1
2

[root@node1 mysql]# ll /etc/init.d/mysqld
-rwxr-xr-x 1 root root 10650 Aug 20 15:55 /etc/init.d/mysqld

(3)、把mysqld服务启动脚本添加到chkconf的控制列表里，能够使用【server】命令控制服务的行为。 可以实现开机自动启动。

1
2
3

[root@node1 mysql]# chkconfig --add mysqld
[root@node1 mysql]# chkconfig --list mysqld
mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off

5、启动MySQL数据库并修改设置用户
启动MySQL数据库服务器

1
2

[root@node1 mysql]# service mysqld start
Starting MySQL.. [ OK ]

查看监听端口

1
2

[root@node1 mysql]# netstat -anptl | grep mysqld
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3041/mysqld

注意：

㈣ 海量日志数据存储用 elasticsearch 和 hbase 哪个好

从基本功能来说这两个确实有相似性，但是根据业务需求不同，我觉得有几点可以考虑：
1. 查询复杂度：HBase支持简单的行或者range查询，比如给一个PK查该行的数据，或者给一个begin/end查这个范围的数据，如果想完成更复杂的功能就不太容易。而ES支持的查询比较丰富，或者说这些查询都带有一点复杂计算的味道了。比如你有个论坛，你想查帖子里面是否包含敏感词，如果采用HBase就比较麻烦，使用HBase你可以将帖子存进来、读出去，但是要查内容里面的东西，只能一点点过滤；而ES是可以比较方便的帮助你完成这个功能的；
2. 数据量：按道理说两者都是支持海量数据的，但是据我个人感觉，HBase可能更容易支持更多的数据，因为其一开始设计就是解决海量问题的；而ES是后来慢慢增强其存储扩展性的；那么也就是说，HBase上手起来扩展性不太会阻碍你使用；ES可能要多费点劲。当然，听说也有人写了ES基于Azure或者S3的存储插件，但是稳定性不知道如何；
3. 剩下的就是比较远的考虑，比如维护性，HBase基于Hadoop那一套，组件多，维护起来代价也不低，而ES自成体系，维护起来稍微好点；当然这个是相对的，绝对来说都不会容易。

㈤ 用什么数据库存储访问日志做分析比较好

日志记录的是，我们操作系统或某个服务或某个软件在运行过程当中所产生事件信息的，这对于我们后续分析系统比较有价值。
比如，某个服务在运行过程中出现故障了，就可以查看该服务的日志信息，分析日志找出服务出现故障的原因所在。
如：我们使用【yum】工具安装软件，系统都会把程序yum做的操作记录到日志里。
如果，我们管理的不是一台主机，每台主机的日志信息都是单独存放的，如果要分析报告当前所有主机的的所有服务的过去某一时间段运行状态，我们则要逐一查看每一台主机的日志文件了。这很不方便。不利于使用一些日志分析工具来分析日志。所以我们要做日志的集中化存储。意思是说：把所有主机产生日志信息发往日志服务器，由日志服务器帮助众多需要存储日志数据的主机存储日志数据。
存储日志数据有两种方式：
1、使用文件存储日志数据
2、把日志信息存储到数据库里

㈥ 如何实现日志的集中化存储以及使用loganalyzer做日志分析

如何实现日志的集中化存储以及使用loganalyzer做日志分析
1、下载网站日志：

流程如下：主机独立控制面板——网站情报系统分析——网站日志——下载WebLog日志——右键点击查看，链接另存为

在主机独立控制面板中，找到网站情报系统分析板块，里面就能看到网站日志了，点击下载WebLog日志，能看到最近几天的网站日志，但是点击查看进去，会发现是一堆看不懂的代码，没有关系，我们先不要进去查看，而是右键点击查看，链接另存为，下载网站日志。
——————
2、代码看不懂的话，可以使用光年日志分析软件GnAnalyzer，这是一个可以帮助我们进行网站日志分析的软件。比如蜘蛛抓取的情况，日志里面都有显示。
——————
3、光年日志分析软件的使用：

下载好网站日志后，就可以使用光年日志分析软件进行网站日志的分析了。

流程如下：光年日志分析软件文件夹中的GnAnalyzer.exe——文件菜单，新建任务——添加（类型选择所有文件）——下一步，保存——马上分析
——————
4、网站日志分析：

马上分析后，就可以查看当天：蜘蛛分析（概要分析、目录抓取、页面抓取、IP排行）；搜索引擎分析（关键字分析）；状态码分析（用户状态码、蜘蛛状态码）的相关信息。

㈦ exchange 2003 事务日志文件存储空间不足，怎样处理啊请各位大侠指导啊。 QQ：278209287

删除一些日志文件就好了。

㈧ 深入理解kafka(五)日志存储

5.1文件目录布局
根目录下有以下5个checkpoint文件: cleaner-offset-checkpoint, log-start-offset-checkpoint, meta.properties, recovery-point-offset-checkpoint, replication-offset-checkpoint
分区目录下有以下目录: 0000xxx.index(偏移量为64位长整形，长度固定为20位), 0000xxx.log, 0000xxx.timeindex.
还有可能包含.deleted .cleaned .swap等临时文件, 以及可能的.snapshot .txnindex leader-epoch-checkpoint
5.2日志格式演变
5.2.1 v0版本
kafka0.10.0之前
RECORD_OVERHEAD包括offset(8B)和message size(4B)
RECORD包括:
crc32(4B):crc32校验值
magic(1B):消息版本号0
attributes(1B):消息属性。低3位表示压缩类型：0-NONE 1-GZIP 2-SNAPPY 3-LZ4(0.9.x引入)
key length(4B):表示消息的key的长度。-1代表null
key: 可选
value length(4B):实际消息体的长度。-1代表null
value: 消息体。可以为空，如墓碑消息
5.2.2 v1版本
kafka0.10.0-0.11.0
比v0多了timestamp(8B)字段，表示消息的时间戳
attributes的第4位也被利用起来，0表示timestamp的类型为CreateTime，1表示timestamp的类型为LogAppendTime
timestamp类型由broker端参数log.message.timestamp.type来配置，默认为CreateTime，即采用生产者创建的时间戳
5.2.3 消息压缩
保证端到端的压缩，服务端配置compression.type，默认为"procer",表示保留生产者使用的压缩方式，还可以配置为"gzip","snappy","lz4"
多条消息压缩至value字段，以提高压缩率
5.2.4 变长字段
变长整形(Varints):每一个字节都有一个位于最高位的msb位(most significant bit),除了最后一个字节为1，其余都为0，字节倒序排列
为了使编码更加高效，Varints使用ZigZag编码:sint32对应 (n<<1)^(n>>31) sint64对应 (n<<1)^(n>>63)
5.2.5 v2版本
Record Batch
first offset:
length:
partition leader epoch:
magic:固定为2
attributes:两个字节。低3位表示压缩格式，第4位表示时间戳类型，第5位表示事务(0-非事务1-事务)，第6位控制消息(0-非控制1控制)
first timestamp:
max timestamp:
procer id:
procer epoch:
first sequence:
records count:
v2版本的消息去掉了crc字段，另外增加了length(消息总长度)、timestamp delta(时间戳增量)、offset delta(位移增量)和headers信息，并且弃用了attributes
Record
length:
attributes:弃用，但仍占据1B
timestamp delta:
offset delta:
headers:
5.3日志索引
稀疏索引(sparse index):每当写入一定量(broker端参数log.index.interval.bytes指定，默认为4096B),偏移量索引文件和时间索引文件分别对应一个索引项
日志段切分策略：
1.大小超过broker端参数log.segment.bytes配置的值，默认为1073741824(1GB)
2.当前日志段消息的最大时间戳与当前系统的时间戳差值大于log.roll.ms或者log.roll.hours，ms优先级高，默认log.roll.hours=168(7天)
3.索引文件或者时间戳索引文件的大小大于log.index.size.max.bytes配置的值，默认为10485760(10MB)
4.偏移量差值(offset-baseOffset)>Integer.MAX_VALUE
5.3.1 偏移量索引
每个索引项占用8个字节，分为两个部分：1.relativeOffset相对偏移量(4B) 2.position物理地址(4B)
使用kafka-mp-log.sh脚本来解析.index文件(包括.timeindex、.snapshot、.txnindex等文件)，如下:
bin/kafka-mp-log.sh --files /tmp/kafka-logs/topicId-0/00……00.index
如果broker端参数log.index.size.max.bytes不是8的倍数，内部会自动转换为8的倍数
5.3.2 时间戳索引
每个索引项占用12个字节，分为两个部分：1.timestamp当前日志分段的最大时间戳(12B) 2.relativeOffset时间戳对应的相对偏移量(4B)
如果broker端参数log.index.size.max.bytes不是12的倍数，内部会自动转换为12的倍数
5.4日志清理
日志清理策略可以控制到主题级别
5.4.1 日志删除
broker端参数log.cleanup.policy设置为delete(默认为delete)
检测周期broker端参数log.retention.check.interval.ms=300000(默认5分钟)
1.基于时间
broker端参数log.retention.hours,log.retention.minutes,log.retention.ms,优先级ms>minutes>hours
删除时先增加.delete后缀，延迟删除根据file.delete.delay.ms(默认60000)配置
2.基于日志大小
日志总大小为broker端参数log.retention.bytes(默认为-1，表示无穷大)
日志段大小为broker端参数log.segment.bytes(默认为1073741824，1GB)
3.基于日志起始偏移量
DeleteRecordRequest请求
1.KafkaAdminClient的deleteRecord()
2.kafka-delete-record.sh脚本
5.4.2 日志压缩
broker端参数log.cleanup.policy设置为compact，且log.cleaner.enable设置为true(默认为true)
5.5磁盘存储
相关测试：一个由6块7200r/min的RAID-5阵列组成的磁盘簇的线性写入600MB/s，随机写入100KB/s，随机内存写入400MB/s，线性内存3.6GB/s
5.5.1 页缓存
Linux操作系统的vm.dirty_background_ratio参数用来指定脏页数量达到系统的百分比之后就触发pdflush/flush/kdmflush，一般小于10，不建议为0
vm.dirty_ratio表示脏页百分比之后刷盘，但是阻塞新IO请求
kafka同样提供同步刷盘及间断性强制刷盘(fsync)功能，可以通过log.flush.interval.messages、log.flush.interval.ms等参数来控制
kafka不建议使用swap分区，vm.swappiness参数上限为100，下限为0，建议设置为1
5.5.2 磁盘I/O流程
一般磁盘IO的场景有以下4种：
1.用户调用标准C库进行IO操作，数据流为：应用程序Buffer->C库标准IOBuffer->文件系统也缓存->通过具体文件系统到磁盘
2.用户调用文件IO，数据流为：应用程序Buffer->文件系统也缓存->通过具体文件系统到磁盘
3.用户打开文件时使用O_DIRECT，绕过页缓存直接读写磁盘
4.用户使用类似dd工具，并使用direct参数，绕过系统cache与文件系统直接读写磁盘
Linux系统中IO调度策略有4种：
1.NOOP：no operation
2.CFQ
3.DEADLINE
4.ANTICIPATORY
5.5.3 零拷贝
指数据直接从磁盘文件复制到网卡设备中，不需要经应用程序
对linux而言依赖于底层的sendfile()
对java而言，FileChannal.transferTo()的底层实现就是sendfile()

㈨ 怎么样保存网上的日志

1--脱机使用和收藏这个功能不能实现日志保存
2--楼上方法都没试过，我是通过保存视频 音乐 的通用方法来实现日志保存的并且n年前就开始这样保存了~~
打开空间--网络日志--选中所有要保存的日志（按shift或者ctrl实现全部选中不用教了吧）--在选中区域任意位置按右键--在弹出的菜单中选择“使用迅雷下载”
3--如果楼主不使用工具下载的话也可以直接下载，强调的是不要错误的选择了“下载选中连接”
4--仍然建议使用工具，下载后可以方便的选择保存位置~如果没有想好保存在哪里，就暂时放在工具里面也无所谓，中毒了也不容易丢失