企业生产应用日志智能分析

1、7ted7企业生产应用日志智能分析简单收集种日志文件HPUXSyslog1,301,670 条日志WebLogicServer Logs1,084,007 条日志DatabaseAlert Logs810,720 条日志通过OnDemand Upload (ODU)的方法人工上载这个日志文件只使用了七个模块中的日志分析模块WebLogicAccess Logs83,878,896 条日志1-Nov-182问题在里，共有到万条日志，有什么潜在问题？1-Nov-183（机器学习的一种），点击自动从万条日志万条日志里找到个潜在问题1-Nov-184操作系统日志分析1-Nov-185次无效用户登入1-

2、Nov-186主要集中在到，每天受到次登入尝试攻击，共次登入尝试攻击来源： 目标： 账号：建议设置告警或拦截这类攻击。1-Nov-187数据库日志分析1-Nov-188问题，上万次的通常是，有没有下补丁？1-Nov-189查询数据库启动日志，我 们发现数据库版本为，大约在年发布，期间已发布 了很多的补丁。1-Nov-1810查询数据库启动日志，我 们发现因为被设定为，被自。对数据库有影响吗？动调节为答案是有的。1-Nov-1811查询数据库启动日志，我 们发现系统审计被关闭1-Nov-1812查询数据库启动日志，我 们发现数据库文件存放位置的告警。As MOS note 2201064.1 s

3、ays:Oracle recommends that DB_RECOVERY_FILE_DEST not same as DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n parameters. A warning will appear in the alert log if it is done.This is harmless warning, can be ignored. But please keep in mind that db_recovery_file_dest is Flash recovery a

4、rea, It is always recommended to put database(controlfile, datafiles, redo) in a different location that is DB_CREATE_FILE_DEST, and better to put archives & backups in recovery location that is DB_RECOVERY_FILE_DEST.1-Nov-1813我们还发现：不能获取更 多空间，可能影响数据库 性能或导致停机。1-Nov-1814可能是目录被删除，不能 备份上的空间不够，进程终止。1-Nov

5、-1815内存不足，进程终止。请 参考1-Nov-1816WebLogic 日志分析1-Nov-1817为什么使用自定义的？不完全支持1-Nov-1818次错误不支持错误1-Nov-1819有做漏洞扫描？还是被扫描？1-Nov-1820HTTP 状态分布1-Nov-1821主要是200撇除200后，主要是304撇除200和304后，主要是404、403和408404403408304200发现部分安全问题1-Nov-1822攻击， 尝试获取密码。失败。1-Nov-1823代码注入攻击，失败。1-Nov-1824客户数据中心OMC整体架构图客户网络代理Proxy用户浏览器 性能数据网关Gatew

