前言
很早就看到了 APCC 这款工具，运维过 Greenplum 的童鞋想必都知道 GPCC (Greenplum Command Center)，十分好用的一款运维工具，基于浏览器的可视化图形界面，而且许多指标都是基于 Segment，每个 Agent 和节点本身的进程还有通信，相较于仅从 Master 节点进行采集监控指标，无疑会丰富得多。
因此当对标 GPCC 的这款 APCC 这款工具出来了之后，笔者便一直想试一下，赶巧，手头上有一套 GP6 的环境，说干就干！
APCC (Analytical Processing Central Console) 是一个专为 Cloudberry 数据库集群和 Greenplum 数据库集群设计的管理平台，旨在提供高效便捷的集群管理、监控、扩容、维护等功能。通过APCC，用户能够实现对 Cloudberry 数据库和 Greenplum 数据库的全面控制，从集群的创建、扩容到性能监控，为运维人员和开发者提供了一个高度集成的管理工具。
可惜的是，理想很丰满，现实很骨感！在历经三个小时的折腾之后，笔者最终还是放弃了。
现实很骨感
众所周知，6 版本的 GP Server，支持的平台仅包括 RHEL6.x_x86_64、RHEL7.x_x86_64、CentOS6.x_x86_64、CentOS7.x_x86_64 和 Ubuntu18.04 LTS，7 版本的 GP Server 闭源已久，可能有少部分人赶在闭源之前，留存了一些 rpm 包。我本地的环境是 Greenplum Database 6.26.4 + Centos 7.9，也正是因为这样，痛苦的事开始了。
根据官方文档：https://www.csudata.com/apcc/manual/1.x/10369，APCC 主要有两个模块：
- apcc-server：是一个主控程序，提供 WEB 界面。
- apcc-agent：在数据库的每台机器上安装。apcc-server 通过发送命令给每台数据库主机上的 apcc-agent 去完成控制数据库的功能。
apcc-server 和 apcc-agent 的环境配置在 csubase 中，apcc-server 的一些配置元数据和一些监控数据也保存到一个单独的数据库中，这个数据库叫 csumdb，是一个 PostgreSQL 数据库。所以安装 apcc-server 之前需要先安装 csubase 和 csumdb，然后再安装 apcc-server，同时在集群所有主机上安装 apcc-agent。
apcc-server 的安装整体还算顺利，虽然也遇到一些问题，但是还能接受，花个十几二十分钟，一键 yum，问题不大。比如
1 | [root@mdw ~]# /opt/apcc-server/bin/apcc-server start |
csumdb 默认装完之后，路径是 /home/csumdb/pgsql-12，应该是 BUG，因此我手动 copy 了一下目录，改为了 pgsql，并添加了动态库。其次还有 openssl 依赖、 libreadline.so.7: cannot open shared object file: No such file or directory 等问题，这里表过不提，处理起来并不棘手。装完之后，就可以登录 WEB 界面了。
可以看到，整体功能还是十分丰富的，监控 + 告警 + 运维，DBA 和运维人员的福音，笔者都有点小激动了。根据文档，下一步需要在各个计算节点上安装 apcc-agent 了，虽然大多数时候，我们在运维 Greenplum (或者类似的 PGXC 系列数据库) 的时候，基本只和 Master 节点打交道，不会去连 Segment，但是这样的话，得到的监控数据都是”片面的”，比如 pg_stat_all_tables，在 Greenplum 上，你就得提前去 analyze 一下，不然数据就会严重失真。
因此，每个节点部署 apcc-agent ，说明监控指标的详细程度和全面性是有保障的👍🏻，不过痛苦的事也随之而来，以我这个环境为例，第一行的报错便很醒目
1 | [root@seg01 ~]# ldd /opt/apcc-agent/bin/apcc-agent |
/lib64/libc.so.6: version `GLIBC_2.34’ not found，出现这种错误，通常是由于二进制文件在编译时所用的系统拥有 GLIBC_2.34 或更高版本，而你当前运行该二进制文件的系统安装了较低版本的 glibc，运行时无法找到所需的符号或版本，从而报错。问了一下 AI，支持 2.34 的包括 RHEL 9.+，CentOS Stream 9、Ubuntu 22.04、Rocky9 等等。因此，又是搜索资料，一个可行的解决办法便是升级 glibc，按照网上的步骤一步一步折腾，手动下载安装包进行编译升级，但这样很容易导致系统崩溃，很不幸，我在安装第一个数据节点的时候就中奖了，目前已经接近瘫痪：
1 | [root@seg01 ~]# ll |
至此，笔者估计花了 3 个小时，中道崩殂。但是按照官方说法
目前 APCC 支持管理Greenplum数据库版本 4、5、6、7 的集群，以及 Cloudberry database 版本 1.5.0 到 1.6.0 的集群。
并且支持平台也包括 CentOS 7，真是辛酸泪呐。
小结
小结一下，目前 apcc-agent 的部署还是不太友好，可能是在一个安装了 GLIBC_2.34 或更高版本的系统上编译和构建的。在这种环境下，编译器和链接器会将新版 glibc 中的符号信息写入可执行文件中。如果目标系统的 glibc 版本低于 2.34，就会找不到某些符号或接口，从而引发错误，说白了就是环境不一致，解决方案通常有以下几种：
- 升级目标系统的 glibc (风险较高，不建议在生产环境中轻易更改系统核心库)，这不，笔者就中奖了，操作系统瘫痪了，还好是测试环境，不然就提桶跑路了
- 在与目标系统匹配的环境中重新编译该 agent，使其链接使用系统中实际提供的 glibc 版本，但是这么一大堆系统，CentOS、Ubuntu、Rocky、Debian、Suse … 排列组合一下，工作量不小
- 采用容器或虚拟机技术，将运行环境与编译环境隔离开，使其具有正确的 glibc 版本
第三种方式无疑会更加便捷一点，另外，也可以考虑用 go/python 进行重构，Go 和 Python 通过不同方式降低了对底层系统库版本的依赖 (Go 静态链接到生成的二进制文件中，python 则是解释器)，从而使得这类版本不匹配的问题相对少见，另外，也希望官方能提供一个在线 Demo，无须繁琐安装，即可在线体验，提升产品友好性，这样无疑会更具吸引力。
不过，瑕不掩瑜，整体 APCC 的功能还是十分完善，也希望 APCC 后续版本能够更加友好，扛起大旗。