告警日志关联分析案例（告警日志英文）

本篇文章给大家谈谈告警日志关联分析案例，以及告警日志英文对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享告警日志关联分析案例的知识，其中也会对告警日志英文进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、关于 CIsco 告警日志分析
• 2、基于大数据审计的信息安全日志分析法
• 3、终端安全管理的终端安全管理经典案例
• 4、oracle数据库的警告日志如何查看

关于 CIsco 告警日志分析

很明显是生成树在搞怪嘛...
一个高速交换网络是否稳定取决于生成树告警日志关联分析案例的变化.
本来fa0/1属于vlan190.但是有一个vlan540接入告警日志关联分析案例了.交换机告警日志关联分析案例的生成树认为网络出现变化.就立即阻塞告警日志关联分析案例了fa0/1.并且提示告警日志关联分析案例你vlan540不是本来就有的VLAN.

基于大数据审计的信息安全日志分析法

噪声数据随着经济和信息技术的不断发展，许多企业开始引入了ERP等系统，这些系统使得企业的众多活动数据可以实时记录，形成了大量有关企业经营管理的数据仓库。从这些海量数据中获取有用的审计数据是目前计算机审计的一个应用。接下来我为你带来基于大数据审计的信息安全日志分析法，希望对你有帮助。

大数据信息安全日志审计分析方法

1．海量数据采集。

大数据采集过程的主要特点和挑战是并发数高，因此采集数据量较大时，分析平台的接收性能也将面临较大挑战。大数据审计平台可采用大数据收集技术对各种类型的数据进行统一采集，使用一定的压缩及加密算法，在保证用户数据隐私性及完整性的前提下，可以进行带宽控制。

2．数据预处理。

在大数据环境下对采集到的海量数据进行有效分析，需要对各种数据进行分类，并按照一定的标准进行归一化，且对数据进行一些简单的清洗和预处理工作。对于海量数据的预处理，大数据审计平台采用新的技术架构，使用基于大数据集群的分布式计算框架，同时结合基于大数据集群的复杂事件处理流程作为实时规则分析引擎，从而能够高效并行地运行多种规则，并能够实时检测异常事件。

3．统计及分析。

按照数据分析的实时性，分为实时数据分析和离线数据分析。大数据平台在数据预处理时使用的分布式计算框架Storm就非常适合对海量数据进行实时的统计计算，并能够快速反馈统计结果。Storm框架利用严格且高效的事件处理流程保证运算时数据的准确性，并提供多种实时统计接口以使用。

4．数据挖掘。

数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识，所以它所得到的信息具有未知、有效、实用三个特征。与传统统计及分析过程不同的是，大数据环境下的数据挖掘一般没有预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测的效果，并进一步实现一些高级别数据分析的需求。

大数据分析信息安全日志的解决方案

统一日志审计与安全大数据分析平台能够实时不间断地将用户网络中来自不同厂商的安全设备、网络设备、主机、操作系统、数据库系统、用户业务系统的日志和警报等信息汇集到管理中心，实现全网综合安全审计；同时借助大数据分析和挖掘技术，通过各种模型场景发现各种网络行为、用户异常访问和操作行为。

1．系统平台架构。

以国内某大数据安全分析系统为例，其架构包括大数据采集平台、未知威胁感知系统、分布式实时计算系统(Storm)、复杂事件处理引擎(Esper)、Hadoop平台、分布式文件系统(HDFS)、分布式列数据库(Hbase)、分布式并行计算框架(Map／Reduce、Spark)、数据仓库(Hive)、分布式全文搜索引擎(ElasticSearch)、科学计算系统(Euler)。这些技术能够解决用户对海量事件的采集、处理、分析、挖掘和存储的需求。

如图1所示，系统能够实时地对采集到的不同类型的信息进行归一化和实时关联分析，通过统一的控制台界面进行实时、可视化的呈现，协助安全管理人员迅速准确地识别安全事件，提高工作效率。

2．实现功能。

系统能够实现的功能包括：审计范围覆盖网络环境中的全部网络设备、安全设备、服务器、数据库、中间件、应用系统，覆盖200多种设备和应用中的上万类日志，快速支持用户业务系统日志审计；系统收集企业和组织中的所有安全日志和告警信息，通过归一化和智能日志关联分析引擎，协助用户准确、快速地识别安全事故；通过系统的'安全事件并及时做出安全响应操作，为用户的网络环境安全提供保障；通过已经审计到的各种审计对象日志，重建一段时间内可疑的事件序列，分析路径，帮助安全分析人员快速发现源；整个Hadoop的体系结构主要通过分布式文件系统(HDFS)来实现对分布式存储的底层支持。

