mnesia在运行时提供了大量的统计量，对这些统计量进行监控，有助于正确使用mnesia，以及对mnesia进行调优，这些统计量包括：
代码版本R15B03
1.启动与运行时参数：
运行相关参数：
mnesia是否在运行中：mnesia:system_info (is_running)
信息输出级别：mnesia:system_info (debug)
是否使用数据存储目录：mnesia:system_info (use_dir)
数据存储目录位置：mnesia:system_info (directory)
初始schema位置：mnesia:system_info (schema_location)
自动修复：mnesia:system_info (auto_repair)
是否激活fallback：mnesia:system_info (fallback_activated)
包含master的表的列表：mnesia:system_info (master_node_tables)
mnesia可等待unclear事务的未决期限，默认为infinity：mnesia:system_info (max_wait_for_decision)
mnesia的coredump文件产生的位置：mnesia:system_info (core_dir)
启动时的并行表加载器的数量：mnesia:system_info (no_table_loaders)
向远程节点发送表数据时的压缩级别：mnesia:system_info (send_compressed)
访问模块相关参数：
事务操作模块：mnesia:system_info (access_module)
备份操作模块：mnesia:system_info (backup_module)
事件模块：mnesia:system_info (event_module)
节点相关参数：
集群所有节点，包括非在线的节点：mnesia:system_info (db_nodes)
本节点可从哪些节点处同步数据：mnesia:system_info (extra_db_nodes)
集群在线节点：mnesia:system_info (running_db_nodes)
日志刷写相关参数：
定时刷写日志间隔，默认3分钟：mnesia:system_info (dump_log_time_threshold)
定量刷写日志间隔，默认1000：mnesia:system_info (dump_log_write_threshold)
是否使用原数据文件进行数据dump，true为使用原数据文件，false为新建一个临时文件：mnesia:system_info (dump_log_update_in_place)
表dump频繁程度，值越大dump表越频繁：mnesia:system_info (dc_dump_limit)
版本相关：
版本：mnesia:system_info (version)
日志版本：mnesia:system_info (log_version)
协议版本：mnesia:system_info (protocol_version)
schema版本：mnesia:system_info (schema_version)
2.表相关：
所有表（包括schema）：TableList = mnesia:system_info (tables)
表定义：PropList = mnesia:table_info(Table, all)
PropList包含了表的所有相关信息，每个Prop为{Key, Value}形式，重点包括：
active_replicas：当前活动副本节点，可求其长度
disc_copies：磁盘副本节点，可求其长度
ram_copies：内存副本节点，可求其长度
index：索引
majority：是否使用majority事务
master_nodes：是否有master副本节点
memory：占用内存
type：表类型
storage_type：表在本节点的副本类型
where_to_commit：事务需向哪些副本节点提交，可求其长度
where_to_read：可从哪个副本节点读取数据
where_to_wlock：为{NodeList, Majority}，NodeList表明事务需向哪些副本节点申请写锁，可求其长度，Majority表明是否为majority写
where_to_write：事务需向哪些副本节点写，可求其长度
对表定义监控时，可列出表定义所有信息，并对重点信息突出显示或聚合
3.锁相关：
锁被哪个事务持有：mnesia:system_info (held_locks)
排队等待的锁：mnesia:system_info (lock_queue)
一个事务持有的锁：没有直接函数，但可以通过以下方法获取：
TidLock = fun() ->
mnesia_locker ! {get_table, self(), mnesia_tid_locks},
receive {mnesia_tid_locks, Ls} -> Ls after 5000 -> [] end
end,
TidLock().
注意：上述锁信息的获取均需要干扰mnesia_locker进程的执行，其工作原理为向mnesia_locker发送请求消息，mnesia_locker读出相关ets表的所有内容，这些ets表均为private，将这些内容通过消息返回给请求进程，负载大时尽量避免使用
4.事务相关：
活动事务：{info, Participants, Coordinators} = mnesia_tm:get_info(10000)
节点参与的事务：活动事务中，Participants包含的事务，可求其长度
节点协调的事务：活动事务中，Coordinator包含的事务，可求其长度
其中节点协调的事务为本地事务，节点参与的事务为远程事务
注意：上述事务信息的获取均需要干扰mnesia_tm进程的执行，其工作原理为向mnesia_tm发送请求消息，mnesia_tm取出进程本地变量，将这些内容通过消息返回给请求进程，负载大时尽量避免使用
未决事务：这些事务处于提交阶段的中途（而非事务执行中途），可以通过mnesia:system_info()或mnesia:info()的输出得到，但不能直接取得其返回结果，可以通过如下方法获取：
ets:match_object(mnesia_decision, {'_', unclear, '_', '_'}).
注意：
mnesia在获取该项信息时，使用的匹配模式为{'_', unclear, '_'}，但经对比mnesia.hrl中对decision的定义，以及mnesia_tm中写入decision的位置，发现应该为{'_', unclear, '_', '_'}
上述事务信息的获取需要扫描整个mnesia_decision表，可能会花费较多时间，负载大时尽量避免使用
事务计数器：
总成功事务数：mnesia:system_info(transaction_commits)
总失败事务数：mnesia:system_info(transaction_failures)
总重启事务数：mnesia:system_info(transaction_restarts)
事务可能因节点down/mnesia down/无法立即获取锁而执行失败，此时mnesia_tm可以将事务进行重启，通常的mnesia:transaction(Fun)会无限重启事务。
成功事务tps：可计算一段时间间隔内的成功事务数，这将成为成功事务tps，该tps为有效tps
失败事务tps：可计算一段时间间隔内的失败事务数，这将成为失败事务tps，该tps为
重启事务tps：可计算一段时间间隔内的重启事务数，这将成为重启事务tps，当事务申请锁失败时，将进行重启执行，观察该tps的频繁程度也可以得到当前
5.事件订阅相关：
mnesia事件订阅者进程：mnesia:system_info(subscribers)
订阅系统事件：mnesia:subscribe(system)
出现系统事件后，mnesia将向订阅进程发出消息
需要关注的系统事件：
过载事件：{mnesia_overload, Detail}，其中Detail为产生过载的上下文，上下文见下段所述
数据库不一致事件：{inconsistent_database, Context, Node}，其中Context为产生不一致的上下文，上下文见
6.过载事件相关：
进行过载检查的上下文及条件：
{mnesia_tm, message_queue_len, [Prev, Len]}：
mnesia_recover每隔10s检查mnesia_tm的消息队列长度，若10s的首尾均发现消息队列长度超过100，则报告该过载事件
schema_prepare：
schema操作为同步下刷日志，下刷日志上下文为schema_prepare
time_threshold：
每隔dump_log_time_threshold个ms，将异步下刷日志，下刷日志上下文为time_threshold
write_threshold：
每产生dump_log_write_threshold个写操作，将异步下刷日志，下刷日志上下文为write_threshold
user：
用户可以通过mnesia:dump_log()进行同步下述日志，下刷日志上下文为user
对于同步/异步下刷日志，若连续两次遭遇相同上下文的下刷日志，mnesia_controller将报告该上下文的过载事件。
当有大量的日志写请求产生，而日志不能及时下刷时，通常会有write_threshold上下文的过载事件，此时通常为并发事务提交太快，而日志下刷过慢或过于频繁导致，可以适当调高dump_log_write_threshold参数
7.数据库不一致事件相关：
数据库不一致事件的上下文：
bad_decision：启动时从对端同步数据，发现事务决议不一致
starting_partitioned_network：启动时从对端同步数据，发现对端节点曾经down过
running_partitioned_network：运行时对端节点up或启动完成同步数据后，发现对端节点曾经down过
不一致事件通常发生在脑裂时，但当前有majority保护，可以仅仅监控该事件
8.日志相关：
日志计数器：
已记入日志的写操作数：mnesia:system_info(transaction_log_writes)
该值为启动以来，已记入日志的写操作数，包括dirty写
计算日志写操作qps：可计算一段时间间隔内的日志写操作数，这将成为日志写操作数qps
日志进程信息：
{info, State} = mnesia_controller:get_info(10000)
State包含的内容包括：
{
supervisor,
schema_is_merged,
early_msgs,
loader_pid,%进行远程/本地加载的进程列表，可求长度，可监控
loader_queue,%进行远程/本地加载的任务列表，可求长度，可监控
sender_pid,%向远程节点发送数据的进程列表，可求长度，可监控
sender_queue,%向远程节点发送数据的任务列表，可求长度，可监控
late_loader_queue,
dumper_pid,%进行本地日志下刷的进程，可为undefined，可监控
dumper_queue,%进行本地日志下刷的任务列表，可求长度，可重点监控
others,
dump_log_timer_ref,
is_stopping
}
具体结构需参照mnesia_controller.erl的定义，不同版本可能变动，可监控项目如上注释
注意：上述日志下刷进程信息的获取均需要干扰mnesia_controller进程的执行，其工作原理为向mnesia_controller发送请求消息，mnesia_tm取出本地状态，将这些内容通过消息返回给请求进程，负载大时尽量避免使用
日志进程工作队列信息：
{workers, Loaders, Senders, Dumper } = mnesia_controller:get_workers(10000)
Loaders为从远程/本地加载数据的worker进程的列表
Senders为向远程节点发送数据的worker进程的列表
Dumper为进行本地日志下刷的worker进程，也可以为undefined
其包含的信息较少，要获得全面的信息，可通过日志进程信息获取
注意：上述日志下刷进程信息的获取均需要干扰mnesia_controller进程的执行，其工作原理为向mnesia_controller发送请求消息，mnesia_tm取出本地状态，将这些内容通过消息返回给请求进程，负载大时尽量避免使用
9.检查点相关：
当前活动检查点：mnesia:system_info(checkpoints)
活动检查点是指通过mnesia_checkpoint:activate激活且未被mnesia_checkpoint:deactivate失活的检查点
10.其它：
待补充