Follow me on GitHub

  1. 2016年终总结

    又到了年终总结的时刻了,回首过去,已经继续了两年,对于我这种不是很勤奋的人来说,真不知道能把每年最后一天的几个小时留给年终时刻会坚持到什么时候.当心里开始有对写年终总结的时候,那说明2016过的如此苍白和无力.

    0X01 工作

    从年初开始,有机会去鹅厂开眼,毕竟鹅厂之前技术相对比较封闭,最近几年才开始慢慢走向开放的.交流从开始的兴奋到后面的失落.就像人心中想象看到了东升的太阳,而实际却看到了落日的余辉.主要是自以为技术有一定积淀,看到人家所做所想,自愧不如,犹如闭门造车,小打小闹.

    交流完毕回来痛定思痛,于是开启本年度最悲伤的项目BDMC,此项目的杀伤力很大,从开始到现在,从最初的6/7个人,剩下了2个人（我把他们都耗走了！）.有如此大杀伤力的项目我想流出专门一篇来写,在此就不细述了.

    当然人是理性和现实的,工作中也不例外,年中开始,经历的人的悲欢离合曲终人散,老大带有一部分人去创业了,另外的同事也都找到了自己的理想工作,只有我还在此挣扎发挥最后的余热.

    技术博客也被托的零零散散,刚看了下,只有三篇产出,平时不是没有技术问题或是技术积累,只是自己的小放纵,导致仅仅有三篇,不过幸好在年低的几天,有了几个开源产出:

    1.https://github.com ...

    Read more...

  2. elasticsearch 服务的监控与报警

    近段时间,由于公司报警系统结构调整,由小米开源的 Open-Falcon 替换了原有的 Zabbix 监控系统,使得一些原自定义监控不可用,于是便着手在新监控系统下完善了 Elasticsearch 服务的监控.

    0x01 Elasticsearch 服务架构

    只谈监控不谈架构那如同耍流氓,监控可以追溯历史,查故障原因,分析瓶颈点,作为服务来说需要全面监控.

    es_monitor

    注: 1.elasticsearch 我们是按角色部署,前面顶了个nginx,可以控制相关访问以及负载.

    2.整个服务监控指的是系统的各个组件,图中有直接关联基础监控部分,也有没有关联的基础监控

    0x02 可监控项

    0x02.1 基础监控

    基础监控是监控系统的基本功能,包含:CPU/IO/网络/内存等等,在此就不说了.

    0x02.2 Nginx 日志监控

    监控到用户的访问量,一些非法请求或是不正常请求情况.

    0x02.3 Elasticsearch ...

    Read more...

  3. django之基于Class-View定制统一API

    近期部门启动了一个"朝阳"项目,从项目规划选型到完成初版披荆斩棘,今仅对项目中用到的知识点作总结,如果项目发展顺利,后期再继续分享我们的"朝阳"项目更多细节.

    0x01 Django框架

    django用来开发内部的运维系统和支持系统个人认为是个不错的选择.你有权力说其他语言,其他框架,我也有权利保持沉默,暂且不挑起语言之争(其实php是世界上最好的语言.^_^). Django严格来说是一个MTV框架,结构与传统MVC架构没有太大的区别.它的核心包含以下几部分:

    1. Model层,一个对象关系映射,作为数据模型和关系型数据库的媒介,对数据的封装简直太友好了
    2. URL(Controller)层.一个基于正则表达式的URL分发器
    3. View层,一个用于处理HTTP请求的系统和web模版渲染系统

    另外Django的一个好处就是模块化设计,每一个模块在内部都称之为APP,在每个APP里面都有自己的三层结构. 如图:

    django_app_arch

    模块化后,不仅可以在开发的时候更容易理解系统,而且因为每个APP都是独立的应用,可以尽量的减少系统的耦合,便于系统后续的扩展和维护.

    ps: 个人认为脚本语言+框架开发是映射现在互联网风的,快速迭代,小步快跑,为快不破,对于臃肿的语言+自己写框架来说更胜一筹.

    0x02 Class-View ...

    Read more...

  4. elasticsearch调优之Merge

    0x01 背景

    天苍苍,野茫茫,过完春节就要忙,服务压力跟不上,用服务器数量来抗.多数人认为这个套路能简单粗暴的解决问题,当然我也不例外.

    春节刚过,我司流量跟着上来了,作为基础的日志处理服务,需要保障流量上涨后的性能和稳定.重头就在es集群性能.于是着手对集群整体进行硬件上的资源扩充.

    • 提高服务器配置和数量 从原来的8台机器扩充到11台机器(这里指的是data node),从原来的 24 core/128g mem/4T * 12 data 扩充到 32 core/128g mem/1T * 24 data.(不要羡慕我司的土豪,有钱就是任性!).

    • 增加消费者(index端) 部分日志处理从 logstash 换成 hangout ( java实现的类Logstash几个常用input/filter/output,在效率上面有很大提升,感谢@携程同学的开源) 并调优相关写入策率 ...

    Read more...

  5. 2015(自嗨型)年终总结

    算是续去年的节,今年免不了需要做个年终总结,当然是别人眼中的"自嗨".在我看来不是朋友圈的三言两语就能总结去年一年的过往,总结是需要长篇大论的扯淡的!

    0X01 工作

    从2014年就开始注定,一年的工作都放在了搞日志分析上

    从2.5台服务器开始,到现在10+台服务器,2月的失败记忆犹新,自认自命不凡,肩负重任,结果来的还是太意外,总之还是太年轻了.之后忍辱负重,抗起抗战大旗

    6月份的职级评审,令自己更加清晰的认识了自己,不过在此我想说,xxx(其中一个评委)你出来,我们谈谈!是你,是你,就是你,让我在反思中成长,结果反思的有些过头了,差点在9月份点亮我的新技能,开启职业生涯的第三段旅程,第三段旅程虽然没有成为现实,但是还是能够影响到为整个的人生轨迹的.

    10月份经历过人生的动荡期,貌似整个人都变好了.让我知道了以后不会再做那么草率的决定.但是时不时还是会有果断偏激的想法.比如现在重整的团队,换汤不换药我感觉行不通(那谁,你有想法咱们私下聊).团队需要大的方向和指标,而不是每一次邮件中的计划,要我说执行比什么都重要

    12月好比拿着石头在探路,具体哪条路走的通那得看下一年的年终总结怎么写了 ...

    Read more...

  6. logstash的kafka插件使用(更新)

    通过kafka传输

    Kafka 是一个高吞吐量的分布式发布订阅日志服务，具有高可用、高性能、分布式、高扩展、持久性等特性。目前已经在各大公司中广泛使用。和之前采用 Redis 做轻量级消息队列不同，Kafka 利用磁盘作队列，所以也就无所谓消息缓冲时的磁盘问题。此外，如果公司内部已有 Kafka 服务在运行，logstash 也可以快速接入，免去重复建设的麻烦。

    如果打算新建 Kafka 系统的，请参考 Kafka 官方入门文档：http://kafka.apache.org/documentation.html#quickstart

    kafka 基本概念

    以下仅对相关基本概念说明，更多概念见官方文档：

    • Topic 主题，声明一个主题，producer指定该主题发布消息，订阅该主题的consumer对该主题进行消费
    • Partition ...

    Read more...

Page 1 / 4 »