当前位置:Gxlcms > mysql > zabbix二次开发之报表系统(二)

zabbix二次开发之报表系统(二)

时间:2021-07-01 10:21:17 帮助过:115人阅读

背景 一切都是业务的推动,继上次做的简陋的报表系统的雏形之后 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。

有兴趣的话看我的目录树吧。

这么做的好处自然不用说了,你懂的。

urls

urls这部分同样是根据app进行划分的,即所以以/kvm_report/开头的urls均会

由kvm_report这个app去处理,而具体怎么去处理的就可以在app中自由的组织了。

[root@zabbix-szq-13 report-system]# cat report_system/report_system/urls.py
from django.conf.urls import patterns, include, url
from django.contrib import admin
from report_system import views
admin.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的方式去查询历史数据,方便维护。

人气教程排行