6、ay(可选)代理(Agent)数据收集器(可选)协议和端口：https/443外网访问地址https:/./*内网访问网关Gateway server (typically 1830)服务器EM13C服务器服务器应用性能管理安全IT分析日志分析基础实施监控配置与合规编排31OMC的服务模型Customer Firewall日志集中暂存日志脱敏非业务数据Python脚本Log Agent核心应用服务商网络Log AnalyticsHttps: 443,22Cloud Gateway数据分类二次脱敏数据压缩数据上传OMC机器分析报告IT专家分析报告基于人工智能的数字化IT管理应用层技术能力层机器学

7、习算法层基础架构DevOps智能故障修复根因智能定位IT服务管理发现问题数据源异常标记单指标异常检测多指标异常检测定位问题问题关联分析根因分析故障拓扑分析故障链调用树告警去噪解决问题故障止损数据止损配置优化决策支撑成本分析容量计划资源调度AIOps算法层性能指标预测机器聚类KPI联动分析KPI事件关联无监督学习故障特征提取ARIMA卡尔曼时序数据分解Holt-Winters奇异谱变换(SSA)DiDDBSCANPearson相关系数J-Measure随机森林AprioriFP-Growth分类监督学习决策树回归DNNCNNLSTM/RNNNLPRMDB告警事件MQ性能指标NoSQL日志TSDB

8、问题单HDFSJobs作业设备配置库自动容量调整27故障配置性能安全传统运维关注管理效果故障的数量没有改善，甚至不断上升人为事故频发用户体验难以控制，业务投诉多各类木马和勒索病毒难以防范问题出在哪儿？缺少对问题和异常的洞 察和预判，运维管理后 知后觉。对配置的属性以及合规性缺少洞察和管控。缺少用户体验管理，同 时缺乏性能与系统容量 计划的管理缺少统一视图管理和查看各类安全事件。解决方法通过机器学习算法的辅助，提升对IT问 题和异常的洞察力。通过机器预测，提升对性能故障的预警能力实时掌控IT配置的变化，洞察配置的属性及其关联关系。对配置的合规性进行管理，尽可能通过自动化手段进行配置，避免人为事故

9、。通过成熟的技术实时监控用户端的操作和页面响应时延。实时洞察页面错误。构建应用性能和系统容量的模型，消除瓶颈对各类型安全事件进行统一管理，统一分析，统一视图。通过规则库自动发现和定义高危操作， 高危用户和高危资产。IT运维之日常28故障配置性能安全传统运维关注管理效果故障的数量没有改善，甚至不断上升人为事故频发用户体验难以控制，业务投诉多各类木马和勒索病毒难以防范缺少对问题和异常的洞 察和预判，运维管理后 知后觉。对配置的属性以及合规性缺少洞察和管控。缺少用户体验管理，同 时缺乏性能与系统容量 计划的管理缺少统一视图管理和查看各类安全事件。解决方法通过机器学习算法的辅助，提升对IT问 题和异常

10、的洞察力。通过机器预测，提升对性能故障的预警能力实时掌控IT配置的变化，洞察配置的属性及其关联关系。对配置的合规性进行管理，尽可能通过自动化手段进行配置，避免人为事故。通过成熟的技术实时监控用户端的操作和页面响应时延。实时洞察页面错误。构建应用性能和系统容量的模型，消除瓶颈对各类型安全事件进行统一管理，统一分析，统一视图。通过规则库自动发现和定义高危操作， 高危用户和高危资产。IT运维之日常29问题出在哪儿？故障配置性能安全传统运维关注管理效果故障的数量没有改善，甚至不断上升人为事故频发用户体验难以控制，业务投诉多各类木马和勒索病毒难以防范缺少对问题和异常的洞 察和预判，运维管理后 知后觉。对

11、配置的属性以及合规性缺少洞察和管控。缺少用户体验管理，同 时缺乏性能与系统容量 计划的管理缺少统一视图管理和查看各类安全事件。解决方法通过机器学习算法的辅助，提升对IT问 题和异常的洞察力。通过机器预测，提升对性能故障的预警能力实时掌控IT配置的变化，洞察配置的属性及其关联关系。对配置的合规性进行管理，尽可能通过自动化手段进行配置，避免人为事故。通过成熟的技术实时监控用户端的操作和页面响应时延。实时洞察页面错误。构建应用性能和系统容量的模型，消除瓶颈对各类型安全事件进行统一管理，统一分析，统一视图。通过规则库自动发现和定义高危操作， 高危用户和高危资产。IT运维之日常30问题出在哪儿？故障配置性能安全传统运维关注管理效果故障的数量没有改善，甚至不断上升人为事故频发用户体验难以控制，业务投诉多各类木马和勒索病毒难以防范缺少对问题和异常的洞 察和预判，运维管理后 知后觉。对配置的属性以及合规性缺少洞察和管控。缺少用户体验管理，同 时缺乏性能与系统容量 计划的管理缺少统一视图管理和查看各类安全事件。解决方法通过机器学习算法的辅助，提升对IT问 题和异常的洞察力。通过机器预测，提升对性能故障的预警能力实时掌控IT