最近在折腾 Rsyslog ,传输日志,对他怎么说呢,谁用谁知道,我仅仅是了解使用的程度,对于里面的坑以及使用策略还没有那么深入,不过日后会逐步的细化了解,其实现在对于日志传输来过网上一大堆技术方案任你选.但是感觉用rsyslog传输还是最方便,最快捷的.他以不变应万变,看图说话:
可见rsyslog的覆盖面是相当的广泛.奈何近几日,打算把redis替换为 kafka ,本篇主要记录 rsyslog 与 kafka 的对接使用. 上了.
通过对 rsyslog官方文档 查看,得知 rsyslog 对 kafka 的支持是 v8.7.0 版本后才提供的支持.通过 ChangeLog 也可以看出 V8.X 的版本变化.
查看本机的rsyslog版本:
rsyslog.x86_64 7.6.3-1.el6 ...最近在了解消息队列,主要是之前用的是redis,redis固然非常好用,但是也有相应的使用场景.随着数据量的增长,redis已经不能满足现在的需求了.所以需要找个更好的替代品.问了一圈大牛,也google一番,锁定在kafka上了.关于kafka怎么"玩",我也不知道,算是在摸索当中,想要知道安装使用等方法,请移步Google吧.虽然kafka我不会玩,但是我会玩怎么监控它.
kafka-web-console,是kafka自己的一个Web管理界面.开源的东西好是好,但是不知道是不是开源的大牛B们都不愿意写文档!!出来个东西,居然没有安装步骤,只是有一些简单的使用说明,甚至说明都不详细,对于此点表示很坑!
1.先下载安装scala构建工具sbt
#本安装环境为centos6.5
curl https://bintray.com/sbt/rpm/rpm > bintray-sbt-rpm.repo
sudo mv ...如果自己设计一套chunkserver选择算法,我们要达到哪些目标呢?
- 文件打散后尽量平均分布到各台chunkserver上
- 各台chunkserver上的chunk数量尽可能的平均
- 数据分发过程衡量系统负载，尽量把数据放在负载低的chunkserver上
- 数据分发过程是否应该衡量各台chunkserver的可用空间?
- 机架感应?
回到MFS使用过程中会有一个疑问.chunkserver的选择是怎么选择的.怎么才能保证数据保存占用空间平衡甚至平均?这就是数据分布算法.也正是分布式文件系统的核心容.所以在此,转来一篇关于MFS的chunk存储选择算法的文章.
还记得matocsserventry结构中的carry字段么,这个字段就是分布算法的核心.每台chunkserver会有自己的carry值,在选择chunkserver会将每台chunkserver按照carry从大到小做快速排序,优先选择carry值大的chunkserver来使用.
在描述具体算法前,先介绍三个概念:
allcnt:mfs中可用的chunkserver的个数
availcnt:mfs中当前可以直接存储数据的chunkserver的个数
demand:当前文件的副本数目
先说allcnt,可用的chunkserver要满足下面几个条件:
- chunkserver是活着的
- chunkserver的总空间大于0
- chunkserver的可用空间(总空间-使用空间)大于1G
availcnt指的是carry值大于1的可用chunkserver的个数.也就是在allcnt的约束条件上加一条carry值大于1.文件1.txt需要存储2个副本,但是mfs中仅仅有1台chunkserver可用,也就是demand>allcnt的时候,mfs会自动减少文件的副本个数到allcnt,保证文件可以成功写入系统.
关于carry有下面几个规则:
- 仅carry值大于1的chunkserver可以存储新数据 ...
博客算是正式用起来了,觉得还不错,但是经过查看或是浏览其他人的博客,感觉自己的还是那么的low.为什么呢?因为没有选择一个高大上的主题,没有使用优秀的插件,没有做相关优化.查了查,还有好多后续工作要做.以下就对博客的插件等设置使用总结下.
简单粗暴的设置可以看这里主题设置相关简介.但是我还想说,上面的那些设置还远远不够.
这里推荐一些优秀的主题
Elegant,清俗淡雅.
pelican-bootstrap3,我早期用的一个主题,其中自己改了一些东西.此主题有些问题在于宽屏展示的会出现字体有宽边.
pelican-fresh.我现在使用的主题.各方面还都不错.
当然其实还有好多的优秀主题没有加入到官方主题库,要善用github的搜索功能.
插件的使用会使你的博客增添一些好的功能.例如评论功能.这里我推荐一些不错值得装的插件.另外官方也有提供插件库.
sitemap
sitemap可以生成xml和txt格式的网站地图,配置见插件的readme.
gzip_cache
gzip_cache,可以将所有的页面压缩为gz格式,相对来说能加快页面的加载速度.
neighbors
neighbors,邻居导航,也就是我们常说的上一篇下一篇文章
related_posts ...
继上篇,感觉说了好多废话,多半是配置文件相关参数,作为一个基础运维人员,更关注的是怎么让服务更加稳定(高可用),出现问题如何恢复(容错)等,更接地气的东西打算在下面介绍下.
master启动后,metalogger\chunker\client三个元素都能自动与master建立连接.
正常启动顺序:matser---chunker---metalogger---client.
关闭顺序:client---chunker---metalogger---master
客户端强制 kill -9 杀掉 mfsmount 进程,需要先 umount ,然后再 mount ,否则会提示:
fuse: bad mount point `/mnt/test/': Transport endpoint is not connected
see: /data/jingbo.li/mfs/bin/mfsmount ...之前面临大量数据存储问题,于是开始选择分布式文件系统.于是MooseFS便映入眼底.正好之前用过,所以直接拿来就用.光会用也不行,闲来之时对他进行了一些简单了解,不管是百度还是谷歌,搜到的都是零零散散的东西,更多的博客都是抄來抄去,所以打算自己做些整理,下面就我对MFS的认识进行一下总结.
- 高可用性(数据可以存储在多个机器上的多个副本)
- 可动态扩展随时新增加机器或者是磁盘
- 可回收在指定时间内删除的文件(“垃圾回收站”是一个系统级别的服务)
- 可以对整个文件甚至在正在写入的文件创建文件的快照.
- 使用和部署非常简单,直接mount使用
对于 Moosefs 的介绍我在此就不详细说了,更多介绍可以查看 官网 以及 英文版权威指南 或是查看田逸所翻译总结的 权威指南 ,以上介绍的比自己总结的可能更加详细.我后面的总结是对以上内容的补充.
*AD:更多资料详见GitHub
- 管理服务器managing server(master):负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝.单个机器管理整个文件系统,用来存储记录每一个文件的Metadata(记录文件的大小 ...