管理节点

当节点正在运行的时候,它暴露了一个 RPC 接口可以让你来监测它,你可以上传和下载附件,访问 REST API 等等。

Logging

默认的,节点的 log 文件会存储在工作目录下的 logs 子目录中,并且会随时的更新。你可以通过传入 --log-to-console 命令行参数来同样将日志打印在 console 中。默认的日志等级是 INFO,可以通过 --logging-level 命令行参数来调整。这个配置选项会影响所有的模块。

有时候你可能想针对某个模块的 subset 变更 log 级别(比如你想更详细地查看 Hibernate activity)。所以,对于更加定制的 logging 配置,logger 的配置可以用分配给 log4j.configurationFile 系统属性一个 Log4j 2 配置文件的通过 更多的自定义 logging,可以通过将一个 Log4j2 配置文件来彻底重写 logger 的设置。

样例

在当前的工作目录中创建一个 sql.mxl 文件:

<?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
        <Appenders>
            <Console name="Console" target="SYSTEM_OUT">
                <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
            </Console>
        </Appenders>
        <Loggers>
            <Logger name="org.hibernate" level="debug" additivity="false">
                <AppenderRef ref="Console"/>
            </Logger>
            <Root level="error">
                <AppenderRef ref="Console"/>
            </Root>
        </Loggers>
    </Configuration>

注意一个额外的名为 org.hibernate 的 logger 设置了指定的 logger level 为 debug

像常规一样启动节点,但是带有一个额外的参数 log4j.configurationFile,指向上边的文件名,比如: java <Your existing startup options here> -Dlog4j.configurationFile=sql.xml -jar corda.jar

为了确定 logger 的名字,对于 Corda 对象,使用完全合格的名字,fully qualified name(比如为了查看节点的 output 更详细的信息,可以使用 net.corda.node.internal.Node,但是要知道我们给这个类标记为 internal,我们保留移动或者改变名字的权利因为他还不是公开 API 的一部分)。对于其他的类库,参考他们的 logging 名字结构。如果你找不到你需要参考什么,像上边那样使用 --logging-level 选项然后从 console 的 output 中确定 logging 模块的名字。

数据库访问

节点通过一个 socket 暴露了它的内部数据库,这个数据库可以使用任何使用 JDBC drivers 的工具所浏览。JDBC URL 会在节点启动的时候被打印在 console 中,像下边这样: jdbc:h2:tcp://192.168.0.31:31339/node

用户名和密码可以在 配置节点 中进行更改,默认的用户名是“sa”,密码是空。

可以使用任何支持 JDBC 的数据库访问工具,但是如果你有 IntelliJ Ultimate edition,那么你的 IDE 有一个集成的工具可以使用。只需要打开 database window,并根据上边的详细信息添加一个 H2 data source。然后你就可以在里边浏览表和数据了。

监控你的节点

像大多数的 Java servers 一样,节点通过业界标准的 JMX infrastructure 暴露了很多有用的 metrics 和管理维护方法。JMX 是一个标准的 API,通常被称为 MBeans... 对象,它的属性和方法通常被用来进行 server 管理。为了 export,它不需要任何指定的网络协议。所以从节点中可以使用多种方式来导出数据:一些监控系统提供一个“Java Agent”,它是一个查找所有的 MBeans 并且通过网络向他们发送一个统计数据搜集器(statistics collector)的 JVM plugin。对于这些系统,按照 vendor 提供的指导去使用他们。

Jolokia 允许你不需要直接连接 JMX port 就可以访问 raw data 和维护操作。节点通过 HTTP 在 /jolokia HTTP endpoint 上导出数据,Jolokia 定义了 JSON 和 REST 格式来访问 MBeans,也提供了客户端类库来跟这个协议一同工作。

有以下几种方式来创建 dashboard 并导出节点的监控数据:

节点的配置参数 exportJMXTo 应该设置为 http 来确保一个 Jolokia 代理会带有 JVM run-time。

下边的 JMX statistics 可以被导出:

当使用 Cordformation runner 启动节点的时候(查看 运行本地节点),你应该会看到类似下边的启动信息: Jolokia: Agent started with URL http://127.0.0.1:7005/jolokia/

当使用 DriverDSL 方式启动节点的时候,你应该在 Logs 中看到像下边这样的启动信息: Starting out-of-process Node USA Bank Corp, debug port is not enabled, jolokia monitoring port is 7005 {}

/config/<evn> 目录下有针对于 dev, test 和 prod 环境的多个基于 Jolokia policy 的安全配置文件(jolokia-access.xml)。

下边的图片显示了使用 hawtio 查看的 Corda flow metrics: Corda Flow Metrics

内存使用和优化

对所有的垃圾搜集程序来说,如果你给他们更多的内存他们会运行的更快,因为他们会更少地需要去搜集。默认的如果你让 JVM 消耗掉你系统中的所有内存的话,那么 JVM 会很愿意那样去做的,Corda 默认会设置为相对比较小的 200mb Java heap。当其他的部分也在消耗内存的时候,一个节点的内存的总体使用量大概会在 500mb 左右(这些消耗可能来自于编译代码、metadata、off-heap buffers、线程栈等)。

如果你希望你的节点更快并且想要超过 GC 最大值的话,或者你的节点出现了 out of memory 的问题,你可以用下边的参数给节点分配更多的内存:

java -Xmx1024m -jar corda.jar

这个例子命令会提供一个 1 gigabyte Java heap。

注意:JVM 不会允许你限制被 Java 程序所使用的内存,仅仅允许你可以修改 heap size。