2019-09

9.2

1. 对于event的获取。按照起始时间去取值，只能取到这个时间段内发生的告警项，在这个时间线之前出现的告警是不会在这个时间段内获取到的，除非这个监控项恢复，再报错才会显示。
2. 对不定数量的监控项值来做计算实在想不出来。。头大
3. gj的zabbix客户端在机器重启之后失联，是因为没有做开机自启动。

9.3

1. 对于zy的网络连通性监控项的推送，由于使用的村行名作为字典的键，当出现不同省两个同名的村行时，一个就会把另外一个覆盖，所以后来就使用 省名+法人行名+村行名来作为键，最大的减少重复。使键唯一
2. zabbix的主机在批量更新的时候，如果要使用新建的主机组，那么可以直接写在主机组那，zabbix会自动提示一个 自定义的主机组名(新)， 然后该主机就使用了这个新建的主机组
3. 新看到一种flag判断，挺好用的

tmp = {}
data = []
if tmp.get(key,True):   #能够取这个key，则进入下一层逻辑，取不到，直接判True，也进入下一层，
        tmp[key] = False    #将这个key设置为False，再次取到这个key的时候，直接pass，不做处理。这样就可以完成分类
        data.append(key)

9.4

1. 代码出现报错，有idea的情况下，可以debug去查看，在生产环境下，我的思路是去找到问题点一层层往上找，诚然可以找到问题点，但是付出的时间有点多，不值。最好的办法就是打印出来问题点，查看变量，通过查看日志可以快速解决，在代码中，使用logging.error，注意打印的变量使用repr转换，然后触发条件，查看实时日志
2. 后台配置的各介质的告警触发头，内容格式，告警恢复的头，内容格式，在介质的生成告警内容中使用
3. 编译后的pyc文件可以由原生的py文件代替
4. 在zabbix中，一个主机的监控项的key是唯一的，重复导致zabbix启动不了
5. go get超时，443的处理，walk做gui的步骤
6. 大脑一天在神游啊，木讷的要死，完全不知道变通啊。烦烦烦

9.5

1. 代码精简之道，还得继续加强，重复的生产代码没有一点用
2. dco报告中做的代码健壮性，思路就是错的，导致一直不报警，以后写的时候还得多审审思路
3. model中可以指定多个字段来组成一个组合型的唯一字段
4. 除了代码迁移，在model层面做的代码修改需要迁移之外，其他的操作，例如指定admin中的显示搜索字段，model中的源类中指定内容等等，都不用进行迁移。直接重启服务就可以用
5. 使用jconsole连接java服务，可以使用jmx从mbean中提取出数据，不同的java服务，mbean中同类型的属性名是不同的。需要区别对待。
6. 模板的克隆，善于使用到处，使用任意编译器进行批量替换。

9.6

1. 对于定制报表中的思路重新整理，可以直接使用zabbix中的可计算类型的监控项来做各个监控项之间的计算，直接省去了很多问题，表也不用了，计算过程也直接省去了
2. go walk中对各个控件的布局。

9.9

1. 对orm的迁移文件需要多看看
2. 定制报表的获取方式有了很大改变，zabbix的search反过来也可以用的很好
3. 数据库文件使用空间并不大，
4. go的集中数据结构

9.10

1. 在jmx脚本中，jar 命令参数作为一整个字符串进行的传递，其中的双引号，逗号不能被直接识别，需要使用代码层面的进行转码，这里将逗号进行特殊定义，然后再程序中再进行解析。这种适用于jmx的mbean中多个参数的传递，中间有逗号分隔的情况，
2. es数据获取失败，经查询是因为es主机磁盘满了，需要进行磁盘扩容
3. 自动发现规则，通过定义的key调用后面指定的脚本，脚本返回来宏变量，可以在规则这里添加过滤器，一般是正则规则，只有通过规则的才能被使用，然后在监控项原型中使用发现的宏变量，生成新的监控项。有一个疑问是在机器重启之后，为什么正则中没有的东西却能被自动发现出来？
4. 不要慌张，仔细点就没问题

9.11

