# 运维中心基本概念 | **基本概念** | **说明** | |:---|:---| | 资源 | 资源是具备一定功能和作用的实例，是部署服务的管理对象，如WiseCloud::MicloudService::NuwaContainer实例、WiseCloud::Cache::DCS实例等。 | | 组件 | 组件是一个具有相同资源的集合，组件具备以下特点： - 可以在组件中声明资源以及资源之间的依赖关系。 - 同一个资源只能属于一个组件。 - 组件下的所有资源上下文一致。 | | 环境 | 环境是一个具有相同组件的集合，环境具有以下特点： - 部署服务代码中的environment-id是"环境"的唯一索引。 - 不同环境下的组件和资源可以同名，同一环境下的资源和组件名称需要保证唯一。 - 一个组件只能属于一个环境，一个环境下会有多个组件。 - 环境变更的本质是环境下组件的变更。 | | 流水线 | 流水线是将多个组件的变更组合起来的流程描述，描述各个组件变更的方式和次序。 | | 变更工单 | 变更工单是实施现网变更的授权许可，业务需要发起现网变更时，通常会由研发人员提交变更电子流，并附上对应的变更文档。该电子流被审批通过后，会在变更工单管理中，创建一条对应的变更工单，运维人员可使用变更工单实施变更。 | | 变更计划 | 变更计划是部署服务发起具体变更动作前的风险影响评估过程。通过风险影响评估过程可以得到，本次变更可能导致的资源动作和属性差异变化，以及可能的风险项。 | | 变更风险项 | 变更风险项是某个资源的具体变更的风险认定。其描述了认定为风险变更的属性变化，以及能够审批允许的审批人列表。 | | 变更电子流 | 变更电子流是用于无人值守变更的高度自动化的变更方式，是在部署服务基础上，尽可能将所有的运维手工选择操作前移到提交电子流之前。 | | Terraform | Terraform是HashiCorp公司开发的基础设施即代码（Infrastructure-as-Code，IaC）软件，它能自动化地进行资源编排，用于安全高效地预览、配置和管理云基础架构和资源，并提供自定义解决方案。 | | 监控 | 是采集、汇总和分析IT基础设施、服务组件以及程序应用的运行指标，以了解其当前状态和运行状况，判断是否安全可靠的过程，是保证业务持续稳定运行的重要手段。 | | 告警 | 告警是监控系统的响应组件，它根据指标值的变化按照既定的策略执行响应操作，其主要目的是引起人们对系统当前状态的关注。告警定义包含基于指标的条件或阈值以及当指标值达到或超出定义条件时要执行的操作。 | | 告警通知 | 告警的通知在所有的告警处理的链路结束以后才会发生。告警处理模块会根据上报告警的上下文获取告警的值班配置，值班配置由业务预置。 | | 告警屏蔽 | 为您提供短时间的屏蔽功能，可以通过设置告警屏蔽的规则，告警将在屏蔽的时间内不再触发任何通知，规则结束后，将会被再次唤醒，屏蔽期间告警被清除后，将不再触发任何通知，减少您的处理频度。 | | 告警过滤 | 告警过滤是直接在接入的阶段就将告警屏蔽，告警仍然会进入Bypass的数据库但不会再向下发送给告警处理模块。 | | 告警收敛 | 多个维度的告警，通过特定的条件将它们变为一条告警，只需要配置自定义的收敛规则，就可以将重复告警收敛到一起，还有默认的规则帮助用户维护告警。 | | 告警标记 | 告警标记的作用是为一段时间内的告警打上标签，例如现网变更或者现网演练时，由于要模拟大量异常请求和其他操作会造成大量无用告警上报，标记的作用就是为这一段时间的告警打上标签与正常告警进行区分。 | | 告警定义 | 对于繁琐复杂的告警上报字段感到困惑，使用统一定义，将会自动下发到业务对应的agent，更加人性化的界面设计，使告警上报更加统一、准确。 | | 告警修复 | 设置特定的命中条件，告警在发送通知之前会执行预置的修复脚本，进行修复操作，自动帮你修复简单的告警。 | | 语音值班配置 | 当告警生成时，配置对应的责任人，通过WeLink、短信、电话等多种形式，快速将异常情况通知到责任人。 | | 日志 | 日志是指设备、系统或服务程序在运作时都会产生的事件记录，每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。一般系统会有各种各样的日志文件，如应用程序日志，安全日志、系统日志、Scheduler服务日志、WWW日志、DNS服务器日志等。 | | 日志项目 | 日志项目是一个包含多个日志服务配置的整体，可以看作是一个微服务实例。 - 同一个微服务实例下的日志服务配置应当包含在一个日志项目中。 - 不同微服务实例使用完全相同的日志服务配置时，也可以共用同一个日志项目。 | | 日志空间 | 日志空间是日志服务为微服务的日志分配的使用空间。 业务须在日志接入页面填写日志相关信息并提交申请日志空间，日志空间支持定义空间内日志的结构化格式信息，此时要求所有使用此空间的日志都满足该日志格式。 | | 日志采集配置 | 日志采集配置是日志服务采集端在采集微服务实例中日志时所需的配置，一种日志对应一项采集配置。 日志采集配置须归属于一个日志项目，并使用一个已分配好的日志空间。 日志采集配置之间可以共用日志空间，此时需要关注日志空间的日志格式要求，未定义日志格式的空间可不用关注。 | | 事件 | 事件是指IT基础设施、服务组件以及程序应用等运行过程中发生的问题。事件可通过监控系统自动生成、客户报障生成或SRE主动巡检生成等。监控系统生成事件首先要采集和分析运行数据，然后根据预定规则判断是否需要生成事件。 | | HCW | HW Cloud Watch，AppStage运维中心提供的监控系统，也称为云眼，可以提供监控、告警功能。 | | HCW Agent | 监控系统的采集框架，需要在每台主机上部署，部署路径为/opt/huawei/HCW_Agent。 | | EAP | 事件自动化平台（Event \& Action Platform，EAP），通过集成各系统动作，解决复杂运维场景的操作编排功能。 | | 流程 | 可以通过EAP平台所提供的各种动作组合来编排解决具体运维场景的流程。 | | 动作 | 各服务的操作（例如部署任务、执行作业、确认告警等）封装。 | | 标签 | 对某一类特定群体或对象的某项特征进行的抽象分类和概括，其值（标签值）具备可分类性。 | | 标签树 | 标签树负责标签的管理，包括标签的创建，删除，修改。系统标签由系统管理员统一进行管理，业务自定义标签由业务人员进行管理。 | | 逻辑主体 | 逻辑主体是业务实体的抽象，是基于物理表（MPPDB、ClickHouse、Influxdb）创建。逻辑主体和物理表之间存在映射关系，逻辑主体的字段名称和物理表可以不一样，这也是为了实现业务属性和物理表之间的解耦。 一个逻辑主体可以映射多种物理实体，当底层数据物理表变更，上层的指标逻辑定义可以不用发生变化。 | | 指标 | 指标是指在被观测系统中观察和收集的资源使用或行为的测量值，可能是原始采集的数据，也可能是后期经过各种计算和统计方法得到的数值。 | | 令牌 | 令牌是使用数据源的鉴权方式，只有通过对应业务的token的鉴权，才能使用对应的数据源。 | | 视图 | 指标本身包含了业务计算规则，只有结合数据源才能真正被查询。视图是指标 + 物理表的结合，也是监控报表上直接可被查询的对象。视图可以包含一个或多个指标，例如折线图只需要单指标的视图，但是表格就需要多指标的视图。 - 查询视图(Query View)。直接作用于物理表的查询视图，大多用在druid实时监控场景。 - 长期存储视图(Long Term View)。基于查询视图，可以创建长期存储视图。如果觉得某个查询视图值得被长期持久化，就可以使用该能力。长期存储视图会自动创建三个聚合任务，分别是5分钟粒度、小时粒度、天粒度。 - 持久化视图(Persistent View)。基于查询视图，可以创建持久化视图。部分视图需要出日报，就可以使用该能力。该视图会自动创建一个汇聚任务。 - 异常检测视图(Anomaly Detect View)。基于查询视图，可以创建异常检测视图，用来为异常检测任务提供数据。 | | 插件 | 可在机器上执行并采集各项参数的二进制文件或者脚本。 | | 微服务 | 微服务是云原生应用的最佳架构， 它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个微服务运行在其独立的进程中， 微服务与微服务间采用轻量级的通信机制互相沟通。每个微服务由全功能团队独立构建、独立测试，并且能够被独立地部署到生产环境。微服务的特点：组件化、松耦合、服务自治、去中心化。 | | 应用 | 完成某项完整业务场景的软件系统。应用一般由多个微服务组成，应用里面的微服务能够相互发现和调用。 | | NUWA框架 | NUWA提供一个完整的微服务开发框架，是一个开箱即用的应用级容器，以插件的形式汇聚云服务平台能力，让开发把时间更多地花在业务代码逻辑上。 | | Kubernetes | Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署、规划、更新、维护的一种机制。 | | Pod | Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。 | | Node | Node是一个执行具体工作的机器，可以是虚拟机或者物理机。Pod是部署在Node节点上的，如果Node故障，整个Pod会被调度到集群中的另外可用的Node节点上去。 | | 工作负载 | 工作负载是在Kubernetes上运行的应用程序。无论您的工作负载是单个组件还是协同工作的多个组件，您都可以在Kubernetes上的一组Pod中运行它。在Kubernetes中，工作负载是对一组Pod的抽象模型，用于描述业务的运行载体，包括Deployment、StatefulSet、DaemonSet、Job、CronJob等多种类型。 - 无状态工作负载：即Kubernetes中的"Deployment"，无状态工作负载支持弹性伸缩与滚动升级，适用于实例完全独立、功能相同的场景，如：nginx、wordpress等。 - 有状态工作负载：即Kubernetes中的"StatefulSet"，有状态工作负载支持实例有序部署和删除，支持持久化存储，适用于实例间存在互访的场景，如ETCD、mysql-HA等。 - 创建守护进程集：即Kubernetes中的"DaemonSet"，守护进程集确保全部（或者某些）节点都运行一个Pod实例，支持实例动态添加到新节点，适用于实例在每个节点上都需要运行的场景，如ceph、fluentd、Prometheus Node Exporter等。 - 普通任务：即Kubernetes中的"Job"，普通任务是一次性运行的短任务，部署完成后即可执行。使用场景为在创建工作负载前，执行普通任务，将镜像上传至镜像仓库。 - 定时任务：即Kubernetes中的"CronJob"，定时任务是按照指定时间周期运行的短任务。使用场景为在某个固定时间点，为所有运行中的节点做时间同步。 |