本页介绍了 Looker 架构中特定组件的常见做法，并介绍了如何在部署中配置这些组件。
Looker 有许多依赖项，用于托管服务器、处理临时和定期工作负载、跟踪迭代模型开发等。本页面将此类依赖项称为组件，以下各部分详细介绍了每个组件：
主机配置
操作系统和分发
Looker 在最常见的 Linux 版本（RedHat、SUSE 和 Debian/Ubuntu）上运行良好。这些发行版的派生版本通常可以正常运行，因为它们是专为在特定环境中运行而设计和优化的。例如， Google Cloud 或 AWS 发行版的 Linux 与 Looker 兼容。Debian/Ubuntu 是 Looker 社区中最常用的 Linux 变种，也是 Looker 支持团队最熟悉的版本。最简单的方法是使用 Debian/Ubuntu 或特定云服务提供商提供的从 Debian/Ubuntu 派生的操作系统。
Looker 在 Java 虚拟机 (JVM) 中运行。选择发行版时，请考虑 OpenJDK 11 的版本是否是最新的。较低版本的 Linux 发行版可能能够运行 Looker，但 Looker 针对特定功能所需的 Java 版本和库必须是最新版本。如果 JVM 不包含所有推荐的 Looker 库和版本，Looker 将无法正常运行。Looker 需要 Java HotSpot 1.8 update 161 或更高版本，或者 Java OpenJDK 11.0.12 或更高版本。
CPU 和内存
对于开发系统或小型团队使用的 Looker 基本测试实例，4x16（4 个 CPU 和 16 GB RAM）节点就足够了。不过，对于生产环境，这通常还不够。根据我们的经验，16x64 个节点（16 个 CPU 和 64 GB RAM）在价格和性能之间取得了良好的平衡。超过 64 GB 的 RAM 可能会影响性能，因为垃圾回收事件是单线程的，并会暂停所有其他线程的执行。
磁盘存储
100 GB 的磁盘空间通常足以满足生产系统的需求。
集群注意事项
Looker 在 Java JVM 上运行，而 Java 在管理超过 64 GB 的内存时可能会遇到困难。一般来说，如果需要更多容量，您应向集群中添加更多 16x64 节点，而不是将节点大小增加到超过 16x64。我们可能还会选择使用集群架构来提高可用性。
在集群中，Looker 节点需要共享文件系统的某些部分。共享的数据包括：
- LookML 模型
- 开发者 LookML 模型
- Git 服务器连接
由于文件系统是共享的，并且托管着多个 Git 代码库，因此处理并发访问和文件锁定至关重要。文件系统必须符合 POSIX 标准。网络文件系统 (NFS) 已知可行，并且可在 Linux 中轻松使用。您应创建一个额外的 Linux 实例，并配置 NFS 以共享磁盘。默认 NFS 可能存在单点故障，因此请考虑采用故障切换设置或高可用性设置。
Looker 元数据也需要集中管理，因此其内部数据库必须迁移到 MySQL。这可以是 MySQL 服务，也可以是专用的 MySQL 部署。本页的内部（后端）数据库部分会对此进行更详细的介绍。
JVM 配置
Looker JVM 设置在 Looker 启动脚本中定义。进行任何更新后，都必须重启 Looker，才能使更改生效。默认配置如下：
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
资源
资源设置在 Looker 启动脚本中定义。
JAVAMEM="2300m" METAMEM="800m"
为 JVM 分配内存时，需要考虑 Looker 所运行的操作系统开销。一般而言，JVM 最多可分配总内存的 60%，但具体取决于机器大小。对于总内存至少为 8 GB 的机器，我们建议将 4-5 GB 分配给 Java，并将 800 MB 分配给 Meta。对于较大的机器，可以为操作系统分配较小比例的内存。例如，对于总内存为 60 GB 的机器，我们建议将 36 GB 分配给 Java，并将 1 GB 分配给 Meta。请务必注意，Java 的内存分配通常应随机器的总内存而扩缩，但 1 GB 的内存应该足以满足 Meta 的要求。
此外，由于 Looker 会与 Chromium 等其他进程共享系统资源以进行渲染，因此应根据预期的渲染负载和机器大小选择分配给 Java 的内存量。如果预计渲染负载较低，则可以为 Java 分配更多总内存。例如，在总内存为 60 GB 的机器上，可以将 46 GB 的内存安全地分配给 Java，这高于一般建议的 60%。适合每个部署的确切资源分配因情况而异，因此请将 60% 用作基准，并根据使用情况进行调整。
垃圾回收
Looker 首选使用适用于其 Java 版本的最现代化的垃圾回收器。默认情况下，垃圾回收超时时间为 2 秒，但您可以通过修改启动配置中的以下选项来更改此时间：
-XX:MaxGCPauseMillis=2000
在具有多个核心的大型机器上，垃圾回收超时时间可能会缩短。
日志
默认情况下，Looker 垃圾回收日志存储在 /tmp/gc.log 中。如需进行更改，请在启动配置中修改以下选项：
-Xloggc:/tmp/gc.log
JMX
管理 Looker 可能需要监控，以帮助优化资源配置。我们建议使用 JMX 监控 JVM 内存用量。
Looker 启动选项
启动选项存储在名为 lookerstart.cfg 的文件中。此文件的来源是启动 Looker 的 Shell 脚本。
线程池
作为一个多线程应用，Looker 具有多个线程池。这些线程池包括核心 Web 服务器，以及调度、渲染和外部数据库连接等专用子服务。根据您的业务工作流，您可能需要修改这些池的默认配置。特别要注意的是，客户托管的基础架构架构模式和实践页面中提到的集群拓扑。
高调度吞吐量选项
对于所有非调度程序节点，请将 --scheduler-threads=0 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。如果没有调度器线程，这些节点上将不会运行任何预定的作业。
对于所有专用调度程序节点，请将 --scheduler-threads=<n> 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。Looker 默认启动 10 个调度程序线程，但可以增加到 <n>。使用 <n> 个调度程序线程时，每个节点都能够执行 <n> 个并发调度作业。通常建议将 <n> 保持在 CPU 数量的 2 倍以下。建议的最大主机是具有 16 个 CPU 和 64 GB 内存的主机，因此调度程序线程的上限应小于 32。
高渲染吞吐量选项
对于所有非渲染节点，请将 --concurrent-render-jobs=0 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。如果没有渲染程序节点，这些节点上将不会运行任何渲染作业。
对于所有专用渲染节点，请将 --concurrent-render-jobs=<n> 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。Looker 默认从两个渲染线程开始，但可以增加到 <n>。使用 <n> 个渲染线程时，每个节点都能够执行 <n> 个并发渲染作业。
每个渲染作业都可能会使用大量内存。每个渲染作业的预算约为 2 GB。例如，如果核心 Looker 进程 (Java) 分配了 60% 的总内存，并且剩余内存的 20% 预留给操作系统，则剩余的 20% 将用于渲染作业。在 64 GB 的机器上，剩下 12 GB，足以支持 6 个并发渲染作业。如果某个节点专用于渲染，并且不包含在处理 Interactive 作业的负载平衡器池中，则可以减少核心 Looker 进程内存，以便处理更多渲染作业。在 64 GB 的机器上，您可以将大约 30%（20 GB）的内存分配给 Looker 核心进程。将 20% 预留给常规操作系统用途，剩下 50%（32 GB）用于渲染，这足以支持 16 个并发渲染作业。
内部（后端）数据库
Looker 服务器会在内部数据库中维护与其自身配置、数据库连接、用户、群组和角色、文件夹、用户定义的 Look 和信息中心以及各种其他数据相关的信息。
对于大小适中的独立 Looker 实例，这些数据存储在 Looker 进程本身嵌入的内存中 HyperSQL 数据库中。此数据库的数据存储在 <looker install directory>/.db/looker.script 文件中。虽然这种数据库方便且轻量，但在高负载情况下会出现性能问题。因此，我们建议您先从远程 MySQL 数据库开始。如果无法实现这一点，我们建议在 ~/looker/.db/looker.script 文件达到 600 MB 时迁移到远程 MySQL 数据库。集群必须使用 MySQL 数据库。
Looker 服务器会对 MySQL 数据库执行许多小型读写操作。每当用户运行 Look 或探索时，Looker 都会检查数据库，以验证用户是否仍处于登录状态、用户是否有权访问数据、用户是否有权运行 Look 或探索等。Looker 还会将数据写入 MySQL 数据库，例如实际运行的 SQL 以及请求的开始时间和结束时间。用户与 Looker 应用之间的一次互动可能会导致对 MySQL 数据库进行 15 到 20 次小型读写。
MySQL
MySQL 服务器应为 8.0.x 版本，并且必须配置为使用 utf8mb4 编码。必须使用 InnoDB 存储引擎。如需了解 MySQL 的设置说明以及如何将数据从现有 HyperSQL 数据库迁移到 MySQL，请参阅将 Looker 后端数据库迁移到 MySQL 文档页面。
配置 Looker 以使用 MySQL 时，必须创建包含连接信息的 YAML 文件。将 YAML 文件命名为 looker-db.yml，并在 lookerstart.cfg 文件的 LOOKERARGS 部分中添加设置 -d looker-db.yml。
MariaDB
MySQL 采用双重许可，既可作为开源产品，也可作为商业产品。Oracle 一直在改进 MySQL，并将 MySQL 分叉为 MariaDB。众所周知，MySQL 的 MariaDB 等效版本可与 Looker 搭配使用，但它们并非由 Looker 工程团队开发或测试；因此，我们不支持或保证其功能。
Cloud 版本
如果您在云基础架构中托管 Looker，则在同一云基础架构中托管 MySQL 数据库是合乎逻辑的做法。三大主要云服务提供商：Amazon AWS、Microsoft Azure 和 Google Cloud。云服务提供商会管理 MySQL 数据库的大部分维护和配置，并提供帮助管理备份和提供快速恢复等服务。以下产品已知可与 Looker 搭配使用。
系统活动查询
MySQL 数据库用于存储有关用户使用 Looker 方式的信息。任何有权查看系统活动模型的 Looker 用户都可以访问多个预构建的 Looker 信息中心，以分析此类数据。用户还可以访问 Looker 元数据的探索，以构建其他分析。MySQL 数据库主要用于执行小型、快速的“操作”查询。系统活动模型生成的大型、缓慢的“分析”查询可能会与这些操作查询竞争，并导致 Looker 运行缓慢。
在这些情况下，MySQL 数据库可以复制到另一个数据库。自行管理型系统和某些云端托管型系统都提供向其他数据库复制的基本配置。配置复制不在本文档的讨论范围内。
为了将副本用于系统 activity 查询，您需要创建 looker-db.yml 文件的副本（例如名为 looker-usage-db.yml），将其修改为指向副本，并将设置 --internal-analytics-connection-file looker-usage-db.yml 添加到 lookerstart.cfg 文件的 LOOKERARGS 部分。
系统活动查询可针对 MySQL 实例或 Google BigQuery 数据库运行。它们未针对其他数据库进行测试。
MySQL 性能配置
除了将 Looker 后端数据库迁移到 MySQL 所需的设置之外，高活跃集群可能还需要进行额外的调整和配置。您可以对 /etc/my.cnf 文件进行这些设置，也可以通过 Google Cloud 控制台（适用于云端管理的实例）进行设置。
my.cnf 配置文件分为以下几个部分。本部分介绍的以下设置更改是在 [mysqld] 部分进行的。
设置 InnoDB 缓冲区池大小
InnoDB 缓冲区大小是用于在内存中存储 InnoDB 数据文件状态的总 RAM 用量。如果服务器专用于运行 MySQL，则应将 innodb_buffer_pool_size 设置为系统总内存的 50%-70%。
如果数据库的总大小较小，则可以将 InnoDB 缓冲区设置为数据库的大小，而不是内存的 50% 或更多。
在此示例中，服务器的内存为 64 GB；因此，InnoDB 缓冲区应介于 32 GB 到 45 GB 之间。通常，分辨率越高越好。
[mysqld] ... innodb_buffer_pool_size=45G
设置 InnoDB 缓冲区池实例
当多个线程尝试搜索大型缓冲区时，它们可能会发生争用。为防止这种情况，缓冲区会被划分为更小的单元，不同的线程可以访问这些单元，而不会发生冲突。默认情况下，缓冲区池会被划分为 8 个实例。这可能会导致 8 个线程出现瓶颈。增加缓冲区池实例数量可以降低出现瓶颈的几率。应设置 innodb_buffer_pool_instances，以便每个缓冲区至少获得 1 GB 的内存。
[mysqld] ... innodb_buffer_pool_instances=32
优化 InnoDB 日志文件
提交事务后，数据库可以选择更新实际文件中的数据，也可以将事务的详细信息保存在日志中。如果数据库在更新数据文件之前崩溃，则可以“重放”日志文件以应用更改。写入日志文件是一项小型附加操作。在提交时附加到日志中，然后将对数据文件的多次更改批量处理，并在单个 IO 操作中写入这些更改，这样做非常高效。当日志文件已满时，数据库必须暂停处理新事务，并将所有更改的数据写回磁盘。
一般来说，InnoDB 日志文件应足够大，能够容纳 1 小时的事务。
通常有两个 InnoDB 日志文件。它们应占 InnoDB 缓冲区池的 25% 左右。对于缓冲区池为 32 GB 的示例数据库，InnoDB 日志文件的总大小应为 8 GB，即每个文件 4 GB。
[mysqld] ... innodb_log_file_size=8GB
配置 InnoDB IO 容量
MySQL 会限制将写入记录到磁盘的速度，以免服务器过载。默认值对于大多数服务器来说都比较保守。为了获得最佳性能，请使用 sysbench 实用程序衡量对数据磁盘的随机写入速度，然后使用该值配置 IO 容量，以便 MySQL 更快地写入数据。
在云托管的系统中，云服务提供商应能够报告用于数据存储的磁盘的性能。对于自托管 MySQL 服务器，请以每秒 IO 操作数 (IOPS) 衡量对数据磁盘执行随机写入的速度。Linux 实用程序 sysbench 就是衡量此类问题的一种方法。将该值用于 innodb_io_capacity_max，并将 innodb_io_capacity 的值设为该值的一半到三分之二。因此，在以下示例中，如果我们测量到 800 IOPS，则会看到相应值。
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
配置 InnoDB 线程
MySQL 会为每个要服务的客户端打开至少一个线程。如果有许多客户端同时连接，可能会导致系统处理大量线程。这可能会导致系统花费在换页的时间比处理时间更多。
应进行基准测试，以确定理想的线程数。如需进行测试，请将线程数设置为介于系统中的 CPU（或 CPU 核心）数量与 CPU 数量的 4 倍之间。对于 16 核系统，此值可能介于 16 到 64 之间。
[mysqld] ... innodb_thread_concurrency=32
事务持久性
将事务值设为 1 会强制 MySQL 针对每笔事务写入磁盘。如果服务器崩溃，事务不会丢失，但数据库性能会受到影响。将此值设置为 0 或 2 可以提高性能，但可能会丢失几秒钟的数据交易。
[mysqld] ... innodb_flush_log_at_trx_commit=1
设置刷新方法
操作系统通常会对写入磁盘的操作进行缓冲。由于 MySQL 和操作系统都进行缓冲，因此会降低性能。减少刷新方法的一层缓冲可以提高性能。
[mysqld] ... innodb_flush_method=O_DIRECT
为每个表启用一个文件
默认情况下，MySQL 将为所有数据使用单个数据文件。innodb_file_per_table 设置会为每个表创建单独的文件，从而提高性能并改善数据管理。
[mysqld] ... innodb_file_per_table=ON
停用元数据统计信息
此设置会停用对内部元数据表的统计信息收集，从而提高读取性能。
[mysqld] ... innodb_stats_on_metadata=OFF
停用查询缓存
查询缓存已废弃，因此将 query_cache_size 和 query_cache_type 设置为 0 可将其停用。
[mysqld] ... query_cache_size=0 query_cache_type=0
扩大联接缓冲区
join_buffer 用于在内存中执行联接。提高该值可以改进某些操作。
[mysqld] ... join_buffer_size=512KB
扩大临时表和堆大小上限
tmp_table_size 和 max_heap_table_size 会在临时内存表被强制写入磁盘之前，为其设置合理的默认值。
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
调整表打开缓存
table_open_cache 设置决定了用于存储打开表的文件描述符的缓存的大小。table_open_cache_instances 设置会将缓存拆分为多个较小的部分。table_open_cache 中可能会出现线程争用，因此将其拆分为更小的部分有助于提高并发性。
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Git 服务
Looker 旨在与 Git 服务搭配使用，以便对 LookML 文件进行版本管理。支持主要的 Git 托管服务，包括 GitHub、GitLab 和 Bitbucket。Git 服务提供商提供额外的增值服务，例如用于查看代码更改的 GUI，以及对拉取请求和更改审批等工作流的支持。如有需要，Git 可以在普通 Linux 服务器上运行。
如果某个 Git 托管服务因安全规则而不适合您的部署，许多此类服务提供商都提供可在您自己的环境中运行的版本。特别是，GitLab 通常是自托管的，可以作为无许可费用的开源产品使用，也可以作为受支持的许可产品使用。GitHub Enterprise 可作为自托管服务提供，是一款受支持的商业产品。
以下部分列出了最常见服务提供商的细微差异。
GitHub/GitHub Enterprise
设置和测试 Git 连接文档页面使用 GitHub 作为示例。
GitLab/gitlab.com
如需了解 GitLab 的详细设置步骤，请参阅 Using GitLab for version control in Looker（在 Looker 中使用 GitLab 进行版本控制）这篇 Looker 社区帖子。如果您的代码库包含在子组中，则可以使用 HTTPS 或 SSH 格式将这些子组添加到代码库网址中：
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
此外，您还可以通过三种不同的方式在 GitLab 中存储 Looker 生成的 SSH 密钥：作为用户 SSH 密钥、代码库部署密钥或全局共享部署密钥。如需更详细的说明，请参阅 GitLab 文档。
Google Cloud 来源
如需了解如何将 Git 与 Cloud Source Repositories 搭配使用，请参阅在 Looker 中使用 Cloud Source Repositories 进行版本控制社区帖子。
Bitbucket Cloud
如需了解使用 Bitbucket Cloud 设置 Git 的步骤，请参阅在 Looker 中使用 Bitbucket 进行版本控制社区帖子。自 2021 年 8 月起，Bitbucket Cloud 不支持部署 webhook 中的 Secret。
Bitbucket Server
如需在 Bitbucket Server 中使用拉取请求，您可能需要完成以下步骤：
- 您打开拉取请求后，Looker 会自动在网址中使用默认端口号 (7999)。如果您使用的是自定义端口号，则需要手动替换网址中的端口号。
- 您需要点击项目的部署 Webhook，以将 Looker 中的生产分支与代码库的主分支同步。
Phabricator 扩散
如需了解如何将 Git 与 Phabricator 搭配使用，请参阅设置 Phabricator 和 Looker 以实现版本控制社区帖子。
网络
传入连接
Looker Web 应用
默认情况下，Looker 会监听端口 9999 上的 HTTPS 请求。Looker 使用 CN 为 self-signed.looker.com 的自签名证书。您也可以将 Looker 服务器配置为执行以下操作：
- 使用
--ssl-provided-externally-by=<s>启动标志接受来自 SSL 终止负载平衡器/代理的 HTTP 连接。该值应设置为代理的 IP 地址，或设置为可在本地解析为代理 IP 地址的主机名。Looker 将仅接受来自此 IP 地址的 HTTP 连接。 - 使用客户提供的 SSL 证书，并设置
--ssl-keystore=<s>启动标志。
Looker API
Looker API 侦听端口 19999。如果安装需要访问 API，则负载平衡器应具有必要的转发规则。与主 Web 应用一样，需要考虑 SSL 问题。我们建议使用与 Web 应用不同的端口。
负载均衡器
负载平衡器通常用于使用客户的证书在端口 443 接受 HTTPS 请求，然后使用自签发证书或 HTTP 将请求转发到端口 9999 的 Looker 服务器节点。如果负载平衡器使用 Looker 自签名证书，则必须将其配置为接受该证书。
空闲连接和超时
当用户在 Looker 中发起大型请求时，可能会导致在数据库上运行查询的费用很高。如果用户以任何方式放弃该请求（例如关闭笔记本电脑的盖子、断开网络连接或终止浏览器中的该标签页），Looker 希望知道并终止该数据库查询。
为了处理这种情况，当客户端 Web 应用发出运行数据库查询的请求时，浏览器将使用长效 HTTP 请求向 Looker 服务器打开套接字连接。此连接将保持打开和空闲状态。如果客户端 Web 应用以任何方式被终止或断开连接，此套接字将断开连接。服务器会看到该断开连接，并取消所有相关的数据库查询。
负载平衡器通常会注意到这些处于空闲状态的打开连接，并将其终止。为了有效运行 Looker，必须将负载平衡器配置为允许此连接在用户可能运行的最长查询期间保持打开状态。建议超时时间至少为 60 分钟。
出站连接
Looker 服务器可以对所有资源（包括公共互联网）拥有不受限制的出站访问权限。这简化了许多任务，例如安装 Chromium，此操作需要访问 Linux 发行版的软件包仓库。
以下是 Looker 可能需要建立的出站连接。
内部数据库连接
默认情况下，MySQL 会监听端口 3306 上的连接。Looker 节点必须能够通过此端口发起与 MySQL 的连接。根据代码库的托管方式，您可能需要穿越防火墙。
外部服务
Looker 遥测服务器和许可服务器可通过 HTTPS 在公共互联网上使用。您可能需要将从 Looker 节点到 ping.looker.com:443 和 license.looker.com:443 的流量添加到许可名单中。
数据仓库连接
托管在云中的数据库可能需要使用公共互联网进行连接。例如，如果您使用的是 BigQuery，则可能需要将 accounts.google.com:443 和 www.googleapis.com:443 添加到许可名单中。如果数据库不在您自己的基础架构中，请咨询数据库主机以了解网络详情。
SMTP 服务
默认情况下，Looker 使用 SendGrid 发送出站邮件。这可能需要将 smtp.sendgrid.net:587 添加到许可名单。您还可以在配置中更改 SMTP 设置，以使用其他邮件处理程序。
操作中心、操作服务器和网络钩子
许多调度程序目的地（尤其是 webhook 以及在 Looker 管理控制台中启用的目的地）都涉及使用 HTTPS 请求发送数据。
- 对于 webhook，这些目的地由用户在运行时指定，可能与防火墙出站连接的目标相悖。
- 对于 Action Hub，这些请求会发送到
actions.looker.com。如需了解详情，请参阅我们的 Looker Action Hub 配置文档。 - 对于其他 Action 服务器，这些请求由管理员在 Looker 管理控制台中发送到 Action 服务器配置中指定的网域。
代理服务器
如果无法直接访问公共互联网，则可以将 Looker 配置为使用代理服务器处理 HTTP(S) 请求，方法是向 lookerstart.cfg 添加类似以下内容的行：
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
请注意，节点间通信是通过 HTTPS 进行的，因此，如果您使用代理服务器且实例是集群的，通常需要将集群中所有节点的 IP 地址/主机名添加到 Dhttp.nonProxyHosts 参数中。
节点间通信
内部主机标识符
在集群中，每个节点都必须能够与其他节点通信。为此，启动配置中指定了每个节点的主机名或 IP 地址。节点启动时，此值将写入 MySQL 代码库。然后，集群的其他成员可以引用这些值来与此节点通信。如需在启动配置中指定主机名或 IP 地址，请将 -H node1.looker.example.com 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。
由于每个节点的主机名都必须是唯一的，因此每个实例上的 lookerstart.cfg 文件也必须是唯一的。除了对主机名或 IP 地址进行硬编码之外，您还可以使用 hostname -I 或 hostname --fqdn 命令在运行时查找这些信息。如需实现此功能，请将 -H $(hostname -I) 或 -H $(hostname --fqdn) 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。
内部端口
除了分别用于 Web 服务器和 API 服务器的端口 9999 和 19999 之外，集群节点还会通过使用端口 1551 和 61616 的消息代理服务相互通信。端口 9999 和 19999 必须对最终用户流量开放，但集群节点之间必须开放端口 1551 和 61616。