You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apollo 1.3.0 没有内置的批量导出功能,只支持单个 namespace 逐个导出。要导出所有应用的 UAT 和 PRO 环境配置,有以下两种实用方案:
方案一:直接查数据库(推荐,最高效)
Apollo 每个环境有独立的 ApolloConfigDB,已发布的配置存储在 Release 表的 Configurations 字段(JSON 格式)。分别连接 UAT 和 PRO 环境的数据库执行:
SELECT
AppId,
ClusterName,
NamespaceName,
Configurations,
DataChange_LastTime as LastModified
FROM Release
WHERE IsDeleted =0ORDER BY AppId, NamespaceName;
建议在目标环境的 ApolloConfigDB 中用只读账号执行下面的 SQL。将 公共配置所属AppId 替换成提供 test 的应用 ID;Namespace 名称按页面上的完整名称填写:
SELECTn.AppId,
n.ClusterName,
n.NamespaceName,
CASE WHEN i.Id IS NULL THEN '未本地覆盖'
ELSE '有本地配置' END AS OverrideStatus,
i.`Value`AS LocalValue,
i.DataChange_LastModifiedByAS LastModifiedBy,
i.DataChange_LastTimeAS LastModifiedTime
FROM`Namespace` n
LEFT JOIN`Item` i
ONi.NamespaceId=n.IdAND i.`Key`='name'ANDi.IsDeleted=0WHEREn.NamespaceName='test'ANDn.AppId<>'公共配置所属AppId'ANDn.IsDeleted=0ORDER BYn.AppId, n.ClusterName;
这条查询按应用、集群列出关联情况:存在本地 name 时显示其值、最后修改人和时间;没有该项也会列出。若只看配置了本地覆盖值的应用,在 WHERE 中再加 AND i.Id IS NOT NULL。这些字段分别来自 Namespace 和 Item 表,二者通过 NamespaceId = Id 关联。[1]
32. 可以通过 Namespace 关联 Item 表查询。Apollo 1.3.0 中,应用关联公共 Namespace 后,在自己的关联 Namespace 中配置同名 key,就可以覆盖公共值。这里要查的是各应用自己保存的 name,而不是继承到的公共值。1.3.0 的覆盖说明
建议在目标环境的 ApolloConfigDB 中用只读账号执行下面的 SQL。将 公共配置所属AppId 替换成提供 test 的应用 ID;Namespace 名称按页面上的完整名称填写:
SELECT
n.AppId,
n.ClusterName,
n.NamespaceName,
CASE WHEN i.Id IS NULL THEN '未本地覆盖'
ELSE '有本地配置' END AS OverrideStatus,
i.Value AS LocalValue,
i.DataChange_LastModifiedBy AS LastModifiedBy,
i.DataChange_LastTime AS LastModifiedTime
FROM Namespace n
LEFT JOIN Item i
ON i.NamespaceId = n.Id
AND i.Key = 'name'
AND i.IsDeleted = 0
WHERE n.NamespaceName = 'test'
AND n.AppId <> '公共配置所属AppId'
AND n.IsDeleted = 0
ORDER BY n.AppId, n.ClusterName;
这条查询按应用、集群列出关联情况:存在本地 `name` 时显示其值、最后修改人和时间;没有该项也会列出。若**只看配置了本地覆盖值的应用**,在 `WHERE` 中再加 `AND i.Id IS NOT NULL`。这些字段分别来自 `Namespace` 和 `Item` 表,二者通过 `NamespaceId = Id` 关联。[[1]](https://github.com/apolloconfig/apollo/blob/ea356770c6393deccd1dbfb18e5a7607e71f2f9e/scripts/sql/src/apolloconfigdb.sql#L231-L271)
注意:这里查的是**当前编辑状态**,可能包含未发布修改;“有本地配置”也不代表它一定与公共值不同。若要确认客户端当前使用的已发布值,还需要核对对应应用、集群、Namespace 的最新有效发布,不能仅凭 `Item` 判断。[[2]](https://github.com/apolloconfig/apollo/blob/ea356770c6393deccd1dbfb18e5a7607e71f2f9e/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/service/NamespaceService.java#L443-L474)
_To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apolloconfig%2Fapollo)._
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=apolloconfig%2Fapollo).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=apolloconfig%2Fapollo&message_id=f188f57a-591a-44f7-bf97-62998798013d) [](https://github.dosu.com/apolloconfig/apollo?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=apolloconfig%2Fapollo) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=apolloconfig%2Fapollo)
关联条件本身没错,但我上条没有把“返回空”的排查讲清楚,抱歉。如果执行的是原始 LEFT JOIN,没有额外加 AND i.Id IS NOT NULL,即使没有本地 name,也应该返回关联的 Namespace。 所以应先排查 Namespace 的名称、环境和排除 AppId 的条件,而不是先查 Item。
32. 可以。通过 Item.NamespaceId = Namespace.Id 关联,就能按 key 查询对应的 AppId、Namespace、key 和 value。[1]
在目标环境的 ApolloConfigDB 中,用只读账号执行,把 name 换成你要查的 key:
SELECT
n.AppId AS appid,
n.NamespaceName AS namespace,
i.Key AS key,
i.Value AS value
FROM Item i
INNER JOIN Namespace n ON n.Id = i.NamespaceId
WHERE i.Key = 'name'
AND i.IsDeleted = 0
AND n.IsDeleted = 0
ORDER BY n.AppId, n.NamespaceName, n.ClusterName;
如果要按 key **模糊查询**,将条件改成:
WHERE i.`Key` LIKE '%name%'
同一应用的不同集群可能都有这个 key,建议在 `SELECT` 中再加一列 `n.ClusterName AS cluster`,便于区分。[[2]](https://github.com/apolloconfig/apollo/blob/ea356770c6393deccd1dbfb18e5a7607e71f2f9e/scripts/sql/src/apolloconfigdb.sql#L257-L271)
注意:查询结果是数据库中**当前保存的配置项**,可能包含未发布修改,不一定是客户端正在使用的值;它也不会把公共 Namespace 的继承值展开到每个使用它的 AppId 下。[[3]](https://github.com/apolloconfig/apollo/blob/ea356770c6393deccd1dbfb18e5a7607e71f2f9e/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/service/NamespaceService.java#L440-L463) [[4]](https://github.com/apolloconfig/apollo/blob/ea356770c6393deccd1dbfb18e5a7607e71f2f9e/apollo-portal/src/main/resources/static/i18n/zh-CN.json#L503-L508)
_To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apolloconfig%2Fapollo)._
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=apolloconfig%2Fapollo).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=apolloconfig%2Fapollo&message_id=dfb35ecb-04c2-4388-99f8-49155eccd061) [](https://github.dosu.com/apolloconfig/apollo?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=apolloconfig%2Fapollo) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=apolloconfig%2Fapollo)
Activity
dosubot commentedon Jun 5, 2025
Hi @zhuangdl! I'm Dosu and I’m helping the apollo team.
Apollo 1.3.0 并不支持通过关键字进行全局配置查询。你在文档中看到的“管理员工具-全局搜索”功能,是在 2.4.0 版本才引入的,1.3.0 版本没有这个功能入口和后端实现,所以你现在的界面里找不到是正常的。如果需要全局搜索配置项,建议升级到 2.4.0 或更高版本,届时管理员可以在“管理员工具”中使用全局搜索功能,按 key 或 value 模糊查找配置项,定位其所在的应用、环境、集群和命名空间等参考。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
dosubot commentedon Jun 5, 2025
Apollo 1.3.0 没有内置全局关键字查询功能,但你可以通过查数据库实现类似需求。核心配置数据存储在
Release表(发布历史)和Item表(配置项)中。你可以用 SQL 在这些表里按 key 或 value 关键字模糊查询,比如:如果想查发布后的实际配置,可以查
Release表的Configurations字段(JSON 格式),用 SQL 的 JSON 函数或导出后用脚本处理。Apollo 的服务端代码也是通过 service 层(如
ReleaseService、ReleaseRepository)查询这些表实现配置下发的,具体实现可以参考 ConfigController 和 ReleaseRepository。注意:直接查库有一定风险,建议只读操作,避免误操作影响线上环境。
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Jun 5, 2025
@dosu 非常感谢
dosubot commentedon Jun 5, 2025
不客气!有其他 Apollo 配置相关的问题随时 @我。祝你使用顺利!
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Jun 5, 2025
@dosu 你好,如何通过namespace id获取app id呢
dosubot commentedon Jun 5, 2025
在 Apollo 1.3.0 里,NamespaceId(命名空间ID)和 AppId(应用ID)之间没有直接的映射表,但你可以通过查数据库的
Namespace表来获取。Namespace表里有Id(即 NamespaceId)和AppId字段。你可以用如下 SQL 查询通过 NamespaceId 查到对应的 AppId:
这样就能拿到这个命名空间对应的应用ID了。注意只读查询,避免误操作影响线上环境。
这种设计在 Apollo 1.3.0 里是通用的,所有命名空间的唯一标识其实是 AppId、ClusterName 和 NamespaceName 的组合,Id 只是数据库主键,业务查询一般用这三个字段组合参考。
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Jun 5, 2025
@dosu 谢谢,已解决
dosubot commentedon Jun 5, 2025
不客气!有需要随时 @我。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Jul 3, 2026
@dosu apollo机器、slb部署在云上,机器通过slb代理。本地和slb网络相同,本地和apollo机器不通。启动java程序报读apollo配置超时,将本地和config机器网络打通后,才能启动,这是为什么
dosubot commentedon Jul 3, 2026
这是 Apollo 的服务发现机制决定的。即使你的 Meta Server(SLB)地址本地可达,客户端最终仍然会直连 Config Service 的真实 IP,而不是通过 SLB 访问 Config Service。
原因如下:
Apollo 客户端启动时的连接流程是:
/services/config接口 [1]homepageUrl字段)[2]所以虽然你本地能访问 SLB,但客户端实际读配置时是直连 Config Service 机器的 IP,如果网络不通就会超时。
解决方案(任选其一):
eureka.instance.homePageUrl等参数指向 SLB)apollo.config-service跳过服务发现:在客户端直接配置-Dapollo.config-service=http://你的SLB地址,这样客户端会跳过 Meta Server 服务发现,直接用你指定的地址访问 Config Service这是 Apollo 架构设计上的特点——客户端使用长轮询(60秒 HTTP 长连接)实时接收配置变更推送 [4],这种有状态的持久连接更适合直连实例而非经过负载均衡器。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Jul 13, 2026
@dosu apollo 1.3.0版本,有DEV、UAT、PRO三个环境,如何将每个应用的UAT、PRO两个环境所有配置导出来
dosubot commentedon Jul 13, 2026
Apollo 1.3.0 没有内置的批量导出功能,只支持单个 namespace 逐个导出。要导出所有应用的 UAT 和 PRO 环境配置,有以下两种实用方案:
方案一:直接查数据库(推荐,最高效)
Apollo 每个环境有独立的 ApolloConfigDB,已发布的配置存储在
Release表的Configurations字段(JSON 格式)。分别连接 UAT 和 PRO 环境的数据库执行:这样可以一次性拿到该环境所有应用的已发布配置 [1]。
Configurations字段是 JSON 格式的 key-value 键值对 。方案二:通过 Portal API 脚本导出
1.3.0 版本有单 namespace 导出接口 [2]:
你可以写个脚本:先获取所有应用列表,再遍历每个应用的所有 namespace,逐个调用该接口导出。但效率不如直接查库。
注意事项:
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Jul 13, 2026
@dosu 直接查数据库方式,是否消耗mysql过多资源
dosubot commentedon Jul 13, 2026
正常情况下不会消耗过多资源,原因如下:
数据量有限:
Release表的记录数取决于你的应用数量和 namespace 数量,一般中小规模(几百个应用)的数据量并不大,一次 SELECT 查询压力很小。一次性查询:这是一次性的导出操作,不是持续高频查询,对数据库的影响是短暂的。
只读操作:纯 SELECT 不会产生锁竞争,不影响 Apollo 正常的配置读写。
如果你仍然担心影响线上,建议:
LIMIT分批导出,避免一次返回过大的结果集(主要是Configurations字段可能较大)SELECT COUNT(*) FROM Release WHERE IsDeleted = 0评估一下数据量总的来说,对于一次性导出场景,直接查库是安全的,不用太担心。
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
13 remaining items
dosubot commentedon Aug 28, 2026
@zhuangdl Apollo 1.3.0 的 Portal 没有专门的登录审计日志功能,代码本身不会主动记录"谁在什么时间登录了"这类信息 [1]。
具体来说:
认证流程不产生业务日志:Portal 基于 Spring Security 实现登录(
/signin接口),但在认证成功或失败时没有专门打印日志或写入审计表的逻辑 [2]。Web 容器访问日志可以间接记录:如果你的 Tomcat 或 Nginx 开启了 access log,每次登录请求的 IP、时间、URL 会出现在容器的访问日志里(但不会记录用户名等业务信息)。
认证方式影响外部日志:Apollo 支持
default(无认证)、auth(Spring Security 数据库认证)、ldap、oidc等多种登录模式 [3]。如果你接入了 LDAP 或 OIDC 外部认证系统,这些系统本身可能会有登录审计日志。总结:如果需要追溯 Portal 的登录记录,Apollo 1.3.0 本身不提供这个能力,需要依赖容器访问日志或外部认证系统的日志。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Aug 28, 2026
@dosu apollo-configservice.log、apollo-adminservice.log、apollo-portal.log记录的都是什么信息
dosubot commentedon Aug 28, 2026
@zhuangdl 这三个日志文件分别对应 Apollo 三个核心服务模块的运行日志,都是基于 Logback 的 Spring Boot 标准日志,默认级别为
INFO[1] [2] [3]:apollo-configservice.log— Config Service 的运行日志,主要包括服务启动信息、客户端拉取配置和长轮询通知的请求处理、Eureka 服务注册/发现相关信息,以及异常堆栈等。apollo-adminservice.log— Admin Service 的运行日志,主要包括服务启动信息、Portal 发起的配置增删改查和发布/回滚等管理操作的处理过程,以及异常堆栈等。apollo-portal.log— Portal Web 应用的运行日志,主要包括应用启动信息、用户在管理界面上的操作请求处理(如编辑配置、发布等)、调用 Admin Service 接口的记录,以及异常堆栈等。三个模块的日志配置结构完全一致,默认同时输出到文件和控制台 [4]。默认文件路径分别是
/tmp/apollo-configservice.log、/tmp/apollo-adminservice.log、/tmp/apollo-portal.log,可通过LOG_PATH或LOG_FILE环境变量修改 [5]。如果你是想排查某个具体问题(比如超时、报错),可以告诉我具体现象,我可以帮你定位应该重点看哪个日志和关注哪些关键字。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Aug 28, 2026
@dosu apollo-portal.log 能看到某个用户做了哪些操作吗
dosubot commentedon Aug 28, 2026
@zhuangdl
apollo-portal.log本身不能按用户维度追踪操作——它只是标准的应用运行日志(启动信息、请求处理、异常堆栈等),并非审计日志 [1]。Apollo 提供了专门的 Audit Log(审计日志)模块,能记录 Who, When, Why, Where, What and How 这些操作信息 [2],这才是你需要的功能。
如何开启:
在
application.properties中添加 [3]:apollo.audit.log.enabled = true如何查看:
AuditLog和AuditLogDataInfluence表中,可以直接 SQL 查询 [5]操作人信息来自当前登录用户(通过
UserInfoHolder获取)[6],也就是说用户通过 Portal 登录后执行的带审计注解的操作(创建应用、修改配置、发布等)都会被记录到AuditLog表中。注意: 审计日志模块是较新版本才引入的功能。如果你当前的版本较老,可能不包含该模块,需要升级后才能使用。
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
zhuangdl commentedon Oct 23, 2026
@dosu apollo1.3.0版本,某个appid提供了公共namespace test,类型为properties,有个配置name。如何查看哪些appid关联了该namespace并修改了name的值吗
dosubot commentedon Oct 23, 2026
可以通过
Namespace关联Item表查询。Apollo 1.3.0 中,应用关联公共 Namespace 后,在自己的关联 Namespace 中配置同名 key,就可以覆盖公共值。这里要查的是各应用自己保存的name,而不是继承到的公共值。1.3.0 的覆盖说明建议在目标环境的
ApolloConfigDB中用只读账号执行下面的 SQL。将公共配置所属AppId替换成提供test的应用 ID;Namespace 名称按页面上的完整名称填写:这条查询按应用、集群列出关联情况:存在本地
name时显示其值、最后修改人和时间;没有该项也会列出。若只看配置了本地覆盖值的应用,在WHERE中再加AND i.Id IS NOT NULL。这些字段分别来自Namespace和Item表,二者通过NamespaceId = Id关联。[1]注意:这里查的是当前编辑状态,可能包含未发布修改;“有本地配置”也不代表它一定与公共值不同。若要确认客户端当前使用的已发布值,还需要核对对应应用、集群、Namespace 的最新有效发布,不能仅凭
Item判断。[2]To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Oct 23, 2026
@dosu 这个sql确定没问题吧,执行了返回为空
dosubot commentedon Oct 23, 2026
关联条件本身没错,但我上条没有把“返回空”的排查讲清楚,抱歉。如果执行的是原始
LEFT JOIN,没有额外加AND i.Id IS NOT NULL,即使没有本地name,也应该返回关联的 Namespace。 所以应先排查Namespace的名称、环境和排除 AppId 的条件,而不是先查Item。建议按下面两步只读查询:
确认连接的是目标环境的
ApolloConfigDB,DEV、UAT、PRO 要分别查各自的库,不能用一个环境的结果代表其他环境。[1]先查看提供公共配置的应用实际有哪些 Namespace:
注意实际名称可能是
部门编号.test,而不是test;公共 Namespace 创建时可以自动加部门前缀,properties 类型本身不加.properties后缀。[2]用上一步查出的完整名称查询,暂时不要排除任何 AppId:
这些就是之前 SQL 左表应匹配的记录。[3]
AND i.Id IS NOT NULL,请先去掉,否则没有本地name的记录都会被过滤。另外,客户端读取了公共 Namespace,不代表它一定在 Portal 中做过关联。不需要覆盖配置的应用可以直接使用公共配置,因此这条 SQL 不能列出所有读取它的应用。[4]
请贴一下这两步的脱敏结果,以及实际执行的 SQL,不用提供配置值,就能继续定位是哪个条件过滤掉了记录。
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Oct 23, 2026
@dosu 能否用这种思路,通过key的名称,查对应value。要求返回appid、namespace、key、value
dosubot commentedon Oct 23, 2026
可以。通过
Item.NamespaceId = Namespace.Id关联,就能按 key 查询对应的 AppId、Namespace、key 和 value。[1]在目标环境的
ApolloConfigDB中,用只读账号执行,把name换成你要查的 key:如果要按 key 模糊查询,将条件改成:
同一应用的不同集群可能都有这个 key,建议在
SELECT中再加一列n.ClusterName AS cluster,便于区分。[2]注意:查询结果是数据库中当前保存的配置项,可能包含未发布修改,不一定是客户端正在使用的值;它也不会把公共 Namespace 的继承值展开到每个使用它的 AppId 下。[3] [4]
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Oct 23, 2026
@dosu 这个sql能展示关联公共namespace的appid和修改后配置,需要再修改下sql,指定key名和namespace名
dosubot commentedon Oct 23, 2026
可以,在原 SQL 中同时指定 Namespace 名和 key 名,并排除公共配置提供方的 AppId,就能列出关联应用本地保存的覆盖值。[1]
在目标环境的
ApolloConfigDB中用只读账号执行,替换下面三个条件值:这条 SQL 只返回本地配置了该 key 的关联应用,不会列出仅继承公共值、没有本地配置该 key 的应用;即使本地值与公共值相同,也会返回。[1]
结果仍是当前保存的编辑值,可能尚未发布,不一定是客户端正在使用的值。[2]
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
zhuangdl commentedon Oct 23, 2026
@dosu 如何查某个公共命名空间被哪些appid关联了
dosubot commentedon Oct 23, 2026
只查“哪些 AppId 关联了公共 Namespace”,不需要关联
Item表,也不需要指定 key。直接按 Namespace 名查询,并排除公共配置提供方的 AppId 即可,Apollo 的关联统计也使用这个逻辑。[1]在目标环境的
ApolloConfigDB中,用只读账号执行:如果还想看关联在哪个集群,将查询列改成
SELECT DISTINCT AppId, ClusterName即可。[2]注意:这查的是显式关联,不是所有读取该公共 Namespace 的应用。应用如果只读取公共配置、不做覆盖,可以不创建关联,所以不会出现在这个结果中。[3]
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.