艾玛， 搞得我好累 。。 。。
Cacti官方提供的模板 sh脚本执行有问题，找不到原因，重新写了脚本就正常。。。
先看看效果图
（大半夜搞出来的 ，，，）
环境：CentOS 6.5
Bind版本：Bind 9.8.2 （yum install bind安装）
未安装Chroot包，（如果有安装那么需要注意文件路径了。）
开搞
1.解压模板压缩包文件，阅读README 说明。
2.在cacti 端导入主机模板
导入后，你点开bind9.7 的主机模板看到如图即正确
3.在Bind服务器端 开启SNMP，并检查是否能正常监控 ，最后在 snmpd.conf配置文件中最后添加一行命令，并重启 snmpd 服务。
extend .1.3.6.1.4.1.18689.0.1 dnscache-stats /root/bin/runstats.sh
4.拷贝runstats.sh dnsstats.pl 两个文件至Bind服务器的/root/bin/ 目录下。
并且添加相应的执行权限（同snmpd.conf文件的属主属组一样即可）。
4.2：查看 named.conf配置文件 options里是否有
statistics-file "/var/named/data/named_stats.txt";
这条配置。 如果没有，那么请添加两条配置选项
zone-statistics yes; statistics-file "/var/named/data/named_stats.txt";
添加完成后重启named服务 并用 rndc stats 命令检查是否生成/var/named/data/named_stats.txt文件
4.3 ：运行 runstats.sh 看能否正常获取数据。
如图 即可正确获取数据。
4.4： 检查bind端 snmpd 服务是否开机启动
chkconfig --list chkconfig snmpd on
5. 拷贝bind-stats.sh 至cacti脚本目录，通常为/var/www/html/scripts/bind-stats.sh
检查脚本的属主属组 并添加相应的执行权限。
5.1： 试运行该脚本 是否能够获取数据
如图即正确。
基本上配置上就搞定了。
最后在添加主机模板的bind图形模板。
保存，稍等片刻即会生成图形，并绘图。
模板文件见下方。
本文出自 "Professor哥" 博客，谢绝转载！
（App Volumes系列三）Manager配置以及Agent安装 在前一篇博客，我们基本了解了App Volumes的四个逻辑组件，环境配置要求以及如何安装App Volumes Manager组件，我们接下来将继续我们的App Volumes之旅。
首先先回顾一下App Volumes的安装，使用流程： 初始配置 -> App Volumes Manager组件安装-> App Volumes Manager组件配置-> App Volumes Agent组件安装-> 应用提取 -> 应用集合（AppStack）分配。
App Volumes Manager组件配置和App Volumes Agent组件安装是我们这篇博客的主要内容。
AppVolumes Manager配置
App Volumes Manager必须经过相应的配置才能使用。因此我们应该在安装完毕App Volumes Manager之后，就立即进行App Volumes Manager的配置工作，该工作需要在App Volumes Agent安装开始之前做完。App Volumes Manager配置主要是指license管理，AD配置信息，vCenter 服务器配置链接信息以及App Stack和writable volumes的存储位置。
首先要配置App VolumesManager的许可证信息，虽然Appp Volumes被VMware收购后的第一个正式的版本还没有推出，但未来的销售模式可以猜测一下，基本上两种模式，一种是单独销售App Volumes的许可证模式，另外一种是作为Horizon Enterprise editions其中的一部分和其他产品打包销售的许可证模式，第二种Horizon Enterprise editions销售许可证模式显然是性价比更好的方式。当然具体的商务信息还要正式版本推出以后才能确定。
具体到安装许可证的步骤，如下图一所示，用户选中许可证文件，将该文件上传到服务器里面就完成了许可证的配置。
图一 许可证配置
然后是AD域控制器的配置。App Volumes管理的对象是基于域控制器的对象，主要是指域计算机对象和域用户对象。虽然App Volumes Manager所在的计算机本身不是必须加入到域里面，但是它需要拥有域控制的信息，包括域名称，管理员用户，密码等等。从而App Volumes Manager可以域里面取出来取出相应的对象的信息，然后将AppStack或者Writable Volumes分配给这些对象。
图二 AD 配置
其次是vCenter的链接配置。App Volumes的简单的实现原理是在虚机层面将App Stack或者Writable Volumes所在的虚机文件（vmdk格式）和目标系统虚机所对应的虚机文件（vmdk格式）动态的挂载成一个系统。而这个挂载的操作需要App Volumes拥有vCenter的管理员权限才可能进行。如下图三所示，管理员需要输入vCenter的主机名或者IP地址，然后该vCenter对应的管理员用户和密码也是必须的。在App Volumes的正式版本推出之前，原有的Cloud Volumes版本只支持一个vCenter, 也就是说，App Volumes在做程序或者内容分发的时候，它所管理的目标机器所在的虚机必须是在一个vCenter的管理之下。当然，笔者相信未来对多个vCenter的支持应该是必须的。
图三 vCenter 链接配置
最后是存储和模板的配置，如下图四所示，这个配置是指用户生成的App Stack和 Writable Volumes所对应的虚机文件的存放位置，原则上来说，这个存放位置应该是管理员想要管理的虚机系统都能存取的位置。另外App Stack或者 Writable Volume虚机文件和模板的存放路径可以采用缺省值不用修改，除非用户自己已经在data store上面手动创建了一个相应的目录架构并且上传了相应的文件，那就在需要在这里做相应的修改。
图四 存储位置配置
经过以上几个配置步骤后，App Volumes Manager配置就完成了，用户就可以进行下一步的客户端的安装了
AppVolumes Agent安装App Volumes在本质上是一个C/S架构的系统，AppVolumes Manager是server部分，App Volumes Agent是client部分。App Volumes Agent需要安装在每一个管理员要管理的目标系统所在的操作系统上。这里面需要有相应的IT规划，1) 如果是全新的系统，管理员可以先创建几个虚机，并且在虚机里面安装操作系统，例如Win7或者Win8，然后在相应的系统里面安装App Volumes Agent软件，然后将相应的虚机保存为模板。当用户需要申请新系统的时候，就可以根据模板创建新的系统，新创建的系统就包含了已经安装好的App Volumes Agent软件，从而App Volumes Manager就可以分发相应的内容给该新系统。2）如果用户已经有了虚机并且已经开始使用了，那管理员就不得不在每一个原有的系统上面手动安装App Volumes Agent软件然后才能使用App Volumes的功能。
这里要强调一下，AppVolumes Agent所安装的目标系统可以分为两类，一类是管理员用来创建App Stack的样板机，另外一类才是普通用户使用到的虚机系统。在这两类系统上，App Volumes Agent的安装方式都是完全一样的。
App Volumes Agent的安装步骤是极为简单的，用户只需要在安装时输入正确的App Volumes Manager的地址就成了。如图一所示，首先用户点击安装包里面安装文件开始，接受license agreement, 然后选择安装 agent
图五Agent选项
接下来，需要输入App Volumes Manager的地址以及端口号，这一步的输入信息一定要准确，因为一旦输错，起码目前的Cloud Volumes Agent版本没有提供一个配置界面让用户可以修改App Volumes Manager的配置信息。所以一旦输错，用户不得不重新卸载掉Cloud Volumes Agent，然后重新安装一次Cloud Volumes Agent来输入正确的信息，所幸安装的步骤足够简单。
图六 App Volumes Manager配置
剩下的就是点击下一步，接受缺省配置，开始安装，等待个把分钟，系统安装完毕后，会要求用户重新启动操作系统。重启以后，App Volumes Agent就Ok了，用户可以进行下一步的应用提取了。
在下面一篇博客，笔者将会着重介绍如何使用App Volumes进行应用管理以及个性化内容管理。
本文出自 "VMware终端用户计算" 博客，请务必保留此出处http://vmwareeuc.blog.51cto.com/8606576/1581707