当前位置: 首页 > 科技观察

网络监控平台Shinken安装演示

时间:2023-03-21 16:36:11 科技观察

Shinken是一个网络监控平台,可以通过一系列直观的方式监控网络内的各种健康状况。Shinken,光是名字就接近“新”的日文发音,Shinken脱胎于Nagios,其实Shinken项目本身就是一群受不了Nagios的Nagios项目人,跳出来用Nagios重构的Python-低版本甚至完全兼容Nagios配置文件。我要吐槽的是Litrin在安装时用了N个版本,0.x版本根本找不到文档;1.x文档很全,插件兼容性有问题;这显然是一个错误。只能在github上fork之后提交patch——还好当天就通过了。不过,这也是开源项目的常态。一旦一个项目快完成了,团队很快就会因为产品定义不同而产生分歧,然后一群人会fork代码开始新的项目。最终的结果是“一堆类似功能的项目很多,但没有一个是完美的”。在安装之前先简单了解一下Shinken的结构,它明显比Nagios复杂很多,Shinken借鉴了Nagios多重角色:区别于传统的C/S架构,应该是基于分布式的考虑,Shinken的结构真的很变态.Arbiter(仲裁):Arbiter节点读取本地配置,然后对配置进行划分,分发给多个合适的schedulers节点Scheduler(调度):scheduler节点分别负责管理poller和reactionner节点的任务调度.poller(轮询):poller节点通过各种插件执行scheduler节点的任务,获取各种健康指标Reactionner(响应):reactionner节点的任务是触发event_handlers机制(比如发送通知,etc.)oncetherequirementsaremet.Broker(middleman):broker节点的任务真的是一个中间人——出口在调度程序节点中处理和管理数据。Receiver(接收者):可选节点,在某些特定场景下,可以通过receiver节点对数据进行汇总(比如汇总私网内部数据,统一转发)。除Arbiter节点外,任何节点都可以是非唯一的。节点之间的关系也是多对多的。每个节点都支持/依赖插件,或者Shinken本身只是插件的框架。保证性能和可靠性——根据CAP法则,一致性是被放弃的。说了这么多理论,我们开始吧!这次终于用上了Ubuntu14.04的Server版。前面说了N个以上的版本并不完善,所以这里只能使用Ubuntu的apt方式安装。为了省去前面六个节点角色的复杂性,这里只用“master”和“controlled”这两个角色来大致演示安装过程。控制终端运行#apt-getinstallshinken查看安装了哪些包root@ubuntu14:~#dpkg-l|grepshinkenrcshinken1.4-2amd64灵活监控工具-Meta-packageiishinken-common1.4-2amd64灵活监控工具-通用文件iishinken-module-broker-webui1.4-2amd64ShinkenWebUI代理模块2amd64ShinkenSqlite存储模块forWebUIbrokeriishinken-module-retention-picklefile1.4-2amd64Arbiter,SchedulerorBrokerRetentionmodule安装完成后,一般情况下会有一个系列以shinken开头的脚本。这时候如果你简单粗暴的启动服务器shienenstart,那肯定有一堆报错等着你。嗯,找了半天发现了这个问题。编辑/etc/default/shinken,将第34行改为:BIN=/usr/lib/python2.7/dist-packages/shinken/bin此时,服务器shinken启动应该成功了。实际上,shinkenstart的脚本启动了所有关联的服务。您可以通过在/etc/default/shinken配置中添加或删除AVAIL_MODULES选项来更改角色。一切OK后,就可以通过浏览器访问主节点7767端口,看到一个Dashboard。但就目前而言,它只是监测当地的健康状况。下面假设主控节点监控另一台主机的网络连通性使用的服务模板名称host_namenfsservice_descriptionSSHcheckretry_interval1check_interval5max_check_attempts2check_commandcheck_sshnotifications_enabled0}重启shinken后,会看到NFS主机SSH端口的监控。如果只需要获取远程主机的ping状态、TCP端口等几个简单的指标,这种模式就足够了。但是如果需要知道远程主机的进程数和磁盘空间,就需要使用Accusedofmakingontheside。这里简单介绍一下在受控端安装poller的实现。被控端的操作和开始的差不多,根据帖子#apt-getinstallshinkenedit/etc/default/shinken,修改第34行为:BIN=/usr/lib/python2.7/dist-packages/shinken/bin受控端只需要一个poller,其他服务可以关闭。修改第39行AVAIL_MODULES="poller"启动shinken:root@ubuntu14:/etc/shinken/hosts#serviceshinkenstartStartingpoller:...done。启动列表确实短了很多。回到主控终端运行vi/etc/shinken/hosts/test.cfg,添加受控终端指示符要使用的服务模板的名称host_nametestservice_descriptionPINGcheck_commandcheck_ping!100.0,20%!500.0,60%}defineservice{uselocal-service;要使用的服务模板名称host_nametestservice_descriptionRootPartitioncheck_commandcheck_local_disk!20%!10%!/}定义服务{使用本地服务;要使用的服务模板的名称host_nametestservice_description总进程数check_commandcheck_local_procs!250!400!RSZDT}vi/etc/shinken/shinken-specific/poller.cfg,添加一个新的pollerdefinepoller{poller_namepoller-test#poller名称地址10.239.21.49#被控制端IP端口7771#端口,默认就是7771##Optionalmanage_sub_realms0;它是否从子领域的调度程序中获取工作?min_workers0;以N个进程开始(每个CPU0=1)max_workers0;不超过N个进程(每个CPU0=1)processes_by_worker256;每个worker管理N个检查polling_interval1;每N分钟超时3从调度程序获取作业;Ping超时data_timeout120;数据发送超时max_check_attempts3;如果ping失败N次或更多次,则该节点已死check_interval60;每N秒Ping节点##可以使用的有趣模块:#-NrpeBooster=替换check_nrpe二进制文件。因此,当有很多NRPE#调用时,它会提高性能。#-CommandFile=允许轮询器读取nagios.cmd命名管道。#这允许使用分布式check_mk检查#如果你愿意的话。#-SnmpBooster=Snmpbulkpollingmodule#modulesNrpeBooster,CommandFilemodules##AdvancedFeatures#passive0;对于DMZ监控,设置为1,以便连接;将来自调度程序->轮询器。#poller_tagsNonerealmAll}重启主控Shinken服务,配置生效后,会在webUI的'All'选项中找到新增测试主机的指标