1. 能力越大，责任越大，需要注意的地方越多，各方沟通都得做，能力提高，以后的路也会也走越宽，
2. 单位转换的逻辑很精妙，
3. zabbix的监控项可以选择是否支持，是否启用，
4. zabbix的最新数据中，会对单位做转换，单位应该是用的zabbix内建的，对特殊的单位如果数值超过1000这种的，就会转换数值和单位，例如 6000bps>6kbps这种的

9.12

1.接下来的日子就得要自己撑起来了，这以后，开发能力，沟通能力，组织能力，都是一项考验，保持初心，不忘始衷
2.头一回有这种累的感觉，特别累，打了一天的哈欠，以后还是要早点睡，身体太乏了，精力跟不上，做事也慢了
3.zy的es由于磁盘满了，然后监控系统中基于es的聚合数据就取不到了，导致数据丢失，在系统组扩容之后，es的服务还需要重新启动才能生效，由于数据量很大，启动会很慢，而且进kibanna的时候一直提示集群状态为red，需等待，一会就能启动的。
而且由于积压了好几天的数据，当下的数据还是不准确的，需要时间段消耗掉积压数据，数值就可以显示正常了。f5数据先打到es中，基于es的数据处理功能再取出处理好的结果
4.zabbix的模板批量重复更改时，导出批量替换，再导入是一个好方法，但是名称需改好，不然会重复 ，监控项，触发器，图形等，宏，自动发现规则，两个模板都不能一样
5.更新前端代码，直接键zip包解压，在index.html中添加刷新时间的源数据，不用重启服务，在1个小时之后就会自动刷新，也可以在左二主机上插上无线鼠标进行操作
6.代码变更前都需要做备份，还有数据库的。
7.django 的orm中可以filter多虑多个条件。
8.前端代码的更新，直接解压覆盖，在前面加上刷新时间，一小时

9.16

1. 对于zy的solarwinds告警迁移到告警平台，只需维护一个触发恢复的队列，发送一个request请求，
2. 给客户发邮件多审几遍
3. 再任何迁移之前都要做备份，备份，备份
4. zy的代码还需要把更改过的拿出来，怕累计一堆。

9.17

1.gj的代理服务器在重启之后因为没有添加自启动项，nginx没启动，导致上交深交的数据缺失，重启nginx服务恢复
2.长连接就是一个开放的连接，不间断的。zy的长连接需求是从起点到终点的固定ip及端口，本来是10.10.22.11:3333>>10.1.12.11:4444验证是否存在长连接，但是登上机器看到的是10.10.22.11:31233>>10.1.12.11:4444 10.10.22.11:3333>>10.1.12.11:12313 并非是指定的固定ip及端口
3.bps是每秒的位传输 bits/persent second, 转换成mb/s 需要/1024/1024/8,
4.item的获取中添加monitored为真，就可以在取出item时排除末班中的监控项，只拿去主机中应用的监控项
5.瞬间感觉啥也不会了，一团乱麻，神烦。

9.18

1.oracle数据库初步了解，
2.zy的长连接监控通过更改脚本模糊匹配一个，精确匹配另一个来指定是否连接成功
3.跟ym沟通，说道一个什么报盘软件的监控，

9.19

