The Mirages

通常大家都用ELK，但是这个世界就永远不会被一样事物统一的，主要是grafana也支持从ES中进行查询了，那就用下，毕竟grafana的界面比kinbana好看很多，虽然都是现成的，也没有二次开发的内容，但是还是会碰到一些问题，这个用ELK其实也会碰到的。 首先，默认fluentd是没有type标志的，这样导致默认到es中的都是string类型，这样只能做count了。所以我们要在所有client上安装fluent-plugin-typecast这个插件。 然后在服务端需要安装2个插件，其实一个就可以了fluent-plugin-elasticsearch, fluent-plugin-secure-forward。 用来支持传输到es中。 好了下面就是fluentd的具体配置了。首先是client端就是靠tail来收集， 但是重点是format的部分如何去匹配，还得考虑日志中的多种不同格式。 同时在打tag的时候把机器名也打进去，这样汇总的时候方便找从哪个nginx过来的日志。 还有type的部分可以把非string的给单独拉出来进行处理，string的就不用处理了。 下面这个是fluentd客户端上的配置： ```c
type tail path /opt/server/log/nginx/nginx-access.log format /^(?[^ ])\s+(?[^ ]) (?[^ ]) \[(?[^ ])\] “(?\S+)(?: +(?[^\“]) +\S)?” (?[^ ]) (?[^ ])(?: “(?[^\“])” “(?[^\“])” “(?[^\“])” (?[^ ])\s+(?[^ ])\s+(?[^ ])\s+(?[^ ])\s+(?[^ ]))?$/ time_format %Y-%m-%dT%H:%M:%S%z types status:integer,size:integer,response_time:float,upstream_time:float,cache_status:integer,upstream_status:integer tag “#{Socket.gethostname}.nginx.access.log” pos_file /var/log/td-agent/tmp/nginx.access.log.pos <match .nginx.access.log> type forward flush_interval 60s buffer_type file buffer_path /opt/server/buffer/ host agg1.hk.op.xxx.com port 24224

1
2
3

 <match *.nginx.access.log> type copy <store> type file path /opt/server/logs/nginx-access/ time_slice_format ./nginx-access/%Y/%m/%d/%Y%m%d%H.nginx.access compress gzip flush_interval 10m time_format %Y-%m-%dT%H:%M:%S%z buffer_path /opt/server/buffer/nginx_access_buffer buffer_type file buffer_chunk_limit 50m </store> <store> type elasticsearch host hk1.es.op.xxx.com port 9200 include_tag_key true tag_key @log_name logstash_format true flush_interval 10s </store> </match> 
```   es的安装的部分就不在这里展开了，也许会在其他地方说下。不过要推荐一个工具kopf， zou哥去es大会上听来后马上给装上了，还不错，可以看到index,  node, share 这些信息，而且随着cluster的健康状态会以不同的颜色来显示出来，这样还是很贴心的。 下面这个就是一个运行的截图 [![kopf](https://images.timoq.com/2015/12/kopf.png)](https://images.timoq.com/2015/12/kopf.png) grafana的安装也不说了，我用的是2.5 stable版本，支持了es做为datasource， 也支持用户验证等等。 默认grafana是用query_string来进行全文匹配，而且不支持正则，不过grafana也支持自定义书写es查询 [https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html) https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html 根据上面的语法我们就可以自定义自己的查询语句。不过我更喜欢正则匹配。 [![grafana-regex](https://images.timoq.com/2015/12/grafana-regex.png)](https://images.timoq.com/2015/12/grafana-regex.png) 第一天用正则匹配发现了问题，怎么都匹配不上URL，后来group by 一下，居然发现png，jpg这些排在最前面，于是查了下原因， 正则不匹配的原因是因为es默认通过/ . 这些符号来进行默认分词。 那就只好更改es的index template,  把某些字段不让它进行分词，下面是我自己建立的一个template, 只用在某些index中。也可以在kopf中进行定义。 ```c
 curl -XPUT http://hk1.es.op.xxx.com:9200/_template/template_1 -d ' { "mappings": { "_default_": { "_all": { "enabled": false }, "_source": { "compress": true }, "properties" : { "path": { "type": "string", "index": "not_analyzed" }, "referer": { "type": "string", "index": "not_analyzed" }, "agent": { "type": "string", "index": "not_analyzed" } } } }, "settings": { "index.cache.field.type" : "soft", "index.refresh_interval": "5s", "index.store.compress.stored": true, "index.number_of_shards": "3", "index.query.default_field": "querystring", "index.routing.allocation.total_shards_per_node": "2" }, "template": "logstash-*" }' 

由于前几次产检结果有臀位，所以在上周四挂了一个麻醉门诊。结果根本没必要那么早去，根本没人挂那个门诊。后来结果等半天来了个医生3分钟就打发了，不过至少也打消了球子说生刨的顾虑了，那这个号也算值了。

不过小小球啊，你就赶紧转过来吧，你妈不想刨腹，还是希望能够顺产的。

还有小小球啊，可恶的医生一会儿说你妈肚子小，然后你妈那半个月老是晚上加餐，体重曲线眼看着超过之前的图表卡了。

然后半个月过去后，照了个B超，又说小小球你长的比别的宝宝要高，还问你妈你爸是不是也高，所以估计你就比别人高了要。

这周你妈又去查了血糖，也都在正常范围内。所以你就放心吧，主要还是前段时间你妈吃多了导致的。

运维的基础就是统一，没有统一啥都是扯谈。 首先是hostname，IP，DNS的统一规划，这个是后续一切的根本。 hostname一定是要可识别具体上面的应用程序的。比如nginx01-bid-hotel.sh1.cn , 这个名字就可以很好的识别部门，项目和具体的应用。同时也可以识别到所在的机房。 为什么要用nginx01呢，不写web01呢，因为用web你是不知道这个是nginx只是代理还是真实的app应用呢。所以我个人用上面的应用程序进行分类，而且尽量不要缩写，毕竟这个是一次性的，你要缩写了你自己清楚，别人未必能够清楚。 IP这个问题，如果可以自己分配的，那必须按需分配好了。先说大的网段。千万不要一个机房就 10.0.0.0/8 这样的进行分。一般来说我们单一一个IDC不会超过256的3次方的机器数量，所以我们一般一个独立IDC都是用10.10.0.0/16 这样的方式来进行，第二个10一般是用省市的电话区号来进行区分，有些省市区号是3个数字或者4个数字，那就自己去编吧。 然后我们说小的，从我个人经验来说，一般会给远程控制卡，运维等基础服务会单独进行分网段。 所有的网关地址都应该是内部的交换机接口，一般都是设置 10.x.x.1/24 这样的。所有的应用最好把网段分的开一点，这样不会导致最后同一应用的网段太分散，比如hadoop集群这样的更要多留几个网段。至于某些领导喜欢吉利数字的网段和IP你也得考虑下。 关于DNS，所有内部服务器地址都是通过dns来获取的，千万别省事弄个hosts文件这样的。而合理的dns设置就应该跟hostname一样就可以了，但是在resolv.conf也要配置好searchdomain 和 重试间隔和次数。 这样大家ping的时候可以偷懒一下,  以及万一你一台DNS挂了不至于等很长时间。  至于nscd的使用还是看实际情况吧。 关于RPM源，这个这么多年还是感觉自己搭建和同步会比较好，一个是速度问题，一个是版本控制问题。虽然在时效性上会没有公共源快，但是我们可以保证速度，不然一旦所有机器同时更新你的公网带宽就挂了。而且时效性主要是看你同步的频率是怎么样的。同时每个IDC之间可以通过rsync进行同步。同时gpgkey还是需要的。 但是gem源，pypi这样的源是否还需要自己建立，这个主要是要评估内部使用的规模来进行了。 系统账号管理，这个无论你用系统本身的，还是LDAP，还是kerberos这样的，绕不过去的就是uid和gid。我一般都会给运维，开发，测试，程序都分不同的起始，比如运维10000开始，开发20000开始这样的。程序启动账号都是5000开始的nologin这样的账号。 同时组的设定也要注意，毕竟后面sudo权限的设置呢还。 安装包目录的统一，要/usr/local或者/opt/app 这样的，个人喜欢把程序，日志，配置文件放在一起。比如 /opt/app/nginx/{logs,sbin,conf,cache} 这样的，也有 喜欢 /opt/app/{logs,sbin,conf}/nginx 这样的。我喜欢那样的只是很方便的进行RPM打包，而且编译参数也比较简单。而且一般一个机器的应用就一个或者几个而已。 日志的收集。 都什么年代了，还一台台看呢。Linux系统日志都必须集中到日志服务器啊，rsyslog不就是干这个的，logwatch就是来进行分析和报警啊。特别是一些kernel类型和sercurity的日志。那程序的log呢， fluentd, flume这些不就是干这些个事情的。当然首先你要准备个大磁盘够装下3年的数据，至于用hdfs，还是glusterfs来装，但是千万别用mongodb来装。

这次产检约的是上午8点到9点之间. 结果球子嫌早，愣是拖到了9点半才到医院。

结果怎么着，人说过号了就要等其他人都看完了才能看，结果小小球你爸上午就白请假了。

等到了12点多，也最终没有看上上午的。下午一点就开始看了，一看也来不及回家吃了，就大众点评查了宽小面，结果点评上的地址还是错的，不过最终还是找到了。马上吃完就回医院了马上，下午就球子妈陪球子看了。

这以后说好的时间可不能再迟到了，之前球子就是在新院看人老迟到，结果自己一来就被延到最后了。

这次产检又要回到老院来进行了。

主要是查有没有糖尿病.不过检查的方法就跟二呆似的，居然要分3次，但是一次结果还不行吗？ 还要空腹那么久的，我们医院的检查方法就这水平？

从这周开始，小小球你就开始折腾你妈了，你妈老被你压的喘不过去，居然还沦落到吸氧的地步了。

还有你妈最近老宫缩，可能是之前带你遛弯给遛出来的，还好经过10-1长假的休养总算没啥问题了。

贝希特斯加登是之前希特勒最喜欢的地方，有著名的鹰巢和国王湖。 但是我们从富森到贝希特斯加登可是好麻烦，刚好碰到德国铁路司机大罢工，那几天新闻都是说strike。 不过人家罢工居然还保留30%的人和车次，可我们发现本来到augsburg直接转车的，现在不得不到慕尼黑，然后出趟国到奥地利的萨尔兹堡然后转公交车，这可真够折腾的。而且还多花了几十欧。不过也算多去了个国家，还有看了下萨尔兹堡的老城堡，感觉奥地利人路上晒太阳的比德国多很多啊。 这个传说中的萨尔兹堡，就拖着两大箱子逛的，路上还碰到很多东亚旅行团。 下了公交车就很快到了贝希特斯加登我们定的酒店，这里是我们这次旅途中早餐最丰盛的一家，而且是包双早的。 虽然很丰盛，可媳妇说要每天这样吃还不吐了啊。我是觉得挺好，咱们太不重视早餐了其实。 拉姆绍和国王湖我们之前预备的两个景点，国王湖因为下雨，所以看的并不真切，而拉姆绍那天走的还是很爽的，当地人居然开辟出步行线路，开车线路，自行车线路，这个之前在天鹅堡也是这样的。 但是很多风光确实在不经意间出现的，那天刚从DM超市出来，天空居然突然放晴了，还有朵朵白云，映衬着远处的雪山，真是美极了。 要说国王湖（Konigssee）这天，刚到的时候天还不错，还能看到山里的薄雾。 可等我们坐船到了Obersee居然下起了雨。而某人为了去Obersee喝牛奶，居然还翻过半个湖过去，结果那天下雨人家不开门。不过这Obersee看着还有点九寨沟的感觉。由于下雨，所以整个徒步过程中见面的人都没超过10个人，大部分都是在湖岸看看就回去了。 国王湖当中有一个教堂，教堂旁边有一家小店，卖烤鱼的。教堂有2个红顶，这个色彩明显是经过综合考量的，蓝天，碧水，红顶。 刚上这个鱼的时候，我都傻了，这是烤鱼吗？ 这个也用刀和叉吃的吗？ 可当我尝了第一口后，就觉得这个真是世间美味，比什么巫山烤全鱼好吃多了，这个就是鱼的本味。然后我们也看了当地老外都是怎么吃的，还真是很快的就把鱼处理的干干净净的。佩服佩服。 有去国王湖的一定要品尝一下，而且这边旅游区的价格真不贵，可比什么39块钱一只虾的地强多了。 Hintersee到拉姆绍是一条徒步的路线，由于各种指示标志都很齐全，我们基本没有迷路的可能，路上和坐公交的时候还碰到一个中国交换生。 我们先是坐846到了Hintersee，一路下去到拉姆绍。这只要有湖的地方就有划船的，更何况这是好天气。 为了防止迷路在森林里，还是把各个路标记清楚了，但是右边这个指示牌一直没有看懂是什么意思。 老天还很配合，在我们快要到拉姆绍的时候，居然天放晴了又，居然还觉得有点热了。 著名的教堂映衬雪山中，这个完全可以当桌面了。 再见了德国，再见巴登府腾堡，再见巴伐利亚。

十一终于薅了一下中信的羊毛可以看电影了。本来想看的是港囧，又看了下发现另外一部片子更不错，沈腾的《夏洛特烦恼》，知道开心麻花的应该都知道的，我是之前看《欢乐戏剧人》里有一次他们团队模仿卓别林的一个哑剧感觉还不错。 说正题吧。全剧讲的一个失败的中年人去参加之前梦中情人的婚礼，为了一点虚荣坐着租来的玛莎拉蒂，还要准备退货的燕尾服，而自己媳妇的一顿大闹（话说刚来还是很给他面子的），意外回到了1997年。 预知未来的他自然是顺风顺水的得到了自己的梦中情人。这部分中笑点不断，可结局还是让人唏嘘不已。 洗尽铅华，我们男主人终于又觉得自己的那个原配是多么的好。只想回到现实中来。 我也想如果我能回到之前会怎么样？  但是发现自己在重要的转折点上都选择了自己真正要走的路，没有什么可反悔的，虽然在一些小事情我会来来回回变化很多次，但是重要的方向都没有走错，至少自己看来。 对于家人，我们常有过分的苛刻，可一旦失去了你回想起来的全部都是好。有人常觉得自己父母整天做一样的饭菜，整天唠叨一样的话。之前看过一部小说《甜蜜的悲伤》也说的是这个问题，有空可以再看看。 对于别人的选择现在我也不瞎指挥了，之前还指导人报志愿，指导人婚姻，现在看来这些都是笑话。在我们看来不可思议的选择其实我们往往只看到了冰山一角而已。别人真的并比你傻。 这所有的一切就是告诉我们要珍惜眼前时。就算人生可以重来，那也不会变的更好，是不是有点劝世的意味。

济州岛是韩国南部的一个大岛。开车环岛游大概需要2个小时左右的时间。所以直观感受是比台湾，海南岛要小许多。 为了满足球子怀孕期间来海边的愿望，同时又不想坐很长时间的飞机，在地图上找了下也就济州岛和冲绳比较合适，可冲绳还要办理签证，于是就选择了济州岛了，时间充裕的话还是选择冲绳比较好。 于是两人在父母的一致反对声音中出发了。这段时间我还是非常担心的其实。 因为是怀孕中的旅行，所以就定了济州岛最好的酒店，不过出门还是以11路和公交为主，出租为辅的。 下了济州岛机场，过边检的时候发现居然都是中文提示，而没有任何日文提示。 出了机场就打车去了乐天城市酒店，对于出门从来没自费住过这么高大上的酒店，感觉还是很好啊。窗外就是汉拿山。 来第一天发现这里的地名都比较奇怪，什么 中文区，我一开始还以为那里就都是讲中文的，还有各种洞，什么莲洞，明洞啥的。应该就是对应于我们这边的区和街道啥的吧。 第二天乘天气不错就来到挟才海滩，这里海水的各种颜色变化还是很明显的。近处由于沙子的原因显示的黄色，远处的绿色，再远处的蓝色。 从这里也可以看到韩国人骨子里还是非常保守的，都没见到有韩国人穿3点式的，男的很多也都穿着上衣下水。基本都裹的跟粽子似的。 还去了一个经典就是山君不离，实际上是一个亿万年前的一个火山洞，而现在基本都是各种植被在上面。 这里至少分布着三种不同的植被。不过这里出名完全是因为一部韩国连续剧导致的，说这里有一片芦苇荡很漂亮。作为一个在海边看烦了芦苇荡的人，实在是无法想象啊。但是韩国人居然能把这个都能推销出去，真是让我十分佩服。 这些就是我们在济州岛主要去的地。下面说说感受吧。   到处都是石头爷爷，无论是桥上，还是装饰品上等等。我也买了一对回家。 免税店里都是国人，而服务员的中文水平都非常高，基本不会有交流障碍，而其他地方的韩国人的外语水平就实在是 比较差的。 基本都是韩国本国的东西，而且基本都是被几个财团所垄断的，乐天，LG，现代，起亚，三星基本上垄断了所有的产业。 韩国的饭真没法吃，基本都是泡菜萝卜啥的，烤肉是比较奢侈的东西。所以韩国的大妈们做饭应该是特容易和快速的事情。 中文在这边还是被大量的使用的，特别是在一些重要的地方。 匆匆3，4天也没特别多的感想。 但是得感谢老天让我把球子平安带回了北京。一切平安。再过一周我又要远走了。 最后给球子来个海边孕妇照。

今天又去新院进行产检了，貌似是最后一次在新院产检。

就做了一个B超，小小球一切标准都很正常，这样你妈就放心。

你妈一直担心你是三瓣嘴什么的，结果好在一切都比较好。

今天中午回你妈家，结果我们开玩笑的话被你妈和你爸当真了，于是还闹的很不愉快，本来球子生日的活动也没戏了看来。

小小球你一切都好就是给你妈最大的安慰，你妈也不要总给你输入负能量了。

前面两周一直在跟icinga2进行较劲，花了2天看了下文档，并进行测试。 国内看到的文章其实都是一个单机版本的安装，没有涉及到远程客户端的。而实际测试发现这步还是比较复杂的。   首先需要是在服务器端生成客户端的唯一码

1

icinga2 pki ticket --cn ebs-aaa-beijing-test-agent 

然后client再根据server产生的这个码进行认证

1
2
3
4
5

mkdir /etc/icinga2/pki && chown -R icinga.icinga /etc/icinga2/pki 
icinga2 pki new-cert --cn ebs-aaa-beijing-test-agent --key /etc/icinga2/pki/ebs-aaa-beijing-test-agent.key --cert /etc/icinga2/pki/ebs-aaa-beijing-test-agent.crt 
icinga2 pki save-cert --key /etc/icinga2/pki/ebs-aaa-beijing-test-agent.key --cert /etc/icinga2/pki/ebs-aaa-beijing-test-agent.crt --trustedcert /etc/icinga2/pki/trusted-master.crt --host ebs-aaa-beijing-monitor 
icinga2 pki request --host ebs-aaa-beijing-monitor --port 5665 --ticket 13aa0b00b14ed45890984827ebfff0747a55449a --key /etc/icinga2/pki/ebs-aaa-beijing-test-agent.key --cert /etc/icinga2/pki/ebs-aaa-beijing-test-agent.crt --trustedcert /etc/icinga2/pki/trusted-master.crt --ca /etc/icinga2/pki/ca.crt 
icinga2 node setup --ticket 13aa0b00b14ed45890984827ebfff0747a55449a --endpoint ebs-aaa-beijing-monitor,ebs-aaa-beijing-monitor,5665 --zone ebs-aaa-beijing-test-agent --master_host ebs-aaa-beijing-monitor --trustedcert /etc/icinga2/pki/trusted-master.crt --accept-config --accept-commands 

而要用好icinga2，那就首先要理解，host, node, endpoint, zones, repository 这几个定义的区别。 但是个人感觉这些优点复杂了。 测试下来最有用的部分是对于hostgroups和servicegroups在icinga2里自定义就太方便了。这个可比nagios大大进步了，nagios里还得跟傻逼一样一个个写，虽然可以写脚本搞定，但是还是感觉很傻。

1

object HostGroup "mysql-server" { display_name = "MySQL Server" assign where match("*mysql*", host.name) && match("db-*", host.vars.prod_mysql_db) ignore where host.vars.test_server == true ignore where match("*internal", host.name) }