#
今天到中山电视台,但根本没与用户深入交流的机会。
如果真是做HFC网络的监测,那我们肯定不行,只能放弃。
不过听他的意思,又好像是要做一般IP网络监测,那我们还有机会。
用TreeMap装载snmp的ifTable,真是个不错的选择
优点:能排序,又有hashMap的功能。
唯一的不好就是只能按主键排序
public class IfEntityTable extends TreeMap<String,IfEntity>
{
private static final long serialVersionUID = 25611283245733824L;
public void add(IfEntity ifObj)
{
put(ifObj.getIndex(),ifObj);
}
}
public class IfEntity implements TableItem
{
//------------property----------
private String index;
private String descr;
}
SourceView综合监控管理系统总体设计如下:
底层实现数据采集,系统通过多种方式对网络设备、服务器、数据库系统以及中间件进行数据采集。采集方式主要有SNMP、NetFlow、SysLog、SNMPTrap、Telnet、JDBC和JMX。
中间层负责数据处理和分析,包括系统的主要功能,实现了IT系统静态数据和动态数据的整合;并实现配置管理、事件管理、故障管理、性能管理等。这一层次中主要实现数据的集中分析和关联分析,将各个监控对象的故障数据和性能数据进行集中整合。
上层是综合监控管理系统的表现层,这一层主要包含拓扑视图、性能报表和故障提示等。用户可以通过web的方式,以图形的方式查询设备的运行情况,可以分为实时和历史两种模式;对于设备运行过程中出现的故障能够在图形上展现出来,并且按照用户设定的方式进行告警。
以前画这个总体结构图都是copy别人的,但其实没有一个能真正反映我的设计思想,
所以今天专门花了好长时间用visio画了个自己的结构图。
根据用户需求,XX公安综合监控管理系统项目的建设目标如下:
1.建立面向运维业务需要的自动化监控管理体系,提高管理质量。
2.保证系统可靠性和可用性,为用户提供7×24小时不间断的可靠服务。
3.在复杂的异构环境中实现集中统一管理,轻松维护复杂的异构环境并使之有效运行。
4.把运维人员从管理产品的复杂负担中解放出来,系统能实现自动的检测和告警。
5.将错综复杂的系统信息,各类系统事件按照运行管理的需求进行过滤整理,帮助系统维护人员专注于重要事件的管理和响应。
6.总结出对系统管理、业务管理、服务管理有用的信息,为管理者提供更全面,更直接的管理信息,为制订相关决策提供依据。
系统设计原则:
1.标准化原则:遵循TCP/IP、SNMP和NetFlow等相关的国际标准或工业标准,支持对设备厂商通用MIB的管理;
2.开放性原则:支持对各种网络设备厂商管理工具的集成,具有开放的API接口,支持对网管系统的二次开发;
3.易用性原则:要求管理功能以良好直观的界面和图形方式实现,能通过浏览器方式进入系统;
4.健壮性原则:系统监控的设备多,数据量巨大,系统本身应健壮、易于维护;
5.节省资源原则:系统设计在满足用户需求的基础上,应尽量减少对网络带宽及系统资源的占用。
今天对XX公安进行需求调研。根据调研,XX公安主要有以下四个方面需求:
1. 网络
(1)XX公安的网络拓扑为星加环结构,其中星形结构作备份用。如果网络拓扑从环形变为星形,系统必须给出告警。
(2)对于汇接层的路由设备,如果其路由表发生变化,系统应给出告警。
(3)对于汇接层的路由设备,可以开启netflow协议,网管系统捕获netflow数据包,以分析网络流量以及带宽利用率,对于异常流量,系统应给出告警。
2. 服务器
XX公安服务器安装有多种操作系统,其中包括Windows2003、AIX、Hp-Ux和Fedora Linux。
对于这些服务器,主要监控:
服务器基本性能指标;
服务器进程;
服务器的错误日志;
3. 数据库
XX公安现有的数据库系统包括Oracle8i、Oracle9i、Oracle10g和MS SQL-Server2000。
对于这些数据库系统,主要监控:
数据库基本性能指标;
数据库错误日志。
4. 中间件
XX公安现有的中间件系统包括WebLogic8.0和WebSphere5.0,主要监控中
间件中数据库连接池当前工作状况。
Architecture Reconstruction
Intended vs. realized architecture. Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the assumptions of the intended architecture is not always achieved. This is particularly true in cases where the intended architecture is not completely specified, documented or disseminated to all of the project members. This problem is exacerbated during maintenance and evolutionary development, as architectural drift and erosion occur.
Why architecture reconstruction important. To apply reasoning about the properties of a system's intended architecture to the properties of the implemented system, we must either ensure that the realized architecture conforms to the intended architecture or change the intended architecture to match reality. Both cases may require reconstructing the architecture of the realized system.
Phases of reconstruction. Architecture reconstruction is an iterative and interactive process, comprising four phases.
- The first phase is the extraction, from implementation artifacts (including source code and dynamic information such as event traces), of a set of extracted views that represent the system's fundamental structural and behavioral elements.
- The second phase is fusion of the extracted views to create fused views that augment or improve the extracted views.
- During the third phase, the analyst iteratively and interactively develops and applies patterns to the fused views to reconstruct architecture-level derived views. Patterns provide the medium for an analyst to express their understanding of a system's architecture as structural and attribute-based relationships among its components.
- Finally, the derived views may be explored for the purposes of evaluating architectural conformance, identifying targets for reengineering or reuse and analyzing the architecture's qualities.
The reconstruction process can be most effectively supported by the integration of existing tools and techniques. There currently exist a large number of commercial and research tools that provide the basic mechanisms for view extraction. Similarly, there are several tools and techniques available for performing view fusion and reconstruction. The synthesis of these tools and techniques provides a support environment for software architects and analysts reconstructing architectures.
To compliment our previous work in reconstruction we are currently surveying tools that are available for reconstruction to determine the current state of the practice for reconstructing architectural representations. We will study the information that these tools extract with emphasis on how they present the extracted views and how they aid in analysis of legacy systems.
The SEI will assist organizations with architecture reconstruction exercises.
Methods for Software Architecture Design
Software architecture forms the backbone for any successful software-intensive system. An architecture is the primary carrier of a software system's quality attributes such as performance or reliability. Designing the right architecture is the linchpin for software project success. Designing the wrong one is a recipe for guaranteed disaster.
Methods for Software Architecture Evaluation
How do you know if a software architecture for a system is suitable without having to build the system first?
The answer is to conduct an evaluation of it. A formal software architecture evaluation should be a standard part of the architecture-based software development life cycle. Architecture evaluation is a cost-effective way of mitigating the substantial risks associated with this highly important artifact.
The achievement of a software system's qualities attributes depends much more on the software architecture than on code-related issues such as language choice, fine-grained design, algorithms, data structures, testing, and so forth. Most complex software systems are required to be modifiable and have good performance. They may also need to be secure, interoperable, portable, and reliable. But for any particular system, what precisely do these quality attributes - modifiability, security, performance, reliability - mean? Can a system be analyzed to determine these desired qualities? How soon can such an analysis occur? What happens these quality attributes are in conflict with each other? How can the tradeoffs be examined, analyzed, and captured?
Methods for Software Architecture Documentation
Because architectures are intellectual constructs of enduring and long-lived importance, communicating an architecture to its stakeholders becomes as important a job as creating it in the first place. If the architecture cannot be understood so that others can build systems from it, analyze it, maintain it, and learn from it, then the effort put into crafting it will by and large have been wasted.
Documenting a software architecture is a matter of choosing a set of relevant views of the architecture, documenting each of those views, and then documenting information that applies to more than one view or to the set of views as a whole.
琢磨了一个多星期,终于把netflow做出来了。
关键在于理解Cisco netflow v9白皮书《Cisco IOS NetFlow Version 9 Flow-Record Format》。
我想要的就是得到源IP、目标IP、源端口、目标端口以及使用的协议,
这是程序运行的结果:
Router IP=192.168.0.254
收到netflow包,包长=1420
version=9
count=29
unixSecs=2007-11-23 03:15:19
packageSequence=9329
源IP=59.41.62.50
目标IP=192.168.3.90
协议=6
源Port=7709
目标Port=2620
源IP=58.251.60.66
目标IP=58.253.18.208
协议=6
源Port=12000
目标Port=1469
源IP=192.168.2.20
目标IP=58.61.32.11
协议=17
源Port=4000
目标Port=8000
源IP=202.106.46.151
目标IP=58.253.18.208
协议=17
源Port=53
目标Port=1034
源IP=192.168.2.20
目标IP=219.133.60.243
协议=17
源Port=4000
目标Port=8000
源IP=219.133.60.153
目标IP=58.253.18.208
协议=17
源Port=8000
目标Port=1035
源IP=192.168.3.90
目标IP=61.152.112.125
协议=6
源Port=2633
目标Port=80
-------------------------/192.168.0.254
收到netflow包,包长=1424
version=9
count=29
unixSecs=2007-11-23 03:16:12
packageSequence=9354
源IP=58.251.60.182
目标IP=192.168.2.154
协议=6
源Port=80
目标Port=2244
源IP=219.133.49.75
目标IP=58.253.18.208
协议=17
源Port=8000
目标Port=2851
源IP=192.168.2.156
目标IP=219.133.49.75
协议=6
源Port=2851
目标Port=80
源IP=4.2.2.4
目标IP=58.253.18.208
协议=17
源Port=53
目标Port=2166
源IP=192.168.2.156
目标IP=222.141.220.165
协议=6
源Port=2981
目标Port=80
下一步就是把结果入库,然后分析,得出用户想要的东西。
1. 设备管理中->查寻,要支持模糊查寻。
2. 拓扑图中可以无限滚动,不好。
3. 报警数据应该立即插入数据库,才能在告警平台上显示。
4. 报表上设备太多,没有查找功能。
5. 生成的excel报表中,没有设备名称以及查询时间
6. 修改了告警平台,压缩告警,以及删除告警(同时删除多条相同的记录)
7. 去掉Cisco的电源和风扇监视器(因为没什么用,而且耗资源)。
8. 要动态更新接口数据。
9. 如果ping不通,其它监视器则不运行。
10. 网络拓扑太大,应该按子网来分。
这些意见对我们系统改进很有帮助,将在2.0中一一改进。
In order to make a analysis of business applications,we decide to
add netflow feature into SourceView2.0.
NetFlow, much like RMON-based probes, can give you information on where,
why, how and by whom specific applications are being used and how the usage
might affect the network. NetFlow is a part of Cisco’s IOS software, and the current
version, 9, is currently moving toward standardization in the IETF as IPFIX.
Networking vendors other than Cisco, such as Enterasys and Juniper, are taking a
role in shaping the standard, and are already showing interest in adopting IPFIX.
This, of course, makes NetFlow/IPFIX far more attractive as a consistent source
for information about application flows over a network in heterogeneous environments.
NetFlow provides the following information:
* IP address source (who is sending an application service?)
* IP address destination (who is receiving service?)
* Source port (what application is it?)
* Destination port (what application is it?)
* Layer 3 protocol type
* Class of service
以前对SNMP Trap没有真正理解,今天收集到了Lucent ATM trap信息,
突然间有了收获,明白了两点:
1. 以前看过的Trap都是公用的。而设备产商可自定义Trap,比如Lucent
ATM发出来的Trap就全是自定义的。generic=6(enterpriseSpecific)表示这
个Trap是自定义的。
2. 这些Trap中的oid其实在acmib.mib中都有定义,查acmib就可以知道这
个trap是什么意思。所以,只要能把解析acmib,把acmib中symbol和oid都导
入数据库中,便可根据oid来查询symbol,从而知道这个trap的意思。
snmp trap from=172.16.1.36
generic=6
specific=5
oid=1.3.6.1.4.1.1751.2.18.8.3
version=V1TRAP
1.3.6.1.4.1.1751.2.18.15.2.0 = 905004
1.3.6.1.4.1.1751.2.18.15.3.0 = 12
1.3.6.1.4.1.1751.2.18.2.23.1.2.0 = 2
“NetworkMapper 是由本公司和清华大学联合研制的以太网络管理产品。系统采用具有自主知识产权的在国际上处于领先位置的核心技术”,不知有啥核心技术?
拓扑发现还可以,但其他基本没什么亮点,而且这个界面很久以前肯定看过,只是记不得是哪个产品了,呵呵。
很久以前一个网管给我的一个软件,系统为c/s程序。它的技术支持http://www.alliedtelesis.com.cn/support.htm已经不能访问了,呵呵。
最大的优点就是发现得比较全面,而且操作比较方便,在拓扑图上基本可以找到你想要的所有操作。
还有,可查看的内容也很丰富。