日志分析运维观测【免费下载链接】graylog2-serverFree and open log management项目地址https://gitcode.com/gh_mirrors/gr/graylog2-server点击查看免费下载本文基于 graylog2-server 仓库data-node/migration/目录下的 Manual Migration Guide 及其配套脚本与配置完整讲解如何把一个既有 OpenSearch 2.x 或 1.3.x 集群以及 Elasticsearch 7.10 集群手动迁移为 Graylog DataNode 集群。读者将掌握证书生成与无证书环境的适配方法、OpenSearch Security 从用户/角色模型切换为JWT 认证模型的关键步骤、securityadmin.sh数据重载操作以及通过 Preflight UI 完成 DataNode 证书配发的完整流程。文中所有命令、配置片段均可在仓库中对应的 docker-compose.yml、es710-docker-compose.yml、cert.sh、custom-opensearch.yml 等文件中找到原始出处。文档性质与适用前提仓库中的这份 Manual-Migration.md 明确标注为preliminary初稿/前置验证文档其定位是为当前代码库找出哪些修改是必须的提供一个最小化基础并用于研究、测试可能的用户体验改进、找出实际能力边界。它来自开发者自建 Docker 环境的实践而非官方承诺的生产迁移路径。因此请注意三条重要前提生产环境不可直接照搬文档原文强调如果你试图用这份指南对真实生产系统做手动迁移所有关于证书等的准备工作大概率与你的使用场景不匹配请自行调整。本文所有密码、证书 DN、hostname 均来自开发环境示例。Docker 复现环境整个流程基于 Docker 编排以保证步骤可重复真实安装如 OS 包安装步骤必然存在差异但迁移逻辑数据目录、安全配置切换、认证机制是通用的。可能有用武之地文档提到这些步骤未来可能用于 PSO专业服务或支持团队手动迁移、修复迁移中发生的问题也可作为运维排障时的参考手册。迁移前必须注意的事项文档列出了一份未充分测试但必须留神的清单核心是保持原有元数据与集群拓扑的一致性保持 hostname 不变DataNode 节点继续沿用原 OpenSearch 节点的 hostname示例中 DataNode 的hostname直接设为opensearch1/2/3。保持 cluster name 不变示例中cluster.namedatanode-cluster在整个迁移过程始终保持一致。原因是 OpenSearch 数据目录中已经写入的集群元数据cluster state、security index 等与节点名、集群名强绑定。一旦改动可能与数据目录中的既有元数据产生冲突例如.opendistro_security索引、nodes 信息轻则启动失败重则损坏数据。文档还特别警告在很多情况下遗漏一步或出现一个错误你除了完全重来之外别无选择而生产环境可能不具备重来的条件——所以务必先做完整备份。另外文档附带一条 macOS 开发提示如果在 macOS 上测试/开发时遇到为 Docker 设置vm.max_map_count失败的情况且正在运行最新版 Docker很可能是最新 Docker 版本与 macOS Sonoma 不兼容唯一解决办法是降级 Docker 版本。迁移目录里的配套文件清单data-node/migration/目录下除指南外还有 7 个配套文件迁移全程都围绕它们展开文件作用docker-compose.yml主编排文件迁移过程中被反复修改es710-docker-compose.ymlElasticsearch 7.10 迁移专用编排文件cert.sh为 OpenSearch 集群生成证书的脚本custom-opensearch.yml证书相关的 OpenSearch 配置挂载为opensearch.ymlopensearch-security-config.yml迁移前使用的 OpenSearch 安全配置用户/角色模型datanode-security-config.yml迁移后使用的默认 DataNode 安全配置JWT 模型create-docker-images.sh本地生成 Graylog / DataNode Docker 镜像的开发辅助脚本环境准备本地镜像与无证书集群的裁剪本地构建镜像开发阶段可使用create-docker-images.sh创建/引入本地生成的 Graylog 或 DataNode Docker 镜像便于在改动代码后快速验证迁移流程。不使用证书时的裁剪方法如果目标 OpenSearch 集群不使用证书无 TLS就不需要生成证书需要从 docker-compose.yml 中删除三处内容从每个 OpenSearch 服务opensearch1/2/3的 volumes 中删除证书相关挂载行?按服务替换为 1–3- ./root-ca.pem:/usr/share/opensearch/config/root-ca.pem - ./node?.pem:/usr/share/opensearch/config/node.pem - ./node?-key.pem:/usr/share/opensearch/config/node-key.pem - ./admin.pem:/usr/share/opensearch/config/admin.pem - ./admin-key.pem:/usr/share/opensearch/config/admin-key.pem - ./keystore.jks:/usr/share/opensearch/config/keystore.jks - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml从 graylog 服务 environment 中删除证书配置GRAYLOG_CA_KEYSTORE_FILE: /usr/share/graylog/data/keystore.jks GRAYLOG_CA_PASSWORD: password从 graylog 服务 volumes 中删除- ./keystore.jks:/usr/share/graylog/data/keystore.jks准备env文件修改env文件内容与仓库常规 docker compose 示例一致其中提供GRAYLOG_PASSWORD_SECRET密码密钥与GRAYLOG_ROOT_PASSWORD_SHA2admin 密码的 SHA-256两个变量并重命名为.env。docker-compose.yml 中通过${GRAYLOG_PASSWORD_SECRET:?...}与${GRAYLOG_ROOT_PASSWORD_SHA2:?...}引用它们缺失时会直接报错提示。同时可选的${DATANODE_IMAGE}/${GRAYLOG_IMAGE}变量用于覆盖默认的graylog/graylog-datanode:5.2.0与graylog/graylog:5.2.0镜像。生成证书使用证书的场景运行 cert.sh 为 OpenSearch 集群生成证书证书相关口令统一使用password以与其他脚本/文件保持一致。脚本执行的内容包括生成 2048 位 RSA 根 CAroot-ca-key.pem/root-ca.pem有效期 730 天subject 为/CCA/STONTARIO/LTORONTO/OORG/OUUNIT/CNroot生成 admin 证书admin-key.pem/admin.pemCNA依次为opensearch1、opensearch2、opensearch3生成节点证书每个证书的 subjectAltName 为对应节点 DNS 名清理中间文件csr、临时 key、ext用keytool -import -trustcacerts将各节点证书、admin 证书与根 CA 导入keystore.jks别名为opensearch1/2/3、admin、root。这些证书随后被 custom-opensearch.yml 引用该文件配置了 transport/http 层的 PEM 证书路径node.pem、node-key.pem、root-ca.pem、JKS truststorekeystore.jks口令password以及plugins.security.authcz.admin_dnCNA,OUUNIT,OORG,LTORONTO,STONTARIO,CCA和plugins.security.nodes_dn三个节点的 CN等安全配置。准备 DataNode 安全配置把密码密钥写入 JWT 配置datanode-security-config.yml 是 DataNode 使用的 OpenSearch Security 配置核心差异在于它启用了JWT 认证域jwt_auth_domainhttp_enabled: true、transport_enabled: true、order: 0认证方式为type: jwt非挑战式并设置了roles_key: os_roles。迁移前需要把GRAYLOG_PASSWORD_SECRET以 base64 形式填入该文件第 131 行的signing_key字段。文档给出的转换方法echo The password secret you chose | base64将输出粘贴到datanode-security-config.yml中signing_key:的引号内替换默认占位base64 encoded GRAYLOG_PASSWORD_SECRET from .env file。该 HMAC 密钥正是后续 Graylog 签发、OpenSearch 校验 JWT 的共同秘密——从源码看DataNode 侧由 DatanodeJwtAuthTokenProvider 负责生成带os_roles角色的 JWT而 OpenSearch Security 插件以相同密钥验签二者必须严格一致。从 OpenSearch 2.x / 1.3.x 迁移的完整步骤以下步骤基于 docker-compose.yml单 MongoDBmongo:7.0 单 Graylog 节点 三节点 OpenSearchopensearchproject/opensearch:2.10.0。全程可通过docker compose down -v加还原文件修改来随时重来。步骤 1OpenSearch 1.3.x 的镜像替换若源集群是 OpenSearch 1.3.x只需把三个服务的镜像2.10.0替换为1.3.1即可对应 es710-docker-compose.yml 中的 OpenSearch 部分写法。步骤 2创建容器并启动原始集群docker compose create docker compose up -d mongodb opensearch1 opensearch2 opensearch3 graylog1等集群就绪后在 Graylog Web 界面创建一个 Input摄入一些数据例如发送测试 GELF/syslog 日志验证旧集群工作正常。步骤 3停止服务并切换 OpenSearch 安全配置docker compose stop graylog1 opensearch1 opensearch2 opensearch3修改docker-compose.yml中三个 OpenSearch 服务的 security config 挂载把注释切换到datanode-security-config.yml即从用户/角色模型切换到JWT 认证模型- ./opensearch-security-config.yml:/usr/share/opensearch/config/opensearch-security/config.yml # - ./datanode-security-config.yml:/usr/share/opensearch/config/opensearch-security/config.yml改为# - ./opensearch-security-config.yml:/usr/share/opensearch/config/opensearch-security/config.yml - ./datanode-security-config.yml:/usr/share/opensearch/config/opensearch-security/config.yml对比两个安全配置文件可以看清差异opensearch-security-config.yml 中basic_internal_auth_domain为http_enabled: trueHTTP Basic 内部用户库而 JWT 域处于禁用状态datanode-security-config.yml 则反过来禁用了 basic 域、启用 JWT 域。这正是从用户/角色模型切到 JWT 认证的本质。步骤 4重启 OpenSearch 并重载安全数据docker compose create opensearch1 opensearch2 opensearch3 docker compose up -d opensearch1 opensearch2 opensearch3通过日志或curl确认 OpenSearch 已恢复。然后用docker ps取得任一节点容器 ID进入容器执行 OpenSearch Security 的securityadmin.sh重载安全配置docker exec -it ID bash cd /usr/share/opensearch/plugins/opensearch-security/tools ./securityadmin.sh -f /usr/share/opensearch/config/opensearch-security/config.yml -icl -h opensearch1 -nhnv -cacert ../../../config/root-ca.pem -cert ../../../config/admin.pem -key ../../../config/admin-key.pem命令参数含义-f指定要加载的配置文件-iclinitialize cluster在集群首次初始化时也允许执行-h指定目标节点-nhnv关闭 hostname 校验-cacert/-cert/-key提供 admin 证书链。这一步是整个迁移的关键它确保 OpenSearch 数据目录包含 security indices 等在把数据目录挂载给 DataNode 之前就已写入 JWT 认证数据。否则后续 DataNode 接管数据目录时安全索引中的认证配置仍是旧模型无法用 JWT 通信。步骤 5停止 OpenSearch修改 Graylog 为 Preflight 模式docker compose stop opensearch1 opensearch2 opensearch3修改 graylog 服务的 environment注释掉连接 OpenSearch 的配置与证书配置开启 Preflight Web UI# GRAYLOG_CA_KEYSTORE_FILE: /usr/share/graylog/data/keystore.jks # GRAYLOG_CA_PASSWORD: password # GRAYLOG_ELASTICSEARCH_HOSTS: https://admin:adminopensearch1:9200,https://admin:adminopensearch2:9200,https://admin:adminopensearch3:9200 GRAYLOG_ENABLE_PREFLIGHT_WEB: true步骤 6启动 DataNode 并通过 Preflight UI 配发证书docker compose create graylog1 docker compose up -d graylog1 datanode1 datanode2 datanode3用docker compose logs -f graylog1查看日志末尾输出的认证信息然后登录http://localhost:9000的Preflight UI。在界面中为三个 DataNode 配发provision证书配发成功后 DataNode 会启动并进入 green 状态随后继续ResumeGraylog 的启动流程。文档提示此时暂时不应发生任何额外动作——这个问题会在开发中很快被处理随即执行docker compose stop graylog1。值得说明的是DataNode 的证书生命周期管理在源码中有完整实现从preflight包下的 DatanodeCertReceiver、DatanodeKeystoreInitService到定期的 DataNodeCertRenewalPeriodical再到 REST 层的 CertificatesController构成签发—下发—续期的完整链路迁移时 DataNode 与 Graylog 之间的 TLS 即依赖这套机制。步骤 7关闭 Preflight恢复 Graylog 正常启动在docker-compose.yml中注释掉 Preflight 开关# GRAYLOG_ENABLE_PREFLIGHT_WEB: true然后docker compose create graylog1 docker compose up -d graylog1此时即可用常规账号登录http://localhost:9000的 Graylog 界面此时后台已是DataNode 集群三个 DataNode 服务各自挂载了原 OpenSearch 的数据卷见 compose 中opensearch-data-0X:/var/lib/graylog-datanode/opensearch/data的映射关系原有数据与索引继续可用。从 Elasticsearch 7.10 迁移必须经由 OpenSearch 中转Elasticsearch 7.10 的迁移需要额外一步因为ES 7.10 原生不支持 JWT 认证。因此不能直接对 ES 数据目录做安全配置切换必须先把它变成 OpenSearch再走上述 OpenSearch 迁移流程。参考 es710-docker-compose.yml它演示了完整链路Elasticsearch 阶段elasticsearch1/2/3使用docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2镜像注意其hostname与node.name已经被设为opensearch1/2/3、cluster.name设为datanode-cluster文档说明示例中为了省事改了名字真实场景应反过来——把 elasticsearch 的名字贯穿整个迁移流程带到 DataNode即遵循保持 hostname 与 cluster name 不变的原则。ES 服务直接挂载opensearch-data-0X数据卷且此阶段不挂载任何证书。启动并灌数据docker compose up -d elasticsearch1 elasticsearch2 elasticsearch3 # ... 写入测试数据 ... docker compose stop elasticsearch1 elasticsearch2 elasticsearch3原地替换为 OpenSearchopensearch1/2/3opensearchproject/opensearch:1.3.1指向同一批数据目录docker compose up -d opensearch1 opensearch2 opensearch3该 compose 文件中 OpenSearch 服务已挂载datanode-security-config.ymlJWT 安全配置、custom-opensearch.yml与各节点证书也就是说 OpenSearch 起来时就直接携带 JWT 配置启动前务必确认已把正确的 base64 编码 secret 填入了安全配置文件。执行securityadmin.sh重载命令与上节一致然后完全沿用 OpenSearch 1.3.x 迁移的后续步骤Preflight UI、DataNode 证书配发、关闭 Preflight、恢复 Graylog。注意ES 阶段不含证书证书是在启动 OpenSearch 集群时通过cert.sh等生成的。ES 数据Lucene 索引格式能被 OpenSearch 1.x 直接读取这是原地替换可行的基础。从源码理解迁移后的运行机制迁移完成后DataNode 接管了原搜索集群的全部职责。仓库中data-node/src/main/java/org/graylog/datanode/下的实现可帮助深入理解这套机制进程管理OpensearchProcessImpl 与 OpensearchProcessService 负责拉起、监控底层 OpenSearch 进程OpensearchStateMachine 管理节点的生命周期状态start/stop/cert-received 等。安全与认证JwtTokenAuthFilter 对 DataNode API 请求做 JWT 校验DatanodeJwtAuthTokenProvider 为 OpenSearch 生成携带os_roles的令牌——这正是迁移配置中signing_key/roles_key的运行时对应物。数据目录兼容性迁移的本质风险在于数据目录。filesystem/下的 OpensearchDataDirCompatibilityService 及配套测试 OpensearchDataDirCompatibilityServiceTest、OpensearchDataDirCompatibilityCheck 会在 DataNode 启动前检查既有数据目录的索引版本与格式兼容性如 Lucene 版本、是否包含 DataNode 所需目录结构支撑原 OpenSearch/ES 数据目录直接交给 DataNode这一迁移核心假设。集成验证data-node/src/test/java/org/graylog/datanode/integration/下的 DatanodeClusterIT、DatanodeSecuritySetupIT 等集成测试覆盖了集群组建与安全配置场景是理解 DataNode 集群行为的参考实现。迁移清单速查最终整理成可直接对照执行的操作顺序备份全部数据卷MongoDB、OpenSearch 数据目录、Graylog 数据与 journal核对.env中GRAYLOG_PASSWORD_SECRET与GRAYLOG_ROOT_PASSWORD_SHA2运行 cert.sh 生成证书口令password或按上文裁剪无证书配置将GRAYLOG_PASSWORD_SECRETbase64 后写入 datanode-security-config.yml 的signing_keydocker compose create并up -d mongodb opensearch1 opensearch2 opensearch3 graylog1建 Input、灌数据docker compose stop graylog1 opensearch1 opensearch2 opensearch3切换安全配置挂载为datanode-security-config.yml重启 OpenSearch容器内执行securityadmin.sh重载 JWT 安全数据docker compose stopOpenSearch修改 graylog 环境变量注释旧连接、开启GRAYLOG_ENABLE_PREFLIGHT_WEBup -d graylog1 datanode1 datanode2 datanode3登录http://localhost:9000Preflight UI配发 DataNode 证书、等待节点 green、Resume Graylog然后停 graylog注释 Preflight 开关重新createup -d graylog1用常规账号登录验证Elasticsearch 7.10 场景在步骤 3 前先按 es710-docker-compose.yml 用 ES 7.10 灌数据再原地换为 OpenSearch 1.3.1 接管同一数据目录之后并入步骤 4 起的流程。再次强调这是初步preliminary迁移指南目标是为开发、研究与支持场景提供可复现的最小基准。生产环境迁移请以官方发布文档为准并务必在完整备份、隔离验证之后再进行。赞分享日志分析运维观测【免费下载链接】graylog2-serverFree and open log management项目地址https://gitcode.com/gh_mirrors/gr/graylog2-server点击查看免费下载相关推荐Akagi麻将AI助手实时分析你的雀魂对局从新手到高手的智能学习伙伴Akagi麻将AI助手实时分析你的雀魂对局从新手到高手的智能学习伙伴 还在为麻将技术提升缓慢而烦恼吗想从雀魂新手快速成长为高手却苦于没有专业的指导Ak桌面应用人工智能如何在5分钟内掌握跨平台代码签名osslsigncode完整指南如何在5分钟内掌握跨平台代码签名osslsigncode完整指南 想象一下你正在Linux或macOS上开发Windows应用程序却因为无法进行代码签名而应用安全代码签名开发工具Swagger-Client 从 2.x 升级到 3.x 迁移指南Swagger Client 从 2.x 升级到 3.x 迁移指南 前言 Swagger Client 作为处理 OpenAPI/Swagger 规范的核心工具后端上一篇Genkit Python Ollama 插件实战本地 LLM 聊天、流式生成、工具调用与向量嵌入接入指南下一篇Kazumi追番神器3分钟打造专属动漫资源库跨平台免费追番指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
