去年我们社区一起翻译了一本书《Elasticsearch权威指南》，并且已经在官方上线了，链接：
https://www.elastic.co/guide/cn/index.html 
 
撒花~ ???????????????????
 
我想给大家分享一些这本书后面的故事：
 
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
 
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
 
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
 
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
 
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
 
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
 
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
 
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spread]https://docs.google.com/spread ... 84528[/url]
 
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsear]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
 
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
 
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
 
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
 
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！


 

 
1、深入详解Elasticearch：http://blog.csdn.net/column/de ... .html
 
2、这个专栏，起初主要用来研究关系型数据mysql/oracle非关系型数据库mongo与Elaticsearch的实时同步问题，随着延伸和项目需要，还会路线拓展ES java开发等问题；
 
3、之前的研究都是基于Elasticsearch2.3.4版本。基础原理想通。 5.X，6.X版本后续也会跟进。
 
欢迎大家品鉴，多提不足！
 
终生学习者：铭毅天下，博客地址：http://blog.csdn.net/laoyang360

职位描述：
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。

任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；

在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。

福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。

Grok 是一个常用的对日志进行结构化的一个工具，
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
 
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
 
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。


 
PS: 
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。