作者来自 Elastic Tyler Perkins使用 ES|QL 视图你只需要一个查询即可支持多个仪表板。定义一次让 Elasticsearch 自动保持一切同步。动手体验 Elasticsearch深入了解 Elasticsearch Labs 仓库中的示例 notebooks开始免费的云试用或者现在就在本地机器上尝试 Elastic。Elasticsearch Query Language ES|QL 现在支持逻辑视图。定义一次查询并像索引一样在 FROM 中通过名称引用。十二个仪表板一个定义零复制粘贴。更新视图所有使用方都会自动获得更新。视图不会存储数据它们在每次读取时都会重新执行因此结果始终反映当前数据和当前定义。如果你使用过 SQL 数据库中的视图这会让你感到熟悉。不同之处在于 ES|QL 视图是存储在 Elasticsearch 集群级别的引擎级虚拟索引而不是在客户端展开的已保存查询文本。它们会出现在 Kibana 自动补全中支持跨集群搜索cross-cluster search - CCS 并由专用的基于角色的访问控制 RBAC 权限进行管理。一个简单视图视图可以封装任何 ES|QL 查询。我们从一个简单的过滤开始——来自 API gateway 的 HTTP 500 错误PUT _query/view/error_triage { query: FROM svc-gateway-* | WHERE http.response.status_code 500 | KEEP timestamp, http.response.status_code, url.path, source.ip }现在任何人都可以直接写 FROM error_triage而无需了解索引模式或过滤条件FROM error_triage | STATS error_count COUNT(*) BY url.path | SORT error_count DESC查询只需定义一次使用方通过名称引用。视图通过 _query/view REST API 支持完整的 创建、读取、列出、更新 和 删除 CRUD 操作。更新传播假设团队决定 error_triage 不仅要捕获 500 错误还要包含客户端错误。可以直接原地更新其定义PUT _query/view/error_triage { query: FROM svc-gateway-* | WHERE http.response.status_code 400 | KEEP timestamp, http.response.status_code, url.path, source.ip }每一个使用 FROM error_triage 的仪表板面板、告警规则和临时查询都会立即反映这一更广泛的过滤条件。无需逐个查找已保存对象也不会存在过时的副本。一次更改处处更新。嵌套视图视图可以引用其他视图从而实现分层抽象。你可以分别创建用于可疑 IP 和威胁情报的视图然后将它们组合起来PUT _query/view/suspicious_ips { query: FROM svc-auth-* | WHERE event.action login AND event.outcome failure | STATS attempts COUNT(*), first_seen FIRST(timestamp, timestamp), latest_user LAST(user.name, timestamp) BY source.ip | WHERE attempts 3 } PUT _query/view/known_threats { query: FROM threat-intel } PUT _query/view/security_overview { query: FROM suspicious_ips, known_threats } FROM security_overview | WHERE source.ip IS NOT NULL | EVAL is_known_threat threat.category IS NOT NULL | KEEP source.ip, attempts, threat.category, threat.severity, is_known_threat | SORT is_known_threat DESC, attempts DESC安全团队可以直接查询 FROM security_overview而无需了解底层数据模型。同时他们也不会受到 suspicious_ips 所有者对其所做任何变更的影响这种抽象边界是真正的隔离而不仅仅是语法层面的。多数据源视图与子查询视图可以封装任意 ES|QL 查询包括使用 FROM 子查询的多数据源组合。每个子查询分支都会独立查询一个服务各自的过滤条件、各自的字段规范化结果会自动合并PUT _query/view/all_errors { query: FROM (FROM svc-gateway-* | WHERE http.response.status_code 500 | EVAL service gateway, error_detail CONCAT(HTTP , http.response.status_code::string) | KEEP timestamp, service, error_detail, source.ip), (FROM svc-payments-* | WHERE transaction.status IN (failed, timeout) | EVAL service payments, error_detail transaction.status | KEEP timestamp, service, error_detail, source.ip) }使用方只需要写FROM all_errors | STATS error_count COUNT(*) BY service | SORT error_count DESC两个索引、两个独立流水线、一个名称。要添加第三个服务只需增加第三个分支现有分支不会改变并且所有下游仪表板和告警都会自动反映更新。关于子查询语法以及在每个分支中可以做什么的深入讲解可以参考《三个索引走进一个 FROM 子句》。视图的底层工作方式当你写 FROM view_name 时ES|QL 会解析该视图的存储查询并将其内联执行。视图在每次读取时都会重新执行因此结果始终反映当前数据和当前定义。视图与索引、别名和数据流共享同一个命名空间。视图不能与这些对象同名在创建时会强制校验。这保证了 FROM my_name 的解析始终清晰不会混淆是视图、索引还是别名。安全模型视图由四个专用 RBAC 权限管理create_view、read_view_metadata、delete_view 和 manage_view。Elasticsearch 检查的是执行查询用户的权限调用者安全模型而不是视图创建者的权限。查询视图的用户需要同时拥有视图本身以及其底层索引的权限。Kibana 集成视图会在 Discover 的 ES|QL 编辑器自动补全中显示与索引并列。基于 ES|QL 的仪表板面板可以透明地使用视图。在最初的技术预览版本中视图管理仅支持 API 操作。未来计划在 Kibana 中提供创建和管理视图的 UI。跨集群搜索视图的定义可以使用 CCS 语法引用远程索引PUT _query/view/cross_cluster_errors { query: FROM cluster-west:logs-*, cluster-east:logs-* | WHERE log.level IN (error, crit) }使用方可以直接查询 FROM cross_cluster_errors而无需了解涉及哪些集群。当前限制在技术预览版本中视图管理仅支持 API 操作SET 指令不能出现在视图定义中调用方在查询时再应用这些设置。基于子查询的视图也不能嵌套在其他多数据源 FROM 表达式中。完整限制列表请参考 views 文档。视图的未来方向当前视图始终是实时的每次读取都会重新执行。物化视图则相反先预计算一次再快速读取。可以把它理解为预聚合的 rollup 视图用于 SLA 仪表板使加载速度达到毫秒级而不是每次刷新都扫描原始数据。Kibana 中的视图 CRUD UI包括 Discover 里的 “Save as View” 工作流也在规划中。试用逻辑视图目前处于技术预览阶段可以在 Kibana Dev Tools 或 Discover 中尝试使用。欢迎反馈问题并在 GitHub 提交带 ES|QL 标签的 issue。ES|QL 逻辑视图属于技术预览功能。技术预览功能可能发生变化不受 GA 功能的支持 SLA 保障。本文中描述的任何功能发布与时间安排均由 Elastic 自行决定部分功能可能不会按期交付甚至可能不会提供。原文https://www.elastic.co/search-labs/blog/elasticsearch-esql-logical-views