3．应用场景。

上述系统可解决传统日志审计无法实现的日志关联分析和智能定位功能。如在企业的网络系统中，大范围分布的网络设备、安全设备、服务器等实时产生的日志量非常大，要从其中提取想要的信息非常困难，而要从设备之间的关联来判断设备故障也将是一大难点。例如，某企业定位某设备与周围直连设备的日志消息相关联起来判断该设备是否存在异常或故障，如对于其中一台核心交换机SW1，与之直连的所有设备如果相继报接口down的日志，则可定位该设备SWl为故障设备，此时应及时做出响应。而传统数据难以通过周围设备的关联告警来定位该故障，大数据审计平台则是最好的解决方法。

大数据分析方法可以利用实体关联分析、地理空间分析和数据统计分析等技术来分析实体之间的关系，并利用相关的结构化和非结构化的信息来检测非法活动。对于集中存储起来的海量信息，可以让审计人员借助历史分析工具对日志进行深度挖掘、调查取证、证据保全。

终端安全管理的终端安全管理经典案例

近年来，税务行业在信息化建设上突飞猛进，信息化服务能力也有了更进一步的提升，在建设逐渐完善的业务系统过程中，伴随而来的是信息的安全、有效、合理的监管问题，怎么管理好与业务系统相伴的安全问题，是关系到整个税务行业信息化建设进一步发展的重要因素。
某省地税局作为税务行业信息化建设的领先者之一，近年在安全建设上取得了一系列重大突破，各地市征管系统顺利完成了由地级市集中处理模式向省级集中处理模式的转换。省级大集中系统的全面上线，标志着江苏地税税收管理最重要的省级一体化信息平台初步建成。随着征管系统的管理机构、工作模式、岗位职责、人员分工等变化，征管系统面临的安全风险也发生了变化。从以往各地的风险仅仅是局部影响，到现在的互动影响，各地问题相互交替，范围扩大，继而影响全省；出现了各地小风险会导致全局大风险，甚至可能演变成全省灾难性风险。为了能够系统地研究分析各地自身终端信息安全，从而达到保证省级大集中系统安全的目的，依据目前安全规范要求，更需要重点关注大集中后各地终端运行安全和信息安全管控，关注应急防范处置，解决安全认识不到位、技术手段的管控力度低、信息资料的定密不清、外来人员的监控不力等问题，而基于人工方式对出现的问题和风险进行排查和处置，已无法解决人手少、范围广、事件多的困难局面，更无法适应面对全省征管大集中新形势下的终端安全需要。
为解决出现的安全管理问题，某省地税计划建立终端安全管理体系，建设终端安全防护平台和终端安全管理平台，逐步形成具有地税特色的功能成熟并能切实发挥作用的终端安全防护和管理平台，促进业务与安全的协调发展，满足省级大集中后全省信息安全有效管控的需要。 在安全教育培训、技术防范、规章制度建立、安全检查评估及整改等方面做了大量的工作，在一定程度上提高了终端安全管理水平。但是，终端系统数量大、应用多，加之安全管理人员少，缺乏完备的技术手段，无法掌握终端安全风险状况，安全管理人员难以对真正紧急的事件进行快速响应。
因此，该地税系统需要建立终端安全管理体系，通过完善相关管理制度、流程、规范组织机构职责、构建终端安全防护和安全管理平台实现以下终端安全管理功能：
实时对内网终端的软硬件、移动介质、接入访问、补丁更新、病毒防范等状况进行统一监控； 实现对终端资产全生命周期的管理； 采集终端安全相关安全事件和日志信息、进行整合和关联分析，提供终端安全态势展示； 评估终端安全风险，实现终端全生命周期的安全风险管理； 审计终端用户行为，重点实现对第三方接入终端的用户行为审计； 产生安全事故和告警，提供自动告警和响应手段； 接收并处理相关单位发来的终端相关的安全预警； 生成各种安全报告并及时进行应急响应； 进行终端相关安全知识管理； 为相关部门的信息安全审计和考核提供技术手段和依据，实现全内网终端系统的安全集中监控、审计和应急响应，全面提升该系统内网终端安全管理能力，提升该系统整体信息安全保障能力。 终端安全防护和安全管理平台将是该系统信息安全管理团队非常必要的技术支撑系统之一。 基于终端安全防护和安全管理平台的建设落实在该终端安全管理体系内，实现终端安全管理工作的信息化，为全省终端安全管理提供技术手段，提高终端安全管理、维护的水平，优化终端安全工作流程，缩短终端安全事件处理的响应处理时间，进而保障全省税务业务网络、支撑网络、业务系统以及整个信息化系统安全高效的运行，系统有如下的建设方向与目标：
搭建终端安全防护和安全管理平台，实现三级机构终端管理； 建设终端安全管理体系的基本组织框架，确保终端安全管理相关工作的有效落实； 推进内网终端安全管理标准化：对内网终端的安全访问、非法内联、非法外联、补丁更新、桌面管理、病毒防范等安全策略进行标准化管理。 推进安全事件管理规范化：对安全事件的采集，汇总及处理规范化管理，规范安全事件的响应措施。 终端安全策略框架和策略脚本建立，构建符合安全策略的基本运作流程，结合终端安全防护和管理平台实现内网终端安全维护管理流程化：对终端安全实施设备及使用的全生命周期管理、风险全过程管理和重要风险系统管理，并配合行政管理，实现终端安全管理流程化管理。 终端安全态势可视化：对各类安全事件进行统一展现，从各种不同角度进行分析，针对不同的安全事件，提供安全预警分析。 推进内网终端运行管理自动化：增强终端管理的自动化，事件响应自动化，安全告警管理和安全工单自动派发。Oslash; 实现内网终端运行管理指标化：对终端安全事件量化处理，实现终端运行监测点及相关考核指标标准化。 该系统安全管理平台建设从三个层面考虑：终端安全防护平台、终端安全管理平台、终端安全防护体系。
终端安全防护平台负责终端信息的采集和维护、终端安全风险的管理和防护、终端安全事件的监测和控制，为管理平台提供所需要的各类数据的采集和传输。实现各类安全事件的“事前防范、事中防御、事后处理”的立体化、流程化防御。是构建综合的、完整的内网终端安全防护体系的基础。
终端安全管理平台在终端安全防护平台提供的数据基础上，提供安全管理人员（系统管理员、安全主管）所需要的管理、监控、风险分析功能，各类管理报表的制作，同时满足省、市、县分布式环境下的行业安全管理要求。是构建完整的终端内网安全管理体系的技术支撑平台。
终端安全管理体系由终端安全组织体系、终端安全运作体系、终端安全策略体系和终端安全技术体系构成。其中终端安全技术体系主要由终端安全防护平台和终端安全管理平台构成。
终端安全防护平台是核心组件，是终端安全管理体系的基础部件。
终端安全管理平台在采取集中监控管理的方式，在更高层面上接收来自终端安全防护平台的安全事件和安全风险监测数据，负责对这些事件进行深层的分析，统计和关联，提供处理方法和建议。
防护平台和管理平台采用联合部署的方式，可以通过同机或者双机的方式进行部署，联合实现终端安全风险管理的有效控制。由于江苏地税的行业特性和网络结构，决定了在不同的网络类型上采用不同的部署方式和部署要求。在部署方式上，同机部署适用于小型网络（区县级网络），双机部署适用于中型网络（县市级网络），多级联合部署适用于大型网络（省市级网络），因为不同的网络级别安全性保障要求也不同。
该终端安全管理体系平台的总体结构如图所示。系统由3个层次组成，包括省局、地市局（园区）和县局（保税区）终端安全防护与安全管理平台。
3个层次组成树形结构，从逻辑上看，省局中心节点只有1个，地市局节点共15个（其中包括13个地市局、省局自身管理和苏州园区），县节点共68个（其中包括67个县和1个保税区）；各地市局节点连接到省局中心节点，各县节点连接到所属地市局节点
图13-3 该终端安全防护与管理系统总体部署示意图
省局中心节点：最顶层是省局终端安全防护与安全管理平台，其中省局终端安全防护平台管理全省统一安全策略，省局终端安全管理平台不仅基于省局终端安全防护平台管理省局内网终端，而且是全省终端安全管理平台的总中心，负责全局终端安全策略的管理和下发，接收全局上报信息，具有全省数据综合分析和与其他系统协同联动的功能。
地市局节点：负责本地市内终端的安全防护和安全管理工作，同时对所管辖的下级县局安全防护平台和安全管理平台有监管功能，具体包括接收省中心策略配置或进行本地配置，收集监控信息并产生事件并上报，同时具有数据分析的能力。
县局节点：负责本县内终端的安全防护和安全管理工作，包括接收省中心和地市局中心策略配置或进行本地配置，收集监控信息并产生事件并上报，同时具有一定的数据分析的能力。
认证授权策略中心：负责全网所有的认证、授权、策略信息，所有服务器的管理角色集中在一起，由省级配发区域管理权限，区域根据自身情况进行使用者信息的管理，并且对于所有使用者信息进行区域化限定。既满足全网管理要求的统一性，又兼顾了本地管理的灵活性，统一性保障终端信息与使用者信息，以及风险信息在全网是一致的，灵活性保障管理角色和使用者具备本地管理属性。对所有节点的认证进行统一维护和备份，当任意节点的服务器出现故障，可以直接从认证中心恢复认证信息。对所有节点的策略信息进行集中管控，可以保障全省安全策略的统一，也支持全省策略的地区差异化，并且上级可以掌握下级差异化的管理详情。
所有节点都与它的父节点、中心节点以及所有的子节点进行通信。中心节点用于统一安全策略，所有节点根据策略的性质配发适用的范围，父节点能够对所有的子节点进行管理和查询，包括策略应用情况、终端安装情况、补丁安装情况查询和报警信息等，如果下级有选配管理中心，还可以对其进行在线考核。每个节点的认证和策略都是本地配置，这些本地配置将只影响本地的终端安全防护，不影响上级或者平级部署的平台，同时由于这些信息都在中心节点备份，所有可以实时进行同步和恢复。
在管理上漫游属于特殊情况，分为两种：资产漫游和人员漫游。
人员漫游比较常见，在现有的部署方案中，人员漫游可以采用人员的管理链接方式，即人员的管理属性不变，还是由其直属上级进行管理，但是资源属性支持共享，即漫游地的上级也可以查看他的属性，并且可以对其的认证和授权信息进行分配。
资产漫游分为两种：借用和设备调拨。借用时，保持资产的原有信息借用到另外区域，终端在两地的信息都会汇总到上级，而上级进行统计和分析的时候，该终端发生的所有事件都是前后关联在一起的。设备调拨时，根据规定会结束原有的生命周期，重新按照流程入网。 通过该税务系统单位与我国信息安全领先厂商天融信共同构建的终端安全管理系统，按照终端安全防护平台、终端安全管理平台、终端安全防护体系三层结构模型的建设，达到了终端风险可管、可控，安全状态可视的效果：
实现内网终端的“全程全网”安全状态可视化（Visualization）。体现在三级机构的内网终端系统相关安全状态信息可以非常直观地可视化监视，安全策略执行情况可感可知，有能力进行事后的分析和追查，提供可以“呈堂”的证据。
内网终端的安全风险处于可管理、可控制状态下。对内网终端系统安全风险的不间断的评估和控制措施调整，使得全内网终端的整体安全状况和风险情况以定性或半定量的形式及时展现出来。帮助安全管理层和终端安全管理维护人员清晰、准确、及时的了解终端所处的风险状况。
使全网的安全保障能力处于国内领先地位。在病毒爆发、违规操作以及其它不可预见的威胁出现时，内网终端安全防护和管理系统有能力及时发现，并迅速的进行响应和恢复，保障业务工作的正常运行。
保证内网终端相关业务活动在网络安全方面的法律法规符合性。规范、管理和审计内网终端安全状态和用户的行为，在整个体系中将建立法律法规符合性审核制度，保证终端系统安全管理工作的有效性，终端系统合法合规的使用。

oracle数据库的警告日志如何查看

‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 24h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 24h，排除第三条。那问题出在什么地方呢？

分析

下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

metric 数据

告警规则

将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

请点击输入图片描述

请点击输入图片描述

首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

capacity（默认值为 10000）：控制缓冲队列的大小，

maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数

了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn，实体上的告警规则数量分别有 y1、y2、y3、...、yn，那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize = (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

注意事项

上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

‍‍

关于告警日志关联分析案例和告警日志英文的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 告警日志关联分析案例的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于告警日志英文、告警日志关联分析案例的信息别忘了在本站进行查找喔。