本页探讨了 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 更新 161 及更高版本或 Java OpenJDK 11.0.12 及更高版本。
CPU 和内存
4x16（4 个 CPU 和 16 GB RAM）节点足以满足开发系统或小型团队使用的基本测试 Looker 实例的需求。不过，对于生产用途，这通常是不够的。根据我们的经验，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 的机器，我们建议为 Java 分配 4-5 GB 内存，为 Meta 分配 800 MB 内存。对于较大的机器，可以为操作系统分配较低比例的内存。例如，对于总内存为 60 GB 的机器，我们建议为 Java 分配 36 GB，为 Meta 分配 1 GB。请务必注意，Java 的内存分配通常应随机器的总内存而扩展，但 Meta 应该在 1 GB 时就足够了。
此外，由于 Looker 会与 Chromium 等其他进程共享系统资源以进行渲染，因此分配给 Java 的内存量应根据预期的渲染负载和机器大小来选择。如果预计渲染负载较低，则可以为 Java 分配更大的总内存份额。例如，在一台总内存为 60 GB 的机器上，可以安全地为 Java 分配 46 GB 的内存，这高于一般建议的 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 环境变量。如果没有调度器线程，则不会在这些节点上运行任何已调度的作业。
对于所有专用调度器节点，请在 lookerstart.cfg 中将 --scheduler-threads=<n> 添加到 LOOKERARGS 环境变量。Looker 默认以 10 个调度程序线程启动，但可以增加到 <n>。借助 <n> 个调度程序线程，每个节点将能够执行 <n> 个并发的调度作业。一般建议将 <n> 保持在 CPU 数量的 2 倍以下。建议的最大主机配置为 16 个 CPU 和 64 GB 内存，因此调度程序线程的上限应小于 32。
高渲染吞吐量选项
对于所有非渲染节点，请在 lookerstart.cfg 中将 --concurrent-render-jobs=0 添加到 LOOKERARGS 环境变量。如果没有渲染器节点，这些节点上将不会运行任何渲染作业。
对于所有专用渲染节点，请在 lookerstart.cfg 中将 --concurrent-render-jobs=<n> 添加到 LOOKERARGS 环境变量。Looker 默认使用两个渲染线程，但可以增加到 <n>。使用 <n> 个渲染线程时，每个节点将能够执行 <n> 个并发渲染作业。
每个渲染作业都会使用大量内存。每个渲染作业的预算约为 2 GB。例如，如果核心 Looker 进程 (Java) 分配了总内存的 60%，并且剩余内存的 20% 预留给了操作系统，那么最后 20% 的内存将用于渲染作业。在 64 GB 的机器上，这会留下 12 GB，足以同时运行 6 个渲染作业。如果某个节点专用于渲染，并且未包含在处理交互式作业的负载均衡器池中，则可以减少核心 Looker 进程内存，以允许更多渲染作业。在 64 GB 的机器上，用户可能会为 Looker 核心进程分配大约 30% (20 GB) 的内存。预留 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 工程团队开发或测试，因此不支持或不保证其功能。
云版本
如果您在云基础架构中托管 Looker，那么在同一云基础架构中托管 MySQL 数据库是合乎逻辑的。三大主要云供应商 - Amazon AWS、Microsoft Azure 和 Google Cloud。云提供商会管理 MySQL 数据库的大部分维护和配置，并提供备份管理和快速恢复等服务。已知这些产品可与 Looker 搭配使用。
系统活动查询
MySQL 数据库用于存储有关用户如何使用 Looker 的信息。任何有权查看系统活动记录模型的 Looker 用户都可以访问许多预构建的 Looker 信息中心来分析这些数据。用户还可以访问 Looker 元数据的探索，以构建其他分析。MySQL 数据库主要用于小型、快速的“操作型”查询。系统活动模型生成的大型慢速“分析”查询可能会与这些操作查询竞争，从而降低 Looker 的运行速度。
在这些情况下，MySQL 数据库可以复制到另一个数据库。无论是自行管理的系统还是某些云端管理的系统，都提供复制到其他数据库的基本配置。配置复制不在本文档的讨论范围内。
为了使用副本进行系统活动查询，您将创建 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 和操作系统都在缓冲，因此会造成性能损失。减少一层缓冲的 flush 方法可以提高性能。
[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，以及对拉取请求和更改审批等工作流程的支持。如果需要，可以在纯 Linux 服务器上运行 Git。
如果 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 来源
如需了解如何通过 Cloud Source Repositories 设置 Git，请参阅在 Looker 中使用 Cloud Source Repositories 进行版本控制社区帖子。
Bitbucket Cloud
如需了解如何使用 Bitbucket Cloud 设置 Git，请参阅在 Looker 中使用 Bitbucket 进行版本控制社区帖子。截至 2021 年 8 月，Bitbucket Cloud 不支持部署 webhook 上的密钥。
Bitbucket Server
如需将拉取请求与 Bitbucket Server 搭配使用，您可能需要完成以下步骤：
- 当您打开拉取请求时，Looker 会自动在网址中使用默认端口号 (7999)。如果您使用的是自定义端口号，则需要手动替换网址中的端口号。
- 您需要调用项目的部署 Webhook，以将 Looker 中的生产分支与代码库的主分支同步。
Phabricator diffusion
如需了解如何将 Git 与 Phabricator 搭配使用，请参阅设置 Phabricator 和 Looker 以进行版本控制社区帖子。
网络
入站连接
Looker Web 应用
默认情况下，Looker 会侦听端口 9999 上的 HTTPS 请求。Looker 使用 CN 为 self-signed.looker.com 的自签名证书。Looker 服务器也可以配置为执行以下操作：
- 接受来自 SSL 终止负载均衡器/代理的 HTTP 连接，并使用
--ssl-provided-externally-by=<s>启动标志。该值应设置为代理的 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，这些目的地由用户在运行时指定，可能与防火墙的出站连接目标相悖。
- 对于操作中心，这些请求会发送到
actions.looker.com。如需了解详情，请参阅我们的 Looker Action Hub 配置文档。 - 对于其他操作服务器，这些请求会由管理员在 Looker Admin 面板中发送到操作服务器配置中指定的网域。
代理服务器
如果无法直接访问公共互联网，则可以通过向 lookerstart.cfg 添加如下所示的行，将 Looker 配置为使用代理服务器来处理 HTTP(S) 请求：
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 必须在集群节点之间开放。