再谈Textfsm-我所理解的textfsm上限
之前写了三篇textfsm的相关文章，我觉得国内你能看到的关于textfsm，这些是最最最详细的资料了。
最近在实际使用中，会有小伙伴和我讨论他们的模板为什么不生效。
其中有的是基础语法，有的是方向可能搞错了。
今天我们结合一个实例，再谈谈textfsm，谈谈它能处理什么样的内容，处理成什么样的结果。
大前提
大前提：textfsm是神器，但它不是万能的。
每个工具本身都是从一些场景来到一些场景去，这些场景就是它的局限性。
其实如果想写好textfsm，我是建议大家看看它的官方文档，循序渐进，讲的也比较清楚，全篇也不是很长。
以上是官方文档里的一些词，我划了一下重点，就是textfsm的上限，文本被它处理过后，是要能形成table的。
Textfsm的上限在哪里？
table是四平八稳的，大家如果学过数据库可以理解成关系型数据库里的table，或者你可以理解成一个csv文件，他们的特点就是每条记录都是长的一样的结构，由相同的字段组装成。每个字段内的值，大家可以理解成csv里的每个格子，就是字符串。
比如官方解析一个板卡，大家可以看到，解析的数据就是一个表格，是可以迁移到数据库的（需要再转换一下），或者是放到csv文件的（无需任何转换）。
这快接近了textfsm的天花板了，为什么这么说呢？
因为可能是谷歌工程师经常需要解析路由表（还有端口的allow vlan 等等，portchannel的成员等等），会有很多字段是list的结构，于是他们又努力了一把，可以实现对list数据的解析。
Destination Gateway Dist/Metric Last Change
----------- ------- ----------- -----------
B EX 0.0.0.0/0 via 192.0.2.73 20/100 4w0d
via 192.0.2.201
via 192.0.2.202
via 192.0.2.74
B IN 192.0.2.76/30 via 203.0.113.183 200/100 4w2d
B IN 192.0.2.204/30 via 203.0.113.183 200/100 4w2d
B IN 192.0.2.80/30 via 203.0.113.183 200/100 4w2d
B IN 192.0.2.208/30 via 203.0.113.183 200/100 4w2d['Protocol', 'Type', 'Prefix', 'Gateway', 'Distance', 'Metric', 'LastChange']
['B', 'EX', '0.0.0.0/0', ['192.0.2.73', '192.0.2.201', '192.0.2.202', '192.0.2.74'], '20', '100', '4w0d']
['B', 'IN', '192.0.2.76/30', ['203.0.113.183'], '200', '100', '4w2d']
['B', 'IN', '192.0.2.204/30', ['203.0.113.183'], '200', '100', '4w2d']
['B', 'IN', '192.0.2.80/30', ['203.0.113.183'], '200', '100', '4w2d']
['B', 'IN', '192.0.2.208/30', ['203.0.113.183'], '200', '100', '4w2d']成功的解析出了list。
这就是textfsm的上限，textfsm能处理的是拉平的数据，几乎是以csv这种格式可以承载的，然后兼容了部分字段是list的情况。
想要文档型数据怎么办？
之前有位读者，提出了这样一个问题，我们截取一部分他的配置（我已二次脱敏）来看一下
VSI Name: 50002
VSI Index : 6
VSI Description : XXXXXX
VSI State : Up
MTU : 1500
Bandwidth : Unlimited
Broadcast Restrain : Unlimited
Multicast Restrain : Unlimited
Unknown Unicast Restrain: Unlimited
MAC Learning : Enabled
MAC Table Limit : -
MAC Learning rate : -
Drop Unknown : -
Flooding : Enabled
Statistics : Disabled
VXLAN ID : 50002
Tunnels:
Tunnel Name Link ID State Type Flood proxy
Tunnel11 0x500000a UP Manual Disabled
Tunnel12 0x500000a UP Manual Disabled
ACs:
AC Link ID State Type
BAGG44 srv8001 0 Up Manual
BAGG45 srv8001 1 Up Manual这个是其中一个vsi的配置，整个配置是有多个vsi的，我们只摘了一段。在这个里面，vsi的相关信息都比较容易写出来，除了tunnel和ac，我理解的是这位读者想解析出成这个样子
[{
vsi_name: 50002,
index: 6,
XXX
tunnels:[{name:tunnel11, id:5000},
{name:tunnel11, id:5000}
]
ACs:[{name:bagg44, id:0},{name:bagg45, id:0}]
}]大家如果了解elastic或者MongoDB，就知道这就是一个文档型的数据了，重点是tunnels字段内的数据有了一个dict的嵌套。文档型数据可以嵌套更多。
这个是textfsm所做不到的，这种数据如果放到关系型数据库里或者csv里，需要三个tbale。
第一个放vsi的list，第二个放tunnel的list，每个tunnel的成员需要标明它与哪个vsi关联。第三个是ac的，同第二个。
按照这个思路，我觉得没有别的办法，Python脚本处理一下，或者在textfsm的基础上再高度封装，可以形成更复杂的文档型数据格式的支持。
我选择前者。因为后者成本太高，且适用场景可能没那么多，textfsm已经能处理百分之99的网络配置（基于cli的），我不排斥写一定脚本稍作处理。（也不排除我将来可能会再封装一层）
为什么Textfsm的天花板止步于list
我觉得主要是两个原因导致的
受限于网络所处的时代
这种文档型的数据处理，其实在cli的网络时代，不是很多，它更多是针对netconf和RESTful API相关场景的。textfsm是2011年开源的第一个版本，网络设备的netconf和RESTful API这个时候其实还处于萌芽阶段，支持的网络设备估计不会太多。而textfsm肯定是在2011年已经在内部有很多版本了，而早期的网络配置数据基于table，我一点也不奇怪。
性价比
从开发人员的角度而言，我觉得我们努力逼近完美，但不一定要百分百完美，完美只是目标，而不是结果。或许变通的完美就是最好的结果，textfsm的强大文本解析能力再加一丢丢Python脚本辅助，为用户实现更复杂的场景，这样性价比比较高。
anyway，这就是我理解的textfsm的天花板，以及为什么天花板在此。
抛砖引玉
笔者在做一些网络运维工具开发的时候，是想打通底层数据的，我选择了es作为数据的生料库，但是在用之前，我也是把数据拉平了一下，尽量不放过于复杂（嵌套过多）的文档型数据。
- 我是出于几种考虑，生料库的数据会流向合适的最终的目的地，一般是关系型数据库，它的关联处理能力更强，而网络的一些信息就是在不同配置数据的某些字段进行咬合关联，所以我还是选择了类似table的做法来存储网络配置数据。
- 虽然yang model的建模方式是典型的文档型数据的建模方式，能比较合理的描述配置之间的关系，放到文档型数据库里是非常好的，但是在使用过程中，这个文档嵌套过深，可读性是打折的。可读性包括两方面，一个是模型的嵌套过深，看的脑壳疼；一个是实际配置数据也会嵌套过深，同样是看的脑壳疼，需要不停的在对象里点点点，这个也是比较烦的。
- cli show出来的数据百分之95甚至以上，都是list可以比较好的展示的，如果不能，那就再detail跳转一下。人一次聚焦在一个维度其实是挺好的。用一些交互是可以近似文档的同时，增加用户体验
