背景 一切都是业务的推动，继上次做的简陋的报表系统的雏形之后 zabbix二次开发之报表系统(一)， 业务同事越来越不满足于那个粗糙的玩意，于是在他们的胁迫下，抽空 完善了下。 新版效果 架构调整 之前的架构大致是这样的， bootstrap 前端 tornado 后端 mon
背景一切都是业务的推动，继上次做的简陋的报表系统的雏形之后
zabbix二次开发之报表系统(一)，
业务同事越来越不满足于那个粗糙的玩意，于是在他们的胁迫下，抽空
完善了下。
新版效果
架构调整之前的架构大致是这样的，
bootstrap 前端tornado 后端monogodb 数据库在一次的更新中几乎全换掉了。改用了如下的组件：
bootstrap 前端django 后端mysql 数据库调整的理由django vs tornado更熟悉django，且是all in one 的框架，可以省去很多的不必要的造轮子的过程。
tornado 的异步模式什么的对我吸引力不大
django完善的后台功能
django非常赞的orm等功能
mysql vs monogodb更熟悉mysql调整的原则开发方便、快捷
技术上更熟悉
目录树[root@zabbix-3 report-system]# tree .├── readme├── report_system│ ├── data│ │ ├── kvm-2014-07-30-16-50.xls│ │ └── kvm-2014-08-03-06-01.xls│ ├── kvm_report│ │ ├── admin.py│ │ ├── admin.pyc│ │ ├── __init__.py│ │ ├── __init__.pyc│ │ ├── kvm_report_generate.py│ │ ├── models.py│ │ ├── models.pyc│ │ ├── templates│ │ │ ├── kvm_report_add.html│ │ │ ├── kvm_report_base.html│ │ │ ├── kvm_report_delete.html│ │ │ ├── kvm_report_execute.html│ │ │ └── kvm_report_search.html│ │ ├── tests.py│ │ ├── urls.py│ │ ├── urls.pyc│ │ ├── views.py│ │ └── views.pyc│ ├── manage.py│ ├── nohup.out│ ├── report_system│ │ ├── __init__.py│ │ ├── __init__.pyc│ │ ├── mail.py│ │ ├── mail.pyc│ │ ├── settings.py│ │ ├── settings.pyc│ │ ├── urls.py│ │ ├── urls.pyc│ │ ├── views.py│ │ ├── views.pyc│ │ ├── wsgi.py│ │ ├── wsgi.pyc│ │ ├── zabbix_mysql_conf.py│ │ └── zabbix_mysql_conf.pyc│ ├── static│ │ ├── css│ │ │ ├── bootstrap.css│ │ │ ├── bootswatch.min.css│ │ │ └── font-awesome.min.css│ │ └── js│ │ ├── bootstrap.min.js│ │ ├── bootswatch.js│ │ └── jquery-1.10.2.min.js│ └── templates│ ├── base.html│ ├── index.html│ └── login.html└── requirement.txt
bootstrap模板的选择第一次版的雏形也就算了，就是一个单页面，这次的可不是，好歹要有三个。。。
所以模板的事我还得头疼下，毕竟自己不大懂前端不是。
高大上的模板挑了半天选中了一个效果，非常华丽的模板，但该起来的非常非常麻烦。
代价也非常大：
加载对象过多，仔细看了下里面的代码，引用了非常多的图片、css、js等
加载速度太慢，和加载对象有很大的关系，而且它居然还引用了谷歌的字体。。。
修改麻烦，需要修改的地方太多，例如静态文件，各种模板自定义的css效果
简洁才是王道还是最简单的用起来方便，最后在同事的推荐下采用bootstrap的模块。
确实比较简洁，没太多的自定义效果，代码组织的也很清晰，就是它了。
后端的重构由于之前采用的tornado写的，所以这次换django之后基本需要全部推倒重来了。
好在我之前基本没啥功能，加上也熟悉，很快就搞定了。
app目前只有一个kvm报表的功能，考虑到以后的其他业务的功能加进来，所以
对一个业务部门划分了一个app的方式去做，方便后期维护嘛；
models还是跟app来的，每个app需要的话会写自己的models代码，即创建自己的表等。
目前就一个app,当然就一个models文件了。
模板模板我这里采用了多个目录去存放的，熟悉django的应该清楚，每个app其实也
是有自己的模块文件的。所以我这里做的就是将公共的模块文件保存在根目录下
的templates文件夹中，app的则是存放在各自的templates目录下。
kvm_report 这个app下面的kvm_report_base.html会继承根目录下的base.html，
同时app下的其他html文件会继承kvm_report_base.html。
有兴趣的话看我的目录树吧。
这么做的好处自然不用说了，你懂的。
urlsurls这部分同样是根据app进行划分的，即所以以/kvm_report/开头的urls均会
由kvm_report这个app去处理，而具体怎么去处理的就可以在app中自由的组织了。
[root@zabbix-szq-13 report-system]# cat report_system/report_system/urls.pyfrom django.conf.urls import patterns, include, urlfrom django.contrib import adminfrom report_system import viewsadmin.autodiscover()urlpatterns = patterns('', # examples: # url(r'^$', 'report_system.views.home', name='home'), # url(r'^blog/', include('blog.urls')), url(r'^$', views.index), url(r'^login/$', 'django_cas.views.login'), url(r'^logout/$', 'django_cas.views.logout'), url(r'^accounts/login/$', 'django_cas.views.login'), url(r'^kvm_report/', include('kvm_report.urls')), url(r'^admin/', include(admin.site.urls)),)
cas验证这部分接入了公司的cas系统，实现起来非常简答，就是采用了django-cas实现的。
可以参考django接入cas验证系统。
手动执行的功能报表这块最早提的是定时生成就可以的，但后来他们老是让我手动帮他们跑，
太烦了，于是做了这个功能让他们自己玩去。
由于这块最早的后台脚本都写完了，所以这次暂时就不改正了，直接使用
subprocess.call 调用系统命令去跑就ok了。
拿到执行结果，返回给用户成功或者失败。
主要更新* 后台架构的更新自然不用说了* 第一版本的很多的配置信息都是保存在文件中的，这一次全部放到了mysql中保存* 加入公司的cas统一认证，增强了安全性* 新增了查询、删除等功能* 增加了每个操作之后的回执，即返回操作结果* 增加了手动执行获取最新报表的功能
总结当然目前还是有很多问题的。
精细的权限验证：
目前只是接入了cas的验证，还未做更具体的权限判断。
审计日志：
目前没有做审计日志的记录，
后台脚本重构：
后台脚本目前是采用subprocess 调用的，且直接是sql查询数据的，在面临版本升级，
例如zabbix1.8 升级至zabbix2.2的时候，这部分脚本都有可能要重写。
后期可以考虑采用zabbix api的方式去查询历史数据，方便维护。
原文地址：zabbix二次开发之报表系统(二), 感谢原作者分享。