1.tar tf xxx.tar.gz不解压查看内部的文件，
tar xvf xxx.tar.gz 不指定解压路径的话默认是解压到当前目录
tar cvf xxx.tar.gz ./* 把当前目录下的文件打包并压缩

1. ansible使用熟悉
2. 实施安装agent重来一遍，需要看懂install.sh check_monitor.sh脚本
3. zy的长连接监控使用另一种实现方式，通过脚本执行脚本，是不是可以永远原生的外部检查实现
   5.netapp的mib文件使用，查询到有用值
4. 不要着急，不要着急，着急解决不了问题，还不如仔细的一步步来

9.20

1. 跟客户沟通是一门学问
2. zabbix中对端口的开放状态监测，有监测本地的和检测对方的
3. 对于触发器的设置可以设置触发跟恢复的条件判断
4. 代码还是注释起来的好，不然后期一看就得哭了
5. 新上的用户管理接管了zabbix中的用户管理，包括设置用户的介质信息

9.21

1. 长连接检测做的还行。文件系统挂载换种思路，通过监控底下的定式文件来判断文件系统是否挂载
2. f5的都是防火墙的相关
3. 培训文档抓紧
4. ntp服务的监控，可以使用zabbix自有的ntp服务监控

9.23

1. agent跟server的事件线不一致，导致zabbix数据库中event的记录出现时间前后不一致的情况
2. 可以定一个周期任务来定时刷新ntp时间
3. alert的日志监控可以创建多个监控项或者多个触发器，来实现

9.24

1. 一脸懵逼，找一个不存在的错误，还不能去怀疑另一家厂商的数据，真是心里操蛋的不行，
2. ASM状态触发器的添加还是有问题，为啥两个str 匹配不到的and关系能触发呢，一个connected mounted
3. ntp直接使用proc进程数量监控，

9.25

1. 情景复现了一把，事实证明还是取决于solarwind库的，solarwinds中的数据时怎么样的，我们就会报什么样的警，
2. 在自动发现规则中的自动发现清单中有更新时间，意思就是在到达更新周期才回去楼一遍数据，符合条件的就创建监控项和触发器，在监控项原型和触发器原型中可以增加删除，到达更新周期的时候就会自动应用
3. 哥们的婚礼是回不去了，很难过，工作就是这样，充满了一些无奈，但是老板还在那儿扛着，将心比心，他更难，回去请哥们吃个饭吧，真是。。。。
4. 说话方式有很大问题，思维方式也有很大问题，继续解决，会说话事半功倍，不会说话，死的透透的，抑制住急躁的脾气，真的，急下来啥都拿不住。而且思维意乱更难。注意啊
5. 赶紧把zy这块任务完了吧，太难受了

9.26

1, 今天一切蛮顺利的，专线状态的判断还是需要确认solarwinds数据库数据在中断的哪个时间点是否会发生值的变化，才能判断出我方取值问题

1. 触发器nodata用的时间是一个周期，在一个周期内就是一个判断周期，在触发器中有多个条件的时候，加上nodata判断就是说在一段时间内有无数据也是一个条件来判断，可以当做是一个报警的显示时长，nodata中设置的时间就是告警恢复的时间，可以那么理解
2. jconsole中还有一些数据能取。
3. 为什么在监控项里面能取到值，在server端使用命令就取得超时了？在获取zy挂载文件系统的大小时发生的超时。
4. zabbix模板的导出要一个一个的导，不能批量导
5. zabbix的监控项如果有触发器，在界面上就会显示有触发器的标志，如果触发器的条件是使用了两个监控项的值来进行比较，那么再两个触发器上都会出现一个触发器，通过这一个触发器关联了两个监控项

9.27

1. ASM磁盘组的监控可以直接在oracle数据库中查询，也可以使用ASM的相关命令查询，命令做成一个定时任务，定时给一个文件中刷数据，在做一个读该文件的监控项，就可以读到数据
2. oracle数据库中有很多能监控到的数据
3. 在磁盘被占用到100%的时候，没有空余磁盘使用，上面写数据的进程就会被堵死，删除一些无用数据即可
4. 在redis的worker被满占用的时候，新生成的任务就会堵塞，一直等任务放开，在此期间的内存数据的ttl会过期。数据清空。

9.29

1. rebase的又给把代码给丢了，多久在linux上有自动上传的，不然白瞎了
2. 在django视图中可以设置zabbix get的命令来执行，不过的链接到zabbix sserver上才行
3. webservice的xml文件中可以解析出方法和参数，再在url中传入方法名和参数即可调用函数取值。
4. snmp
5. os.makedirs可以批量创建层级文件夹。
6. repo可以在nginx配置文件中配置，启动了nginx服务器就可以把linux作为一个文件服务器来用，可以上传下载
7. django上传文件需要使用的是request.FILE.['前端给file定义的键']

转载于:https://www.cnblogs.com/0916m/p/11482037.html