This is a netflow monitor tool, you can capture, graph and store data.
Founded in 1992, the Distributed Management Task Force, Inc. (DMTF) is the industry organization leading the development of management standards and integration technology for enterprise and Internet environments.
Social Networking Meets Business, Concursive have CRM, online communitie, collaboration tools.
上面是ITIL v3的定义，CMDB的定义和v2没有变化。可以看出CMDB是一个存储配置记录的数据库，非常多的用户一拍脑门“不就是一个数据库么！我们也可以自己开发一个的。”。这样的情况下，IT组织的不同部门都可能会各自立门户，开发自己的配置管理信息库；例如：资产管理、终端分发和管理、机房管理等等。数据重复、数据不一致、配置信息不对称；无法得到跨部门和系统的报告。所以V3提出了CMS系统，它是CMDB系统的下一代管理系统。CMS系统需要 具有对现有信息资料的兼容性，CMS的建立不能忘记过去；一定要集成已有配置信息。
错误一：配置信息是一个独立的配置管理系统，由专人负责数据的更新和维护，手工的管理和维护所有数据。
错误二：最配置管理就是要做的细，我要管理到机房中的每一根网线，CI的属性需要设计的非常多，越细致越好。
错误三：我们自己有开发人员，我们有CMDB的需求，那就开始做吧，先看法着看看，不就是一个数据的增删改查么！！ITIL在国内的实施也有8年之久，就我看过和做过的项目中：service desk是最多实施的工具，它包括IM/PM；还有Change Management；用户们还可能会常常认为，Release Management可以和变更流程可以混在一起搞。服务台一般先上，有的变更流程先上，服务台的共同特点还有PM一般形同虚设。就我所见所闻的项目和用 户来说，CMDB没有那家能建的好用的好；CMDB的建设的缺失似乎成了所有ITIL用户的通病，应该也是想重点突破的瓶颈。
ITIL v3发布后，CMDB成了CMS中的一个数据库；而且，CMS中包括不止像CMDB这样的配置信息数据库，其实任何保存配置信息的数据库都算在CMS系统 内。既然是一个系统，所以它就不光包含数据还包含一套配套工具集合，通过这套工具，维护和使用配置信息。CMS为其他所有ITIL流程提供基础的配置信 息。它的结构如下图所示：
配置管理系统
如果说上面这幅图比较还是比较抽象的话，那么请见下图：
CMS is a set of tools based on all configuration data
从上图中我们看到，CMS系统一共可以分为四层。上三层是核心CMDB数据库和相关配套工具，最低层Data层则是是所有配置信息的基础来源。从 ITIL v3的角度来说，只建设一个集中的CMDB数据库来存储所有的CI信息是不够的，CMS系统中必须能够包含和处理所有企业已有的各个系统中的配置数据。换 言之，CMDB建设的局限性在于，它只是配置信息数据化，或者说电子化的第一步。
当前依然有很多企业雄心勃勃的上马CMDB项目，不过切记在规划时，一定先好好阅读一下ITIL v3中和CMS相关的内容，适当调整项目的目标和预期总是好的，也可以规避一些项目风险。
CMDB不只是一个数据库那么简单，更不可能在服务台的数据库中建立几张表就可以搞定。从企业IT管理的全局出发，按照 ITIL v3的规范，建设CMS应该是所有ITIL项目的当务之急。CMS系统决不能遗忘过去，必须有效整个现有的各个配置信息数据源，无论其以何种形式存在。它 必须是一个开放的平台，能过最大限度的和其他任何配置信息的消费者（ITIL流程，以及任何需要获取配置信息的任何应用）整合，
以上的一些是我对CMS建设的一些认识。如果要落地到项目上还不许经过一个痛苦的过程，那就是产品选型。选项的过程中可以注重一下几点：
最近可能还会接触一下CMDB的项目，其他经验总结待续。
