顺序第3周,其实是第6周了。
申请过的用户已经通过申请邮箱邮件推送
HSVS 内网版部署指南
定义
hcap: hsvs HTTP流还原模块,使用Docker方式安装部署
hsvs-mbridge: hsvs 预处理模块,使用Dockr方式安装部署
ElasticSearch: 开源文档存储引擎https://www.elastic.co
kafka: 开源分布式消息队列 http://kafka.apache.org
redis: 开源内存k/v数据库 https://redis.io/
nsq: golang开发的开源分布式消息队列 https://nsq.io
部署方案
为了方便适配各种规模企业的使用场景,HSVS支持三种消息中间件redis/nsq/kafka。
kafka方案
优点: kafka吞吐率,稳定性,持久化很优秀,经过长期实践检验,kafka可以多group消费者同时消费一topic数据,方便自定义开发分析程序
缺点: kafka部署较为麻烦,kafka要配合zookeeper来使用; 优先选择企业内部已经搭建好的kafka,最新版的kafka已经集成了zookeeper,如果需要自己搭建请参考http://kafka.apache.org/quickstart
nsq方案
优点: nsq是一个golang开发的消息中间件,部署简单,使用也简单,支持持久化,支持多group消费者消费同一topic数据。
缺点: nsq设计理念是本地agent,所以如果在镜像流量的节点nsq消息两会大幅大于其他端点,没有实现想要的负载均衡。
redis方案
优点: 部署简单,可以使用企业已有redis(目前不支持redis集群)
缺点: 目前hcap不支持写入集群,redis不支持多group订阅消费,无法自定义分析程序,且不支持持久化。
抓取过滤器规则
hcap支持按照域名和资源来进行过滤,只保留自己所需要的内容
[FILTER]
include_domains = *.baidu.com
exclude_domains = ad.baidu.com
drop_extentions = png,jpg,bmp,css,js,gif,ico,woff,woff2,ttf,eot
drop_urls =
drop_resp_types =
drop_req_types = multipart/form-data
说明
* include_domain: 只有匹配到这里的规则的数据才会被保留
* exclude_domain: 在include_domain之后,会排除掉匹配到这条规则的字段
* drop_extenstions: 如果扩展名是这些,那么响应体(response.body)会被drop掉,其他记录任然会保留
* drop_urls: 丢弃指定URL的记录,只保留记录
* drop_resp_types: 根据响应的content-type来丢弃响应体(response.body)
* drop_req_types: 根据请求体来丢弃响应体(response.body)
使用kafka时 分区数hsvs-mbridge对应关系
kafka对生产者的个数没有限制,HSVS使用轮训随机写入多个分区 kafka对消费者的数量有限制,应当能够被分区书目整除,负责会出现有的分区时钟无法被消费的情况。 kafka分配分区时建议按照2的整数倍进行分配,建议从4开始,如果不够,那么分配8、16,消费者hsvs-mbridge 建议从2开始,如果不够加到4.通常2Gbps下,4个hsvs-mbridge足够应对。
怎么查看处理性能是否足够,是否需要扩容。 系统搭建完毕后在kibana中可以看到没跳抓取的内容。 没条记录里均含有三个时间raw_time和@timestamp,raw_time表示网卡抓取到数据的时刻,@timestamp表示hsvs-mbridge的处理时间。如果相隔距离越来越大,表明消费者处理能力不够,需要增加。 另外查看每一个hsvs-mbridge的CPU占用率也是重要的参考。
判断kafka分区数目是否需要扩容,通过经验值+带宽估算,kafka主要的性能瓶颈是带宽。 千兆网络环境下,kafka broker性能等于带宽乘以broker所在物理机数量。 通常设计时,分区数量的性能应当在最大流量的两倍。
更新历史:
点击原文链接查看详细手册
本文分享自微信公众号 - 这里是河马(gh_d110440c4890)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。